ScadaPy — использование OPC UA
В предыдущих нескольких статьях, мною были описаны возможности применения протокола modbus для создания собственной Scada системы на базе python. В этот раз хочется поделиться опытом построения системы опроса подчиненных устройств с использованием ОРС технологии.
Недостатки OPC серверов в том, что их можно использовать только в операционных системах семейства Microsoft Windows (как правило они платные), а об устройствах использующих ОС Linux можно было забыть.
Но со временем была создана спецификация OPC Unified Architecture (англ. Унифицированная архитектура OPC), что дало возможность использовать данную технологию передачи данных на иных операционных системах отличных от Windows. Это касается и встраиваемых систем, где может быть запущен полноценный Linux.
Подробнее можно прочитать здесь.
Например, на одноплатном компьютере Raspberry Pi можно запустить одновременно несколько различных OPC UA серверов для опроса терминальных устройств, счетчиков, датчиков и т.д., при этом система будет работать вполне стабильно.
Установка библиотек
Для работы с OPC UA и modbus серверами используются Xubuntu 17.04 Desktop и Windows 8.1. В Xubuntu 17.04 уже установлены Python 2.7 и Python 3.5 по умолчанию. Выбираем Python 3.5.
Если после установки операционной системы на компьютер не были добавлены необходимые пакеты, то нужно выполнить:
Решаем проблему зависимостей:
После поставим еще необходимые библиотеки:
Для windows можно установить через pip3.exe, библиотека и примеры находятся здесь
Для запуска сервера, библиотеку нужно импортировать:
Теперь создаем OPC UA сервер.
Вот и весь код на python для запуска OPC UA. Как оказалось ничего сложного, и если теперь подключиться к запущенному серверу с помощью UA Expert, то можно увидеть иерархический список наших объектов и переменных со значениями.
Для модификации значений переменных используется функция set_value типа:
Конечно это очень примитивный пример, но в библиотеке OPC UA заложено намного больше возможностей, о которых можно прочитать здесь.
Единственное в чем не удалось разобраться, так это, как установить логин и пароль на сервер, вроде как-то посредством politics, думаю позже решу эту проблему.
Конфигуратор серверов
В продолжение к вышесказанному, возникла задача по оперативному конфигурированию каждого вновь создаваемого сервера.
Для данной цели был написан «Конфигуратор серверов» на библиотеке PyQt5.
— создается база данных на sqlite3
— формируются таблицы для slave и master частей сервера.
— таблицы заполняются необходимыми параметрами.
— формируется скрипт запуска.
Основная идея – серверы должны одинаково работать как в Windows, так и в Linux.
Скачать можно здесь
Структура каталогов:
srvconf.py – программа «Конфигуратор сервера»
db – находится файл базы данных srvDb.db.
img – файлы .png для кнопок
source – файлы шаблонов серверов
- mercury.py – библиотека для опроса счетчиков меркурий 230
- modbustcp_master_dcon.py – slave-сервер modbusTCP, master – опрашивает подчиненные устройства по протоколу DCON (Advantech). В настоящий момент только модуль 4050.
- modbustcp_master_http.py – slave-сервер modbusTCP, master – формирует запрос методом GET по URL или IP, в ответ получаем список значений типа int или string разделенных запятыми. Используется для встроенных систем с http серверами на борту, я использовал для ESP8266 c wi-fi соединением.
- modbustcp_master_ping.py – slave-сервер modbusTCP, master – отправляет ICMP пакет ping на указанный сервер, в случае true формирует дискретную 1, в случае false – 0.
- modbustcp_master_rtu.py — slave-сервер modbusTCP, master – modbusRTU. Используется для опроса подчиненных устройств по протоколу modbusRTU
- modbustcp_master_tcp.py — slave-сервер modbusTCP, master – modbusTCP. Используется для опроса удаленных устройств по протоколу modbusTCP.
- opcua_master_dcon.py — slave-сервер OPC-UA, master – опрашивает подчиненные устройства по протоколу DCON (Advantech). В настоящий момент только модуль 4050.
- opcua_master_http.py — slave-сервер OPC-UA, master – формирует запрос методом GET по URL или IP, в ответ получаем список значений типа int или string разделенных запятыми. Используется для встроенных систем с http серверами на борту, я использовал для ESP8266 c wi-fi соединением.
- opcua_master_mercury230.py — slave-сервер OPC-UA, master – формируются команды опроса счетчиков меркурий 230. Реализация исключительно только для OPCUA, поскольку не все параметры ответа по данному протоколу можно однозначно обработать для того чтобы поместить в регистры modbus.
- opcua_master_ping.py — slave-сервер OPC-UA,master – отправляет ICMP пакет ping на указанный сервер, в случае true формирует дискретную 1, в случае false – 0.
- opcua_master_rtu.py — slave-сервер OPC-UA,master – modbusRTU. Используется для опроса подчиненных устройств по протоколу modbusRTU.
- opcua_master_tcp.py — slave-сервер OPC-UA, master – modbusTCP. Используется для опроса удаленных устройств по протоколу modbusTCP.
scr – файлы сценариев для запуска сервера.
Для Windows будет создан файл типа start_XX.bat, для Linux файл типа start_XX.sh, где ХХ порядковый номер сервера в таблице servers.
Содержимое файла start_XX.bat:
Содержимое файла start_XX.sh для Linux:
В параметрах запуска для Linux используется xfce4-terminal, т.к. работаю в Xubuntu 17.04,
но можно указать и другой тип запуска, вроде gnome-terminal.
В примерах довольно понятно описаны параметры заполнения таблиц.
Примечательно, что на raspberry Pi запускалось одновременно 4 сервера — mobus_ping, opcua_http, opcua_mercury230 на /dev/ttyUSB0 и modbus_dcon на /dev/ttyUSB1, при этом он работал довольно стабильно и без сбоев.
Управление на данный момент реализовано частично и только в master_dcon, поэтому используется только телесигнализация и телеизмерения. В дальнейшем думаю добавить и телеуправление.
Источник
OPC UA — НОВЫЙ ВИТОК ЭВОЛЮЦИИ
Первая версия технологии OPC была разработана международной некоммерческой организацией OPC Foundation в 1996 г. Перед ее создателями стояла задача собрать и привести к общему знаменателю целый «зоопарк» уже существующих и находящихся в разработке протоколов. Несмотря на первоначальный скепсис производителей ряда SCADA-систем, технология оказалась революционной. Приняв технологию OPC, разработчики SCADA избавились от необходимости поддерживать сотни драйверов для различных устройств, а производители оборудования, разработав OPC-сервер, обрели уверенность в том, что их продукт может применяться пользователями любых SCADA.
Бурное распространение OPC пришлось на начало 2000-х годов. Технология активно развивалась: появились стандарты для обмена архивными данными и сообщениями, все производители SCADA-систем реализовали поддержку технологии OPC, а наличие OPCсервера к приборам стало само собой разумеющимся.
Однако сегодня можно смело утверждать, что «классическая» OPC (стандарты OPC DA и OPC HDA) доживает свой век: унификация различных протоколов была с блеском решена на технологиях, которые в настоящий момент уже устарели. Дело в том, что OPC DA и OPC HDA базируются на технологии Microsoft DCOM. В 1996 г. Windows была доминирующей операционной системой: Apple находилась в шаге от банкротства, а Linux была нишевым продуктом, использовавшимся преимущественно в серверах и требовавшим высокой квалификации для обслуживания. По этой причине привязка к технологии DCOM (на тот момент современной) была для OPC Foundation логичным, а возможно, даже единственным вариантом. В то время Internet только начинал появляться на предприятиях и был медленным и дорогим средством коммуникации, поэтому необходимости в поддержке работы по сети не было.
Однако за 20 лет в ИТ-отрасли произошли радикальные изменения. В настоящее время Windows больше не является самой популярной ОС, хотя и остается главной на десктопных компьютерах. Процессоры стали быстрее, и теперь ОС может обслуживать и дешевый контроллер. Развитие Internet, в том числе мобильного, позволило удаленно подключать различные объекты и собирать с них данные. Кроме того, добавились и новые вызовы: на системы управления ТП начались хакерские атаки, что привело к необходимости шифрования и аутентификации. К новой реальности «классическая» OPC оказалась не готова.
Для актуализации технологии OPC организация OPC Foundation инициировала создание нового стандарта, по сути, с нуля. Теперь за основу брались открытые кроссплатформенные технологии без привязки к DCOM. Новая редакция получила название OPC UA — Unified Architecture («унифицированная архитектура»). OPC UA сохранила все достижения «классической» OPC, но при этом лишена ее недостатков.
OPC UA обладает следующими преимуществами [1, 2].
• Полностью кроссплатформенный стандарт. На первый взгляд это кажется несущественным, так как большинство SCADA-систем все равно остаются (и останутся) работать на ОС Windows. Однако с появлением кроссплатформенности исчезла необходимость в существовании OPC-сервера как отдельного приложения
на компьютере, поскольку теперь большинство контроллеров уже имеют встроенную ОС и производитель может установить OPC-сервер непосредственно в контроллер. Для получения тегов из контроллера больше не требуется настраивать отдельное приложение, достаточно задать в SCADA-системе параметры подключения к контроллеру, и весь список переменных (в том числе архивных) будет получен и добавлен в проект. Таким образом, построение проекта существенно ускоряется.
• Легкость удаленного подключения. Любой разработчик АСУ с содроганием вспоминает процесс подключения удаленного «классического» OPC-сервера к SCADA-системе: для получения данных от другого компьютера необходимо было настроить DCOM по специальной инструкции. Вряд ли найдется хоть один специалист, которому удалось это сделать с первого раза. А настройка серверных редакций ОС Windows еще более сложная, в ряде случаев заканчивающаяся неудачей. В OPC UA такой проблемы в принципе нет. Все, что нужно, — это открыть разрешение в файрволе на нужный TCP-порт. Если удаленный компьютер находится во внутренней сети, недоступной SCADA, то и это не становится проблемой. Задача решается переадресацией порта. А при работе через Internet обмен можно вести как через VPN, так и через публичный IPадрес. Теперь подключение удаленных OPC не вызывает никаких проблем.
• Шифрование и аутентификация. К сожалению, к новым вызовам, требующим повышенной безопасности передачи данных, пока не готов ни один промышленный протокол: все они разработаны в конце 1990-х годов (или даже ранее) и не имеют никакой защиты. Технология OPC UA в этом вопросе является исключением: в ней применяются несколько вариантов шифрования и аутентификации. Это позволяетвести передачу данных через Internet, не беспокоясь за их сохранность.
• Унификация данных. В «классической» OPC существуют несколько стандартов для каждого варианта использования: OPC DA — для текущих данных, OPC HDA — для архивных и т. д. В OPC UA все стандарты объединены: текущие данные, архивные данные, сообщения — все это передается через один сервер, по единому интерфейсу.
В России технологию OPC первой среди отечественных разработчиков применила компания ИнСАТ. SCADA-система MasterSCADA полностью базируется на стандарте OPC, все переменные проекта наследуют атрибуты и значения OPC-тегов. Также первой в России компания ИнСАТ выпустила инструментарий для разработки OPC-серверов — MasterOPC Toolkit, ставший «движком» для многих OPC-серверов.
В лидерах компания ИнСАТ оказалась и с OPC UA — она первой обеспечила полный комплекс продуктов с поддержкой данной технологии. В 2015 г. компания выпустила MasterSCADA 3.7 с поддержкой OPC UA клиента, а также MultiProtocol MasterOPC — сервер с поддержкой OPC UA сервера [3]. В 2016 г. была запущена MasterSCADA 3.8 с поддержкой OPC UA сервера, то есть SCADA теперь может не только получать данные по UA, но и отдавать их.
В новейшем продукте — платформе MasterSCADA 4D — также реализована полная поддержка OPC UA. При этом она предназначена для работы как на компьютерах, так и на контроллерах. Это означает, что OPC UA сервер будет функционировать непосредственно на контроллере и передавать данные напрямую UAклиентам. На данный момент исполнительная система MasterSCADA 4D уже портирована на контроллеры Trei, Wago, Fastwell, ОВЕН и др.
На сегодняшний день не все компании — разработчики контроллеров способны реализовать OPC UA серверы для собственных изделий. Компания ИнСАТ максимально облегчает для них указанную задачу. Для этого в Multi-Protocol MasterOPC сервер добавлена возможность создания собственных драйверов. Достаточно написать небольшую библиотеку с реализацией необходимого протокола, чтобы появилась возможность передачи данных как по OPC DA и HDA, так и по OPC UA.
На протяжении еще долгого времени будет оставаться актуальной задача подключения удаленных OPC DA/HDA серверов. Как уже было отмечено, в «классической» OPC это очень трудоемкий процесс с непредсказуемым результатом. Для решения данной проблемы уже давно существует специальный класс продуктов — OPC-туннели. Подобные продукты выпускают фирмы Matrikon, Kepware, Cogent. Компания ИнСАТ также разработала аналогичный продукт — MasterOPC Tunneler. Однако у зарубежных производителей обмен между частями туннеля реализован по внутреннему протоколу, а в MasterOPC Tunneler — через OPC UA. Физически он представляет собой Multi-Protocol MasterOPC с двумя плагинами: OPC DA Client и OPC UA Client.
Таким образом, на компьютер с целевыми OPC-серверами ставится Multi-Protocol с плагином OPC DA Client, работающим в режиме OPC UA сервера, а на компьютер с целевой SCADA-системой — MultiProtocol с плагином OPC UA Client. Рассмотрим плюсы такого решения.
Первое ключевое преимущество состоит в возможности создания произвольной архитектуры туннеля (рис. 1).
Кроме того, если SCADA-система уже имеет встроенный UA-клиент, то необходимость в одном плагине просто отпадает. В этом случае архитектура упрощается — остается только один Multi-Protocol MasterOPC с плагином OPC DA Client (рис. 2).
Это позволяет гибко подобрать структуру ПО под каждую конкретную задачу и, учитывая, что каждый плагин лицензируется отдельно и стоит существенно дешевле аналогов, помогает к тому же максимально оптимизировать затраты. При этом на любом узле сети, на котором установлен Multi-Protocol MasterOPC, возможно подключение не только OPC-серверов, но и различных устройств по протоколам SNMP, Profinet, IEC60870-5-104, BacNET, а также разнообразных счетчиков коммерческого учета. В итоге Multi-Protocol MasterOPC превращается в многофункциональный коммуникационный хаб с огромными возможностями и безграничной гибкостью.
При анализе тенденций развития современных технологий появляется уверенность в том, что OPC UA, как и в свое время «классическая» OPC, произведет революцию в обмене данными посредством промышленных сетей, обеспечив пользователям удобство, надежность и безопасность.
Источник
