Поддержка МЭК 60870-5-104

Мы разработали шлюз для трансляции сообщений между MQTT-брокером и системами c поддержкой протокола МЭК 60870-5-104.

Шлюз предназанчен только для Wiren Board 6, предыдущие контролеры не поддерживаются.

Установка

Если репозиторий experimental не подключен, нужно включить его, выполнив команду:

echo 'deb http://releases.contactless.ru/experimental/stretch stretch main' > /etc/apt/sources.list.d/contactless-experimental.list

Обновить список пакетов:

apt update

Установить командой:

apt install wb-mqtt-iec104=0.3.0~feature+first-release+0+64a7c63

При запуске шлюза происходит автоматическое создание конфигурационного файла /etc/wb-mqtt-iec104.conf . При последующих запусках шлюз анализирует доступные MQTT каналы(контролы) и добавляет их в файл. Активировать передачу данных конкретных каналов можно, редактируя /etc/wb-mqtt-serial.conf , либо воспользовавшись онлайн-редактором настроек. Структура конфигурационного файла описана тут.

Шлюз подключается к заданому MQTT брокеру и подписывается на сообщения от каналов, указанных в конфигурационном файле. В системах с поддержкой протокола МЭК 60870-5-104 шлюз выступает в роли контролируемой станции и принимает входящие TCP/IP соединения по указаному в конфигурационном файле локальному интерфейсу и порту.

Передача сообщений из MQTT в МЭК 60870-5-104

Сообщения MQTT передаются в МЭК 60870-5-104 блоками данных (ASDU) с причиной передачи “спорадически”(3). При подключении нового контролирующего устройства, шлюз автоматически высылает последние известные значения всех включенных каналов. В дальнейшем каждое новое MQTT-сообщение сразу же передаётся в МЭК 60870-5-104.

Передача команд МЭК 60870-5-104 в MQTT

Шлюз поддерживает ASDU с типами:

  • одноэлементная команда (C_SC_NA_1);
  • команда уставки, масштабированное значение (C_SE_NB_1);
  • команда уставки, короткое число с плавающей запятой (C_SE_NC_1).

Обрабатывается первый объект информации в ASDU. Если в конфигурационном файле есть включенный канал для адреса этого объекта информации, шлюз произведёт запись полученного значения в соответствующую тему канала (например, /devices/wb-gpio/controls/5V_OUT/on). Также поддерживается команда общего опроса станции (C_IC_NA_1, QOI равный 20), прочие команды не поддерживаются.

Интерфейс онлайн-конфигуратора

После установки шлюза его можно настроить в интерфейсе онлайн-конфигуратора, выбрав из списка файл /etc/wb-mqtt-iec104.conf.

Онлайн-конфигуратор позволяет указать параметры подключения к MQTT-брокеру (дополнительные параметры можно выбрать, нажав на кнопку “Properties”) и выбрать локальный IP и порт, по которым шлюз будет ожидать подключения.


Ниже показан интерфейс редактирования списка групп и каналов для трансляции из MQTT в МЭК 60870-5-104. По умолчанию шлюз создаёт отдельную группу для каждого устройства. Список групп расположен слева, его можно самостоятельно редактировать.

При выборе конкретной группы в правой части появится список входящих в неё каналов. Каналы так же можно создавать, удалять и редактировать. Столбец “MQTT device and control” указывает конкретный канал MQTT. Он формируется из названия устройства и канала. Для первого в списке канала соотвествующий топик MQTT будет /devices/wb-m1w2_107/controls/External Sensor 1 . Уникальный адрес объекта информации согласно МЭК генерируется при старте сервиса, его можно изменить в столбце “Unique IEC information object address”. Также можно поменять тип объекта информации.

4 симпатии

А можно дополнить инструкцией по Оффлайн установке?(что скачать и откуда, куда закачать, какими коммандами установить)
МЭК104 достаточно специализированный протокол и обычно там где он нужен доступ в интернет отсутствует.

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

У нас в контроллере Debian Linux и стандартный для него пакетный менеджер apt. Для закачки пакетов можно воспользоваться любым способом, например, как описано здесь.

Вобщем мы заинтересовались в установке вашего контроллера на Подстанции 35 кВ как устройство сбора и передачи информации и телеуправления. Все по тому что цена существенно ниже чем у аналогов. Если довести до ума работу с МЭК 104, особенно в настройках спорадики и телеуправления. То есть потенциал выхода на рынок для электроэнергетики.

Можете подробнее рассказать какие настройки нужны?

Тип занчения масштабируемое или с плавающей точкой, если масштабируемое то масштабный множитель и масштабный сдвиг. Аппертура - величина, на которое должно измениться значение в нутри прибора чтобы сообщить об изменении на верхний уровень(спорадическая/спонтанная передача с меткой времени).
Для токов аппартура 1 ампер значит что передаются только целые значения 1,2,3, …
Также удобно будет если у каждой группы будет настройка циклической передачи - в секундах и галочка включения. Если включена циклическая передача - то раз в интервал прибор передает все параметры в группе независимо от их состояния.
Возможно также нужна коррекция времени через протокол МЭК104 и настройка временной зоны.
Телеуправление (запись в параметр): тут не знаю как лучше сделать, но в другом оборудовании запись в параметр включает реле на некоторый интервал - на один адрес комманда включения переводит реле К1 в активное состояние на 1000 мс, а комманда отключения переводит реле K2 в активное состояние на 1000 мс. Думаю это можно реализовать через правила - введя промежуточный сигнал, по изменению которого будет включаться то или иное реле.
И те адреса которые используются как управление обычно не выдаются в ответе на опрос.
Общая идеология МЭК 104 в электроэнергетике такая: есть 3 основных класса данных: ТС - дискретные входы, ТИ - аналоговые входы, ТУ - дискретные выходы. По входам имеются флаги качества - если пропала связь с нижестоящим оборудованием передаются последние данные с флагом “аппаратная недосотоверность”(думаю тут по таймауту неактивности топика MQTT можно сделать), остальные флаги типа “установлен вручную” - не думаю что реализуемо.

Телеуправление комутационными аппаратами обычно выполняется в два этапа(двухтактные):

  1. select - подготовка (захват в монопольный режим)
  2. execute - исполнение(переключение и освобождение захвата)
    В контексте mqtt вряд ли удастся реализовать данный алгоритм работы - это скорее всего для нескольких МЭК104 клиентов чтобы избежать конкуренциии в коммандах управления.

Поэтому логично будет разделить в настройке данные по типам: Distrete, Analog, Control - можно впринципе через селект типа объекта определять: discrete single point (обычный вход 0/1),discrete double point(сдвоенный вход, два бита, концевики крайнего положения, 0…3 промежуточное/откл/вкл/ошибка), measured value float(с плавающей точкой - может домножаться на множитель), measured value scaled(обязательно домножается на множитель и прибавляется сдвиг), command single point(одно реле - либо вкл, либо откл), command double point(два реле - одно на включение, другое на отключение) - также надо продумать прием single point команды в адрес duble point - c отключением по таймауту если они больше нуля (в миллисекундах)

Это все пока размышления по поводу как надо чтобы было удобно. Может кто еще подскажет или выразт свои мысли по этому поводу.

Это реализуется передачей не “сырого” значения а предварительной обработкой скриптом (правилом) на контроллере. То есть передаем не непосредственно значение датчика а сначала его, значение обрабатываем “внутри” так, как нам надо, и меняем уже “виртуальный” параметр.
Вот посмотрите, на примере шунта:


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

Тот же механизм. Создаем виртуальное устройство, изменение полей которого может выставлять время (Но зачем, если по NTP синхронизируется?) и запускать коррекцию таймзоны.

Есть мета “error” в топиках, использовать можно его. Оне ставится сразу же драйвером при ошибках связи с устройством.

По остальному - весьма признателен за мысли, нам важно мнение (и критика!) практиков.

Трафик NTP может блокироваться в технологических сетях, да и речь про поддержку протокола.
Синхронизация времени это отдельная функция/команда внутри протокола:

C_CS_NA_1 (103) протокола обмена ГОСТ Р МЭК 60870-5-101 - 2006 стр. 20

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

Циклическая передача это тоже функционал протокола - у такой информации причина передачи 1, у данных при изменении(спорадика) причина 3, у данных ответа на запрос 4. Это функции протокола и их должен осуществлять сам драйвер этого протокола(это буде сложно - лучше на потом оставить, да и особой необходимости нет если нормально опрос работает).

Основное что очень неоходимо это: масштабный сдвиг, множитель, аппертуру - их будет не сложно сделать в самом сервере - условие в цикле добавления изменившихся значений
перед строкой https://github.com/wirenboard/wb-mqtt-iec104/blob/main/src/gateway.cpp#L108
приводим к аппертуре и сравниваем с предыдущим - поменялось - передаем, не поменялось пропускаем. В каком объекте хранить старое значение проще разобраться тому кто писал(Для каждого клиента отдельно наверно).

А вот телеуправление с двумя реле - не стоит заморачиваться - проще в правилах описать, со всеми таймаутами.

С кодами качества придется повозиться - я не доконца понял на каком уровне появляется значение, а на каком внедряется его качество. Похоже что качество перед отправкой устанавливается, когда из информации о значении осталось лишь само значение.

Двухпозиционную информацию тоже на потом оставить - ее смысл в том что два входа передаются в одном адресе, характерна она восновном для комутационных аппаратов с моторными приводами - когда мотор может отказать в процессе переключения.

Драйвер сейчас пересылает информацию от MQTT, а там нет меток времени. Так что от синхронизации времени мало пользы, все данные по МЭК драйвер отдаёт как объекты информации без меток времени.
Отвечать на команду опроса драйвер умеет, при этом будут выданы последние полученные из MQTT значения, но опять же без меток времени.

Без меток времени плохо. Много пользователей сталкиваются с этой проблемой в MQTT. У изменившегося значения должна быть метка времени. Думаю надо проработать этот момент.

1 симпатия