В предыдущем посте был предложен алгоритм выбора системы управления для разных задач «Интернета вещей». Для решений среднего масштаба оптимальным оказалось использование облачных IoT платформ.
Этот материал о том, как мы реализовали систему мониторинга и управления на базе платформы Amazon WEB Services (AWS). В качестве объекта управления рассмотрен шкаф связи, напоминающий маленький «Умный дом». Внутри такого шкафа может быть установлено оборудование сотовой или фиксированной связи, городского WiFi, видеонаблюдения, управления освещением или т.п., а также устройства электропитания и климат-контроля. С использованием контроллера«умного дома» шкафа, набора датчиков и системы верхнего уровня оператор может наблюдать за состоянием оборудования, микроклиматом и охранно-пожарной безопасностью.
Рассмотрим создание двухуровневой системы, структурная схема которой показана ниже.
На нижнем уровне должны использоваться контроллеры с датчиками, исполнительными и цифровыми устройствами.
Сегодня в мире разработано более 600 IoT платформ и это количество постоянно растет. При этом наибольшей популярностью у разработчиков в 2019 году пользовалась платформа Amazon WEB Services (AWS). Доминирующая позиция AWS определила наш выбор данной платформы в качестве базовой для нашей системы ST-Eye. На решение также повлияла оперативная техническая поддержка и наличие большого количества справочной информации. Ребята из AWS поделились лучшими практиками и помогли выбрать наиболее эффективные технологии.
Ниже приведены архитектура и описание системы ST-Eye.
Объектовые контроллеры подключаются к сервису AWS IoT-Core с использованием протокола TLS. Адрес сервера, используемый для подключения, содержит уникальный для учетной записи идентификатор. Аутентификация осуществляется по протоколу x509. Каждое устройство при этом использует собственный уникальный сертификат. Кроме собственного сертификата, на контроллере сохранен сертификат удостоверяющего центра для проверки подлинности сервера. Создание и распространение сертификатов осуществляется средствами платформы AWS. После успешной аутентификации используется протокол MQTT, ставший стандартом де-факто в IoT. В основе протокола MQTT лежит взаимодействие клиентов друг с другом по принципу pub/sub. Клиенты публикуют сообщения в каналы (топики)и подписываются на имеющиеся топики других клиентов. Это обеспечивает промежуточный сервис — брокер, который хранит список топиков и списки подписчиков по каждому из имеющихся топиков. Сервис IoT-Core предоставляет несколько стандартных топиков для подписки и публикации, можно создавать другие топики. Они будут доступны в пределах региона AWS и учетной записи. Например, контроллеры подписываются на топики прямого управления, а WEB-приложение публикует в них команды. Благодаря низким требованиям MQTT к ресурсам, время реакции контроллера на команду оператора минимально (в нашей системе — не более 0.5 сек при использовании офисного Ethernet соединения). IoT-Core это управляемый (managed) сервис, соответственно, резервирование и масштабирование выполняются без участия пользователя.
Одна из ключевых функций сервиса IoT-Core – виртуальный образ устройства shadow (англ. «тень»). Он позволяет получать последнее известное состояние устройства и отображать его даже тогда, когда устройство не доступно по сети. Такая возможность незаменима для работы с GSM устройствами или устройствами на батарейном питании, поскольку они могут находиться не на связи длительное время. Shadow — это JSON объект, содержащий два основных поля: reported и desired. В каждом поле содержатся пары ключ-значение, соответствующие выходным данным и/или параметрам устройства. При изменении желаемых параметров устройства формируется поле delta, содержащее разницу между полями desired и reported. Устройство подписывается на топик $aws/things/thingName/shadow/update/delta и обновляет свое внутреннее состояние при наличии параметров в поле delta. Shadow содержит дату и время последнего обновления. Таким образом приложение верхнего уровня получает информацию о том, как давно контроллер выходил на связь последний раз.
Сервис IoT-Core также предоставляет гибкую систему правил для взаимодействия с другими сервисами. В нашем приложении правила IoT-Core используются, например, для отправки уведомлений и для активации устройств. Настройка уведомлений производится в АРМ администратора. Доступны SMS оповещения, электронная почта, push.
К процессу обновления ПО в IoT устройствах предъявляются строгие требования. Источник обновления и контейнер с новой прошивкой должны быть проверены на подлинность и совместимость с контроллером. В противном случае контроллер после обновления может превратиться в «кирпич». Для выполнения обновления ПО (Firmware over the air — FOTA) или конфигурации устройства применяется механизм Job. Контроллер получает набор команд и дополнительные данные через специальный топик, затем последовательно выполняет команды. Например, скачивает прошивку с облачного хранилища AWS S3 по ссылке и проверяет ее подпись.
Для обработки данных, поступающих от сервиса IoT-Core в AWS, используется подсистема IoT-Analytics. Блок channel с помощью sql-подобных правил позволяет выбрать источник данных, например, отдельные поля сообщений, поступающих от устройств. Сырые данные, поступающие через channel, могут сохраняться во внутреннее хранилище сервиса или в S3. Компонент pipeline позволяет провести предварительную обработку, фильтрацию данных, или дополнить их. Например, на основе некоторых данных можно сделать запрос к базе данных (БД) или внешнему сервису и добавить информацию из ответа. Предобработанные данные сохраняются в базу данных datastore. Эта БД относится к типу time series database (TSDB) и предназначена для работы с данными, поступающими от датчиков с привязкой ко времени. С использованием этих данных можно отследить изменение каждого параметра системы в течение всего периода наблюдения. В отличие от других типов БД, в TSDB имеются такие инструменты, как политики хранения/удаления данных, планировщик запросов и гибкие функции агрегации.
К записям в datastore в последствии применяются выборки данных (datasets). Они могут быть реализованы в виде SQL запросов и выполняться планировщиком внутри подсистемы IoT-Analytics, а, если требуется более сложная логика, в Docker-контейнере. Результаты постобработки хранятся в сервисном хранилище и доступны в течение 90 дней из WEB приложения и сервиса визуализации данных (Quicksight). По истечении срока хранения, данные переносятся в холодное хранилище на S3 с помощью Lambda функции.
На верхнем уровне системы реализован WEB портал, представленный несколькими автоматизированными рабочими местами (АРМ), в частности, администратора, аналитика/руководителя и диспетчера.
Рассмотрим АРМ диспетчера. Его главное окно имеет вид таблицы, в которую сведены данные по группам объектов.
Каждый объект может находиться в одном из пяти состояний: норма, авария/тревога, нарушение, сервисный режим и отсутствие связи. Каждая ячейка таблицы позволяет перейти к списку соответствующих объектов с более подробной информацией:
Кликнув по соответствующему устройству в списке, можно открыть страницу его мониторинга и управления.
WEB приложение использует протокол TLS в качестве транспорта для подключения к AWS. Аутентификация работает по алгоритму Signature V4 и использует микросервис Cognito. Код приложения размещается в хранилище S3. Портал использует механизм Continuous Integration. Новые версии автоматически проходят тестирование и, при успешном результате, применяются к платформе. Для контроля версий и автоматического развертывания используется сервис Beanstalk.
В российском законодательстве для государственных применений (B2G) имеются ограничения по использованию серверов за пределами России, например, 187-ФЗ. Наиболее продвинутый российский облачный сервис — Яндекс.Облако, частью которого является IoT платформа. На старте работ над нашей системой некоторые компоненты, доступные в AWS, еще не были представлены у Яндекса. В частности, для создания законченного решения требовался собственный бэкэнд для взаимодействия с WEB приложением и MQTT брокером. С другой стороны, Яндекс уже предлагал богатые инструменты аналитики и баз данных, средства для развертывания приложений и облачное хранилище (Object Storage). Уже доступен сервис Datalens для визуализации данных (аналог AWS Quicksight), а также БД ClickHouse, прекрасно подходящая для хранения time series данных.
Яндекс делает большой вклад в развитие Open Source в мире, а также, старается делать свои продукты совместимыми с уже существующими решениями. Так, например, можно работать с Object Storage Яндекс с помощью утилиты aws-cli, используя команды для AWS S3.
Рынок объектовых контроллеров достаточно большой. Количество опций и производителей, из которых можно выбирать, идет на десятки, а моделей – на сотни. Как правило, при создании систем управления используют контроллеры, с которыми уже умеют работать, либо которые рекомендует поставщик системы верхнего уровня. Такое положение вещей единственно возможно при использовании систем верхнего уровня, разработанных под определенное оборудование (hardware-specific software platforms) и работающих с контроллерами по закрытым протоколам обмена.
При использовании систем верхнего уровня, работающих по открытым протоколам (облачные IoT платформы именно такие), можно сэкономить, подобрав оптимальное оборудование под требования проекта. Пример таких требований приведен выше в пункте «Функции системы нижнего уровня и требования к контроллеру».
Для B2G решений в соответствии с ПП-878 лучше ориентироваться на российские контроллеры. Для некоторых областей становится все более важным использование оборудования на российской элементной базе.
Не всем известна опция по разработке контроллеров на заказ. Она может окупиться за счет использования недорогой элементной базы и реализации нужного количества функциональных блоков под конкретный проект. Кроме этого, комплекс оборудования на объекте будет состоять из минимального количества устройств (иногда всего одного), а значит будет меньше работ по сборке, установке и пусконаладке.
Заказная разработка контроллера может окупиться за счет более низкой стоимости оборудования, меньшего объема монтажных и пуско-наладочных работ.
Для описанной задачи мы использовали контроллер GiC (Generic Internet Controller) собственной разработки. Он снабжен необходимым количеством сетевых интерфейсов, портов ввода-вывода, встроенным блоком питания, поддерживает протоколы MQTT, WEB, SNMP, ModBUS и может опрашивать различные цифровые устройства: приборы учета, системы электропитания, кондиционеры (перечень постоянно расширяется).
Выше мы рассказали, как сделана наша система управления на AWS. Облачные технологии упрощают подобные разработки, но еще нельзя утверждать, что это дело пары кликов. Если ваша задача похожа на нашу, обращайтесь.
В IoT платформах стоит ждать появления преднастроенных шаблонов систем «Умного дома», АСКУЭ, NMS, СКУД и т.п. Это еще упростит создание законченных решений, снизит порог входа в данный бизнес и привлечет дополнительную аудиторию к облачным технологиям.
IoT платформы используют открытые протоколы обмена с контроллерами. Благодаря этому пользователи получают свободу выбора объектового оборудования. Появляется возможность заказной разработки контроллеров (наша специализация). Использование заказных контроллеров может уменьшить бюджет проекта.
Для государственных проектов и проектов, относящихся к критической информационной инфраструктуре, лучше ориентироваться на российские системы и объектовое оборудование, благо рынок таких систем уже сформирован и развивается.
Этот материал о том, как мы реализовали систему мониторинга и управления на базе платформы Amazon WEB Services (AWS). В качестве объекта управления рассмотрен шкаф связи, напоминающий маленький «Умный дом». Внутри такого шкафа может быть установлено оборудование сотовой или фиксированной связи, городского WiFi, видеонаблюдения, управления освещением или т.п., а также устройства электропитания и климат-контроля. С использованием контроллера
Задача
Рассмотрим создание двухуровневой системы, структурная схема которой показана ниже.
На нижнем уровне должны использоваться контроллеры с датчиками, исполнительными и цифровыми устройствами.
Функции системы нижнего уровня и требования к контроллеру
| Функции | Требования к контроллеру |
| Питание от сети или системы резервного питания постоянного тока | Блок питания на 220VAC, либо 18..72VDC (для шкафов с системой резервного питания) |
| Связь с системой верхнего уровня | Порт Ethernet и/или 2G/LTE модуль.Поддержка протоколов: MQTT/TLS, WEB, интерфейс командной строки (CLI), SNMP v.1-3, Syslog, Radius авторизация. |
| Связь с ИБП, кондиционером, счетчиком электроэнергии и другим объектовым оборудованием | RS485, RS232, CAN, USB, дополнительный Ethernet порт. Программная поддержка протоколов работы с подключаемым оборудованием |
| Охранно-пожарная сигнализация: контроль датчиков дверей, вибрации, движения людей, задымления, протечки. Мониторинг показаний датчиков температуры, влажности |
Входы-выходы для дискретных и цифровых DHT датчиков, а также для подключения внешних реле; Токовые входы 0..20мА для аналоговых датчиков, датчиков NAMUR. Функция сброса питания для пожарных извещателей;1-Wire порт для подключения нескольких цифровых датчиков от Maxim Integrated. |
| Дистанционное включение и выключение питания серверов или активного оборудования связи, вентиляторов, нагревателей (если не используется кондиционер) | Релейные выходы Uном = 230В, Imax > 5A(при управлении мощными потребителями через внешние реле) |
Требования к системе верхнего уровня
- должна использоваться система управления на базе облачной IoT платформы,
- система должна предусматривать работу с тысячами контролируемых объектов без необходимости переделки архитектуры,
- архитектура системы должна подходить как для B2B решений, так и для B2C систем класса «умный дом»,
- система должна постоянно контролировать наличие связи с объектами и собирать статистику по своей работе,
- система должна автоматизированно обновлять настройки и программное обеспечение контроллеров;
- в качестве основного пользовательского интерфейса должен использоваться WEB интерфейс,
- в перспективе система должна также работать через мобильное приложение,
- система должна иметь защиту от несанкционированного доступа на уровнях связи с пользователями и оборудованием.
Разработка системы верхнего уровня
Сегодня в мире разработано более 600 IoT платформ и это количество постоянно растет. При этом наибольшей популярностью у разработчиков в 2019 году пользовалась платформа Amazon WEB Services (AWS). Доминирующая позиция AWS определила наш выбор данной платформы в качестве базовой для нашей системы ST-Eye. На решение также повлияла оперативная техническая поддержка и наличие большого количества справочной информации. Ребята из AWS поделились лучшими практиками и помогли выбрать наиболее эффективные технологии.
Ниже приведены архитектура и описание системы ST-Eye.
Архитектура IoT системы ST-Eye на платформе AWS
Уровень связи с контроллерами
Объектовые контроллеры подключаются к сервису AWS IoT-Core с использованием протокола TLS. Адрес сервера, используемый для подключения, содержит уникальный для учетной записи идентификатор. Аутентификация осуществляется по протоколу x509. Каждое устройство при этом использует собственный уникальный сертификат. Кроме собственного сертификата, на контроллере сохранен сертификат удостоверяющего центра для проверки подлинности сервера. Создание и распространение сертификатов осуществляется средствами платформы AWS. После успешной аутентификации используется протокол MQTT, ставший стандартом де-факто в IoT. В основе протокола MQTT лежит взаимодействие клиентов друг с другом по принципу pub/sub. Клиенты публикуют сообщения в каналы (топики)и подписываются на имеющиеся топики других клиентов. Это обеспечивает промежуточный сервис — брокер, который хранит список топиков и списки подписчиков по каждому из имеющихся топиков. Сервис IoT-Core предоставляет несколько стандартных топиков для подписки и публикации, можно создавать другие топики. Они будут доступны в пределах региона AWS и учетной записи. Например, контроллеры подписываются на топики прямого управления, а WEB-приложение публикует в них команды. Благодаря низким требованиям MQTT к ресурсам, время реакции контроллера на команду оператора минимально (в нашей системе — не более 0.5 сек при использовании офисного Ethernet соединения). IoT-Core это управляемый (managed) сервис, соответственно, резервирование и масштабирование выполняются без участия пользователя.
Одна из ключевых функций сервиса IoT-Core – виртуальный образ устройства shadow (англ. «тень»). Он позволяет получать последнее известное состояние устройства и отображать его даже тогда, когда устройство не доступно по сети. Такая возможность незаменима для работы с GSM устройствами или устройствами на батарейном питании, поскольку они могут находиться не на связи длительное время. Shadow — это JSON объект, содержащий два основных поля: reported и desired. В каждом поле содержатся пары ключ-значение, соответствующие выходным данным и/или параметрам устройства. При изменении желаемых параметров устройства формируется поле delta, содержащее разницу между полями desired и reported. Устройство подписывается на топик $aws/things/thingName/shadow/update/delta и обновляет свое внутреннее состояние при наличии параметров в поле delta. Shadow содержит дату и время последнего обновления. Таким образом приложение верхнего уровня получает информацию о том, как давно контроллер выходил на связь последний раз.
Сервис IoT-Core также предоставляет гибкую систему правил для взаимодействия с другими сервисами. В нашем приложении правила IoT-Core используются, например, для отправки уведомлений и для активации устройств. Настройка уведомлений производится в АРМ администратора. Доступны SMS оповещения, электронная почта, push.
К процессу обновления ПО в IoT устройствах предъявляются строгие требования. Источник обновления и контейнер с новой прошивкой должны быть проверены на подлинность и совместимость с контроллером. В противном случае контроллер после обновления может превратиться в «кирпич». Для выполнения обновления ПО (Firmware over the air — FOTA) или конфигурации устройства применяется механизм Job. Контроллер получает набор команд и дополнительные данные через специальный топик, затем последовательно выполняет команды. Например, скачивает прошивку с облачного хранилища AWS S3 по ссылке и проверяет ее подпись.
Уровень обработки данных
Для обработки данных, поступающих от сервиса IoT-Core в AWS, используется подсистема IoT-Analytics. Блок channel с помощью sql-подобных правил позволяет выбрать источник данных, например, отдельные поля сообщений, поступающих от устройств. Сырые данные, поступающие через channel, могут сохраняться во внутреннее хранилище сервиса или в S3. Компонент pipeline позволяет провести предварительную обработку, фильтрацию данных, или дополнить их. Например, на основе некоторых данных можно сделать запрос к базе данных (БД) или внешнему сервису и добавить информацию из ответа. Предобработанные данные сохраняются в базу данных datastore. Эта БД относится к типу time series database (TSDB) и предназначена для работы с данными, поступающими от датчиков с привязкой ко времени. С использованием этих данных можно отследить изменение каждого параметра системы в течение всего периода наблюдения. В отличие от других типов БД, в TSDB имеются такие инструменты, как политики хранения/удаления данных, планировщик запросов и гибкие функции агрегации.
К записям в datastore в последствии применяются выборки данных (datasets). Они могут быть реализованы в виде SQL запросов и выполняться планировщиком внутри подсистемы IoT-Analytics, а, если требуется более сложная логика, в Docker-контейнере. Результаты постобработки хранятся в сервисном хранилище и доступны в течение 90 дней из WEB приложения и сервиса визуализации данных (Quicksight). По истечении срока хранения, данные переносятся в холодное хранилище на S3 с помощью Lambda функции.
Уровень визуализации (WEB app)
На верхнем уровне системы реализован WEB портал, представленный несколькими автоматизированными рабочими местами (АРМ), в частности, администратора, аналитика/руководителя и диспетчера.
Рассмотрим АРМ диспетчера. Его главное окно имеет вид таблицы, в которую сведены данные по группам объектов.
Каждый объект может находиться в одном из пяти состояний: норма, авария/тревога, нарушение, сервисный режим и отсутствие связи. Каждая ячейка таблицы позволяет перейти к списку соответствующих объектов с более подробной информацией:
Кликнув по соответствующему устройству в списке, можно открыть страницу его мониторинга и управления.
WEB приложение использует протокол TLS в качестве транспорта для подключения к AWS. Аутентификация работает по алгоритму Signature V4 и использует микросервис Cognito. Код приложения размещается в хранилище S3. Портал использует механизм Continuous Integration. Новые версии автоматически проходят тестирование и, при успешном результате, применяются к платформе. Для контроля версий и автоматического развертывания используется сервис Beanstalk.
Импортозамещение
В российском законодательстве для государственных применений (B2G) имеются ограничения по использованию серверов за пределами России, например, 187-ФЗ. Наиболее продвинутый российский облачный сервис — Яндекс.Облако, частью которого является IoT платформа. На старте работ над нашей системой некоторые компоненты, доступные в AWS, еще не были представлены у Яндекса. В частности, для создания законченного решения требовался собственный бэкэнд для взаимодействия с WEB приложением и MQTT брокером. С другой стороны, Яндекс уже предлагал богатые инструменты аналитики и баз данных, средства для развертывания приложений и облачное хранилище (Object Storage). Уже доступен сервис Datalens для визуализации данных (аналог AWS Quicksight), а также БД ClickHouse, прекрасно подходящая для хранения time series данных.
Яндекс делает большой вклад в развитие Open Source в мире, а также, старается делать свои продукты совместимыми с уже существующими решениями. Так, например, можно работать с Object Storage Яндекс с помощью утилиты aws-cli, используя команды для AWS S3.
Выбор объектовых контроллеров
Рынок объектовых контроллеров достаточно большой. Количество опций и производителей, из которых можно выбирать, идет на десятки, а моделей – на сотни. Как правило, при создании систем управления используют контроллеры, с которыми уже умеют работать, либо которые рекомендует поставщик системы верхнего уровня. Такое положение вещей единственно возможно при использовании систем верхнего уровня, разработанных под определенное оборудование (hardware-specific software platforms) и работающих с контроллерами по закрытым протоколам обмена.
При использовании систем верхнего уровня, работающих по открытым протоколам (облачные IoT платформы именно такие), можно сэкономить, подобрав оптимальное оборудование под требования проекта. Пример таких требований приведен выше в пункте «Функции системы нижнего уровня и требования к контроллеру».
Для B2G решений в соответствии с ПП-878 лучше ориентироваться на российские контроллеры. Для некоторых областей становится все более важным использование оборудования на российской элементной базе.
Не всем известна опция по разработке контроллеров на заказ. Она может окупиться за счет использования недорогой элементной базы и реализации нужного количества функциональных блоков под конкретный проект. Кроме этого, комплекс оборудования на объекте будет состоять из минимального количества устройств (иногда всего одного), а значит будет меньше работ по сборке, установке и пусконаладке.
Заказная разработка контроллера может окупиться за счет более низкой стоимости оборудования, меньшего объема монтажных и пуско-наладочных работ.
Для описанной задачи мы использовали контроллер GiC (Generic Internet Controller) собственной разработки. Он снабжен необходимым количеством сетевых интерфейсов, портов ввода-вывода, встроенным блоком питания, поддерживает протоколы MQTT, WEB, SNMP, ModBUS и может опрашивать различные цифровые устройства: приборы учета, системы электропитания, кондиционеры (перечень постоянно расширяется).
Заключение
Выше мы рассказали, как сделана наша система управления на AWS. Облачные технологии упрощают подобные разработки, но еще нельзя утверждать, что это дело пары кликов. Если ваша задача похожа на нашу, обращайтесь.
В IoT платформах стоит ждать появления преднастроенных шаблонов систем «Умного дома», АСКУЭ, NMS, СКУД и т.п. Это еще упростит создание законченных решений, снизит порог входа в данный бизнес и привлечет дополнительную аудиторию к облачным технологиям.
IoT платформы используют открытые протоколы обмена с контроллерами. Благодаря этому пользователи получают свободу выбора объектового оборудования. Появляется возможность заказной разработки контроллеров (наша специализация). Использование заказных контроллеров может уменьшить бюджет проекта.
Для государственных проектов и проектов, относящихся к критической информационной инфраструктуре, лучше ориентироваться на российские системы и объектовое оборудование, благо рынок таких систем уже сформирован и развивается.
