А можно дополнить инструкцией по Оффлайн установке?(что скачать и откуда, куда закачать, какими коммандами установить)
МЭК104 достаточно специализированный протокол и обычно там где он нужен доступ в интернет отсутствует.
А так вроде работает, но явно нехватает настроек циклической передачи и спорадики(аппертура у каждого параметра). В MQTT события достаточно часто сыпятся и для внутренних целей это нормально, но в системы верхнего уровня так часто не надо.
У нас в контроллере Debian Linux и стандартный для него пакетный менеджер apt. Для закачки пакетов можно воспользоваться любым способом, например, как описано здесь.
Вобщем мы заинтересовались в установке вашего контроллера на Подстанции 35 кВ как устройство сбора и передачи информации и телеуправления. Все по тому что цена существенно ниже чем у аналогов. Если довести до ума работу с МЭК 104, особенно в настройках спорадики и телеуправления. То есть потенциал выхода на рынок для электроэнергетики.
Можете подробнее рассказать какие настройки нужны?
Тип занчения масштабируемое или с плавающей точкой, если масштабируемое то масштабный множитель и масштабный сдвиг. Аппертура - величина, на которое должно измениться значение в нутри прибора чтобы сообщить об изменении на верхний уровень(спорадическая/спонтанная передача с меткой времени).
Для токов аппартура 1 ампер значит что передаются только целые значения 1,2,3, …
Также удобно будет если у каждой группы будет настройка циклической передачи - в секундах и галочка включения. Если включена циклическая передача - то раз в интервал прибор передает все параметры в группе независимо от их состояния.
Возможно также нужна коррекция времени через протокол МЭК104 и настройка временной зоны.
Телеуправление (запись в параметр): тут не знаю как лучше сделать, но в другом оборудовании запись в параметр включает реле на некоторый интервал - на один адрес комманда включения переводит реле К1 в активное состояние на 1000 мс, а комманда отключения переводит реле K2 в активное состояние на 1000 мс. Думаю это можно реализовать через правила - введя промежуточный сигнал, по изменению которого будет включаться то или иное реле.
И те адреса которые используются как управление обычно не выдаются в ответе на опрос.
Общая идеология МЭК 104 в электроэнергетике такая: есть 3 основных класса данных: ТС - дискретные входы, ТИ - аналоговые входы, ТУ - дискретные выходы. По входам имеются флаги качества - если пропала связь с нижестоящим оборудованием передаются последние данные с флагом “аппаратная недосотоверность”(думаю тут по таймауту неактивности топика MQTT можно сделать), остальные флаги типа “установлен вручную” - не думаю что реализуемо.
Телеуправление комутационными аппаратами обычно выполняется в два этапа(двухтактные):
Поэтому логично будет разделить в настройке данные по типам: 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. У изменившегося значения должна быть метка времени. Думаю надо проработать этот момент.
Как насчет меток времени в payload MQTT?
Хотелось бы конечно в бинарном виде передавать, но и в payload вполне приемлимый вариант.
Так как в МЭК 60870-5-104 есть коды качества то хочется видеть и их тоже. Основная стратегия кодов качества:1. если значение заданно не самим устройством а скриптом или через веб то хотелось бы видеть соответсвующий флаг:
SB - при получении значения не от устройства, а от скрипта
NT - при отсутсвии связи с устройством
Метки времени в стадии проектирования. Конкретных сроков реализации пока нет.
Шлюз работает с брокером MQTT и больше ничего не знает о реальных устройствах, поэтому можно выставлять NT, если в /meta/error есть r.
Расскажите больше про "значение заданно не самим устройством а скриптом или через веб", что вы имеете ввиду?
В шлюзах МЭК 60870-5-104 есть понятие значения установленного вручную. Обычный режим когда значения собираются с оборудования и ретранслируются шлюзом - без вмешательства человека. Но иногда оборудование неисправно и значение идет некорректное, тогда на шлюзе можно изменить данное значение вручную установив соответсвующую галочку. При этом фактически передается константа которую может менять только пользователь. Для систем верхнего уровня это означает вмешательство в процесс ретрансляции. Скрипт наверно не должен вызывать данный флаг. Флаг должен появляться только после установки значения через веб интерфейс.
Параметр изменили через веб - установился флаг, произошло изменение от опроса устройства(датчика) - флаг сбрасывается. Возможно также в настройках шлюза устанавливается галочка и константа вместо значения.
Вобще есть мысль что все значения полученные топиком вне опроса устройства должны быть с флагом SB(установленно вручную) - актуально когда датчик неисправен-отключен мы записываем в его топик значение чтобы скрипты работалии корректно на время ремонта. Таким образом NT когда просто пропала связь"с термодатчиком нет связи последние данные -10 градусов", а SB когда человек сказал “так, вроде там сейчас 20 градусов, поэтому ставим 20 градусов”. А для констант передаваемых из веб интерфейса и меняемых только пользователем - должен всегда передаваться флаг SB.
Данная концепция применима только в энергосистемах, чтобы диспетчер мог понимать что значение установленно другим диспетчером. Например есть диспетчер отвечающий за большой район энергосистемы, а есть диспетчер отвечающий за участок большого района и они географически разнесены. При изменении значений диспетчером участка - диспетчер района должен об этом знать. Значения заданные вручную всегда требуют уточнения - так как может влиять человеческий фактор(забыл поменять).
Здравствуйте!
Планируем увеличить партию и для этого купили несколько контроллеров Wiren Board 6 для наладки и тестирование. Данный момент появился вопрос можно ли настроить прием данных от устройств(датчики измерение и телесигнализации) по протоколу МЭК 104 в Wiren Board 6.
Если да то как можете подсказать будем благодарны!!!
Нет. Сейчас такой функционал не поддерживается.
Получается можем только передавать по протоколу МЭК 104 ? А телеуправление можем осуществить?
Можно запросить через МЭК 104 то, что опубликовано в MQTT. Если в MQTT контролы доступны для записи, то в них можно писать через МЭК 104. Например, управлять реле и т.п.
Телеуправление в классическом виде(реле включения и реле отключения) только через скрипт. У них даже синхронизация времени Отключена в мэк104(в коде 104 просто затычка вместо установки времени) .
Скрипт телеуправления могу дать.
В своём филиале Россети мы делали освещение на WirenBoard 6, потому что он относительно дешевле и есть скрипты на Js. управление по времени восхода, заката (сумерки) - просто для JS был готовый скрипт, а решать уравнение восхода самому как то сложновато уже.
Делать на нем полноценный КП ТМ подстанции я бы не стал.
Здравствуйте, хотелось бы уточнить, поддерживает ли протокол передачу сигнала с меткой времени на сегодняшний момент?
Нет. Сейчас метка времени не передаётся
