КОММУНИКАЦИОННЫЕ СРЕДЫ ДЛЯ ПРОМЫШЛЕННЫХ ПРЕДПРИЯТИЙ

Скачать

И.В. Иванов (ООО "ИнСАТ")

В настоящий момент в промышленной автоматизации используются следующие среды физической передачи данных:

1. Токовая петля — как в аналоговом, так и цифровом виде (HART‑протокол и различные разработки отдельных фирм). Токовая петля применяется для опроса всевозможных датчиков: простых с аналоговым сигналом и интеллектуальных с передачей набора параметров и диагностики, а также для управления.
   
2. Интерфейс RS‑485 и в меньшей степени его ближайшие родственники — RS‑232/422. Применяется на «полевом» уровне для связи контроллера с модулями ввода, измерительными приборами, датчиками. Зачастую RS‑485 даже не выходит за пределы щита [1].
   
3. Интерфейс Ethernet — наиболее востребован в последнее время за счет ценовой доступности, широкой номенклатуры кабелей, коннекторов, стандартных инструментов и способов построения сетей. Основное применение Ethernet — связь между узлами системы (между компьютером и контроллером или сетью контроллеров) [2].
   
4. Различные беспроводные интерфейсы: Wi‑Fi, GPRS, 3G и др. Применяются либо в случаях больших расстояний, либо когда прокладка кабельных линий невозможна [3].
   

Краткое описание некоторых промышленных протоколов 

• Modbus можно смело назвать «королем», так как он является самым массовым промышленным протоколом за счет простоты реализации. Однако протокол не лишен недостатков: передаваемые данные не стандартизированы, отсутствует возможность автоматического получения списка переменных устройства, работа ведется только в режиме постоянного опроса (чтения), сложная передача архивных данных [1].

• IEC 60870-5 — имеет две основных разновидности: IEC 60870‑5‑101 (для RS‑485) и IEC 60870‑5‑104 (для сетей TCP/IP). Протокол применяется в электроэнергетике. В настоящее время более распространен IEC 60870‑5‑104. Преимущества данного протокола: работа в режиме подписки (устройство передает данные получателю), что снижает нагрузку на сеть, несложная реализация, а также возможность передачи архивных значений с метками времени (например, для точной фиксации времени аварии).

• IEC 61850 — также применяется в электроэнергетике и газо‑ и нефтетранспортных системах. Данный протокол более функционален по сравнению с 60870‑5‑104, так как имеет возможность передачи файлов и может работать как в режиме постоянного опроса (чтения) через протокол MMS, так и в режиме подписки через протокол GOOSE. Кроме того, имеется возможность получения перечня переменных устройства, что упрощает конфигурирование. К недостаткам протокола можно отнести высокую сложность его реализации.

• BACnet — один из наиболее технически совершенных протоколов: способен работать как в режиме опроса, так и в режиме подписки (что снижает нагрузку на сеть), а также имеет возможность сегментации данных (упаковку запрашиваемых объектов в один пакет, что тоже снижает нагрузку на сеть); имеет возможность автоматического считывания не только перечня переменных устройства, но и всех доступных устройств по сети (что существенно ускоряет конфигурирование), при этом к каждой  переменной устройства передается набор атрибутов данных (шкала, единицы измерения, комментарий), что ускоряет конфигурирование. К минусам протокола можно отнести высокую сложность реализации.

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

Отметим еще одно направление развития промышленных протоколов — это системы учета, в которых используются всевозможные счетчики. Здесь каждый производитель разрабатывает собственные протоколы, ориентированные под специфику данных задач. Таким образом, на рынке промышленной автоматизации присутствуют несколько десятков промышленных протоколов. Резонный вопрос: Зачем столько?

Причин несколько. Область промышленной автоматизации очень инерционна, и новые решения приживаются в ней очень долго, а обкатанные остаются «на вооружении». Этим объясняется активное применение «ветерана» промышленных протоколов — Modbus. Другая причина в том, что стандартизированные протоколы (BACnet, IEC61850) сложны в реализации и могут оказаться избыточными для многих задач. Поэтому все крупные производители считают своим долгом разработать собственный протокол, который замыкает пользователей оборудования на продукцию компании. Это выгодно для производителя, но далеко не всегда удобно потребителю. 

Возможна ли в будущем унификация протоколов? Ответ: «Да — возможна». Идеально на эту роль подходит стандарт OPC. Ранее OPC существовал в трех спецификациях (DA, HDA, AE), применялся исключительно на компьютерах, играл роль программного шлюза — конвертера из различных промышленных протоколов в один унифицированный интерфейс и использовался со SCADA‑системами. В таком виде он не мог быть инструментом всеобъемлющей унификации, так как был жестко привязан к технологии DCOM от Microsoft. В 2007 г. была выпущена первая версия новой спецификации стандарта — OPC UA [4, 5]. Новая спецификация избавилась от некоторых недостатков и впитала преимущества всех существующих протоколов.

Возможности OPC-серверов унифицированной архитектуры

1. Поддержка клиент‑серверной архитектуры. При этом как клиент, так и сервер может иметь неограниченное число подключений, что позволяет строить структурно сложные системы.
2. Кроссплатформенность. Сервер или клиент могут быть запущены на любой программно‑аппаратной платформе с невысокими системными требованиями
3. Передача различных форматов данных: текущие значения, архивные записи, файлы, сообщения.
4. Считывание списка переменных (в том числе с иерархией), а также поиск устройств. 
5. Поддержка всех современных механизмов безопасности: аутентификация подключения и шифрование передаваемых данных. Этим не может похвастаться ни один промышленный протокол.

Последний пункт из года в год становится все более актуальным. Не секрет, что сети АСУТП — головная боль системных администраторов. Ни один промышленный протокол не имеет средств защиты от намеренного или случайного взлома. Системным администраторам приходится строить изолированные физические сети, виртуальные сети с белым списком MAC‑адресов, создавать VPN‑туннели и т. д. С механизмами безопасности OPC UA можно значительно упростить сетевую архитектуру.

Когда же ожидать массового внедрения OPC UA на рынке? Мы считаем, что переломный момент в истории данного стандарта уже наступил. Прошло 10 лет с момента выхода первой версии новой спецификации. За это время был выпущен рабочий код UA‑сервера и клиента от различных разработчиков и от самой OPC Foundation. Код OPC Foundation опубликован на GitHub и распространяется бесплатно. Это выгодно отличает его от других протоколов, у которых в открытом доступе находится лишь описание самого протокола обмена данными. Крупные разработчики SCADA‑систем внедрили OPC UA клиенты в свои продукты. Не отстают и производители OPC‑серверов — UA‑серверы также стали доступны на рынке.

Ранее применение OPC UA в основном касалось распределенных систем сбора данных, где UA использовался в качестве туннеля. Например: сбор данных на сервере от различных протоколов (Modbus, Profinet, OPC DA) с последующей передачей на удаленный SCADA‑сервер. Однако на рынке стали появляться контроллеры со встроенным OPC UA сервером от компаний Siemens, Beckhoff, Omron и др.

Рис. 1 Интерфейс конфигурирования Multi-Protocol MasterOPC

Компания «ИнСАТ» первой в России приняла на вооружение «классический» OPC [4]: первой сделала OPC‑клиент в MasterSCADA, выпустила OPC‑сервер —MasterOPC Toolkit. Первым OPC UA продуктом в нашей стране стал Multi‑Protocol MasterOPC сервер. Он имел и встроенные UA‑сервер и UA‑клиент, а также OPC DA клиент, что позволило быстро завоевать рынок OPC‑туннелей, который до этого был представлен лишь дорогими иностранными продуктами. Затем OPC UA появился во всех остальных продуктах: в Modbus Universal MasterOPC сервере и в MasterSCADA. В MasterSCADA спецификация OPC UA реализована в трех исполнениях: UA‑клиента, UA‑сервера и в качестве внутреннего протокола сетевого обмена. Это позволило MasterSCADA выйти на новый уровень сетевого взаимодействия, увеличить сложность и многообразие создаваемых сетевых архитектур (рис. 1).

Также OPC UA встроен в перспективный продукт компании «ИнСАТ» — MasterSCADA 4D. Поскольку его главной особенностью является кроссплатформенная среда исполнения, OPC UA будет функционировать не только на рабочих станциях, но и в контроллерах, в операторских панелях, в облачных сервисах (рис. 2).

Рис. 2 Операция добавления протокола в MasterSCDA 4D

«Умный дом» и концепция Internet of things

Помимо промышленной автоматизации существует также отдельная отрасль автоматизации зданий и систем «умного дома» со своими контроллерами, стандартами, протоколами. Если в системах автоматизации зданий уже много лет и достаточно активно применяются протоколы BacNET и Lonworks, то в сегменте «умного дома» доминирующий протокол — KNX. Однако по‑настоящему массовым рынок систем «умного дома» не может стать из‑за высокой стоимости компонентов автоматизации. Если на уровне зданий высокая стоимость компонентов автоматизации не является препятствием, так как преимущества такой автоматизации очевидны, то на уровне дома — это серьезная проблема. 

Снижению стоимости компонентов могло бы способствовать повышение конкуренции на этом рынке — приход новых, небольших компаний‑производителей. Однако им мешает отсутствие унифицированных протоколов. Доминирующий протокол KNX сложен в реализации, а каждое новое KNX‑устройство должно проходить сертификацию. Кроме того, протокол использует  собственную интерфейсную шину (хотя есть реализация протокола под TCP/IP). Все это приводит к тому, что отдельные производители также пытаются сделать «свой KNX».

Перспективным унифицированным протоколом для систем «умного дома» и интеграции в него устройств IoT может стать MQTT. Данный протокол был разработан еще в 1999 г., а впоследствии стандартизирован. Протокол полностью открытый. Кроме того, существует несколько открытых бесплатных кроссплатформенных библиотек, с помощью которых можно быстро подключить данный протокол к любому приложению или интегрировать в устройство. Помимо рынка IoT, протокол MQTT активно применяется как механизм передачи данных в различных облачных сервисах, например в Microsoft Azure. 

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

Рис. 3. OPC UA и MQTT позволяют конвертировать различные протоколы в один унифицированный интерфейс

В настоящий момент специалисты компании «ИнСАТ» встроили MQTT‑клиент в ОРС‑серверы: Modbus Universal MasterOPC и Multi‑Protocol MasterOPC, а также в MasterSCADA 4D. Таким образом, продукты компании позволяют интегрировать системы управления (со всем разнообразием применяемых в них протоколов) со стремительно развивающейся индустрией IoT и IIoT (рис. 3). В совокупности с коммуникационными возможностями всех поддержанных промышленных протоколов продукты «ИнСАТ» являются мощным инструментом, позволяющим создавать самые сложные распределенные системы.

Список литературы

1. Аристова Н.И. И снова о промышленных сетях // Автоматизация в промышленности. 2012. №12.
2. Аристова Н.И. Ethernet в промышленной автоматизации: преодоление преград // Автоматизация в промышленности. 2013. № 1.
3. Аристова Н.И. Беспроводная связь в промышленной автоматизации: современные стандарты и области применения//Автоматизация в промышленности. 2013. № 1.
   
4. Иванов И.В. OPC UA – революция в сетевом обмене промышленных сетей // Автоматизация в промышленности. 2017. № 2.
   
5. Фортин Т., Хокинсон Б. OPC UA и роль стандартов связи в развитии промышленного Internet вещей // Автоматизация в промышленности. 2016. № 8.
   

Иванов Игорь Владимирович – ведущий инженер компании «ИнСАТ».