Схема передачи данных в IoT-протоколе СЕРЕБРУМ

ПЛК СЕРЕБРУМ — контроллеры для удаленного мониторинга

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

Требования к системе удаленного мониторинга

Для решения большинства задач автоматизации, как правило, используется оборудование известных брендов: многолетний опыт их применений дает пользователям гарантию работоспособности устройств. Однако если говорить об удаленном мониторинге, то при обширности предоставляемых производителями библиотек и продуманности программного обеспечения в популярных контроллерах средства для его обеспечения отсутствуют. Поэтому российская компания «Серебрум» разработала ПЛК со встроенным сервисом удаленного мониторинга.

Одним из ключевых аргументов заказчиков против удаленного мониторинга обычно является его небезопасность. Часто разработчики используют в своем оборудовании ничем не защищенный Modbus, Profibus или еще что-нибудь из прошлого века. Впрочем, современные ProfiNet и EtherCAT тоже не годятся для таких задач. Кроме того, эти протоколы в принципе не предназначены для передачи данных через Интернет.

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

Чтобы предоставить минимальные функции удаленного управления, некоторым разработчикам приходится выкручиваться по-своему: например, открывать порт 502 через 3G-роутер. Однако нужно помнить о том, что это небезопасно.

Попробуем сформулировать требования к промышленной системе удаленного мониторинга и управления:

  • Безопасность. Данные должны быть скрыты от постороннего наблюдателя. Несанкционированное проникновение в систему и изменение параметров работы системы управления пресекаются.
  • Компактность. Удаленный доступ не должен требовать ресурсов в архитектуре ПЛК. Мы не строим систему вокруг сервера диспетчеризации — напротив, диспетчеризация должна находиться в недрах системы, чтобы ее не было видно, но при этом она работала.
  • Простота настройки и эксплуатации. Пользователю нужна возможность включить контроллер и увидеть данные на сервере. Разумеется, должна быть обеспечена безопасность передачи информации.
  • Способность работать в слабых сетях, экономя объем трафика. С каждым годом стоимость Интернета падает, иногда доступ предоставляется бесплатно. Но экономия никогда не повредит, поэтому не стоит передавать мегабайты данных в JSON только для того, чтобы установить соединение с сервером.
  • Легкость присоединения к существующим системам SCADA и IoT. Информация должна отображаться в удобном виде, пользователи хотят видеть графики, современные индикаторы и журналы событий.
  • Масштабируемость. Способность обеспечить свой рост за счет развертывания резервных и вспомогательных узлов сети.
  • Разумная цена. В идеале диспетчеризация должна быть бесплатным сервисом, встроенным в оборудование для удобства клиентов.

 

Решение от «Серебрум»

Особенностью ПЛК СЕРЕБРУМ является использование собственной программной платформы (среда программирования и исполнения программ). Она позволяет легко интегрировать современные интернет-технологии в одном изделии.

Кроме того, у всех ПЛК есть унифицированная среда проектирования — YART Studio. Создав проект для одного контроллера, его можно легко перенести на другую платформу.

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

Рассмотрим СЕРЕБРУМ с точки зрения предъявленных выше требований.

Безопасность в данных ПЛК обеспечивается двумя способами: с помощью канала передачи TLS-SSL или собственного компактного алгоритма шифрования данных телеметрии. Тип алгоритма защиты определяется применяемым оборудованием. IRIS — производительный контроллер с поддержкой TLS-SSL, а Yart и Green Motion работают только с собственным механизмом защиты данных.

В данном алгоритме шифрования реализовано два механизма безопасности:

  • Двухфакторная аутентификация пользователей. Подключение к серверу телеметрии возможно только для зарегистрированных абонентов (контроллеров) при соблюдении ряда условий. В случае перехвата данных аутентификации система сменит токен подключения, что обесценит полученную злоумышленником информацию.
  • Шифрование AES128. Информация, передаваемая между абонентами, шифруется симметричным ключом по алгоритму AES128. Ключ рассчитывается динамически для каждого абонента и сессии.

Что касается трафика, то в IoT-протоколе СЕРЕБРУМ данные передаются в бинарном виде через MQTT — популярное решение для организации удаленного мониторинга и управления (рис. 1).

 Схема передачи данных в IoT-протоколе СЕРЕБРУМ

Рис. 1. Схема передачи данных в IoT-протоколе СЕРЕБРУМ

Особенностью MQTT является принцип передачи информации по подпискам. В сети нет выделенного Мастера, по командам которого удаленные устройства начинают передавать данные. Это позволяет снизить нагрузку на сеть и сервер. Удаленное устройство MQTT инициирует передачу данных по мере их появления: по расписанию или при изменении вычисляемой величины.

Также MQTT отличается компактностью — данные бинарные, однако ограничения на формат информации нет. Сам протокол считается транспортным.

В IoT-протоколе СЕРЕБРУМ переменные привязаны к уникальному для конкретного проекта 32-разрядному идентификатору, по которому сервер определяет тип и требуемую длину тега. При этом для всего пакета рассчитывается контрольная сумма CRC16, что дает гарантию блокировки сбойных пакетов, если вдруг такие будут переданы.

Как известно, MQTT предполагает использование отдельного топика (topic) для каждой переменной. Из этого следует, что в случае одновременной работы тысяч контроллеров с сотнями передаваемых переменных нагрузка на MQTT-брокер будет слишком большой, ведь речь пойдет
о сотнях тысяч топиков. Выход из этой ситуации найден за счет использования собственного метаформата, совместимого при этом с MQTT.

Каждый контроллер создает в пространстве брокера три топика: оглавление, прием и передача данных. Оглавление обновляется для каждой новой сессии и содержит в себе сжатое описание участвующих в обмене переменных. На практике оно занимает несколько килобайт. Таким образом, один абонент (контроллер) требует создания только трех топиков, что снижает нагрузку на брокер.

Для лучшего понимания приведем пример диспетчеризации одного объекта. Пусть удаленный контроллер содержит 120 переменных, которые передаются в пространство сервера телеметрии. Каждая переменная потребует около 30 байт для описания. Таким образом, получится 30×120 = 3600 байт. Сессия будет прерываться каждые 12 часов (GPRS/3G/LTE-канал) — заголовки будут отправляться заново. Пусть 20 переменных требуют частой отправки на сервер. Период обновления составит 5 минут. Кроме того, 70 переменных будут отображать накопленные значения, отправка которых требуется не чаще одного раза в сутки. Как правило, такие переменные отправляются по команде с сервера, но пока что важен требуемый объем трафика. Оставшиеся 30 переменных — это уставки, настройки и команды, которые передаются в ПЛК по требованию. Предположим, что уставки изменяются два раза в сутки.

В протоколе телеметрии СЕРЕБРУМ возможна передача массивов, но для упрощения расчетов в примере массивов не будет. Также допустим, что каждый тег — это число с плавающей точкой. Таким образом, размер одной переменной составит 4 байта (в ПЛК СЕРЕБРУМ переменная типа float занимает 4 байта). Тип переменной по протоколу не передается, требуется только идентификатор (4 байта).

Получаем следующие результаты.

Частая отправка: 40×(4+4) = 320 байт × 288 раз в сутки = 92160 байт.
Суточные данные: 70×(4+4)×1= 560 байт.
Уставки/команды от сервера: 30×(4+4)×2 = 480 байт.
Итого за сутки: 92160+560+480+3600×2 = 100400 байт = 100 кбайт (упрощенно).

Необходимо отметить, что MQTT добавляет свои данные, все абоненты передают heartbeat-сообщения — таким образом, суточный трафик увеличится приблизительно на 50%.

В результате получится 150 кбайт в сутки или 4,6 Мбайт в месяц. Очевидно, что в наше время такой трафик — это мало.

Если системе придется работать в условиях плохого качества связи, снизится пиковая скорость передачи информации и существенный объем трафика не будет передан. Однако при использовании СЕРЕБРУМ пользователь сможет получить доступ к объекту в реальном времени. Для этого прикладному программисту потребуется выполнить следующие действия.

Алгоритм телеметрии уже встроен в контроллер. Необходимо определить ряд настроек в отдельном окне проекта в YART Studio:

  • тип подключения и параметры аутентификации (рис. 2);
  • переменные для публикации и подписки.
Определение типа подключения и параметров аутентификации

Рис. 2. Определение типа подключения и параметров аутентификации

Список телеметрии формируется из перечня переменных проекта методом Drag&Drop, то есть переносится в область отправки и подписки (рис. 3).

Формирование списка телеметрии

Рис. 3. Формирование списка телеметрии

После рестарта контроллер начнет обмен данными с сервером.

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

Для таких задач СЕРЕБРУМ использует стандарт OPC UA:

  • переменные в пространстве OPC UA представляются в читаемом формате, что является важным преимуществом (рис. 4);
  • OPC UA легко стыкуется с большинством современных SCADA-систем («Серебрум» предоставляет список проверенных SCADA для интеграции).
Переменные в пространстве OPC UA

Рис. 4. Переменные в пространстве OPC UA

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

Вместо SCADA пользователи могут развернуть backend-сервер самостоятельно, на основе Node-Red или подобных IoT-программ.

Отдельно стоит рассказать о решении Cloud SCADA, предоставляемом «Серебрум» совместно с компанией «ИнСАТ» — разработчиком Master SCADA 4D. Это SAAS-решение, ориентированное на пользователей, для которых нецелесообразно развертывание собственного сервера телеметрии. Вместо этого потребители арендуют выделенное виртуальное пространство на специальном сервере. За небольшую арендную плату в их распоряжении оказывается run-time-лицензия Master SCADA и выделенный URL для подключения заранее оговоренного количества ПЛК. По мере роста потребностей пользователь вправе организовать собственные серверы: контроллеры будут выбирать предпочтительный сервер из пула возможных. Число возможных точек подключения не ограничено. Однако в один момент времени соединение возможно только с одним сервером.

В заключение отметим, что сервисы телеметрии СЕРЕБРУМ являются частью ПЛК. Использование удаленного управления не потребует дополнительных усилий, поскольку алгоритмы, протоколы и интерфейсы включены непосредственно в ОС контроллеров. Таким образом, пользователь платит только за оборудование: контроллер, модули расширения и связи.

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

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