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

Программное обеспечение
,
1

Мы разработали шлюз для трансляции сообщений между 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 и порт, по которым шлюз будет ожидать подключения.

image1
image11929×1865 191 KB

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

image
image3002×1615 245 KB

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

4 лайка
2
3

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

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

4

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

5

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

6

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

7

Тип занчения масштабируемое или с плавающей точкой, если масштабируемое то масштабный множитель и масштабный сдвиг. Аппертура - величина, на которое должно измениться значение в нутри прибора чтобы сообщить об изменении на верхний уровень(спорадическая/спонтанная передача с меткой времени).
Для токов аппартура 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 отключением по таймауту если они больше нуля (в миллисекундах)

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

8

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

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

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

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

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

9

Трафик 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
приводим к аппертуре и сравниваем с предыдущим - поменялось - передаем, не поменялось пропускаем. В каком объекте хранить старое значение проще разобраться тому кто писал(Для каждого клиента отдельно наверно).

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

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

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

10

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

11

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

1 лайк
12

Сообщение было перенесено в новую тему: Скрипт для телеуправления с ключом блокировки

13

Как насчет меток времени в payload MQTT?
Хотелось бы конечно в бинарном виде передавать, но и в payload вполне приемлимый вариант.
Так как в МЭК 60870-5-104 есть коды качества то хочется видеть и их тоже. Основная стратегия кодов качества:1. если значение заданно не самим устройством а скриптом или через веб то хотелось бы видеть соответсвующий флаг:
SB - при получении значения не от устройства, а от скрипта
NT - при отсутсвии связи с устройством

image
image857×457 52.6 KB

скорее всего передавать код качества придется также в теле payload.
вопрос как удобнее это осуществить использовать JSON или CSV.
{“v”:1,“q”:2,“t”:1620710456}
1,2,1620710456

14

Метки времени в стадии проектирования. Конкретных сроков реализации пока нет.
Шлюз работает с брокером MQTT и больше ничего не знает о реальных устройствах, поэтому можно выставлять NT, если в /meta/error есть r.
Расскажите больше про "значение заданно не самим устройством а скриптом или через веб", что вы имеете ввиду?

15

В шлюзах МЭК 60870-5-104 есть понятие значения установленного вручную. Обычный режим когда значения собираются с оборудования и ретранслируются шлюзом - без вмешательства человека. Но иногда оборудование неисправно и значение идет некорректное, тогда на шлюзе можно изменить данное значение вручную установив соответсвующую галочку. При этом фактически передается константа которую может менять только пользователь. Для систем верхнего уровня это означает вмешательство в процесс ретрансляции. Скрипт наверно не должен вызывать данный флаг. Флаг должен появляться только после установки значения через веб интерфейс.
Параметр изменили через веб - установился флаг, произошло изменение от опроса устройства(датчика) - флаг сбрасывается. Возможно также в настройках шлюза устанавливается галочка и константа вместо значения.
Вобще есть мысль что все значения полученные топиком вне опроса устройства должны быть с флагом SB(установленно вручную) - актуально когда датчик неисправен-отключен мы записываем в его топик значение чтобы скрипты работалии корректно на время ремонта. Таким образом NT когда просто пропала связь"с термодатчиком нет связи последние данные -10 градусов", а SB когда человек сказал “так, вроде там сейчас 20 градусов, поэтому ставим 20 градусов”. А для констант передаваемых из веб интерфейса и меняемых только пользователем - должен всегда передаваться флаг SB.

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

16

Здравствуйте!
Планируем увеличить партию и для этого купили несколько контроллеров Wiren Board 6 для наладки и тестирование. Данный момент появился вопрос можно ли настроить прием данных от устройств(датчики измерение и телесигнализации) по протоколу МЭК 104 в Wiren Board 6.
Если да то как можете подсказать будем благодарны!!!

17

Нет. Сейчас такой функционал не поддерживается.

18

Получается можем только передавать по протоколу МЭК 104 ? А телеуправление можем осуществить?

19

Можно запросить через МЭК 104 то, что опубликовано в MQTT. Если в MQTT контролы доступны для записи, то в них можно писать через МЭК 104. Например, управлять реле и т.п.

20

Телеуправление в классическом виде(реле включения и реле отключения) только через скрипт. У них даже синхронизация времени Отключена в мэк104(в коде 104 просто затычка вместо установки времени) .

Скрипт телеуправления могу дать.

В своём филиале Россети мы делали освещение на WirenBoard 6, потому что он относительно дешевле и есть скрипты на Js. управление по времени восхода, заката (сумерки) - просто для JS был готовый скрипт, а решать уравнение восхода самому как то сложновато уже.

Делать на нем полноценный КП ТМ подстанции я бы не стал.

1 лайк