От SMS до AWS: выбор технологии управления в зависимости от проекта

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

Задача

Мы в Synergy Team разрабатываем и выпускаем промышленные контроллеры. Они предназначены для учета ресурсов, управления объектами энергетики и других применений, которые принято называть «Интернетом вещей» (IoT). Часто нашим заказчикам не нужны просто контроллеры. Им нужно комплексное решение, включающее систему управления.

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


В этом посте мы ограничились классом задач, когда IoT контроллеры напрямую подключаются к управляющей системе (Directly-connected IoT). Итак, наша задача – разработать систему управления, которая должна:

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

Если система состоит из большого количества объектов и/или выполняет ответственные задачи, она дополнительно должна:

• постоянно контролировать наличие связи с объектами,
• собирать статистику по своей работе,
• обновлять настройки и программное обеспечение контроллеров (по запросу);
• иметь защиту от несанкционированного доступа. Для государственных и крупных частных компаний система также должна соответствовать законодательству по работе с объектами критической информационной инфраструктуры (КИИ). В частности, требованиям 187-ФЗ, ФСБ, ФСТЭК, приказам Минкомсвязи и т.п.

Управление без выделенного сервера

Для нескольких объектов задача просто решается с управлением по GSM сети посредством SMS команд или звонков. Этот подход был популярен в начале 2010х, а его плюсы и минусы описаны, например, здесь. Для большинства серьезных систем этот подход на сегодня теряет актуальность.


Чуть более сложным является «ручное» управление контроллерами по выделенным IP через WEB или командную строку (CLI). Контроллеры должны быть постоянно включены в сеть, иметь статические «белые» или «серые» IP адреса. Альтернативно можно использовать динамические IP c привязкой к статическим доменным именам по технологии DynDNS или аналогичным. Это неплохо работает, если объектов мало и к надежности не предъявляется особых требований.

Недостатки:

• неудобно, если WEB страницы от всех контроллеров нельзя разместить на экране(ах) диспетчера;
• большая абонентская плата за статические IP адреса;
• сложно настроить неподготовленным пользователям, когда устройства расположены за NAT;
• долго согласовывать с оператором связи выделение пула адресов и доступ в IP подсеть. Например, для организации GSM APN у нас уходили недели;
• неудобно, поскольку диспетчеру необходимо анализировать данные на мониторе «глазами»;
• высокий риск несанкционированного доступа к контроллерам при использовании сетей общего пользования (Интернет).

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

Здесь мы не рассматривали ситуацию, когда на одном и том же компьютере работает диспетчер и установлена система управления, поскольку считаем ее вырожденным случаем следующего пункта.

Управление через выделенный сервер

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

Если контроллеры передают данные только в направлении сервера, например, счетчики воды или простейшие навигационные устройства (трекеры), достаточно однонаправленного соединения. При этом контроллерам достаточно знать IP сервера.

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

• периодическое считывание настроек или команд с сервера по инициативе контроллера (допустимо, если не нужна быстрая реакция на команды), либо
• использование на контроллерах статических IP или доменных имен, чтобы сервер мог «достучаться» до них самостоятельно, либо
• использование протоколов связи, предусматривающих установку туннеля. В частности, MQTT, EGTS или программных брокеров (надстроек над протоколами прошлых поколений). При этом контроллерам не нужны статические IP. После включения, потери связи или перезагрузки контроллеры инициативно установят и будут поддерживать туннельное соединение с сервером.

Разработка на базе коробочных продуктов

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

Если же нужен мониторинг и/или управление однотипными объектами (как в предложенной задаче), то использование SCADA может сделать решение слишком «тяжелым» из-за сложности настройки, трудоемкости добавления типовых объектов и повышенных требований к производительности сервера. Лучше использовать одну из специализированных коробочных систем, представленных на рынке, наиболее подходящую для задачи. Например:

• систему мониторинга и управления сетевым оборудованием – Network management system (SNMP, TR-069, CLI);
• систему автоматизированного учета тепла, электричества, газа, воды. Для краткости –АСКУЭ;
• систему навигационного трекинга подвижных объектов с контролем бортовых систем;
• систему управления климатом (вентиляция, кондиционирование и отопление) – HVAC;
• систему «умный дом»/офис/здание;
• систему управления объектами энергетики: подстанциями, наружным (уличным) освещением, зарядными станциями для электротранспорта;
• систему контроля доступа и охранно-пожарной безопасности, и т.д.

Перечисленные системы часто перекрывают функционал друг друга. Например, на базе АСКУЭ можно реализовать управление наружным освещением, а на базе «Умного дома» сделать управление климатом и доступом. Расширение функционала «живых» систем происходит постоянно. Появляются новые API для интеграции коробочных продуктов в решения заказчиков, а также поддержка пользовательских функций в коробочном ПО. Огромным плюсом коробочных продуктов является тот факт, что их можно купить и поставить на свой сервер, получив отчуждаемое решение, работающее в закрытом контуре заказчика.

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

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

Разработка на базе IoT платформ

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

• регистрации и удаления IoT устройств,
• безопасной аутентификации IoT устройств и поддержания связи с ними,
• работы с данными (базы данных, оптимизированные для разных задач),
• регистрации пользователей и управления правами доступа,
• формирования аналитики по собранным данным,
• формирования уведомлений для пользователей (SMS, E-Mail, push сообщения, …),
• хранения последних данных, считанных с IoT устройств,
• выполнения различных действий по событиям,
• визуализации данных и т.п.

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

Систему на IoT платформе можно разработать за минимальное время. Ее архитектура не будет сильно меняться при увеличении размера.

Плюсы разработки на облачной IoT платформе:

• пилотный проект можно запустить с небольшими затратами. В AWS для большинства сервисов есть лимиты бесплатного использования. В Яндекс.Облаке предусмотрен тестовый период и стартовый грант.
• гибкая тарификация, например, стоимость сервиса базы данных зависит от количества запросов, а стоимость MQTT-брокера – от количества обработанных сообщений. Это особенно выгодно на старте, когда надо считать каждую копейку.
• IoT платформы протестированы на миллионах устройств. Можно быть уверенным в масштабируемости (решение не придется сильно переписывать при увеличении количества устройств) и архитектурной грамотности решения (если советоваться с инженерами по поддержке используемых IoT платформ).
• информационная безопасность обеспечивается самой платформой на различных уровнях.
• задачу первичной разработки можно отдать на аутсорс. В перспективе решение смогут сопровождать не только разработчики изначальной системы, как это бывает обычно. Ведь IoT платформы имеют мощную техподдержку, подробно документированы, а количество разработчиков, умеющих с ними работать, неуклонно растет.

Недостатки:

• компоненты IoT платформ работают только на мощностях их владельцев, создать полностью отчуждаемую систему, которая будет работать в ЦОД заказчика, возможно в редких случаях;
• стоимость использования IoT платформы для крупных проектов может быть выше стоимости аренды виртуальных машин в ЦОД;
• миграция с одной IoT платформы на другую связана с изменением приличного объема кода. Хотя сейчас наметилась тенденция к стандартизации API;
• далеко не все IoT платформы развернуты в ЦОДах внутри России, что делает невозможным их использование в интересах государственных заказчиков.

Полностью своя разработка

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

Собственные решения часто реализуют на базе таких open-source систем, как ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia glial. Для небольших проектов они могут оказаться слишком «тяжелыми» из-за:

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

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

Если нужна быстрая демонстрация (MVP), то ее можно сделать на IoT платформе или коробочном ПО, взяв «на вооружение» проверенные временем подходы, параллельно разрабатывая свое большое решение.

Заключение

На основе сделанного анализа разных систем предлагаем следующий алгоритм выбора системы управления.



Для демонстраций и маленьких IoT проектов на несколько объектов можно использовать прямое управление по IP, SMS или через GSM звонки. В остальных случаях необходима система верхнего уровня. Использование SCADA оправдано в промышленной автоматизации и на больших объектах энергетики. Для учета ресурсов, управления сетевым оборудованием, трекинга, охраны, «умного дома» и т.п. удобно использовать коробочное решение нужной специализации. Разработка систем на IoT платформах сложнее, но дает больше перспектив и гибкости. Решения на зарубежных IoT платформах серьезно ограничены по масштабу и областям применений в России. Самой сложной является полностью своя разработка. И она оправдана только для госзаказа и самых амбициозных проектов. При этом для быстрых демонстраций и копирования лучших практик будет полезно параллельно с собственной разработкой сделать эскизный проект на IoT платформе.

Напоследок хотим поделиться небольшим прогнозом:

• в облачных IoT платформах стоит ждать появление преднастроенных шаблонов «Умного дома», АСКУЭ, NMS, СКУД и т.п. Это еще больше упростит использование IoT платформ и привлечет к ним еще большую аудиторию.
• традиционные разработчики SCADA и других коробочных решений предложат больше инструментов для внешних разработчиков, которые хорошо зарекомендовали себя в IoT платформах. Закрытые коробочные решения вряд ли выдержат рыночную конкуренцию.
• отечественные IoT платформы для государственных и больших частных заказчиков будут развиваться еще активнее.
• API разных IoT платформ станут со временем более похожими друг на друга. Из-за этого переход с одной IoT платформы на другую будет упрощаться.

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

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