Пост ориентирован на людей, задумывающихся о создании своей первой системы управления.
Опытных специалистов может заинтересовать «взгляд сверху» на разные технологии управления Интернетом вещей, выводы и краткий прогноз в заключении.
Задача
Мы в Команда Синергия Мы разрабатываем и производим промышленные контроллеры.Они предназначены для учета ресурсов, управления энергетическими объектами и других приложений, которые принято называть Интернетом вещей (IoT).
Зачастую нашим клиентам нужны не просто контроллеры.
Им нужно комплексное решение, включающее систему управления.
И эта система должна быть близка к оптимальной: быстрой, простой и надежной.
Но, согласно известному анекдоту, одновременно выполнить все эти требования невозможно.
Нужно искать баланс в зависимости от задачи, что мы и попытались сделать.
В этом посте мы ограничились классом задач, когда IoT-контроллеры напрямую подключены к системе управления ( Интернет вещей с прямым подключением ).
Итак, наша задача – разработать систему управления, которая должна:
- передавать данные от датчиков, подключенных к контроллерам,
- передавать события (например, о повышении температуры, открытии двери, потере связи и т.п.
),
- передавать команды управления на исполнительные механизмы,
- постоянно следить за наличием связи с объектами,
- собирать статистику о своей работе,
- обновить настройки и программное обеспечение контроллера (по запросу);
- быть защищены от несанкционированного доступа.
Для государственных и крупных частных компаний система также должна соответствовать законодательству о работе с объектами критической информационной инфраструктуры (КИИ).
В частности, требования 187-ФЗ, ФСБ, ФСТЭК, приказы Минкомсвязи и др.
Управление без выделенного сервера
Для некоторых объектов проблема просто решается контролем над сетью GSM посредством СМС-команд или звонков.Этот подход был популярен в начале 2010-х годов, его плюсы и минусы описаны, например, Здесь .
Для большинства серьезных систем такой подход сегодня теряет актуальность.
Немного сложнее «ручное» управление контроллерами по выделенным IP-адресам через WEB или командную строку (CLI).
Контроллеры должны быть постоянно подключены к сети и иметь статические «белые» или «серые» IP-адреса.
Альтернативно вы можете использовать динамические IP-адреса, связанные со статическими доменными именами, используя технологию ДинДНС или похожий .
Это хорошо работает, если объектов мало и нет особых требований к надежности.
Недостатки:
- неудобно, если WEB-страницы со всех контроллеров не могут быть размещены на экране(ах) диспетчера;
- большая абонентская плата за статические IP-адреса;
- сложность настройки неподготовленным пользователям, когда устройства расположены за NAT;
- Долго согласовывать с оператором связи выделение пула адресов и доступ к IP-подсети.
Например, нам потребовались недели, чтобы настроить GSM APN;
- неудобно, так как диспетчеру необходимо «глазами» анализировать данные на мониторе;
- высокий риск несанкционированного доступа к контроллерам при использовании сетей общего пользования (Интернет).
Здесь мы не рассматривали ситуацию, когда на одном компьютере работает диспетчер и установлена система управления, поскольку считаем ее вырожденным случаем следующего пункта.
Управление через выделенный сервер
В остальных случаях необходим сервер с выделенным IP, через который будут подключаться контроллеры, диспетчеры и сторонние системы.
Если контроллеры передают данные только в сторону сервера, например счетчики воды или простые навигационные устройства (трекеры), достаточно однонаправленного соединения.
В этом случае контроллерам достаточно знать IP сервера.
В нашей задаче обновление ПО контроллера и передача команд требует двустороннего обмена данными.
Для организации такого обмена необходимо:
- периодическое чтение настроек или команд с сервера по инициативе контроллера (допустимо, если не требуется быстрое реагирование на команды), или
- использование статических IP-адресов или доменных имен на контроллерах, чтобы сервер мог «достучаться» до них независимо, или
- использование протоколов связи, предусматривающих установку туннеля.
В частности, MQTT, EGTS или программные брокеры (дополнения к протоколам предыдущего поколения).
В этом случае контроллерам не нужны статические IP-адреса.
После включения питания, потери соединения или перезагрузки контроллеры заранее устанавливают и поддерживают туннельное соединение с сервером.
Разработка на основе упакованных продуктов
Когда речь идет о системе управления, основанной на проверенном и надежном решении, первое, что приходит на ум, — это SCADA. И это вполне оправдано, если речь идет об автоматизации производства или крупного энергетического объекта.Короче говоря, когда система содержит большое количество датчиков и исполнительных механизмов разного типа.
Такие системы требуют разработки уникальных мнемосхем и алгоритмов взаимодействия оборудования для каждого объекта, что прекрасно продумано в SCADA. Если вам необходимо отслеживать и/или управлять однотипными объектами (как в предлагаемой задаче), то использование SCADA может сделать решение слишком «тяжелым» из-за сложности настройки, сложности добавления стандартных объектов и увеличения Требования к производительности сервера.
Лучше использовать одну из представленных на рынке специализированных коробочных систем, наиболее подходящую для поставленной задачи.
Например:
- система мониторинга и управления сетевым оборудованием - Система управления сетью (SNMP, TR-069, CLI);
- автоматизированная система учета тепла, электроэнергии, газа, воды.
Сокращенно –АСКУ?;
- система навигационного слежения за движущимися объектами с контролем бортовых систем;
- система климат-контроля (вентиляция, кондиционирование и отопление) - HVAC;
- система «умный дом/офис/здание»;
- системы управления энергообъектами: подстанциями, наружным (уличным) освещением, зарядными станциями для электромобилей;
- системы контроля доступа и пожарной безопасности и т.д.
Например, на базе АСКУ? Можно реализовать управление внешним освещением, а на базе «Умного дома» управлять климатом и доступом.
Функционал «живых» систем постоянно расширяется.
Появляются новые API-интерфейсы для интеграции пакетных продуктов в решения клиентов, а также поддержки пользовательских функций в пакетном программном обеспечении.
Огромным преимуществом пакетных продуктов является тот факт, что вы можете купить их и установить на свой сервер, получив отчуждаемое решение, работающее в замкнутом контуре клиента.
Если у вас есть планы продавать собственную систему на свободном рынке, нужно понимать, что сегодняшний поставщик пакетного ПО завтра может перерасти в конкурента.
Кроме того, использование коробочных систем несет в себе дополнительные риски, такие как:
- рост цен на лицензии,
- слабый контроль над системой (нет источников, даже если они есть, поддерживать их крайне сложно),
- многие системы можно использовать только как облачный сервис, что может не подходить для крупных и/или государственных проектов.
Разработка на базе IoT-платформ
Если использование пакетного программного обеспечения невозможно, хорошей идеей будет разработка на одном из популярные платформы Интернета вещей .Такие платформы содержат универсальные модули требуется в любой системе IoT для:
- регистрация и удаление IoT-устройств,
- безопасно аутентифицировать устройства IoT и поддерживать связь с ними,
- работа с данными (базы данных, оптимизированные под разные задачи),
- регистрация пользователей и управление правами доступа,
- генерирование аналитики на основе собранных данных,
- создание уведомлений для пользователей (SMS, электронная почта, push-сообщения, .
),
- хранение последних данных, считанных с устройств IoT,
- выполнение различных действий на основе событий,
- визуализация данных и т. д.
Все задачи по балансировке нагрузки, устранению «тормозов» базы данных и «тяжелых» функций берет на себя платформа.
Кроме того, серверная часть приложения быстро собирается из «кубиков» — микросервисов.
Сокращаются как время вывода на рынок, так и стоимость решения, которая напрямую зависит от оплаты программистов.
Систему на платформе IoT можно разработать за минимальное время.
Его архитектура не сильно изменится по мере увеличения размера.
Преимущества разработки на облачной IoT-платформе:
- пилотный проект может быть запущен с небольшими затратами.
AWS имеет ограничения на бесплатное использование для большинства сервисов.
Яндекс.
Облако предоставляет тестовый период и стартовый грант .
- гибкое ценообразование, например, стоимость услуги базы данных зависит от количества запросов, а стоимость MQTT-брокера зависит от количества обработанных сообщений.
Особенно это выгодно на старте, когда нужно считать каждую копейку.
- Платформы Интернета вещей были протестированы на миллионах устройств.
Вы можете быть уверены в масштабируемости (решение не придется сильно переписывать по мере увеличения количества устройств) и архитектурной грамотности решения (если проконсультироваться с инженерами по поддержке используемых IoT-платформ).
- информационная безопасность обеспечивается самой платформой на различных уровнях.
- задачу первичной разработки можно передать на аутсорсинг.
В дальнейшем решение будет поддерживаться не только разработчиками исходной системы, как это обычно бывает. Ведь IoT-платформы имеют мощную техническую поддержку, детально документированы, а число разработчиков, умеющих с ними работать, неуклонно растет.
- компоненты IoT-платформ работают только на объектах своих владельцев; в редких случаях возможно создание полностью отчужденной системы, которая будет работать в дата-центре заказчика;
- стоимость использования IoT-платформы для крупных проектов может быть выше стоимости аренды виртуальных машин в дата-центре;
- миграция с одной платформы Интернета вещей на другую предполагает изменение значительного объема кода.
Хотя сейчас наблюдается тенденция к стандартизации API;
- Не все IoT-платформы развернуты в дата-центрах на территории России, что делает невозможным их использование в интересах госзаказчиков.
Полностью наша собственная разработка
Если недостатки предыдущих решений критичны, необходимо разработать собственное решение.И каким бы хорошим ни был план, первые версии системы будут кривыми.
Собственные решения зачастую реализуются на базе таких open-source систем, как ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia gial. Для небольших проектов они могут оказаться слишком «тяжелыми» из-за:
- длительный период разработки и соответствующие финансовые затраты.
Обычно подсчет ведется в человеко-летах;
- при увеличении количества объектов будут возникать узкие места в виде медленных баз данных, сборщиков, генераторов отчетов и т.п.
, решение которых потребует изменения архитектуры и добавления балансировщиков и дублирующих ресурсов;
- расходы на текущее администрирование и техническую поддержку.
Если вам нужна быстрая демонстрация ( MVP ), то это можно сделать на IoT-платформе или пакетном программном обеспечении, применив проверенные временем подходы и одновременно разработав собственное крупное решение.
Заключение
На основе анализа различных систем мы предлагаем следующий алгоритм выбора системы управления.
Для демонстраций и небольших IoT-проектов для нескольких объектов можно использовать прямое управление через IP, SMS или GSM-звонки.
В остальных случаях требуется система верхнего уровня.
Использование SCADA оправдано в промышленной автоматизации и на крупных энергетических объектах.
Для учета ресурсов, управления сетевым оборудованием, трекинга, безопасности, умного дома и т. д. Удобно использовать коробочное решение необходимой специализации.
Разработка систем на IoT-платформах сложнее, но дает больше перспектив и гибкости.
Решения на зарубежных IoT-платформах серьезно ограничены по масштабам и сферам применения в России.
Самое сложное — разработать свою полностью.
И это оправдано только для госзаказа и самых амбициозных проектов.
При этом для быстрой демонстрации и копирования лучших практик будет полезно сделать предварительный проект на IoT-платформе параллельно с собственной разработкой.
Напоследок хотим поделиться небольшим прогнозом:
- в облачных IoT-платформах следует ожидать появления преднастроенных шаблонов «Умного дома», автоматизированной системы управления, NMS, системы контроля доступа и т. д. Это еще больше упростит использование IoT-платформ и привлечет к ним еще большую аудиторию.
.
- традиционные разработчики SCADA и других пакетных решений предложат больше инструментов внешним разработчикам, зарекомендовавшим себя на IoT-платформах.
Закрытые коробочные решения вряд ли выдержат рыночную конкуренцию.
- отечественные IoT-платформы для государственных и крупных частных заказчиков будут развиваться еще активнее.
- API разных IoT-платформ со временем станут более похожими друг на друга.
Благодаря этому переход с одной IoT-платформы на другую будет упрощен.
ГИК .
Обязательно напишите в комментариях, если мы пропустили что-то важное.
Одна из целей нашего блога — получение конструктивной обратной связи.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Как вы используете IoT 0% Не использую IoT, но верю в его полезность и планирую начать в ближайшем будущем 0 50% Использую как частный пользователь (например, в «Умном доме») 4 37,5% Использую в профессиональной деятельности 3 12,5% Не использую На IoT даже не планирую, потому что это путь в скайнет и это вообще зло! Проголосовали 1 8 пользователей.
2 пользователя воздержались.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Какова ваша область применения Интернета вещей? 40% Мониторинг объектов/серверов связи 4 60% Умный дом/здание/дача 6 10% Сельское хозяйство 1 10% Отслеживание и контроль состояния транспортных средств 1 30% Тепло-, водо-, газо-, электроснабжение 3 10% Управление и контроль уличного освещения 1 10% Добыча и транспортировка нефти/газа 1 50% Промышленная автоматизация 5 30% Безопасность и контроль доступа 3 0% Учет рабочего времени 0 30% Остальные 3 Проголосовали 10 пользователей.
3 пользователя воздержались.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Сколько IoT-устройств вы используете? 0% 1-3 0 22,22% 4-9 2 55,56% 10-49 5 11,11% 49 – 499 1 11,11% проголосовали более 500 1 9 пользователей.
3 пользователя воздержались.
Теги: #Интернет вещей #Умный дом #aws #Amazon Web Services #askue #controller #scada #sms #sms #scod #scud #система управления #GSM
-
Понижение Версии Журнала
19 Oct, 24
