Iot решения – Архитектура IoT-решения на реальном примере / Microsoft corporate blog / Habr

Архитектура IoT-решения на реальном примере / Microsoft corporate blog / Habr

Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV). В этом выпуске технический директор компании «ИНПРОСИСТЕМ» AlexandrSurkov рассказывает об опыте разработки архитектуры охранной IoT-системы СеСМИК.

Многие считают, что понятие «Интернета вещей» неразрывно связано с сетью, которой мы пользуемся каждый день. Можно представить себе картину, где множество устройств, объединенных в единое целое через глобальную сеть, обмениваются данными между собой и серверами и создают цифровую картину мира. В данной статье я расскажу о том, как мы делали систему, объединяющую сотни датчиков.

Понятие «интернет» стоит рассматривать гораздо шире. В данном случае это общая для устройств сеть. Она может содержать 10 устройств, а может и 10 000. Может быть проводная, а может быть беспроводная. Может располагаться в одной комнате, а может охватывать несколько стран. Все зависит от задач, которые ставятся перед системой.

При этом создание даже небольшой сети устройств сопровождается множеством трудностей.

Постановка задачи

Нам была поставлена задача по разработке системы охраны периметра. Периметр — это забор, окружающий некоторый объект. Его длина ничем не ограничена.

Система создавалась с нуля. К моменту начала проектирования существовал прототип датчика, способного собирать колебания периметра, проанализировав которые, можно было четко определить факт преодоления или разрушения забора. Опытным путем мы определили, что датчики нужно ставить примерно через каждые 10 метров.

Кроме датчиков планировались еще управляющие устройства с реле и управляемые устройства с «сухим контактом». Система должна работать в уличных условиях при широком диапазоне температур и погодных явлений.

Итак, имеется:

  • 3 типа устройств;
  • Минимум 100 устройств на километр;
  • Количество километров не ограничено;
  • Система должна иметь уличное исполнение.

Сразу можно выделить главные вопросы по архитектуре:

  • Организация передачи данных и питания;
  • Распределение потоков информации: где и как анализировать данные;
  • Безопасность решения: какие протоколы использовать;
  • Как управлять таким количеством устройств.

Общая схема решения

Clemens Vasters написал прекрасную статью о том, с чем сталкивается разработчик системы «Интернета вещей». Эти же проблемы пришлось решать и нам.

Многие решения диктовались ГОСТами и другими требованиями к таким системам. Но многое пришлось придумывать самим.

Сперва нужно было понять, как распределить информационные потоки в системе. Для анализа колебаний использовалась как временная, так и частотная составляющая. Диапазон частот от 0 до 500 герц. Значит, замеры нужно делать 1000 раз в секунду. Каждое измерение делаются по 3 осям по 10 бит на каждую.

Итого 3*10*1000 = 30 килобит в секунду только от одного датчика. На километр (100 датчиков) это уже 3 мегабита.

Передать то эти данные можно, но как их обрабатывать? Периметр в 10 км давал бы уже 30 мегабит данных в секунду. Получается, что нагрузка на сервер возрастает с увеличением количества устройств.

Было принято решение, что каждый датчик будет обрабатывать данные сам и отдавать только факты тревог. Это значительно снизило объем данных и распределило вычислительную нагрузку.

Организация сети была выбрана проводная из-за того, что беспроводная требует батареи. Так как система у нас реального времени, то срок жизни батареи будет очень маленький. Кроме того, отрицательные температуры сильно уменьшают емкость питающих элементов. Да и заглушить беспроводную связь относительно легко, а это уже является очень существенным недостатком для системы безопасности.

ГОСТы запрещают прокладывать по ограждению 220В, поэтому “питаться” наши устройства будут от постоянного напряжения.

В качестве архитектуры сети мы выбрали шину. Это позволило не тянуть провод к каждому датчику.

Однако шина накладывает ограничение на длину сети и количество устройств. Поэтому было введено новое устройство: шлюз. Он имеет 2 шины, занимается менеджментом устройств и трансляцией данных на сервер и от сервера. Также он занимается контролем параметров питания и окружающей среды.

Таким образом с сервера снимается еще одна большая нагрузка: менеджмент датчиков.

Кроме того, такой модульный подход с распределенной вычислительной нагрузкой позволяет объединять в общую систему очень большое число датчиков без существенного увеличения требований к серверу.

Остальные исполнительные устройства так же, как и датчики, подключаются к шине.

В итоге получается такая схема:

Выбор протоколов и способов взаимодействия

Теперь необходимо было определиться с тем, как именно будут передаваться данные. Каждое устройство в системе участвует в 2-х типах обмена:

  • команда от сервера — ответ серверу;
  • асинхронное событие от устройства к серверу.

Команды используются для изменения состояния устройства и его настройки. События генерируются в случае, если у устройства появляется информация для сервера (например, тревога от датчика)

Со стороны сервера шлюз считается таким же исполнительным устройством, как и все остальные, так как он, помимо менеджмента устройств на шине, занимается еще отслеживанием параметров питания и температуры.

В качестве шины выбор стоял в основном между RS485 и CAN. Только эти два стандарта позволяли подключить множество устройств на достаточно больших расстояниях.

В результате анализа мы предпочли CAN. Параметры сети выбрали следующие:

  • Максимум 500 метров;
  • Максимум 100 устройств;
  • Скорость 50 кбит.

По нашему мнению, это являются оптимальным балансом скорости, плотности устройств и длины сети для нашей системы.

В шлюзе используется микроконтроллер с двумя драйверами CAN на борту, что позволило сделать 2 фланга и закрыть одним шлюзом 1 км.

У CAN есть еще и другие преимущества: помехоустойчивость, разрешение коллизий и гарантированная доставка пакетов адресату. Кроме того, он имеет достаточно сильную модель диагностики ошибок в сети.

Однако CAN представляет собой только канальный уровень сети. Для непосредственной работы с ним существует множество протоколов более высокого уровня. Самый известный из них — CANOpen.

Изучив различные варианты, мы пришли к выводу, что ни один из протоколов нам не подходит. Некоторые слишком сложны для нашей задачи, некоторые требуют отчислений за использование, а некоторые не поддерживают то, что хотелось бы реализовать.

А реализовать хотелось систему по принципу PlugAndPlay:

  • Подключение и отключение устройств без отключения питания;
  • Автоматическая определение изменения конфигурации системы;
  • Система должна начать работать сразу после сборки
.

В итоге нам удалось сделать то, что было задумано, написав свой простой, но достаточно мощный протокол. Так как речь идет о маленькой пропускной способности шины и небольшой вычислительной мощности микроконтроллеров, то тип протокола был выбран байтовый. Из-за оптимизации пропускной способности протокол получился достаточно сильно связанным с CAN, но нам удалось сделать его теоретически переносимым на другие стандарты.

Протокол позволяет:

  • обнаруживать “на лету” подключенные устройства;
  • обнаруживать отключение устройств;
  • работать в режиме запрос-ответ;
  • передавать асинхронные события;
  • передавать потоковые данные с устройства.

Наладив обмен между устройствами и шлюзом, осталось разобраться с сервером.

Шлюз имеет выход Ethernet. Это наиболее универсальная технология передачи данных. Сеть может быть организована как угодно: оптическими каналами, беспроводными каналами, обычной витой парой — при этом мы всегда сможем подключиться к этой сети, используя оптические конвертеры и точки доступа. Это позволяет заказчику проектировать инфраструктуру сети любой сложности и протяженности.

Передача данных была организована с помощью Сокетов Беркли на базе TCP/IP. Такое решение позволяет серверу гарантированно получать информацию от любого датчика и не зависеть от программных платформ. Протокол поверх TCP/IP мы разработали так же свой. Он тоже байтовый, для оптимизации работы на стороне микроконтроллера. У байтовых протоколов есть большой минус: сложность с последующей модификацией. Однако текстовый протокол для микроконтроллерного устройства слишком избыточен.

Самым сложным с точки зрения разработки ПО оказался сервер. Мы реализовали асинхронную многопоточную модель взаимодействия, что позволило получить “живую” систему, мгновенно реагирующую на любые изменения. Подключение нового устройства, потеря связи со шлюзом, тревога от датчика, открытие крышки на устройства — любое событие в системе мгновенно регистрируется, даже если они происходят одновременно.

В итоге мы получили гибкую модульную систему, управляемую через единый центр — сервер. Он так же имеет свой протокол, позволяющий подключаться к нему и получать события в системе. Это позволяет использовать нашу систему как составную часть большого комплекса и масштабировать ее практически до бесконечности.

Вопросы безопасности

С безопасностью системы оказалось все достаточно просто. Дело в том, что все сети, которые находятся на охраняемых объектах, сами по себе являются охраняемыми объектами. Таким образом все сети, с которыми работает система, становятся “доверенными”.

Кроме того, “цена” взлома информационной системы охраны гораздо выше, чем другие способы преодоления. Иными словами, опытный нарушитель найдет более простой способ преодолеть заграждение, а менее опытный просто не сможет взломать систему.

Поэтому никакими особыми способами защиты информации мы не пользовались, ограничившись только базовыми принципами.

Что дальше?

Несмотря на то, что система уже сформировалась, мы продолжаем активно ее развивать и искать новые способы применения.

Одним из направлений развития системы является машинное обучение. Используя эти алгоритмы, можно отфильтровывать регулярные помехи, такие как шум от грузовиков поездов и самолетов. В экспериментах для этого направления нам очень сильно помогает Azure Machine Learning. Он содержит множество готовых решений для машинного обучения, что позволяет достаточно быстро получить результаты.

Анализ колебаний ограждения далеко не единственный способ использования технологий, заложенных в нашу систему. Контроль вибраций высотных зданий, трубопроводов и газопроводов, хрупких грузов, вибродиагностика турбин и подвижных частей различных конструкций — далеко не полный список возможностей.

Количество датчиков в таких системах будет только возрастать и тут практически не минуем переход к облачным системам на объектах, для которых не запрещено использование интернета.

Очень перспективными нам кажутся новые технологии IoT от Microsoft. Единая платформа Windows теоретически способна сэкономить много времени, так как можно написать общий для разных аппаратных платформ код.

А для обработки данных использовать Azure IoT Suite. По заявлениям разработчиков, он содержит в себе инструменты, позволяющие не только объединять и управлять множеством IoT устройств, но и обрабатывать большие объемы данных с них. Это мы и собираемся проверить в ближайшем будущем.

Заключение

Когда мы начинали разработку системы, понятие “Интернета вещей” еще не набрало такой популярности. Опыта было немного, со многими вещами мы столкнулись в первый раз. Сейчас, когда об этой концепции много пишут и рассказывают, стало ясно, что выбран правильный путь.

Работа была сложной и долгой. Создание первой коммерческой версии системы заняло примерно 3 года. Первый ушел на разработку инженерных образцов отдельных устройств. Еще год был потрачен на разработку системы в целом. Третий год шла доводка и отладка.

За это время мы получили огромный опыт в решении разнообразных инженерных задач. Причем подбор корпусов, кабельной продукции, организация производства и логистики отняли не меньше сил, чем разработка самой системы.

Сейчас система смонтирована и работает на многих объектах в России и зарубежом. Самый крупный из них состоит из нескольких периметров общей протяженностью более 15 км. В проектировании находятся и более масштабные объекты.

Более подробную информацию можно получить на сайте системы.

habr.com

Интернет вещей: что это, зачем и как работает

Что такое интернет вещей

Сейчас многие говорят про интернет вещей, но не все понимают, что это такое.

Если верить «Википедии», это концепция вычислительной сети физических объектов («вещей»), оснащённых встроенными технологиями для взаимодействия друг с другом или с внешней средой, рассматривающая организацию таких сетей как явление, способное перестроить экономические и общественные процессы, исключающее из части действий и операций необходимость участия человека.

Говоря простым языком, интернет вещей — это некая сеть, в которую объединены вещи. Причём под вещами я подразумеваю всё что угодно: автомобиль, утюг, мебель, тапочки. Всё это сможет «общаться» друг с другом без участия человека при помощи передаваемых данных.

Появление подобной системы было ожидаемо, ведь лень — двигатель прогресса. Не придётся утром идти к кофеварке, чтобы сделать кофе. Она уже знает, когда вы обычно просыпаетесь, и к этому времени сама сварит ароматный кофе. Классно? Пожалуй, но насколько это реально и когда появится?

Как это работает

picjumbo.com

Мы находимся в начале пути, и об интернете вещей пока говорить рано. Возьмём для примера кофеварку, о которой я писал выше. Сейчас человеку приходится самостоятельно вводить время своего пробуждения, чтобы она сварила ему утром кофе. Но что произойдёт, если в это время человека не будет дома или он захочет чай? Да всё то же самое, так как он не поменял программу и бездушная железка снова сварила свой кофе. Такой сценарий интересен, но это скорее автоматизация процесса, чем интернет вещей.

У руля всегда стоит человек, он центр. Умных гаджетов с каждым годом становится всё больше, но они не работают без команды человека. Эту несчастную кофеварку придётся постоянно контролировать, менять программу, что неудобно.

Как это должно работать

picjumbo.com

Интернет вещей подразумевает, что человек определяет цель, а не задаёт программу по достижению этой цели. Ещё лучше, если система сама анализирует данные и предугадывает желания человека.

Едете вы с работы домой, уставший и голодный. В это время автомобиль уже сообщил дому, что через полчаса привезёт вас: мол, готовьтесь. Включается свет, термостат настраивает комфортную температуру, в духовке готовится ужин. Зашли в дом — включился телевизор с записью игры любимой команды, ужин готов, добро пожаловать домой.

Вот в чём главные особенности интернета вещей:

  • Это постоянное сопровождение повседневных действий человека.
  • Всё происходит прозрачно, ненавязчиво, с ориентацией на результат.
  • Человек указывает, что должно получиться, а не как это сделать.

Скажете, фантастика? Нет, это ближайшее будущее, но, чтобы добиться таких результатов, необходимо ещё многое сделать.

Как этого добиться

picjumbo.com
1. Единый центр

Логично, что в центре всех этих вещей должен стоять не человек, а какой-то девайс, который и будет передавать программу по достижению цели. Он будет контролировать другие устройства и выполнение задач, а также собирать данные. Такой девайс должен стоять в каждом доме, офисе и других местах. Их объединит единая сеть, через которую они будут обмениваться данными и помогать человеку в любом месте.

Зачатки такого центра мы уже видим сейчас. Amazon Echo, Google Home, да и Apple вроде тоже работает над чем-то подобным. Такие системы уже сейчас могут выполнять роль центра умного дома, хотя их возможности пока ограничены.

2. Единые стандарты

Это станет, пожалуй, главным препятствием на пути к глобальному интернету вещей. Для масштабной работы системы необходим единый язык. Над своей экосистемой сейчас работают Apple, Google, Microsoft. Но все они двигаются по отдельности, в разные стороны, а значит, в лучшем случае мы получим локальные системы, которые сложно объединить даже на уровне города.

Возможно, какая-то из систем станет стандартом, либо каждая сеть так и останется локальной и не перерастёт в нечто глобальное.

3. Безопасность

Естественно, разрабатывая такую систему, необходимо позаботиться о защите данных. Если сеть взломает хакер, он будет знать о вас абсолютно всё. Умные вещи сдадут вас злоумышленникам с потрохами, так что над шифрованием данных стоит серьёзно поработать. Конечно, над этим работают уже сейчас, но периодически всплывающие скандалы говорят о том, что до идеальной безопасности ещё далеко.

Что нас ждёт в ближайшем будущем

Mitch Nielsen/unsplash.com

В ближайшем будущем нас ждут умные дома, которые будут сами открывать двери для владельцев при приближении, поддерживать комфортный микроклимат, самостоятельно пополнять холодильник и заказывать необходимые лекарства, если человек заболел. Причём перед этим дом получит показатели с умного браслета и отправит их врачу. По дорогам будут ездить беспилотные автомобили, а на самих дорогах больше не останется пробок. Интернет вещей позволит разработать более продвинутую систему контроля трафика, которая сможет предотвращать появление пробок и заторов на дорогах.

Уже сейчас многие гаджеты работают в связке с различными системами, однако в ближайшие 5–10 лет нас ждёт настоящий бум развития интернета вещей. Вот только в будущем возможен расклад как в мультике «ВАЛЛ-И», где человечество превратилось в беспомощных толстяков, обслуживаемых роботами. Так себе перспектива. А что думаете вы?

lifehacker.ru

как работает интернет вещей — анализ решений

Концепция интернета вещей (Internet of Things, сокращенно IoT) возникла в 1999 году. К 2010 году направление обросло разнообразными технологиями, получило практическое применение и с тех пор устойчиво развивается.

По прогнозам исследовательской компании Gartner, в 2019 году произойдет слияние интернета вещей с несколькими ИТ-трендами. Искусственный интеллект, машинное обучение и периферийные вычисления, соединившись с IoT, откроют новые возможности и в ближайшие пять лет окажут серьезное влияние на рынок.* По оценкам IDC**, к 2025 году 95% данных, собираемых в реальном времени, будет обрабатываться на базе IoT-решений.

Разработчики компании Axmor проанализировали существующие решения для интернета вещей и поделились особенностями реализации боевых проектов.

Что же такое IoT?

Идея Internet of Things — во взаимодействии вещей с сервером и между собой, где участие человека сводится к минимуму. Например, счетчики электроэнергии, отсылающие показания в управляющую компанию; GPS-трекеры, отслеживающие движение такси; разнообразные фитнес-браслеты — это все интернет вещей.

Классическая архитектура интернета вещей включает в себя:

  • IoT-устройства. Они собирают показания с датчиков и выполняют физические действия. Могут быть персональными, носимыми и встроенными.
  • Шлюзы, которые получают информацию от устройств и передают им команды выполнения действий. Как правило, представлены аппаратным маршрутизатором или программным обеспечением; используют разные протоколы.
  • Сервер, где хранятся, обрабатываются и анализируются показания датчиков. Может быть реализован на базе виртуального сервера, реальной машины или через облако.
  • Клиентская часть, реализуется через мобильное или веб-приложение. Обеспечивает доступ к данным устройств и наглядному представлению результатов анализа.

В общем виде схема такого сервиса представлена на рисунке ниже:

Схема работы IoT сервиса

Архитектура IoT на практике

Современные IoT-решения строятся на базе протоколов передачи данных (например, MQTT, AMQP, HTTP, CoAP и другие)  и обеспечивают взаимодействие конечных устройств с облачными сервисами (например, Azure IoT Suite, Amazon Web Services IoT).

Как и большинство компаний, создающих программное обеспечение на заказ, мы работаем с IoT-устройствами заказчика. В Axmor не программируют их, наша задача — создать экосистемы сбора и анализа информации с уже готовых датчиков, а также разработать конечные пользовательские приложения. Поэтому прежде всего нас интересуют:

  • протоколы передачи данных,
  • средства сбора и анализа данных,
  • серверная часть,
  • визуализация информации на стороне клиента.

Первое, что мы делаем — оценка проекта. При этом важно понимать не только требования заказчика к пользовательской части, но и то, как будет реализован backend (серверная часть).

Какие решения предложить заказчику? Проанализируем популярные тенденции в сфере IoT.

Протоколы передачи данных

На сегодняшний день существует несколько протоколов прикладного уровня (Application layer) используемых при создании IoT-сервисов:

  • CoAP,
  • DTLS,
  • Eddystone,
  • HTTP,
  • iBeacon,
  • MQTT,
  • PJON,
  • STOMP,
  • Websocket,
  • XMPP.

Несмотря на их разнообразие на практике разработчики чаще применяют протоколы MQTT и HTTP. Кроме того, их поддерживают основные провайдеры облачных сервисов в своих решениях (Amazon, Microsoft, IBM, Google).***

Статистика использования протоколов подтверждается исследованием IoT Developer Survey 2018, проведенным Eclipse IoT Working Group (подразделение Eclipse Foundation) совместно с AGILE IoT, IEEE и Open Mobile Alliance.****

Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under a Creative Commons Attribution 4.0 International License (CC BY 4.0).

Из графиков видно, что последние три года MQTT и HTTP удерживают абсолютное лидерство среди всех протоколов, опережая ближайших конкурентов более чем в два раза.

В прошлом году сформировался новый тренд на применение протокола Websockets. Протокол был включен в веб-стандарт, и все самые популярные браузеры внедрили его в свое ядро. Websockets используется для непрерывной передачи данных между устройствами или между веб-страницами и серверами.

Тем не менее, самый оптимальный протокол для общения с IoT-устройствами — MQTT. Он разработан специально для этого направления, минимален по количеству передаваемых данных (в отличии от AMQP и HTTP), и не требует постоянного и стабильного соединения с интернетом (как HTTP и Websocket).

Разработчику также имеет смысл обратить внимание на протоколы iBeacon и Eddystone. Их можно использовать для определения местоположения пользователя (или объекта) внутри помещения. Протоколы поддерживаются в устройствах на базе iOS и Android.

Остальные протоколы сегодня менее популярны.

В IoT-проектах компании Axmor мы чаще всего применяем MQTT. Он прост в использовании, способен работать в условиях постоянной потери связи, легко встраивается в любую систему и не нагружает канал связи. В итоге проекты с MQTT снижают конечную стоимость решения и позволяют сэкономить заказчику как на процессе разработки, так и на дальнейшей эксплуатации системы.

Выбираем IoT-платформу

Из исследования IoT Developer Survey 2018 можно сделать еще несколько интересных выводов. Например, среди различных облачных сервисов IoT, Amazon Web Services (AWS) уверенно удерживает лидирующие позиции (см. рисунок ниже). Вторым по значению сервисом остается Microsoft Azure IoT.

Интересно, что Eclipse Foundation сравнивает с лидерами рынка решения от Kubernetes. По мнению исследователей, в 2018 году среди IoT-систем локального развертывания инфраструктуры и развертывания в облаке Kubernetes занял сразу пятое место, стартовав с нулевой позиции.

Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under a Creative Commons Attribution 4.0 International License (CC BY 4.0).

Что делает эти сервисы такими популярными?

Amazon Web Services IoT

Платформа AWS IoT Core позволяет подключать устройства ко всем сервисам AWS и другим устройствам, помогая собирать, хранить и анализировать данные даже при отсутствии сети интернет. AWS IoT дает возможность работать со множеством компонентов: от периферийных устройств до облачных систем, расширяя возможности для создания IoT-решений.

Microsoft Azure IoT

IoT-решение от Microsoft — это набор облачных сервисов. Они интегрированы со средой Azure, организующей двунаправленный обмен данными между устройствами и облаком. Сервис разрешает подключить к облаку практически любые сетевые устройства, идентифицировать их и управлять ими.
Microsoft Azure:

  • поддерживает все популярные протоколы,
  • предоставляет локальное хранилище и выделенную очередь сообщений для каждого подключенного устройства,
  • обеспечивает безопасность за счет шифрования и подписывания передаваемых данных.

(Источник: https://azure.microsoft.com/ru-ru/services/iot-central/)

Google Cloud IoT

Производитель сообщает, что: «Google Cloud IoT — это полностью управляемый сервис, который позволяет просто и безопасно подключаться, управлять данными и загружать их из миллионов, разбросанных по различным регионам устройств. В сочетании с другими сервисами на платформе Google Cloud IoT, Cloud IoT Core предлагает полнофункциональное решение для сбора, обработки, анализа и визуализации данных интернета вещей для поддержки и повышения эффективности работы в режиме реального времени».

(Источник: https://cloud.google.com/iot-core/)

IBM Watson IoT Platform

IBM Watson IoT Platform не входит в тройку лидеров, но также обеспечивает:

  • регистрацию устройств,
  • подключение,
  • контроль,
  • оперативную визуализацию,
  • хранение данных.

Ее особенность — в возможности быстро приступить к работе над IoT-проектами. Платформа поддерживает несколько языков программирования и множество сервисов, что позволяет запустить, развернуть и управлять приложением через облако буквально за несколько минут, даже если оно написано на уникальном (разработанном вами) языке программирования. Облачное хранилище IBM, а также некоторые сервисы стоят дешевле, чем у AWS и Microsoft Azure.

(Источник: https://developer.ibm.com/answers/questions/427732/difference-between-ibm-cloud-amazon-aws-microsoft/)

Лидеры рынка Microsoft и Amazon уделяют пристальное внимание развитию IoT-сервисов. AWS и Azure удобны и для разработчиков, и для пользователя, поэтому в Axmor мы отдаем предпочтение именно им.

Для выбранной платформы определяются совместимые с ней средства сбора и анализа данных.

Часто при решении задач в области интернета вещей используется технологии, аналогичные созданию веб-приложений (языки программирования, СУБД, фреймворки и так далее). Одни из них лучше подходят для быстрого прототипирования и проверки гипотез, другие — для внедрения промышленных решений.

В следующей статье мы рассмотрим, какие технологии полезны при работе с IoT-системами и на что стоит обратить внимание при проектировании серверной части.

Ссылки на источники:

* Gartner опубликовал исследование ТОП-10 стратегических трендов в ИТ на 2019 год: https://www.gartner.com/doc/3891569

** По оценкам IDC (международная исследовательская компания International Data Corporation), к 2025 году 25% собираемых данных будут обрабатываться в реальном времени, из них 95% — на базе IoT-решений: https://www.idc.com/

*** Основные провайдеры облачных сервисов поддерживают MQTT и HTTP в своих решениях:
https://docs.aws.amazon.com/en_us/iot/latest/developerguide/protocols.html
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-protocols
https://www.ibm.com/support/knowledgecenter/en/SSWMAJ_2.0.0/com.ibm.ism.doc/Overview/ov00050.html
https://cloud.google.com/iot/docs/concepts/protocols

**** Eclipse Foundation проводит ежегодный опрос мнений среди разработчиков. В 2018 году в опросе участвовало более 500 специалистов. https://iot.eclipse.org/resources/iot-developer-survey/iot-developer-survey-2018.pdf

Авторы: Максим Щипко и Михаил Костылев

Оцените статью

axmor.ru

Двадцать один пример IoT-платформ

Я уже пишу, наверное, двадцатую статью про «Интернет Вещей». Но всегда, как в первый раз, вынужден рассказывать, объяснять и доказывать. Но тут появился запрос не про объяснения, но про приведение примеров.

Как вы знаете, у меня есть небольшой частный телеграм-канал «ЗаТелеком», куда я выплескиваю новости, старости или просто заметки. Ну, и один пост почему-то вызвал «особый интерес» в виде массы репостов и упоминаний. Он был про «самые модные в этом сезоне IoT-платформы». Короткий простой пост с девятью ссылками на эти самые платформы.

Ну, поскольку интерес к теме проявился нешуточный, я решил сделать вот этот материал, где все и объясню. В очередной раз. Ну, вот первая попытка была.

Начнем с простого: что есть IoT-платформа, и как отличить оригинал от подделки?

Это очень, на самом деле, сложный вопрос, на который я ответить не смогу. И пытаться не буду.

Но вот есть гораздо более умные парни (разумеется, не наши), которые все понятно объяснили. Вот здесь оригинал, а ниже — краткий переклад на русский.

IoT-платформы — это такая штука, которая объединяет собственно «вещи» и «интернет». По сути — это ключевой инструмент разработки IoT-приложений и сервисов, объединяющий физические объекты и Сеть.

При этом многие вендоры, которые пытаются «держать нос по ветру», предлагают «IoT-платформы», которые в корне различаются между собой. И в ряде случаев, не являются «платформой» в широком смысле слова, но совершенно очевидно имеют основания себя таковой считать — есть «вещь», есть некий ресурс в интернете, который принимает/передает данные от/к «вещи». И что-то там делает (пытается делать) с этими данными. Следовательно,  претендовать на высокое звание дом образцового быта платформы вполне себе может. Притом, что четкого и конкретного определения IoT-платформы попросту не существует.

По мнению авторов «IoT Analytics», полноценной IoT-платформой следует считать такую платформу, которая позволяет разрабатывать соответствующие приложения/решения (IoT Application Enablement Platform).

А вот четыре типа платформ, которые называют «IoT-платформами», однако они не вполне подходят под классификацию IoT Analytics:

  • Connectivity / M2M platforms. Платформы в своей работе фокусируются на связи умных объектов через телекоммуникационные сети, но редко на обработке сигналов от датчиков (пример такой платформы: Sierra Wireless с продуктом AirVantage).
  • IaaS backends. Инфраструктура-как-сервис-серверы, предоставляющие хостинг-пространство и вычислительные мощности для приложений и сервисов, ранее оптимизировались для десктопов и мобильных приложений, но сейчас в фокус попал и IoT (пример — IBM Bluemix, но не IBM IoT Foundation).
  • Hardware-specific software platforms. Некоторые компании, продающие умные гаджеты, создают собственный программный бэкенд и рассуждают о нем, как об IoT-платформе. Но так как эта платформа носит закрытый для всех остальных характер, правомерность такого наименования сомнительна (например — Google Nest).
  • Consumer/Enterprise software extensions. Существующие пакеты корпоративного программного обеспечения и операционные системы типа MS Windows 10 становятся все более открытыми для интеграции IoT-устройств. В настоящее время эта область еще недостаточно развита, чтобы называться IoT-платформой, но будущее у нее очень перспективное.

В общем все запутано и ясности в терминологии нет. Что еще и усугубляется «модностью» темы и желанием разработчиков IoT-платформ комбинировать фантазии маркетологов, как, например, это делает IBM (IoT Foundation application enablement platform + Bluemix IaaS backend).

И вот парни из  IoT Analytics сделали интеллектуальное усилие, и выделили  восемь компонентов полноценной IoT-платформы:

  1. Связь и нормализация (Connectivity & normalization): сведение различных  протоколов и форматов данных в один «программный» интерфейс, гарантируя точную передачу данных и взаимодействие со всеми устройствами.
  2. Управление устройствами (Device management): обеспечение правильной работы подключенных «интернет-вещей», их конфигурирование,  бесперебойную работу, «накатку» патчей и обновлений. Причем, не только ПО собственно «вещей», но и приложений, работающих на устройстве или пограничных шлюзах.
  3. База данных (Database): тут все достаточно понятно и прозрачно — масштабируемое хранилище данных от «вещей». Требования к этим данным, попытка навести порядок в обработке и перенос данных из, например, разных «платформ» или вовсе к информационным системам «третьих лиц».
  4. Обработка и управление действиями (Processing & action management): данные, полученные от «вещей» в конечном итоге  влияют на события в реальности. По этому «платформа» должна уметь строить процессы, «триггеры событий» и прочее «умные действия» на основе конкретных данных датчиков.
  5. Аналитика (Analytics): данные от «вещей» являются ценными сами по себе. Поэтому существование комплекса средств их анализа является всенепременным требованием к «платформе». Если сюда включить еще и средства кластеризации данных и глубокого машинного обучения вплоть до прогнозирующей аналитики,то ценность «платформы» очевидно растет.
  6. Визуализация (Visualization): всю вышеперечисленную аналитику и вообще было бы неплохо показать таким образом, чтобы людям было понятно, приятно и красиво. Строить графики, модели, просто визуализировать то, что происходит с «вещами». Ну, и просто удобный интерфейс.
  7. Дополнительные инструменты (Additional tools): набор инструментов, который позволяет разработчикам IoT создавать прототипы, тестировать и пробовать различные системы. Приложения, виджеты, машапы — вот это все. Желательно, чтобы не очень углубляться в код и хардкор-программирование.
  8. Внешние интерфейсы (External interfaces): интеграция с помощью платформы — одна из главных возможностей. Мир интернет-разработки сегодня не терпит замкнутых решений. Всегда может потребоваться передача и обмен со сторонними системами. Поэтому настоящая IoT-платформа обязана иметь интерфейсы прикладного программирования (API), комплекты разработки программного обеспечения (SDK) и шлюзы.

Вот картинка для общего понимания (я не стал ее переводить):

На рынке уже имеются сотни платформ. IoT Analytics насчитали их  более 450 и число продолжает расти. При этом различные платформы появляются из-за  различных стратегий входа различных компаний, видения развития, подходов и начальных условий. Клиентские сегменты, кстати:

Стартапы, производители оборудования и сетевого оборудования, корпоративного программного обеспечения и компаний по управлению мобильностью — все они конкурируют, чтобы вывести на рынок лучший продукт.

Попробуем разобрать эти стратегии:

  • Стратегия «органического роста» снизу-вверх (Organic bottom-up approach): то есть, платформа начинает расти от «вещей» — сначала появляются некие устройства (обычно универсальные датчики), а потом начинается расширение и улучшение функционала, выстраиваются связи, подключаются другие «железки». Так, например, начиналась платформа  Ayla Networks, которая возникла с контроллеров STM32F3.
  • Стратегия  «сверху вниз» (Organic top-down approach): обратная ситуация, когда сначала появлялась аналитическая составляющая, а потом к ней пытались приспособить как можно больше разных «вещей». Пример — упомянутая IBM IoT Foundation.
  • Стратегия «партнерства» (Partnership approach): создание альянсов для развития продукта. Кто-то «приносит» «вещи», кто-то «админку». Пример: альянс GE Predix (это тот самый «Дженерал Электрик», у которого активов по Миру на триллион) и PTC Thingworx. Последняя компания в России больше известна пакетом компьютерной алгебры Mathcad.
  • «Слияния и поглощения» (M&A approach): любимый капиталистический прием по целевой скупке интересных решений крупным игроком. Например, Amazon в 2015 году купил  2lemetry, и теперь это все называется AWS IoT. Вариант стратегии — объединение бизнесов, как, например, Nokia и Alcatel-Lucent.
  • Ну, и есть еще «Инвестиционный подход» (Investment approach): тактические инвестиции по всей экосистеме IoT. Так любит поступать, например, Cisco.

IoT Analytics утверждает, что в настоящее время продажа основного продукта становится побочным процессом, а основные бизнес-интересы строятся вокруг «торговли данными», что довольно интересная мысль, но на российском рынке пока «цифровой нефтью» интересуются лишь спецслужбы.

В прогнозе IoT Analytics присутствует простая мысль, которую я много раз уже повторял в своих опусах про «интернет вещей»:  очень скоро мы увидим создание абсолютно новых отраслей, которые становятся возможными с повсеместным использованием «множества устройств, подключенных к интернету».

Для того чтобы эти модели «полетели» практически все готово — есть аппаратное обеспечение, имеется развитая инфраструктура передачи данных, есть очень хорошее программное обеспечение. Осталось чуть-чуть, и…

Но двинемся дальше.

Поскольку  список большой, я не стану по каждой платформе писать подробно. Но все эти проекты объединяет одно — открытый исходный код. На каждую сделаны ссылки, но не каждую ссылку я проверил методом установки и изучения кода. Нужно понять и простить. Ссылки в алфавитном порядке.

Предупреждаю, что в процессе осмысления можно сломать мозг. Слишком много концептуальных терминов и названий, которые я вообще затрудняюсь перевести.

  1. AllSeen Alliance (AllJoyn) — Фреймворк взаимодействия «вещей» AllJoyn, созданная AllSeen Alliance (ASA), который является проектом Linux Foundation. Есть мнение, что это одна из самых популярных IoT-платформ с открытым исходным кодом.
     
  2. Bug Labs  — пример стратегии разработки «снизу вверх». Парни из «Лаборатории ошибок» (красиво, кстати), начали разработку и железок для IoT под заказ, но потом обросли кучей веб-приложений и стали платформой, которая зарабатывает на разработке «нестандартных решений». Например, таких. Bug Labs в настоящее время имеет платформу для обмена сообщениями и оповещений «dweet» и «Freeboard — дашборд для создания панелей вывода и визуализации IoT».

  1. DeviceHive — платформа управления всевозможными устройствами на базе DataArt — форк AllJoyn (первый пункт). Предназначен для быстрого развертывания на популярных облачных сервисах: Azure, AWS, Apache Mesos и OpenStack. DeviceHive фокусируется на анализе больших данных с использованием таких инструментов, как ElasticSearch, Apache Spark, Cassandra и Kafka. Работает на любом устройстве, на котором запущено Ubuntu Snappy Core. Собственно ПО построено по модульному принципу с идеологией «промежуточного шлюза». Ну, то есть собственно «вещь» подключается к бордеру в виде, например, Raspberry PI (вот список поддерживаемого железа, где работает  Snappy Core), а затем уже «цепляется» к облаку, где развернут DeviceHive.
     
  2. DSA — Архитектура распределенных служб (Distributed Services Architecture). Достаточно сложная для понимания штука, которая предполагает создание полносвязных сетей «вещей». Имеет три элемента: DSBroker, DSLink и nodeAPI. Попробуйте сами разобраться.
     
  3. Eclipse IoT (Kura) —  IoT-решение от  Eclipse Foundation. Основа заключается в наличии API-контейнера Kura API. Написан на Java / OSGi и платформе агрегации для приложений M2M, работающих на служебных шлюзах. Kura использует  Eurotech Everywhere Cloud IoT, легко интегрируется с Apache Camel. Подпроекты Eclipse IoT включают в себя инфраструктуру протоколов обмена сообщениями Paho, и полный стек MQTT Mosquitto для «легких серверов» со  средой Eclipse SmartHome. Существует также Java-реализация протокола CoAP  под названием Californium и еще что-то. Много всего.
     
  4. Kaa  — проект поддерживается компанией  CyberVision, и представляет собой  масштабируемую инфраструктуру IoT, предназначенную для достаточно больших сетей. Платформа имеет серверную функцию REST-сообщений для служб, аналитику и управление данными. На базе Apache Zookeeper можно создавать кластерные системы, масштабируемые «до куда угодно». SDK Kaa поддерживают разработку на Java, C ++ и C. Имеются библиотеки организации связи «клиент-сервер», аутентификацию, шифрование, хранение и сортировку данных.
     
  5. Macchina .io  — универсальная среда для разработки приложений IoT-шлюзов, работающих на железках под Linux. Macchina.io уже включает поддержку  огромного количества датчиков и технологий подключения, включая Tinkerforge bricklets, кучу датчиков на XBee/ZB, GPS/GNSS приемники и еще кучу всего.
     
  6. GE Predix  — выше эта платформа уже упоминалась. Это по сути PaaS (платформа как услуга) для промышленного IoT и базируется на Cloud Foundry. Платформа умеет  «управлять активами, обеспечивать безопасность устройств и готовить аналитику в режиме реального времени. Ну, и все остальное, что должны уметь платформы, конечно это сбор данных, их хранение и обеспечение доступности. «Дженерал Электрик» разработали GE Predix, прежде всего, для собственных нужд. Соответственно имеет некоторую отраслевую специфику — электроэнергетика. Predix считается одной из самых успешных IoT-платформ и утверждается, что генерит разработчику порядка 6 млрд. долларов.
     
  7. Home Assistant  — платформа для массового использования для целей домашней автоматизации. Написана на Python.
     
  8. Mainspring — платформа запилена на Java компанией M2MLabs. Довольно старенькая и страшненькая (как, впрочем, и все написанное на Java — шутка). Использует для коммуникаций «вещей» REST и предлагает инструменты настройки оборудования и моделирования.
     
  9. Node-RED  — этот инструмент визуальной разработки на Node.js. Имеется  браузерный редактор «потоков», с помощью которого можно проектировать целые сети IoT с узлами и хабами. После узлы могут быть быстро развернуты как «среды выполнения» на куче серверов и/или в облаках. Обмен данными основан на JSON, что логично. Поддерживаются «вещи» на платах с Linux, а облачная поддержка — Docker, IBM Bluemix, AWS и Azure.
     
  10. Open Connectivity Foundation (IoTivity). Совместная разработка Intel и Samsung, которые инвестировали в Open Interconnect Consortium (OIC) и UPnP Forum. Очень хотят стать ведущей группой стандартов на базе открытого кода для IoT. IoTivity поддерживает протоколы обмена данными на RESTful, JSON и CoAP.
     
  11. OpenHAB  — среда разработки для «умного дома» с открытым исходным кодом. Может (по задумке) работать на любом устройстве, способном запускать JVM. Модульная архитектура на уровне абстракции разделяет все используемые технологии и компоненты IoT на «элементы», которые поддерживает  всевозможные правила, скрипты и процессы.
     
  12. OpenIoT  — Java-based платформа для создания IoT-приложений. Облачная, разумеется. Платформа включает промежуточное ПО датчиков и сенсорной сети, а также онтологии, семантические модели и аннотации для представления объектов IoT. Судя по гитхабу — давненько не обновлялось.
     
  13. OpenRemote  — система, которую изначально разрабатывали  для автоматизации зданий. OpenRemote отличается широкой поддержкой редких сетевых спецификаций и протоколов, например 1-Wire, EnOcean, xPL, Insteon и X10. Все остальное стандартно — правила, сценарии и события. Разумеется облачные инструменты проектирования для пользовательского интерфейса, установка и настройка, а также удаленные обновления и диагностика.
     
  14. OpenThread  — спин-офф от известной компании Nest (купленной Google за 3,2 млрд. долларов) с открытым исходным кодом. Заточен под устройства на 6LoWPAN, но есть поддержка и других протоколов. Работает на железных платформах от  ARM, Atmel, Microchip, Dialog, Qualcomm и TI. OpenThread реализует сетевые роли модели «Thread»: End Device, Router, Leader, and Border Router.
     
  15. Physical Web / Eddystone  — опен-сорс разработка Google. Это они пытались создать что-то очень похожее на  iBeacon от  Apple. Маячки на Bluetooth 4.0 с поддержкой «экономии энергии» (BLE) должны передавать URL-адреса на ваш смартфон. Идея состоит в том, что обладатели смартфонов могут взаимодействовать с любыми девайсами с поддержкой BLE, таким как парковочные счетчики, вывески или розничные продукты.
     
  16. PlatformIO  — система разработана на Python и включает в себя IDE, генератор проектов и веб-менеджер библиотек. Изначально разрабатывалась для доступа к данным с конечных точек на Arduino и ARM Mbed. Сейчас имеются  готовые прошивки-настройки для более чем 200 плат и интегрируется с Eclipse, Qt Creator и другими IDE.
     
  17. The Thing System  — программное обеспечение на  Node.js, предназначенное для смартфонов. Утверждается, что имеется поддержка «реальной автоматизации», а не просто уведомления — таких проектов, надо сказать, очень много. Есть что-то похожее на «самообучение» и искусственный интеллект, что позволяет организовать взаимодействие множества сценариев M2M взаимодействия. Отсутствие облачного компонента обеспечивает большую безопасность, конфиденциальность и контроль. Ну…
     
  18. ThingSpeak  — проект с пятилетней историей. Фокусируется на регистрации датчиков, отслеживании местоположения, триггерах и предупреждениях и анализе всех этих данных. Пользователи ThingSpeak могут использовать версию MATLAB для анализа и визуализации данных, не покупая лицензию от Mathworks.
     
  19. Zetta  — сервер-ориентированная IoT-платформа на Node.js и REST/WebSockets. Использует философию разработки, основанную «на потоках реактивного программирования» (не знаю что это).  Рекламируется как API-first система с интерфейсами Siren hypermedia. Любое устройство представляется, как  набор API REST, и связывается с облачными сервисами, где имеются инструменты визуализации и поддержки машинной аналитики Splunk. Платформа поддерживает любые Linux-платки и Arduino. Использует Heroku для создания геораспределенных сетей, что тоже звучит очень круто.
     

Насколько мне известно, работы по созданию IoT-платформ в РФ идут днем и ночью. Тысячи энтузиастов перерабатывают гигабайты открытого исходного кода для создания систем или «умного дома», или для «сбора данных со счетчиков».

На большее фантазии не хватает.

Впрочем, если вы знаете российские хорошие годные проекты — напишите мне. Я сделаю обзор.

Пока же покажу одну систему, которую вполне можно назвать IoT-платформой — это iRidium Mobile (нет, не спутниковая система связи) из Нижнего Тагила. Земляки.

Это как раз платформа для управления «умным домом». По сути, это некий «облачный хаб», который умеет преобразовывать массу IoT-протоколов и сводить их к «порталу управления». Если еще понятнее — инсталляторы «умных домов», а также «умных зданий» и прочих систем интернет-автоматизации экономят массу времени, денег и усилий на разработке пользовательских интерфейсов и интеграции кучи всяких протоколов и данных. Можно подобрать соответствующие датчики и/или исполнительные устройства, подключить их «по инструкции», а все остальное отдать iRidium.

Где уже готовы интерфейсы — нужно только перетащить мышкой в нужное место и поставить «логотип заказчика». Ну, и чуток автоматизации там тоже есть — это же платформа.

Более подробно на сайте. Я же покажу несколько фоточек, которые с сайта и утянул:

Например, «умный корабль»: 

Музей бронетехники:

Иди даже культовое сооружение «Храм Соломона» в Бразилии:

 

nag.ru

Двадцать один пример IoT-платформ

Я уже пишу, наверное, двадцатую статью про «Интернет Вещей». Но всегда, как в первый раз, вынужден рассказывать, объяснять и доказывать. Но тут появился запрос не про объяснения, но про приведение примеров.

Как вы знаете, у меня есть небольшой частный телеграм-канал «ЗаТелеком», куда я выплескиваю новости, старости или просто заметки. Ну, и один пост почему-то вызвал «особый интерес» в виде массы репостов и упоминаний. Он был про «самые модные в этом сезоне IoT-платформы». Короткий простой пост с девятью ссылками на эти самые платформы.

Ну, поскольку интерес к теме проявился нешуточный, я решил сделать вот этот материал, где все и объясню. В очередной раз. Ну, вот первая попытка была.

Начнем с простого: что есть IoT-платформа, и как отличить оригинал от подделки?

Это очень, на самом деле, сложный вопрос, на который я ответить не смогу. И пытаться не буду.

Но вот есть гораздо более умные парни (разумеется, не наши), которые все понятно объяснили. Вот здесь оригинал, а ниже — краткий переклад на русский.

IoT-платформы — это такая штука, которая объединяет собственно «вещи» и «интернет». По сути — это ключевой инструмент разработки IoT-приложений и сервисов, объединяющий физические объекты и Сеть.

При этом многие вендоры, которые пытаются «держать нос по ветру», предлагают «IoT-платформы», которые в корне различаются между собой. И в ряде случаев, не являются «платформой» в широком смысле слова, но совершенно очевидно имеют основания себя таковой считать — есть «вещь», есть некий ресурс в интернете, который принимает/передает данные от/к «вещи». И что-то там делает (пытается делать) с этими данными. Следовательно,  претендовать на высокое звание дом образцового быта платформы вполне себе может. Притом, что четкого и конкретного определения IoT-платформы попросту не существует.

По мнению авторов «IoT Analytics», полноценной IoT-платформой следует считать такую платформу, которая позволяет разрабатывать соответствующие приложения/решения (IoT Application Enablement Platform).

А вот четыре типа платформ, которые называют «IoT-платформами», однако они не вполне подходят под классификацию IoT Analytics:

  • Connectivity / M2M platforms. Платформы в своей работе фокусируются на связи умных объектов через телекоммуникационные сети, но редко на обработке сигналов от датчиков (пример такой платформы: Sierra Wireless с продуктом AirVantage).
  • IaaS backends. Инфраструктура-как-сервис-серверы, предоставляющие хостинг-пространство и вычислительные мощности для приложений и сервисов, ранее оптимизировались для десктопов и мобильных приложений, но сейчас в фокус попал и IoT (пример — IBM Bluemix, но не IBM IoT Foundation).
  • Hardware-specific software platforms. Некоторые компании, продающие умные гаджеты, создают собственный программный бэкенд и рассуждают о нем, как об IoT-платформе. Но так как эта платформа носит закрытый для всех остальных характер, правомерность такого наименования сомнительна (например — Google Nest).
  • Consumer/Enterprise software extensions. Существующие пакеты корпоративного программного обеспечения и операционные системы типа MS Windows 10 становятся все более открытыми для интеграции IoT-устройств. В настоящее время эта область еще недостаточно развита, чтобы называться IoT-платформой, но будущее у нее очень перспективное.

В общем все запутано и ясности в терминологии нет. Что еще и усугубляется «модностью» темы и желанием разработчиков IoT-платформ комбинировать фантазии маркетологов, как, например, это делает IBM (IoT Foundation application enablement platform + Bluemix IaaS backend).

И вот парни из  IoT Analytics сделали интеллектуальное усилие, и выделили  восемь компонентов полноценной IoT-платформы:

  1. Связь и нормализация (Connectivity & normalization): сведение различных  протоколов и форматов данных в один «программный» интерфейс, гарантируя точную передачу данных и взаимодействие со всеми устройствами.
  2. Управление устройствами (Device management): обеспечение правильной работы подключенных «интернет-вещей», их конфигурирование,  бесперебойную работу, «накатку» патчей и обновлений. Причем, не только ПО собственно «вещей», но и приложений, работающих на устройстве или пограничных шлюзах.
  3. База данных (Database): тут все достаточно понятно и прозрачно — масштабируемое хранилище данных от «вещей». Требования к этим данным, попытка навести порядок в обработке и перенос данных из, например, разных «платформ» или вовсе к информационным системам «третьих лиц».
  4. Обработка и управление действиями (Processing & action management): данные, полученные от «вещей» в конечном итоге  влияют на события в реальности. По этому «платформа» должна уметь строить процессы, «триггеры событий» и прочее «умные действия» на основе конкретных данных датчиков.
  5. Аналитика (Analytics): данные от «вещей» являются ценными сами по себе. Поэтому существование комплекса средств их анализа является всенепременным требованием к «платформе». Если сюда включить еще и средства кластеризации данных и глубокого машинного обучения вплоть до прогнозирующей аналитики,то ценность «платформы» очевидно растет.
  6. Визуализация (Visualization): всю вышеперечисленную аналитику и вообще было бы неплохо показать таким образом, чтобы людям было понятно, приятно и красиво. Строить графики, модели, просто визуализировать то, что происходит с «вещами». Ну, и просто удобный интерфейс.
  7. Дополнительные инструменты (Additional tools): набор инструментов, который позволяет разработчикам IoT создавать прототипы, тестировать и пробовать различные системы. Приложения, виджеты, машапы — вот это все. Желательно, чтобы не очень углубляться в код и хардкор-программирование.
  8. Внешние интерфейсы (External interfaces): интеграция с помощью платформы — одна из главных возможностей. Мир интернет-разработки сегодня не терпит замкнутых решений. Всегда может потребоваться передача и обмен со сторонними системами. Поэтому настоящая IoT-платформа обязана иметь интерфейсы прикладного программирования (API), комплекты разработки программного обеспечения (SDK) и шлюзы.

Вот картинка для общего понимания (я не стал ее переводить):

На рынке уже имеются сотни платформ. IoT Analytics насчитали их  более 450 и число продолжает расти. При этом различные платформы появляются из-за  различных стратегий входа различных компаний, видения развития, подходов и начальных условий. Клиентские сегменты, кстати:

Стартапы, производители оборудования и сетевого оборудования, корпоративного программного обеспечения и компаний по управлению мобильностью — все они конкурируют, чтобы вывести на рынок лучший продукт.

Попробуем разобрать эти стратегии:

  • Стратегия «органического роста» снизу-вверх (Organic bottom-up approach): то есть, платформа начинает расти от «вещей» — сначала появляются некие устройства (обычно универсальные датчики), а потом начинается расширение и улучшение функционала, выстраиваются связи, подключаются другие «железки». Так, например, начиналась платформа  Ayla Networks, которая возникла с контроллеров STM32F3.
  • Стратегия  «сверху вниз» (Organic top-down approach): обратная ситуация, когда сначала появлялась аналитическая составляющая, а потом к ней пытались приспособить как можно больше разных «вещей». Пример — упомянутая IBM IoT Foundation.
  • Стратегия «партнерства» (Partnership approach): создание альянсов для развития продукта. Кто-то «приносит» «вещи», кто-то «админку». Пример: альянс GE Predix (это тот самый «Дженерал Электрик», у которого активов по Миру на триллион) и PTC Thingworx. Последняя компания в России больше известна пакетом компьютерной алгебры Mathcad.
  • «Слияния и поглощения» (M&A approach): любимый капиталистический прием по целевой скупке интересных решений крупным игроком. Например, Amazon в 2015 году купил  2lemetry, и теперь это все называется AWS IoT. Вариант стратегии — объединение бизнесов, как, например, Nokia и Alcatel-Lucent.
  • Ну, и есть еще «Инвестиционный подход» (Investment approach): тактические инвестиции по всей экосистеме IoT. Так любит поступать, например, Cisco.

IoT Analytics утверждает, что в настоящее время продажа основного продукта становится побочным процессом, а основные бизнес-интересы строятся вокруг «торговли данными», что довольно интересная мысль, но на российском рынке пока «цифровой нефтью» интересуются лишь спецслужбы.

В прогнозе IoT Analytics присутствует простая мысль, которую я много раз уже повторял в своих опусах про «интернет вещей»:  очень скоро мы увидим создание абсолютно новых отраслей, которые становятся возможными с повсеместным использованием «множества устройств, подключенных к интернету».

Для того чтобы эти модели «полетели» практически все готово — есть аппаратное обеспечение, имеется развитая инфраструктура передачи данных, есть очень хорошее программное обеспечение. Осталось чуть-чуть, и…

Но двинемся дальше.

Поскольку  список большой, я не стану по каждой платформе писать подробно. Но все эти проекты объединяет одно — открытый исходный код. На каждую сделаны ссылки, но не каждую ссылку я проверил методом установки и изучения кода. Нужно понять и простить. Ссылки в алфавитном порядке.

Предупреждаю, что в процессе осмысления можно сломать мозг. Слишком много концептуальных терминов и названий, которые я вообще затрудняюсь перевести.

  1. AllSeen Alliance (AllJoyn) — Фреймворк взаимодействия «вещей» AllJoyn, созданная AllSeen Alliance (ASA), который является проектом Linux Foundation. Есть мнение, что это одна из самых популярных IoT-платформ с открытым исходным кодом.
     
  2. Bug Labs  — пример стратегии разработки «снизу вверх». Парни из «Лаборатории ошибок» (красиво, кстати), начали разработку и железок для IoT под заказ, но потом обросли кучей веб-приложений и стали платформой, которая зарабатывает на разработке «нестандартных решений». Например, таких. Bug Labs в настоящее время имеет платформу для обмена сообщениями и оповещений «dweet» и «Freeboard — дашборд для создания панелей вывода и визуализации IoT».

  1. DeviceHive — платформа управления всевозможными устройствами на базе DataArt — форк AllJoyn (первый пункт). Предназначен для быстрого развертывания на популярных облачных сервисах: Azure, AWS, Apache Mesos и OpenStack. DeviceHive фокусируется на анализе больших данных с использованием таких инструментов, как ElasticSearch, Apache Spark, Cassandra и Kafka. Работает на любом устройстве, на котором запущено Ubuntu Snappy Core. Собственно ПО построено по модульному принципу с идеологией «промежуточного шлюза». Ну, то есть собственно «вещь» подключается к бордеру в виде, например, Raspberry PI (вот список поддерживаемого железа, где работает  Snappy Core), а затем уже «цепляется» к облаку, где развернут DeviceHive.
     
  2. DSA — Архитектура распределенных служб (Distributed Services Architecture). Достаточно сложная для понимания штука, которая предполагает создание полносвязных сетей «вещей». Имеет три элемента: DSBroker, DSLink и nodeAPI. Попробуйте сами разобраться.
     
  3. Eclipse IoT (Kura) —  IoT-решение от  Eclipse Foundation. Основа заключается в наличии API-контейнера Kura API. Написан на Java / OSGi и платформе агрегации для приложений M2M, работающих на служебных шлюзах. Kura использует  Eurotech Everywhere Cloud IoT, легко интегрируется с Apache Camel. Подпроекты Eclipse IoT включают в себя инфраструктуру протоколов обмена сообщениями Paho, и полный стек MQTT Mosquitto для «легких серверов» со  средой Eclipse SmartHome. Существует также Java-реализация протокола CoAP  под названием Californium и еще что-то. Много всего.
     
  4. Kaa  — проект поддерживается компанией  CyberVision, и представляет собой  масштабируемую инфраструктуру IoT, предназначенную для достаточно больших сетей. Платформа имеет серверную функцию REST-сообщений для служб, аналитику и управление данными. На базе Apache Zookeeper можно создавать кластерные системы, масштабируемые «до куда угодно». SDK Kaa поддерживают разработку на Java, C ++ и C. Имеются библиотеки организации связи «клиент-сервер», аутентификацию, шифрование, хранение и сортировку данных.
     
  5. Macchina .io  — универсальная среда для разработки приложений IoT-шлюзов, работающих на железках под Linux. Macchina.io уже включает поддержку  огромного количества датчиков и технологий подключения, включая Tinkerforge bricklets, кучу датчиков на XBee/ZB, GPS/GNSS приемники и еще кучу всего.
     
  6. GE Predix  — выше эта платформа уже упоминалась. Это по сути PaaS (платформа как услуга) для промышленного IoT и базируется на Cloud Foundry. Платформа умеет  «управлять активами, обеспечивать безопасность устройств и готовить аналитику в режиме реального времени. Ну, и все остальное, что должны уметь платформы, конечно это сбор данных, их хранение и обеспечение доступности. «Дженерал Электрик» разработали GE Predix, прежде всего, для собственных нужд. Соответственно имеет некоторую отраслевую специфику — электроэнергетика. Predix считается одной из самых успешных IoT-платформ и утверждается, что генерит разработчику порядка 6 млрд. долларов.
     
  7. Home Assistant  — платформа для массового использования для целей домашней автоматизации. Написана на Python.
     
  8. Mainspring — платформа запилена на Java компанией M2MLabs. Довольно старенькая и страшненькая (как, впрочем, и все написанное на Java — шутка). Использует для коммуникаций «вещей» REST и предлагает инструменты настройки оборудования и моделирования.
     
  9. Node-RED  — этот инструмент визуальной разработки на Node.js. Имеется  браузерный редактор «потоков», с помощью которого можно проектировать целые сети IoT с узлами и хабами. После узлы могут быть быстро развернуты как «среды выполнения» на куче серверов и/или в облаках. Обмен данными основан на JSON, что логично. Поддерживаются «вещи» на платах с Linux, а облачная поддержка — Docker, IBM Bluemix, AWS и Azure.
     
  10. Open Connectivity Foundation (IoTivity). Совместная разработка Intel и Samsung, которые инвестировали в Open Interconnect Consortium (OIC) и UPnP Forum. Очень хотят стать ведущей группой стандартов на базе открытого кода для IoT. IoTivity поддерживает протоколы обмена данными на RESTful, JSON и CoAP.
     
  11. OpenHAB  — среда разработки для «умного дома» с открытым исходным кодом. Может (по задумке) работать на любом устройстве, способном запускать JVM. Модульная архитектура на уровне абстракции разделяет все используемые технологии и компоненты IoT на «элементы», которые поддерживает  всевозможные правила, скрипты и процессы.
     
  12. OpenIoT  — Java-based платформа для создания IoT-приложений. Облачная, разумеется. Платформа включает промежуточное ПО датчиков и сенсорной сети, а также онтологии, семантические модели и аннотации для представления объектов IoT. Судя по гитхабу — давненько не обновлялось.
     
  13. OpenRemote  — система, которую изначально разрабатывали  для автоматизации зданий. OpenRemote отличается широкой поддержкой редких сетевых спецификаций и протоколов, например 1-Wire, EnOcean, xPL, Insteon и X10. Все остальное стандартно — правила, сценарии и события. Разумеется облачные инструменты проектирования для пользовательского интерфейса, установка и настройка, а также удаленные обновления и диагностика.
     
  14. OpenThread  — спин-офф от известной компании Nest (купленной Google за 3,2 млрд. долларов) с открытым исходным кодом. Заточен под устройства на 6LoWPAN, но есть поддержка и других протоколов. Работает на железных платформах от  ARM, Atmel, Microchip, Dialog, Qualcomm и TI. OpenThread реализует сетевые роли модели «Thread»: End Device, Router, Leader, and Border Router.
     
  15. Physical Web / Eddystone  — опен-сорс разработка Google. Это они пытались создать что-то очень похожее на  iBeacon от  Apple. Маячки на Bluetooth 4.0 с поддержкой «экономии энергии» (BLE) должны передавать URL-адреса на ваш смартфон. Идея состоит в том, что обладатели смартфонов могут взаимодействовать с любыми девайсами с поддержкой BLE, таким как парковочные счетчики, вывески или розничные продукты.
     
  16. PlatformIO  — система разработана на Python и включает в себя IDE, генератор проектов и веб-менеджер библиотек. Изначально разрабатывалась для доступа к данным с конечных точек на Arduino и ARM Mbed. Сейчас имеются  готовые прошивки-настройки для более чем 200 плат и интегрируется с Eclipse, Qt Creator и другими IDE.
     
  17. The Thing System  — программное обеспечение на  Node.js, предназначенное для смартфонов. Утверждается, что имеется поддержка «реальной автоматизации», а не просто уведомления — таких проектов, надо сказать, очень много. Есть что-то похожее на «самообучение» и искусственный интеллект, что позволяет организовать взаимодействие множества сценариев M2M взаимодействия. Отсутствие облачного компонента обеспечивает большую безопасность, конфиденциальность и контроль. Ну…
     
  18. ThingSpeak  — проект с пятилетней историей. Фокусируется на регистрации датчиков, отслеживании местоположения, триггерах и предупреждениях и анализе всех этих данных. Пользователи ThingSpeak могут использовать версию MATLAB для анализа и визуализации данных, не покупая лицензию от Mathworks.
     
  19. Zetta  — сервер-ориентированная IoT-платформа на Node.js и REST/WebSockets. Использует философию разработки, основанную «на потоках реактивного программирования» (не знаю что это).  Рекламируется как API-first система с интерфейсами Siren hypermedia. Любое устройство представляется, как  набор API REST, и связывается с облачными сервисами, где имеются инструменты визуализации и поддержки машинной аналитики Splunk. Платформа поддерживает любые Linux-платки и Arduino. Использует Heroku для создания геораспределенных сетей, что тоже звучит очень круто.
     

Насколько мне известно, работы по созданию IoT-платформ в РФ идут днем и ночью. Тысячи энтузиастов перерабатывают гигабайты открытого исходного кода для создания систем или «умного дома», или для «сбора данных со счетчиков».

На большее фантазии не хватает.

Впрочем, если вы знаете российские хорошие годные проекты — напишите мне. Я сделаю обзор.

Пока же покажу одну систему, которую вполне можно назвать IoT-платформой — это iRidium Mobile (нет, не спутниковая система связи) из Нижнего Тагила. Земляки.

Это как раз платформа для управления «умным домом». По сути, это некий «облачный хаб», который умеет преобразовывать массу IoT-протоколов и сводить их к «порталу управления». Если еще понятнее — инсталляторы «умных домов», а также «умных зданий» и прочих систем интернет-автоматизации экономят массу времени, денег и усилий на разработке пользовательских интерфейсов и интеграции кучи всяких протоколов и данных. Можно подобрать соответствующие датчики и/или исполнительные устройства, подключить их «по инструкции», а все остальное отдать iRidium.

Где уже готовы интерфейсы — нужно только перетащить мышкой в нужное место и поставить «логотип заказчика». Ну, и чуток автоматизации там тоже есть — это же платформа.

Более подробно на сайте. Я же покажу несколько фоточек, которые с сайта и утянул:

Например, «умный корабль»: 

Музей бронетехники:

Иди даже культовое сооружение «Храм Соломона» в Бразилии:

 

nag.ru

Архитектура IoT-решения на реальном примере

Дата публикации: 18.12.2015


Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV). В этом выпуске технический директор компании «ИНПРОСИСТЕМ» AlexandrSurkov рассказывает об опыте разработки архитектуры охранной IoT-системы СеСМИК.


Многие считают, что понятие «Интернета вещей» неразрывно связано с сетью, которой мы пользуемся каждый день. Можно представить себе картину, где множество устройств, объединенных в единое целое через глобальную сеть, обмениваются данными между собой и серверами и создают цифровую картину мира. В данной статье я расскажу о том, как мы делали систему, объединяющую сотни датчиков.

Понятие «интернет» стоит рассматривать гораздо шире. В данном случае это общая для устройств сеть. Она может содержать 10 устройств, а может и 10 000. Может быть проводная, а может быть беспроводная. Может располагаться в одной комнате, а может охватывать несколько стран. Все зависит от задач, которые ставятся перед системой.

При этом создание даже небольшой сети устройств сопровождается множеством трудностей.

Постановка задачи

Нам была поставлена задача по разработке системы охраны периметра. Периметр — это забор, окружающий некоторый объект. Его длина ничем не ограничена.

Система создавалась с нуля. К моменту начала проектирования существовал прототип датчика, способного собирать колебания периметра, проанализировав которые, можно было четко определить факт преодоления или разрушения забора. Опытным путем мы определили, что датчики нужно ставить примерно через каждые 10 метров.

Кроме датчиков планировались еще управляющие устройства с реле и управляемые устройства с «сухим контактом». Система должна работать в уличных условиях при широком диапазоне температур и погодных явлений.

Итак, имеется:

  • 3 типа устройств;
  • Минимум 100 устройств на километр;
  • Количество километров не ограничено;
  • Система должна иметь уличное исполнение.

Сразу можно выделить главные вопросы по архитектуре:

  • Организация передачи данных и питания;
  • Распределение потоков информации: где и как анализировать данные;
  • Безопасность решения: какие протоколы использовать;
  • Как управлять таким количеством устройств.

Общая схема решения

Clemens Vasters написал прекрасную статью о том, с чем сталкивается разработчик системы «Интернета вещей». Эти же проблемы пришлось решать и нам.

Многие решения диктовались ГОСТами и другими требованиями к таким системам. Но многое пришлось придумывать самим.

Сперва нужно было понять, как распределить информационные потоки в системе. Для анализа колебаний использовалась как временная, так и частотная составляющая. Диапазон частот от 0 до 500 герц. Значит, замеры нужно делать 1000 раз в секунду. Каждое измерение делаются по 3 осям по 10 бит на каждую.

Итого 3*10*1000 = 30 килобит в секунду только от одного датчика. На километр (100 датчиков) это уже 3 мегабита.

Передать то эти данные можно, но как их обрабатывать? Периметр в 10 км давал бы уже 30 мегабит данных в секунду. Получается, что нагрузка на сервер возрастает с увеличением количества устройств.

Было принято решение, что каждый датчик будет обрабатывать данные сам и отдавать только факты тревог. Это значительно снизило объем данных и распределило вычислительную нагрузку.

Организация сети была выбрана проводная из-за того, что беспроводная требует батареи. Так как система у нас реального времени, то срок жизни батареи будет очень маленький. Кроме того, отрицательные температуры сильно уменьшают емкость питающих элементов. Да и заглушить беспроводную связь относительно легко, а это уже является очень существенным недостатком для системы безопасности.

ГОСТы запрещают прокладывать по ограждению 220В, поэтому “питаться” наши устройства будут от постоянного напряжения.

В качестве архитектуры сети мы выбрали шину. Это позволило не тянуть провод к каждому датчику.

Однако шина накладывает ограничение на длину сети и количество устройств. Поэтому было введено новое устройство: шлюз. Он имеет 2 шины, занимается менеджментом устройств и трансляцией данных на сервер и от сервера. Также он занимается контролем параметров питания и окружающей среды.

Таким образом с сервера снимается еще одна большая нагрузка: менеджмент датчиков.

Кроме того, такой модульный подход с распределенной вычислительной нагрузкой позволяет объединять в общую систему очень большое число датчиков без существенного увеличения требований к серверу.

Остальные исполнительные устройства так же, как и датчики, подключаются к шине.

В итоге получается такая схема:

Выбор протоколов и способов взаимодействия

Теперь необходимо было определиться с тем, как именно будут передаваться данные. Каждое устройство в системе участвует в 2-х типах обмена:

  • команда от сервера — ответ серверу;
  • асинхронное событие от устройства к серверу.

Команды используются для изменения состояния устройства и его настройки. События генерируются в случае, если у устройства появляется информация для сервера (например, тревога от датчика)

Со стороны сервера шлюз считается таким же исполнительным устройством, как и все остальные, так как он, помимо менеджмента устройств на шине, занимается еще отслеживанием параметров питания и температуры.

В качестве шины выбор стоял в основном между RS485 и CAN. Только эти два стандарта позволяли подключить множество устройств на достаточно больших расстояниях.

В результате анализа мы предпочли CAN. Параметры сети выбрали следующие:

  • Максимум 500 метров;
  • Максимум 100 устройств;
  • Скорость 50 кбит.

По нашему мнению, это являются оптимальным балансом скорости, плотности устройств и длины сети для нашей системы.

В шлюзе используется микроконтроллер с двумя драйверами CAN на борту, что позволило сделать 2 фланга и закрыть одним шлюзом 1 км.

У CAN есть еще и другие преимущества: помехоустойчивость, разрешение коллизий и гарантированная доставка пакетов адресату. Кроме того, он имеет достаточно сильную модель диагностики ошибок в сети.

Однако CAN представляет собой только канальный уровень сети. Для непосредственной работы с ним существует множество протоколов более высокого уровня. Самый известный из них — CANOpen.

Изучив различные варианты, мы пришли к выводу, что ни один из протоколов нам не подходит. Некоторые слишком сложны для нашей задачи, некоторые требуют отчислений за использование, а некоторые не поддерживают то, что хотелось бы реализовать.

А реализовать хотелось систему по принципу PlugAndPlay:

  • Подключение и отключение устройств без отключения питания;
  • Автоматическая определение изменения конфигурации системы;
  • Система должна начать работать сразу после сборки

В итоге нам удалось сделать то, что было задумано, написав свой простой, но достаточно мощный протокол. Так как речь идет о маленькой пропускной способности шины и небольшой вычислительной мощности микроконтроллеров, то тип протокола был выбран байтовый. Из-за оптимизации пропускной способности протокол получился достаточно сильно связанным с CAN, но нам удалось сделать его теоретически переносимым на другие стандарты.

Протокол позволяет:

  • обнаруживать “на лету” подключенные устройства;
  • обнаруживать отключение устройств;
  • работать в режиме запрос-ответ;
  • передавать асинхронные события;
  • передавать потоковые данные с устройства.

Наладив обмен между устройствами и шлюзом, осталось разобраться с сервером.

Шлюз имеет выход Ethernet. Это наиболее универсальная технология передачи данных. Сеть может быть организована как угодно: оптическими каналами, беспроводными каналами, обычной витой парой — при этом мы всегда сможем подключиться к этой сети, используя оптические конвертеры и точки доступа. Это позволяет заказчику проектировать инфраструктуру сети любой сложности и протяженности.

Передача данных была организована с помощью Сокетов Беркли на базе TCP/IP. Такое решение позволяет серверу гарантированно получать информацию от любого датчика и не зависеть от программных платформ. Протокол поверх TCP/IP мы разработали так же свой. Он тоже байтовый, для оптимизации работы на стороне микроконтроллера. У байтовых протоколов есть большой минус: сложность с последующей модификацией. Однако текстовый протокол для микроконтроллерного устройства слишком избыточен.

Самым сложным с точки зрения разработки ПО оказался сервер. Мы реализовали асинхронную многопоточную модель взаимодействия, что позволило получить “живую” систему, мгновенно реагирующую на любые изменения. Подключение нового устройства, потеря связи со шлюзом, тревога от датчика, открытие крышки на устройства — любое событие в системе мгновенно регистрируется, даже если они происходят одновременно.

В итоге мы получили гибкую модульную систему, управляемую через единый центр — сервер. Он так же имеет свой протокол, позволяющий подключаться к нему и получать события в системе. Это позволяет использовать нашу систему как составную часть большого комплекса и масштабировать ее практически до бесконечности.

Вопросы безопасности

С безопасностью системы оказалось все достаточно просто. Дело в том, что все сети, которые находятся на охраняемых объектах, сами по себе являются охраняемыми объектами. Таким образом все сети, с которыми работает система, становятся “доверенными”.

Кроме того, “цена” взлома информационной системы охраны гораздо выше, чем другие способы преодоления. Иными словами, опытный нарушитель найдет более простой способ преодолеть заграждение, а менее опытный просто не сможет взломать систему.

Поэтому никакими особыми способами защиты информации мы не пользовались, ограничившись только базовыми принципами.

Что дальше?

Несмотря на то, что система уже сформировалась, мы продолжаем активно ее развивать и искать новые способы применения.

Одним из направлений развития системы является машинное обучение. Используя эти алгоритмы, можно отфильтровывать регулярные помехи, такие как шум от грузовиков поездов и самолетов. В экспериментах для этого направления нам очень сильно помогает Azure Machine Learning. Он содержит множество готовых решений для машинного обучения, что позволяет достаточно быстро получить результаты.

Анализ колебаний ограждения далеко не единственный способ использования технологий, заложенных в нашу систему. Контроль вибраций высотных зданий, трубопроводов и газопроводов, хрупких грузов, вибродиагностика турбин и подвижных частей различных конструкций — далеко не полный список возможностей.

Количество датчиков в таких системах будет только возрастать и тут практически не минуем переход к облачным системам на объектах, для которых не запрещено использование интернета.

Очень перспективными нам кажутся новые технологии IoT от Microsoft. Единая платформа Windows теоретически способна сэкономить много времени, так как можно написать общий для разных аппаратных платформ код.

А для обработки данных использовать Azure IoT Suite. По заявлениям разработчиков, он содержит в себе инструменты, позволяющие не только объединять и управлять множеством IoT устройств, но и обрабатывать большие объемы данных с них. Это мы и собираемся проверить в ближайшем будущем.

Заключение

Когда мы начинали разработку системы, понятие “Интернета вещей” еще не набрало такой популярности. Опыта было немного, со многими вещами мы столкнулись в первый раз. Сейчас, когда об этой концепции много пишут и рассказывают, стало ясно, что выбран правильный путь.

Работа была сложной и долгой. Создание первой коммерческой версии системы заняло примерно 3 года. Первый ушел на разработку инженерных образцов отдельных устройств. Еще год был потрачен на разработку системы в целом. Третий год шла доводка и отладка.

За это время мы получили огромный опыт в решении разнообразных инженерных задач. Причем подбор корпусов, кабельной продукции, организация производства и логистики отняли не меньше сил, чем разработка самой системы.

Сейчас система смонтирована и работает на многих объектах в России и зарубежом. Самый крупный из них состоит из нескольких периметров общей протяженностью более 15 км. В проектировании находятся и более масштабные объекты.

Более подробную информацию можно получить на сайте системы.

Автор статьи: Александр Сурков

Данный материал написан участником сообщества. В статье представлено мнение автора, которое может не совпадать с мнением корпорации Microsoft. Microsoft не несет ответственности за проблемы в работе аппаратного или программного обеспечения, которые могли возникнуть после использования материалов данной статьи.

msdn.microsoft.com

IOT решения и технологии — Интернет вещей

 

Интеграция со сторонними платформами IOT

Попробуйте IOT платформу ICBCom


LoRaWAN оборудование


NB-IoT оборудование


3G/4G оборудование


Ethernet оборудование


LTE-450 оборудование


WI-FI оборудование

Проектирование iot решений – это создание правильных решений для подключения ряда устройств к интернету. Глобальная инфраструктура дает уникальную возможность виртуальному и реальному оборудованию наладить качественный контакт и организовать их взаимосвязь. Для этого необходимо понимать, как создать технологическую цепочку, которая будет бесперебойно и эффективно функционировать.

Особенности

Интернет вещей можно использовать для обслуживания потребителей разного уровня, начиная с простых физических лиц, заканчивая крупными бизнес проектами. Для применения IoT уже создана основная инфраструктура в виде фиксированных и мобильных сетей. Все это дополнительно обеспечивается платформами, сенсорами, приложениями, которые доступны каждому.

Основная цель – это снижение затрат и повышение функциональности, что достигается следующим образом:

  • выявление трат и анализ услуги;
  • исследование условий создания радиоканала;
  • моделирование канала с учетом выбранной методики;
  • определение экономической эффективности.

Для внедрения и разработки IoT необходимо определить метод соединения устройств между собой, технологию их сбора, способ обработки информации для принятия корректного решения.

Преимущества

К основным достоинствам интернета-вещей можно отнести:

  • широкая область применения;
  • готова необходимая, основная инфраструктура;
  • снижение расходов на передачу данных, вычислительных мощностей;
  • гибкая система анализа и хранения данных;
  • быстрый рост количества подключаемых устройств.

Использование IoT технологий максимально облегчает и организует жизнь пользователю и повышает уровень функциональности.

Данные виды устройств содержат в своем составе датчики для различных целей, маршрутизаторы, счетчики. При необходимости можно собрать требуемые системы для конкретных производственных потребностей, но в большинстве случаев подойдут готовые IOT решения.

Схема соединения простая. Все датчики, счетчики, метеостанции подключаются к передатчику, передающего все сведения в облачное хранилище. Пользователи при необходимости могут оперативно обрабатывать эту информацию. Так как все систематизировано и расположено в одном месте, обработка данных не занимает много времени.

Выпускаемые приборы подходят не только для крупных компаний. Предлагаемые решения интегрируются к технологиям «умного» дома. Быстрая передача информации как к серверу, так и обратно, работают на расстоянии, большем, чем у других известных сетей. Это делает применение оборудования IOT надежным и комфортным. Гарантией качества оборудования являются долгосрочные партнерские отношения с самыми крупными компании России.

icbcom.ru

Обновлено: 28.07.2019 — 21:57

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *