Найти тему
Adventory

Как соединить Simatic IOT2040 и электросчетчик «Меркурий»

Решаемая задача

В качестве демонстрационной задачи была принята передача телеметрии с устройства с нестандартным протоколом. С этой целью для демо-стенда был использован счетчик электроэнергии «Меркурий 206 RN», связь с которым осуществляется по шине RS-485.

Данная схема может быть применима в случае реализации системы АСКУЭ уровня предприятия или системы автоматизированного онлайн-расчета себестоимости продукции при наличии существующей инфраструктуры учета электроэнергии. Также, данная схема с определенными оговорками может быть применима к системам коммерческого учета электроэнергии.

Чистое время сборки, реализации протокола обмена и программирования описываемого функционала данного стенда составило около 8 рабочих часов.

Схема соединений стенда

Электросчетчик «Меркурий 206 RN» установлен в разрыв линии питания 220VAC и выполняет непосредственно измерение параметров электросети, включая активную и реактивную компоненты. Нагрузкой электросчетчика является блок питания Logo!Power, имеющий на выходе потребляемую шлюзом Simatic IOT2040 и тонким клиентом Simatic ITC1200. Поскольку последовательный порт электросчетчика требует 5VDC, данный тип питания был взят с USB-порта IOT2040.

Рисунок 1. Силовая схема
Рисунок 1. Силовая схема

Измеренные данные запрашиваются из электросчетчика шлюзом Simatic IOT2040 по шине RS-485 с использованием собственного протокола «Меркурий»[i], после чего парсятся. По окончании этой процедуры данные становятся доступными для визуализации и отправки через порт Ethernet.

Рисунок 1. Силовая схема
Рисунок 1. Силовая схема

Программная архитектура решения

Для выполнения преобразования данных было принято решение по использованию системы Node-Red, как бесплатно входящей в состав базового образа ОС Yocto для шлюза Simatic IOT2040. Указанная система построена на программной платформе Node.js и оперирует кроссплатформенным кодом на языке JavaScript, исполняемом на сервере. Для Node-Red помимо встроенных программных модулей (в терминологии системы - nodes, узлов, нодов) присутствует большое количество, разработанных как изготовителями аппаратного обеспечения, так и свободным коммьюнити.

Соответственно, для реализации описываемого стенда были применены нестандартные ноды «serial in» и «serial out», предустановленные Siemens, и набор компонентов node-red-dashboard, загруженный из репозитория Npmjs.org.

В репозитории присутствуют ноды, реализующие формирование и разбор пакетов обмена по протоколу «Меркурий», однако автор стенда с целью повышения наглядности принял решение реализовать необходимый обмен самостоятельно.

При реализации проекта в реальных условиях с успехом также могут быть применены ноды для отправки данных по почти любым известным протоколам – MQTT, REST, Modbus TCP/RTU, S7 и т.п.

Рисунок 3. Общий код проекта
Рисунок 3. Общий код проекта

Запрос данных из электросчетчика

Протокол «Меркурий» является протоколом типа «запрос ведущего – ответ ведомого», производным от Modbus/RTU. Качество документирования протокола среднее, что привело к необходимости проведения ряда экспериментов и увеличило время реализации проекта. Например, одной из неявно документированных особенностей протокола является то, что в пределах одного пакета четырёхбайтовый адрес устройства передаётся старшим байтом вперёд, а двухбайтовый CRC – младшим.

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

Блок запросов отрабатывается 1 раз в 2 секунды, задержка между отправкой отдельных запросов 100 мс. Данный тайминг является подобранным с точки зрения достаточности обновления на экране и считываемости отдельных сообщений обмена в окне отладки. ВременнЫе характеристики реализованы с использованием стандартных нодов “inject” и “delay”.

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

Описываемый код формирует массив специализированного типа Buffer, предназначенного для отправки в последовательный порт. Отличие данного типа от TypedArray[ii], описываемого стандартом ECMAScript 2015 состоит в том, что Buffer может состоять только из элементов Uint8 и не допускает полиморфизма составляющих массив элементов. Это позволяет избежать большого количества неявных проблем, возникающих при отправке через порт элементов длиннее 8 бит.

Рисунок 4. Код функции sendReq
Рисунок 4. Код функции sendReq

Сформированный буфер отправляется при помощи ноды “serial out”, которая использует устройство /dev/ttyS2 (соответствует внешнему разъему X30 COM1) в режиме 9600 8N1. Режим порта “RS-485” был заранее выставлен при помощи внутренней команды iot2000setup, выполненной в консоли через SSH.

Рисунок 4. Код функции sendReq
Рисунок 4. Код функции sendReq

Парсинг данных

Обработка ответа электросчетчика начинается с сообщения ноды “serial in” о получении данных в буфер последовательного порта. Код процедуры использовался в том числе для парсинга обмена между электросчетчиком и компьютером и поэтому содержит компоненты работы как с запросами, так и с ответами. Разбор ответа для выбранных шести функций выполняется полностью, с именованием и образмериванием, для остальных – кратко.

Рисунок 4. Код функции sendReq
Рисунок 4. Код функции sendReq

Функция парсинга имеет два выхода. Первый является диагностическим, в него выводится сообщение типа Object, содержащее тип сообщения, номер функции, измеренный параметр и его значение, единицы измерения. Данный формат вывода пригоден для практически любой обработки или отправки во внешние системы. Второй является рабочим, в него выводится сообщение, в котором topic обозначает наименование передаваемой величины, а само тело сообщения в формате number – значение величины.

Рисунок 7. Распарсенные данные
Рисунок 7. Распарсенные данные

Визуализация данных

Местная визуализация данных готовится при помощи компонентов node-red-dashboard, построенных на базе известной библиотеки Grafana. Разбор общего потока сообщений о различных параметрах выполняется при помощи стандартной ноды switch в зависимости от свойства сообщения topic. Выходы блока switch соединены с компонентами, образующими отдельные поля вывода информационного экрана.

Рисунок 8. Сортировка вывода
Рисунок 8. Сортировка вывода

Структура компонентов на экране (группировка) задаётся фиксированно в параметрах соответствующих нодов, положение на экране подстраивается браузером динамически в зависимости от разрешения клиента. Передача осуществляется при помощи HTML5, не требующем наличия дополнительных компонент в клиенте.

Рисунок 9. Экран вывода данных
Рисунок 9. Экран вывода данных

Для непосредственно отображения в демо-стенде использован тонкий клиент ITC1200 v2, как умеющий работать по указанному протоколу без дополнительных компонентов. Вместо него может быть применено любое устройство с барузером HTML5, промышленного или бытового назначения.

Рисунок 10. Вывод на тонкий клиент ITC1200
Рисунок 10. Вывод на тонкий клиент ITC1200


Эта статья на ЖЖ:
https://adventory.livejournal.com/1256.html

Полезные ссылки
[i] https://www.incotexcom.ru/support/docs
[ii] https://stackoverflow.com/questions/9988166/nodejs-buffers-vs-typed-arrays

При подготовке публикации использовались материалы и изображения SIEMENS AG

<-