Кроссплатформенный OPC UA Сервер
В общем, потребовалось передавать данные по OPC UA, загвоздка в том, что пилить свою реализацию нет времени, а сервер должен работать на x86-64 Windows & Linux, а так же на ARMv7.
Может есть какие-то либы или sdk для создания данного сервера, можно платные, цена в несколько тыщ баксов значения не сыграет.
А то, что перечислено в Wikipedia уже смотрели и ничего не подошло?
И что тебя смутило в http? если не брать бинарную реализацию?
Эм, смотрел только в русской вики и даже не видел этих ссылок, спасибо. Буду смотреть =)
Брать надо обе ибо заказчик хочет
Там тебя пнули где посмотреть, есть реализации на пистонет, жабе, выбирай на вкус
Какой пистонет и жаба на ARMv7, смеётесь что ли?
понятно, каши не сваришь, раз такой очередной удивленный возглас
Тогда бы писал конкретней, что тебе хочется — си, плюсы
И то и другое тоже есть
Тогда бы писал конкретней, что тебе хочется — си, плюсы
Warning: The sample server is not a complete server, and a number of security related features are missing. Please refer to Mantis Issue #3949 for details.
можно платные, цена в несколько тыщ баксов значения не сыграет.
ты вот весь такой противоречивый
тут походу не вопрос надо задавать, а сразу в джоб
А в чём противоречие?! В том, что сервер по ссылке не готов, а мне нужен готовый сервер в продакшен. Если есть платный аналог, это тоже устроит, просто выберу что больше подходит под задачу, всё равно окупиться.
Pthon / Mono / Java — не подходят, ибо на железке с армом кроме OPC там уже вертится миллион служб и производительность \ ОЗУ на исходе.
C / C++ или другой язык не будет иметь значение, главное чтобы был C ABI.
тут походу не вопрос надо задавать, а сразу в джоб
О да конечно, что бы получить чей-то недовысер который ровно столько же придётся адаптировать под проект, как если бы я взял опенсурсное решение.
нет такого, под никсами используется МЭКовский протокол, который обычно поддерживается нашими сырьевиками
Эм. Кем используется? 0_о
газовиками/нефтевиками и прочими алмазными шахтами. или у вас прям под нужды производства? О_о
У нас просто в скаду показания датчиков и счётчиков будут передаваться о_0
У нас просто в скаду показания датчиков и счётчиков будут передаваться о_0
да об этом я и говорил, под никсами все мэк используют для заведения датчиков и счетчиков в скаду
У нас просто в скаду показания датчиков и счётчиков будут передаваться о_0
а есть разница? мэк все поддерживают в 2к17, но часто заказчики все протоколы просто называют орс, тк он брат сестры директора, но тз выдать надо. постоянно у кого-то появляется желание забомбить орс под никсы и все заканчивается на мэк 🙂
Мы вот для заведения датчиков и счётчиков модбасим, в основном.
Мы вот для заведения датчиков и счётчиков модбасим, в основном
это если к компу со скадой напрямую цеплять датчики. орс или мэк появляются когда система дофига распределенная, особенно с узкими каналами до сервера со скадой и логами. по спутнику или gprs модбас особо не погоняешь 🙂
Ему архивы передавать надо. А кто в наше время весь стандарт реализовывает, с чтением архивов (файлы там, или очередь к примеру). Все велосипедят архивы на модбасе.
И у меня стойкое ощущение, что он не понимает, что такое OPC и хотит его прям в контроллер запихать.
В реальности всё наоборот. По gprs гоняют modbus TCP и на 9600 (условно) спокойно сливают данные за считанные секунды.
У меня в практике только один случай был, когда к скаде напрямую (завод, витая пара до объекта 1 км) подключение.
МЭК в этом отношении хуже модбаса, т.к. он ASCII (соответственно числа передаются текстом: 112432.34 против 4 байт в модбасе, например).
А нет, вру. Ещё по радиоканалу оборудование было. «Напрямую» можно считать потому что радио просто удлиняло кабель. А так в системе как com порт виделось и объекты по-очереди надо было опрашивать.
В реальности всё наоборот. По gprs гоняют modbus TCP и на 9600 (условно) спокойно сливают данные за считанные секунды.
У меня в практике только один случай был, когда к скаде напрямую (завод, витая пара до объекта 1 км) подключение.
МЭК в этом отношении хуже модбаса, т.к. он ASCII (соответственно числа передаются текстом: 112432.34 против 4 байт в модбасе, например).
похоже мы немного о разных реальностях 🙂
Если на объекте под пару сотен датчиков, а до него только спутник, или, в лучшем случае, gprs, и на это все требование, чтобы оператор имел возможность реагировать на нештатные ситуации в реальном времени. Т.е. чтобы если например давление закинет, или пожар какой, он не ждал по несколько минут. Если все это добро опрашивать напрямую через modbus tcp, то нужно будет интервал опроса выставлять в совершенно неприличные значения. При этом обычно на таких объектах состояние +/- стабильное, а трафик платный, поэтому постоянный опрос такого количества устройств с получением одних и тех же значений обойдется неадекватно дорого. Вот тут и пригождается ОРС или МЭК: на узлах выставляются уставки на параметры и их приоритезация по любой упоротой логике, контроллер на месте опрашивает все по модбасу и только если изменение параметра выходит за уставку передает по спутниковому каналу. ПрофИт.
да об этом я и говорил, под никсами все мэк используют для заведения датчиков и счетчиков в скаду
Да нафига мне МЭК которого нет в контракте?! Есть только OPC UA по ТЗ =)
Да нафига мне МЭК которого нет в контракте?! Есть только OPC UA по ТЗ =)
Спасибо, мне на такую херню везёт, то OPC, то транслятор какой-то надо написать, ну ёпрст, весь год такой =)
И у меня стойкое ощущение, что он не понимает, что такое OPC и хотит его прям в контроллер запихать.
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, поэтому используется только телесигнализация и телеизмерения. В дальнейшем думаю добавить и телеуправление.