Возьмем смартфон, который будет эмулировать IoT устройство c датчиками температуры, влажности и давления и отсылать показания на Amazon IoT платформу. На платформе заведем правило, которое при поступлении данных от нашего устройства будет вызывать сервис нотификаций, который в свою очередь будет отсылать e-mail с полученными данными.
Такая система, конечно, несет мало практической ценности, но позволяет разобраться, как все устроено:
Почему именно IoT платформа от Amazon? И зачем вообще нужно понимать, как работают IoT платформы?
M2M – IoT — IoE
В мире становится всё больше IoT устройств, об этом говорят, как аналитические агентства, так и мировая статистика.
Мы и сами прекрасно видим, что все больше систем подключаются к интернету и управляются автоматически или людьми: умные дома, автомобили, носимые устройства. И сейчас уже говорят не просто об IoT, а о IoE (Internet of Everything), т.к. устройства которые подключаются к платформам используются не только в промышленных системах, но и людьми.
Поэтому нужно самим разбираться в принципах работы, хотя бы для того, чтобы понимать, как можно эффективно использовать свои устройства или какие есть ограничения и нюансы с безопасностью.
Почему Amazon?
Amazon создает сервисы с учетом мировых трендов и в результате получаются “универсальные” системы, основные принципы которых используют все производители. У облачной платформы есть еще больший плюс – это возможность самостоятельно развернуть систему за пару часов, не привлекая корпоративную IT службу и безопасность)
Почему смартфон, а не какой-нибудь IoT Starter Kit?
При внимательном рассмотрении смартфон хорошо эмулирует IoT устройство:
- В нём есть Linux, на котором можно запускать приложения;
- Есть мобильная связь с Интернет;
- С помощью программных средств можно эмулировать показания датчиков.
Т.е. работа с настоящим IoT устройством ничем не будет отличаться от работы со смартфоном, кроме использования специфичного SDK для получения показаний датчиков. Всё остальные коммуникации будут аналогичны.
Позвольте мне пропустить раздел со стандартами, аналитикой и маркетинговыми исследованиями – в конце статьи приведу несколько актуальных ссылок. Не терпится сделать что-нибудь интересное)
AWS IoT платформа
Amazon рисует достаточно наглядную схему своей платформы:
Тут в общем все понятно:
- (1) Есть устройства, которые взаимодействуют с IoT платформой с помощью SDK.
- (2) Устройства посылают сообщения, которые проверяются службой аутентификации и авторизации.
- (3) Сообщения приходят на Device Gateway, используя разные протоколы и далее попадают в обработчик правил (4.1) и копируются (4.2) на тени устройств (Device Shadows).
- (4.2) Device Shadows – это такие цифровые двойники, которые хранят текущие состояния устройств, которые всегда доступны приложениям. С другой стороны, при отсутствии связи с устройством Device Shadow выполняет управляющие команды от приложений и при восстановлении коннективности синхронизирует актуальное состояние с устройством.
- (4.1) Обработчик правил в зависимости от поступивших данных выполняет заранее определенные действия (5.1), например, сохраняет данные в DB, посылает SMS или e-mail нотификацию, вызывает HTTP API, отправляет данные в систему аналитики и т.п.
- (5.2) Приложения используют эти данные для контроля и управления устройствами с помощью AWS API (6)
- Информация о всех устройствах хранится на AWS IoT платформе (7).
Начинаем разбираться, схема немного усложняется:
Появляются:
Jobs – выполняют стандартные действия над устройствами, например устанавливают приложения, обновляют прошивки, производят перезагрузку устройств и т.п.
Topics – сущности MQTT протокола. Сообщения от IoT устройств посылаются в определенные топики.
IAM Roles – AWS пользователи, от имени которых выполняются правила и которые имеют доступ к необходимым AWS ресурсам.
Правила состоят из:
- Filter — фильтр сообщений для обработки. Задается в виде SQL запроса.
- Action — действие, которое надо выполнить.
- Role — одна или несколько IAM ролей.
Certificate – загружаются на IoT устройство, с их помощью происходит аутентификация устройств на AWS платформе. Состоят из:
- Cертификат устройства X.509
- Private key
- Корневой сертификат AWS платформы
Policy – к сертификатам прикрепляются политики, которые определяет какие действия можно совершать устройству. С помощью политик происходит авторизация устройств.
Детализируются AWS сервисы, на которые поступает информация с IoT платформы: Аналитика, DB, сервис нотификаций SNS.
Подключаем устройство
Я не буду полностью приводить инструкцию по подключению IoT устройства к Amazon платформе: Getting Started with AWS IoT. Но для понимания объёма задачи перечислю шаги, которые нужно сделать, чтобы схема заработала:
- Создаем на платформе устройство my-iot-dev
- Получаем сертификат устройства X.509, private key, public key
- Получаем корневой сертификат AWS платформы (Root CA for AWS IoT)
- Создаем политику my-iot-dev-policy. Для нашей демы разрешаем все действия: iot:*
- Прикрепляем политику к сертификату
- Прикрепляем сертификат к устройству
- В результате получили сертификат с устройством и политикой:
- Создаем правило. Правило будет вызывать сервис нотификаций AWS SNS (Simple Notification Service) для отправки e-mail. Поэтому сначала надо создать топик в AWS SNS (my-iot-dev-sns-topic):
- Теперь конфигурируем, что именно данный топик будет делать при получении данных. Для этого создаем подписку на топик (Subscribe to the Amazon SNS topic), вводим целевой e-mail адрес, дожидаемся проверочного письма, подтверждаем e-mail.
Теперь создаем само правило (my_iot_dev_rule), которое будет вызывать созданный топик:
- Filter: SELECT * FROM ‘my/dev-topic’ — фильтр срабатывает при получении любого сообщения в топике с именем ‘my/dev-topic’;
- Action: посылка сообщения в созданный заранее SNS топик “arn:aws:sns:eu-central-1:1219xxx34064:my-iot-dev-sns-topic”;
- IAM role: создаем роль my-dev-role с доступом к SNS топикам.
- Все логические сущности для нашего устройства созданы. Теперь можно протестировать, что теоретически схема работает. Для этого в AWS есть тестовое средство, позволяющее отправлять и получать сообщения аналогично реальным устройствам. Запускаем его, подписываемся на topic (my/dev-topic) и посылаем “Hello World!” сообщение:
- Проверяем, что пришел e-mail с сообщением “Hello World!” и делаем вывод, что схема работает.
Конфигурация смартфона
Настало время конфигурации IoT устройства, в роли которого будет выступать мой смартфон. Для этого используем инструкцию AWS SDK JavaScript. Чтобы превратить смартфон в IoT устройство надо:
- Скопировать на устройство: private key, X.509 и “Root CA for AWS” сертификаты;
- Установить Node.js и npm package manager;
- Установить AWS SDK;
- Установить и запустить тестовую программу.
В нашем случае все будет немного проще, т.к. сертификаты, AWS SDK и тестовую программу я положил на GitHub и можно просто клонировать репозиторий IoT-Sensors. Если кто-нибудь захочет использовать мою тестовую программу, то в каталог /IoT/certs надо будет положить свои сертификаты и в файле /server/src/services/IoT-AOI-Server прописать актуальный для устройства Rest API Endpoint:
device = deviceModule({
…
host: 'a2lqo1xxx4zydi-ats.iot.eu-central-1.amazonaws.com',
…
})
Rest API Endpoint берется из настроек устройства:
Если хочется попробовать что-то стандартное, то можно использовать тестовые программы из поставки AWS SDK.
Android — он тот же Linux, но со своими ограничениями, поэтому для запуска JS приложений надо установить специальный терминал, например, Termux.
Для начального освоения Termux есть ряд статей, например: Запуск NodeJS-приложения на Android. Но по большому счету после установки Termux нужно выполнить всего лишь несколько магических команд:
git clone https://github.com/AlexeySushkov/IoT-Sensors.git
Установка сервера
cd ~/IoT-Sensors/server
npm install
npm start
Если все прошло успешно, в терминале появится строка:
Server started on port: 8081
Вживую это выглядит так:
Установка клиента
cd ~/IoT-Sensors/client
npm install
npm run serve
Если все прошло успешно, в терминале появится строка:
App running at port: 8080
Далее в браузере смартфона вводим: http://localhost:8080
И на экране появится тестовое приложение:
Нажимаем кнопку “INIT DEV”. При этом происходит аутентификация и авторизация IoT устройства на AWS IoT платформе. При успешном выполнении статус становится “Init OK”.
Далее вводим значения показаний датчиков температуры, влажности и давления, например:
Temperature: 23
Humidity: 65
Pressure: 787
И нажимаем кнопку “SEND DATA”.
После этого приложение добавляет метку времени и посылает данные в виде MQTT сообщения в топик “my/dev-topic”. IoT платформа получает сообщение и активирует правило, которое посылает сообщение в сервис нотификаций AWS SNS, который посылает e-mail с полученными данными в JSON формате:
{"time":"Mon, 30 Sep 2019 13:54:52 GMT", "temperature":"23", "humidity":"65", "pressure":"787"}
Если сообщение послано успешно, то статус меняется на: “publish OK” и на почту приходит e-mail:
В AWS IoT платформе есть система мониторинга, которая показывает число соединений и сообщений от IoT устройств, статистику по протоколам, типам сообщений и т.п.:
Итак, теперь все работает по-настоящему!
Заключение
Мы построили маленький, но настоящий IoT, используя платформу от Amazon. Все платформы построены по одинаковым принципам, поэтому если встанет вопрос выбора IoT системы, то мы будем готовы задать следующие вопросы. И дальше, зная ответы от Amazon, сможем сделать выводы, насколько зрелая предлагается платформа:
Устройства
- Как устройства добавляются в системе?
- Как обеспечивается аутентификация и авторизация устройств?
- Происходит ли шифрование отправляемых на платформу данных?
Платформа
- Как защищены ключи и сертификаты на платформе?
- Как формируются правила?
- Какие действия могут выполнять правила?
- Как осуществляется мониторинг и управление устройствами?
- Есть ли тени (цифровые двойники) устройств на платформе?
- Какие отчеты и аналитика доступны?
Взаимодействие
- Какие протоколы для подключения устройств используются?
- Как осуществляется взаимодействие приложений с устройством?
- Как осуществляется тестирование логики взаимодействия?
Как и обещал, приведу несколько актуальных ссылок на стандарты и аналитику:
Стандарты IoT
Как ни удивительно, но гиганты стандартизации (ISO/IEC, IEEE, ITU-T) потеряли интерес к IoT после 2016 года. Они, конечно, что-то делают, но как-то без огонька). NIST тоже выпустил свое исследование Networks of ‘Things’, но после 2016 больше ничего интересного.
Лучше выглядят телекоммуникационные институты, что не удивительно, т.к. без коннективности IoT — это не IoT. TM-Forum под своим зонтиком собирает кейсы и проекты IoE & Digital Ecosystems, ETSI поступил проще и вступил в OneM2M.
И вот мы подходим к двум организациям, которые образовались относительно недавно, но уже определяют мировое направление развитие IoT:
OneM2M
OneM2M – это объединение организаций по стандартизации, телекоммуникационных компаний и производителей разных стран. У них в открытом доступе десятки актуальных документов, которые греют душу архитектурными моделями и функциональными схемами.
IIC
IIC (Industrial Internet Consortium) — организация по стандартизации индустриального интернета вещей — это, в основном, производители софта и устройств. Они также выпускают свои эталонные архитектуры. В общем, есть где посмотреть на идеальный мир! )
Аналитика по IoT
Все наши любимые аналитические агентства выпускают исследования по IoT, но не все есть в свободном доступе. Для примера приведу несколько актуальных статей, демонстрирующие оптимистичные прогнозы по развитию IoT:
- Gartner, про IoT есть в тексте статьи: 5 Trends Appear on the Gartner Hype Cycle for Emerging Technologies, 2019
It's only the beginning!
Комментарии (13)
ramilexe
22.10.2019 13:33А есть какое-нибудь похожее решение, но self-hosted?
lingvo
22.10.2019 13:38Для такой функциональности тот же NodeRED легко справится и легче настроить. И может быть и self-hosted и не self.
AlexeySushkov Автор
22.10.2019 15:31Интернет говорит о наличии open source вариантов IoT платформ, например тот же OneM2M предоставляет список проектов, совместимых с их стандартом, но я, честно говоря, ничего из этого не пробовал, т.к. нахожусь только в начале пути)
mazy
23.10.2019 12:26завязка на облако — не всегда хорошо…
температура понизилась, термостат включил отопление, оборвали магистраль у провайдера и так и будет топить пока вручную не отключишь…
я у себе делал на RPi+Mosquitto+Node-Red, но т.к. датчики и актуаторьі — на вайфай ( дом изначально старьій и проводку под все уже не сделаешь ).
после того, как во время грозьі сгорел роутер — и управлять котлом стало невозможно, дописал код в есп, чтоб если нет вайфая — управлял сам по жестко зашитьім параметрам.AlexeySushkov Автор
23.10.2019 15:34Совершенно согласен, что облако и интернет вносят риски в схему. Впрочем как и электричество, но если с электричеством научились бороться с помощью аккумуляторов, то интернета впрок не запастись) Поэтому тут надо считать риски и, как вы, реализовывать офлайновые режимы работы.
sav6622
23.10.2019 16:34Интернет как раз проще резервируется, чем, к примеру, электричество на пару часов…
AlexeySushkov Автор
23.10.2019 17:21В городе, наверное, да, а вот если в месте установки IoT устройства есть только 1 мобильный оператор то сложнее)
lingvo
23.10.2019 18:02Тем не менее IIoT (Industrial IoT) склоняется к такому варианту — только критические вычисления и управление на Edge, а все остальное в облаке. Стандартный набор для связи — SIM + Wi-Fi + RJ45 с автоматическим переключением на резерв. Сбои в связи на минуты не должны приводить к отказам.
AlexeySushkov Автор
24.10.2019 10:58Выносить вычисления в облако тут логика понятна: устройства должны потреблять как можно меньше электричества, т.к. могут быть вообще энергонезависимы. А насчет стандартов связи для IoT, насколько мне известно, ими являются NB-IoT, работающий поверх GSM сетей и LoRaWAN, работающий в не лицензируемых частотах.
lingvo
Вы не указали, сколько будет стоить такое решение при такой функциональности. При выборе облака для IoT проекта это важный фактор, так как цена напрямую будет ложиться в стоимость устройств/сервисов.
Также насчет "Почему смартфон, а не какой-нибудь IoT Starter Kit?" — я бы сказал, что стартеркит лучше, так как смарт не позволит проверить надежность связи и ее восстановления при пропадании питания, а также непрерывной работы в режиме 24/7. А подключение к датчикам так и ограничится эмуляцией, так как физическая реализация начнет все бессмысленно усложнять. ИМХО какой-нибудь RPi был бы в данном случае не сильно сложнее, так как тот же Linux и для него практически у всех провайдеров есть API.
AlexeySushkov Автор
Согласен, что стоимость сервисов Амазон имеет значение и нужно внимательно считать затраты при принятии решения об использовании AWS для промышленного решения. Стоимость использования Амазон IoT платформы рассчитывается по числу запросов, которое в моем случае было в рамках бесплатного лимита.
И про стартер кит согласен, что он лучше и я честно искал что-нибудь приемлемое, но разнообразие устройств и комплектаций давало мне хороший шанс зря потратить 100-200 долларов, поэтому и остановился на самом простом варианте)
lingvo
RPi всегда пригодится в хозяйстве :-)
А насчет простого варианта в виде смартфона — не знаю простой ли это или только зря постраченное время. Для сбора данных вы его точно использовать не будете, а в качестве платформы для GUI вам нужно будет универсальное решение для iOS/Android. Т.е. все равно придется переделывать. И попробовать можно было бы, наверное, проще — поставить любой MQTT клиент, да с него слать ваши данные в облако.
AlexeySushkov Автор
Так я на ноуте сначала и сделал — «поставить любой MQTT клиент, да с него слать ваши данные в облако», но хотелось, чтобы конструкция была похожа на настоящий IoT )