В свое время мне приходилось заниматься внедрением средств защиты АСУ ТП непосредственно на металлургических заводах. И помимо особенностей самих технологических процессов на меня также производило впечатление наличие большого числа различных протоколов, используемых для работы SCADA систем. Представьте цех, где одновременно работают станки с ЧПУ 90-х годов на Modbus RTU, более‑менее современные ПЛК Siemens на Profinet, контроллеры с OPC UA‑серверами и датчики, передающие данные по MQTT в корпоративное облако. Это не исключение, а суровая реальность любого промышленного предприятия с долгой историей.

В мире промышленной автоматизации насчитывается более 200 различных протоколов связи. Modbus, Profibus, EtherCAT, OPC UA, MQTT, CANopen, DeviceNet, EtherNet/IP — и это далеко не полный список. Каждый производитель оборудования привносит что‑то своё, а предприятия вынуждены годами эксплуатировать разнородный парк устройств.

При этом важно понимать, что проблема «зоопарка» протоколов — это не просто вопрос неудобства. Это прямые финансовые потери, выраженные в высокой стоимости интеграции нового оборудования в уже работающую сеть. Также в таком «зоопарке» сложно диагностировать и находить неисправности. Кроме того, нам важно вести единый сбор данных для MES и ERP, что в разношерстной сети сделать очень непросто. Потеря данных на стыках систем и длительные простои при модернизации сети также приводят к дополнительным затратам.

В этой статье мы разберём, как превратить хаос протоколов в стройную систему, используя шлюзы, конвертеры и OPC‑серверы. И главное — как организовать единое пространство данных, где SCADA и MES говорят на одном языке.

Почему протоколов так много?

На тех предприятиях, где мне приходилось бывать, промышленные сети традиционно вырастали из корпоративных, причем развивались они как правило довольно хаотично.

Основные вехи развития промышленных можно представить следующими этапами:

  • 1979 год: Modicon создаёт Modbus — первый открытый промышленный протокол. Простой, надёжный, работает по RS-485 и используется до сих пор.

  • 1980–90-е: Немецкие производители развивают Profibus (Process Field Bus) для более сложных задач. Собственно тоже «живее всех живых».

  • 2000-е: С приходом Ethernet в промышленность появляются промышленные протоколы, работающие по сети: Modbus TCP, Profinet, EtherNet/IP.

  • 2010-е: OPC UA (Unified Architecture) приносит семантическую совместимость и встроенную безопасность (которую не все используют).

  • 2020-е: MQTT становится стандартом для IIoT и облачных интеграций. Но на российских предприятиях мне такое видеть приходилось не часто.

В результате на одном предприятии могут соседствовать устройства всех этих поколений. И каждое говорит на своём языке.

Соединяем несоединимое

Как и в корпоративных сетях, в промышленности самый простой и распространённый способ «подружить» различные устройства — использовать аппаратные или программно‑аппаратные шлюзы.

То есть, шлюз принимает данные по одному протоколу (например, опрашивает устройства по Modbus RTU), преобразует их во внутреннее представление и отдаёт наружу по другому протоколу (например, публикует в MQTT‑брокер).

Вот пример, использования аппаратных шлюзов на практике. На металлургического предприятия развернули MQTT‑шлюзы, которые собирали данные с более чем 2000 датчиков по Modbus RTU/TCP, Profinet и EtherNet/IP. На выходе — единый MQTT‑поток с TLS‑шифрованием, уходящий в облачную платформу. Результат: время интеграции нового оборудования сократилось с недель до часов.

В качестве альтернативы аппаратным шлюзам можно рассмотреть использование OPC‑серверов как универсального средства интеграции. Вообще, OPC (Open Platform Communications) — это не протокол, а стандарт интерфейсов, который позволяет приложениям обмениваться данными с промышленным оборудованием. То есть, OPC‑серверы не устраняют нативные протоколы — они их оборачивают.

По сути, OPC‑сервер выступает переводчиком, с которым с одной стороны общаются сами устройства по своим протоколам (Modbus, Profibus, Siemens S7 и так далее), а со стороны SCADA/MES сервер предоставляет унифицированный OPC‑интерфейс.

Вот как может выглядеть типовая интеграция. ПЛК общается с панелью оператора по RS-485/Modbus RTU, а панель оператора должна передавать данные в SCADA по Ethernet.

Для реализации такого взаимодействия мы настраиваем связь между ПЛК и панелью по Modbus RTU (скорость 9600, 8 бит, чётность, 1 стоп‑бит). Соответственно, на панели оператора настраиваем Ethernet‑соединение с ролью Modbus TCP Slave. Также, в панели организуем передачу данных из регистров ПЛК в локальные регистры (LB, LW) через макрокоманды или компонент «Таймер».

Далее мы настраиваем OPC‑сервер (MasterOPC Universal Modbus Server) на опрос регистров панели оператора.

Здесь стоит отметить важный нюанс: внешний OPC‑сервер напрямую не видит регистры ПЛК — только регистры панели оператора. Поэтому данные нужно предварительно скопировать в локальную память панели оператора.

Нативные драйверы vs OPC

Важный вопрос архитектуры: использовать универсальные OPC‑серверы или нативные драйверы, встроенные в SCADA‑систему. Нативный драйвер реализует протокол устройства напрямую внутри SCADA‑приложения. То есть, SCADA система взаимодействует через нативный драйвер напрямую с целевым устройством. И здесь у нас нет никаких промежуточных слоёв, никаких дополнительных серверов и прочих посредников.

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

В свою очередь OPC‑серверы лучше выбирать, когда в вашей инфраструктуре уже есть работающий OPC‑сервер, к которому подключены несколько приложений, или, когда требуется интеграция с корпоративными системами (MES/ERP) на уровне предприятия.

Рассогласования времени

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

Когда данные проходят через несколько уровней преобразования, возникает проблема временных меток. Например, датчик давления опрашивается ПЛК по Modbus RTU (цикл 100 мс). ПЛК передаёт данные в OPC‑сервер (цикл 500 мс). OPC‑сервер отдаёт данные в SCADA (по подписке). MES забирает данные из SCADA по запросу раз в минуту. Как видно, у нас здесь несколько уровней, и на каком из них ставить временную метку? Если ставить её на каждом этапе заново — теряется синхронность. Если передавать исходную метку от датчика — нужно, чтобы все звенья цепи поддерживали передачу временных штампов.

И здесь нам на помощь приходит возможность использовать протоколы с поддержкой временных меток на источнике. Так, уже знакомый нам OPC UA позволяет передавать данные с исходными временными метками.

Так, для нашего примера, необходимо на датчике (если конечно он поддерживает такую возможность) установить SourceTimestamp = 10:00:00.000. ПЛК при опросе получает значение, но если датчик «немой» по времени, ПЛК сам становится источником и устанавливает SourceTimestamp = 10:00:00.100. OPC UA Server получает данные в 10:00:00.150 и устанавливает:

SourceTimestamp = то, что пришло от ПЛК (10:00:00.100)

ServerTimestamp = 10:00:00.150 (своё время получения)

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

Организация единого пространства данных для SCADA и MES

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

Для того, чтобы лучше понять суть проблемы рассмотрим еще один пример. В типовой ситуации SCADA знает температуру в реакторе как регистр%MW100, MES знает ту же температуру как «TIC-203_PV». А в отчётах для руководства это значение просто «температура в цехе № 5». Как видим, данные есть, но сопоставить их без ручного вмешательства невозможно. Для решение этой проблемы нам необходимо построение семантической модели данных.

В общем случае, наиболее подходящей является трехуровневая модель, состоящая из уровня источников, активов и бизнес‑семантики.

Здесь на уровне источников у нас фиксируются физические подключения, протоколы, адреса регистров. На уровне активов выполняется привязка к конкретным единицам оборудования (насос № 3, реактор № 7, линия розлива А). И на уровне и бизнес‑семантики мы выполняем интерпретацию в терминах производства (производительность, эффективность, качество).

Рассмотрим, как это работает на примере архитектуры «промышленный шлюз + дата‑центр + SCADA/MES».

Шаг 1. Сначала мы осуществляем сбор и нормализацию данных на периметре. Промышленные шлюзы (например, USR‑M300) выполняют сбор данных по разным протоколам (Modbus, Profinet, OPC UA) и преобразование в единый формат (обычно JSON или MQTT Sparkplug B). Далее проводится первичная обработка: фильтрация, агрегация (средние за минуту, максимальные значения), выявление аномалий.

Шаг 2. Семантическое моделирование в дата‑центре. В промышленном дата‑центре или SCADA‑платформе регистры переводятся в теги с понятными именами. Затем теги группируются по единицам оборудования, добавляются бизнес‑атрибуты (нормативные значения, единицы измерения, класс точности). По сути здесь мы обогащаем имеющиеся данные дополнительной информацией.

Для лучшего понимания, как обычно, обратимся к практическому примеру. На химическом предприятии развернули систему, где PLC‑регистры (Modbus) через шлюзы преобразовывались в MQTT, а затем в OPC UA с семантической моделью. В результате время согласования данных между SCADA и MES сократилось с 15 секунд до 200 миллисекунд, а точность прогнозирования отказов достигла 92%.

Шаг 3. Предоставление данных потребителям. Единая модель данных позволяет разным системам получать данные в нужном им виде:

SCADA — через OPC UA с высокой скоростью обновления

MES — через REST API или прямое подключение к историческим данным

BI‑системы — через SQL‑запросы к хранилищу

Мобильные приложения — через MQTT или WebSocket

Заключение

Проблема «зоопарка» протоколов в АСУ ТП не имеет простого решения. Она не исчезнет сама собой — можно только научиться с ней работать, превращая хаос в управляемую гетерогенность.

Для этого не пытайтесь унифицировать всё до единого протокола. Это невозможно экономически. Но можно использовать правильные инструменты для правильных задач. Так для максимальной производительности на критичных участках подойдут нативные драйверы, а серверы OPC UA — для интеграции разнородных систем и семантической совместимости. Шлюзы и конвертеры — для стыковки «старого» и «нового».

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

В конечном счёте, цель всей этой интеграционной работы — дать технологам, диспетчерам и руководителям прозрачную картину производства, где данные от любого датчика, независимо от его протокола и года выпуска, доступны в нужном месте, в нужное время и в нужном контексте. И современные технологии — от промышленных шлюзов до платформ класса Industrial Data Hub — делают эту цель достижимой даже на предприятиях с самой пёстрой историей автоматизации.

Если в АСУ ТП вы уже упёрлись в предел разрозненных знаний и понимаете, что одних наладки и монтажа уже недостаточно, дальше нужен системный переход к проектированию и программированию. Курс «Программист АСУ ТП» как раз закрывает этот разрыв: помогает собрать в единую логику путь от ПЛК до SCADA, понять архитектуру решений и начать увереннее брать на себя более сложные инженерные задачи.

Начать можно с открытых уроков — они помогают быстро понять, насколько вам подходит этот переход в программирование АСУ ТП.

  • 9 апреля в 20:00. «Введение в АСУ ТП: путь от электрика до программиста». Записаться

  • 24 апреля в 20:00. «Программируемые реле в АСУ ТП: гибкий инструмент для решения инженерных задач». Записаться