Шлюзы промышленных протоколов обмена на Linux. Собери сам

Я занимаюсь разработкой, внедрением и эксплуатацией систем автоматического управления технологическими процессами (АСУ ТП). Поначалу работал со SCADA-системами. Потом довольно быстро переключился на работу с протоколами обмена промышленных устройств. Как самостоятельное написание драйверов, так и настройка систем сбора данных. В настоящий момент моя работа проходит атмосфере Modbus-ов, МЭКов-101/104-х, ОРС и прочих протоколов.

Рис. 1. Многообразие протоколов обмена, используемых в АСУ ТП

Кратко о том, как устроена типичная система сбора данных (Немного упрощенно).

Рис. 2. Система сбора данных 

Специальное ПО, называемое OPC-сервером ведёт опрос устройств, подключенных к интерфейсу RS-485. OPC-сервер является своего рода прослойкой между SCADA-системой и устройствами, переводя язык на котором общаются устройства в язык, понятный SCADA-системе. Преобразователь Ethernet/RS-485 служит для преобразования TCP/IP-пакетов в пакеты, которые ходят по физической среде RS-485.

Эта схема имеет ряд недостатков:

1. Установим, например, в ОРС-сервере таймаут ожидания ответа 200 мс. В идеальном случае, когда пакеты в Ethernet ходят без задержек, обмен с устройствами идёт с хорошей скоростью (интенсивностью). Но если пакет, содержащий ответ, задерживается, например, на 300 мс (это больше таймаута ожидания ответа 200 мс), то ОРС-сервер считает, что ответ на запрос не пришел и отправляет следующий запрос. В это время приходит ответ на предыдущий запрос, но ОРС-сервер думает, что это пришел ответ на текущий запрос и передаёт неправильные данные наверх. Как результат данные на АРМе «скачут». Чтобы уйти от таких ситуаций установим таймаут больше. Возьмём с запасом — 3000 мс. Если ответ приходит раньше 3000 мс, то оставшееся время не ждём, переходим к следующему запросу. Пока всё идёт хорошо, но стоит нескольким устройствам перестать отвечать, как образуются задержки по 3000 мс на каждое устройство. Время опроса увеличивается.
2. Большинство протоколов, используемых в АСУ ТП (Modbus, счетчики э/э) основываются на последовательном опросе одних и тех же параметров. Учитывая, что большую часть времени значения параметров остаются неизменными, сеть передачи данных используется для передачи одного и того же. Это нерационально, если среда передачи GPRS, и трафик стоит денег. Кроме того, в среде передачи GPRS задержки прохождения пакетов могут достигать нескольких секунд. Зачем тратить время и ресурсы для передачи одного и того же?

Для вышеперечисленных ситуаций более подходит протокол, в котором данные передаются наверх по изменению (спорадически) и сгруппированными по несколько значений в один TCP-пакет. Такими протоколами являются МЭК-60870-5-104 и OPC UA. Подойдёт и ModBus-TCP, в нём нет передачи по изменению, но зато, если данных немного, их можно упаковать в один пакет. Хорошо бы иметь какой-нибудь контроллер, который можно повесить на DIN-рейку, подключить к нему устройства по RS-485 и передавать данные по Ethernet в SCADA-систему.

В общем какие-то аппаратные шлюзы есть и в немалом количестве. Но в виде готовых неделимых решений. Всё в одном. И это мне не особо нравится. Понадобился мне когда-то шлюз, преобразующий протоколы счетчиков СЭТ-4ТМ в OPC UA с шестью портами RS-485 и двумя Ethernet. У одного производителя есть шлюз с поддержкой нужных протоколов обмена, но мало портов RS-485, у другого есть нужное количество портов RS-485, но нет двух портов Ethernet. У третьего есть два порта Ethernet, но нет всех протоколов обмена. У четвёртого есть почти всё, но нет OPC UA, имеющиеся на борту МЭК-60870-5-104 или ModBus-TCP требуют ОРС-сервера для этих протоколов.

А как бы было замечательно: купить контроллер или мини-ПК с ОС у одного производителя. Купить ПО для контроллера у другого. Если одного производителя ПО не поддерживает что-то, докупить что-то из ПО у другого, объединить между собой компоненты ПО через стандартный программный интерфейс. Казалось бы, вот оно светлое будущее!

Вот поэтому шлюзы протоколов применяются реже чем связка «ОРС-сервер и «Преобразователь Ethernet в RS-485»» — из-за их неделимости на компоненты.

Одна из причин, почему мало развиты SCADA для Linux: SCADA есть, протоколов обмена в ней поддержано мало, а ОРС-серверов для связи с оборудованием нет. SCADA оставляет интегратора один на один с железом.

Читатель уже может задавать вопрос: Что можете предложить? Что уже есть? Есть OPC UA серверы для Linux для следующих протоколов:

• МЭК 60870-5-104;
• МЭК 60870-5-101;
• Счетчики Меркурий 230, 231, 233, 234, 236;
• Счетчики СЭТ-4ТМ, ПСЧ-3ТМ, ПСЧ-4ТМ;
• Счетчики Энергомера;
• SNMP;
• MQTT;
• Счетчики Меркурий 200.

Чтобы на верхний уровень можно было передавать данные не только по протоколу OPC UA, создан «Преобразователь OPC UA в Modbus и МЭК 60870-5-104». Помимо функции передачи данных по этим протоколам, «Преобразователь» имеет встроенный web-сервер. С помощью специального редактора можно нарисовать схему, на неё вывести значения тэгов, а потом открыть её в браузере. Получается мини-SCADA непосредственно в контроллере. Как работает оживление схемы я уже писал здесь, про редактор здесь. В будущем планируется «Преобразователь OPC UA в MQTT».

OPC UA серверы и преобразователь работают на архитектурах x64, ARMv7 и AARCH64.
Таким образом, для аппаратной части можно использовать как проверенные временем решения на базе мини промышленных компьютеров, так и всевозможные «raspberry pi совместимые» ARM миникомпьютеры. Как производится установка и настройка ПО с примерами можно почитать здесь или здесь.

В общем виде структура комплекса выглядит так:

Система обладает масштабируемостью. Используются компоненты необходимые только для решения текущей задачи.

С использованием OPC UA сервера наша схема преобразуется:

У нас получилось следующее:

• OPC UA сервер собирает данные с устройств по RS-485 без больших задержек между запросами;
• Данные в SCADA выдаются по нескольку штук в одном TCP-пакете по изменению;
• К OPC UA серверу можно подключить несколько одинаково настроенных АРМов. Пригодится, если нужно дублирование.

Таким образом, вместо связки ОРС-сервер и «Преобразователь Ethernet в RS-485» у нас получается одно устройство, объединяющее в себе их функциональность. Мне такая схема нравится больше. А Вам?