Выбор способа управления системой. OPC сервер и прочее.

[Mirmik]

Сделали мы систему. Осями крутит, что нужно измеряет, в общем работает.
Управляется компьютером на линухе по самопальному протоколу. Протокол тяготеет к использованию паттерна RPC и отчасти к publisher/subscriber, то есть запрос - вызов функции - ответ и фоновое уведомление о возникающих событиях.

Проблема в том, что творение сие весьма самопально. Сейчас стоит задача о переводе протокола управления на что-то стандартное.
Я посмотрел на всякие mqtt, zeromq и прочее, но, поскольку оборудование наше таки тяготеет к АСУ ТП, я так же задумался об использовании OPC сервера и прочего, что с этим связано.

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

1. Правильно ли вообще моё желание работать с OPC?
1,5. Правильно ли моё понимание, что OPC - это такая морда лица, которым моё оборудование смотрит в сеть на подключающегося к ней клиента?
2. Поддерживает ли OPC средства типа publisher/subscriber или доставку сообщений о событиях?
3. Как у данных систем с быстродействием? (у нас критичны задержки на передачу сообщений 5-10 мс).
4. Существуют ли opensource OPC, и в каком они состоянии?.
5. Реально ли работать с OPC под linux, qnx. Какие реализации можно рассмотреть?
6. Какие преимущества даст использование OPC по сравнению с прочими решениями?.
7. Каков порог вхождения и каковы могут быть мои первые действия по части освоения данного вопроса.

Заранее спасибо :).

[Михайло]

OPC - это программная технология by Майкрософт. Суть - технология предоставляет возможность циклического обмена данными между двумя приложениями в ОС Windows. Сеть (Ethernet или RS485) здесь не при чем. OPC - это передача данных между двумя локальными программами. Одна программа должна включать в себя стандартный OPC-сервер, а другая - стандартный OPC-клиент.
Почему многие OPC-серверы работают через сеть? Ответ: OPC-сервер имеет два интерфейса - первый интерфейс - OPC, а второй - сетевой интерфейс с неким устройством. То есть то, что общепринято называть OPC-сервером - это не просто OPC-сервер, это нечто большее. Лучше те самые "OPC-серверы" называть драйверами устройств с OPC-интерфейсом. То есть, если Вы скачали драйвер (OPC-сервер) устройства, то можете быть уверены, что с помощью OPC-клиента получите доступ к данным устройства.

Работа OPC-мостика идет через посредство ОС Windows, поэтому задержки 5-10 мс объяснимы и неустранимы. Наличие OPC-серверов под Linux нужно узнавать у производителей железа.

Существуют также такие программы, которые можно назвать "универсальные OPC-серверы". Это драйвера, у которых оба интерфейса стандартны, например, OPC-сервер + Modbus TCP. Такие драйверы позволяют получить доступ к любым устройствам со стандартным интерфейсом, например, Modbus TCP.

[Mirmik]

А есть же вроде, OPC UA которое должно отвязать OPC от винды.

[Mirmik]

А в догонку еще такой вопрос... OPC сервер вообще нужен?

[Михайло]

Писать самому драйвер для устройства геморно, лучше взять готовый OPC-сервер и прикрутить к OPC-клиенту, код которого найдете в opensource.

[Romcheg]

Лучше сделать поддержку ModBusTCP/IP, быстрее, надежнее, и меньше возни, поддержка будет со стороны практически 99.9% скада-систем. И к тому же под линуксом не проблема его сделать, а вот с ОРС только стандарт UA под линь будет и то, имхо, еще пару лет подождать надо, пока он крепко на ноги встанет...

И забудьте про open source насчет ОРС...

[Михайло]

Лучше сделать поддержку ModBusTCP/IP, быстрее, надежнее, и меньше возни, поддержка будет со стороны практически 99.9% скада-систем.

Роман, не путайте, человек свою "скаду" пишет. Ему не нужны чужие скады.

И забудьте про open source насчет ОРС...

Я видел, предлагается много исходников OPC-клиентов. Это все фигня?

[Romcheg]

Я видел, предлагается много исходников OPC-клиентов. Это все фигня?

Видеть исходник - это одно, а вот использовать его в своем решении - это абсолютно другое. Внимательно надо читать лицензии, которыми эти исходники сопровождаются. Все около ОРС-шные дела контролирует ассоциация OPC Foundation и они не являются апологетами open source, к тому же за официал хотят денег в виде членских взносов.

[Mirmik]

Лучше сделать поддержку ModBusTCP/IP, быстрее, надежнее, и меньше возни, поддержка будет со стороны практически 99.9% скада-систем.

Romcheg

Насколько я понимаю, в рамках ModBusTCP невозможно организовать подписку на события или хотя бы уведомления от аппаратуры. То есть, для этого придется вводить дополнительный канал связи. Правильно?

[Romcheg]

Нет, модбас - транзакционный: запрос-ответ. Если что-то по подписке смотреть, то надо стандарты покрупнее - могу ошибаться, но вроде МЭК 104-й умеет так как Вам надо.

[Siluet]

Если что-то по подписке смотреть, то надо стандарты покрупнее

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

[Dotarev]

И забудьте про open source насчет ОРС...

Справедливости ради стоит сказать, что Microsoft опубликовало на Github под свободной лицензией (GPL 2.0) библиотек, реализующих как сервер, так и клиент OPC UA. Есть также примеры.
Лицензия GPL 2.0 означает, что реализованные на основе данной библиотеки программы Вы обязаны распространять вместе с исходным кодом. Заявлена также дальнейшая поддержка проекта.
Впрочем, можно стать OPC Foundation Corporate Members и делать закрытый программный продукт.

[+] Из рассылки OPC Foundation

"...cross-platform reference stacks enables the creation of single-source OPC UA applications that will run unmodified on Linux, iOS, iPhone, Windows Phone and Android (via Xamarin), Windows Nano Server, Windows Vista, 7, 8 and 8.1, Windows 10’s Universal Windows Platform as well as Azure Service Fabric and Azure ASP"

следует, это кросс-платформенное решение, позволяющее без модификации исходного кода транслировать и запускать приложения под Linux, iOS, iPhone, Windows Phone и Android (используя Xamarin). Ну и, разумеется, под всеми версиями Windows, начиная с семерки.

[Dotarev]

Впрочем, в Вашем случае OPC сервер действительно избыточен. У Вас ведь вопрос в том, по какому протоколу управлять контроллером? Тут действительно самое простое - Modbus + карта регистров. Даже если использовать ModbusRTU (физический канал RS485), при ограниченном количестве параметров можно получить ГАРАНТИРОВАННУЮ задержку менее 10мс. Просто от клиента (в вашем случае - АРМ на LINUX) требуется выполнять постоянно циклически опрос требуемых регистров.
А вот сценарий publisher/subscriber в принципе не может дать никаких гарантий на максимальное время задержки. Даже если устройство publisher в линии одно, сама линия может быть занята приемом/передачей телеметрии по расписанию. Если publisher в линии множество, такой сценарий даст меньшее время реакции на события, но только в среднем...

[Mirmik]

Тут действительно самое простое - Modbus + карта регистров.

А как решается вопрос с управлением по Modbus в случае, если изделие плохо ложится в формат карты регистров.
P.S. У нас недетерминированное количество осей у изделия и постоянно возникает необходимость в расширении функционала, что, как мне представляется, может негативно отразится на обратной совместимости в случае попытки использования регистровой карты.

А если использовать в основном user функции модбаса, то есть ли вообще смысл в использовании Modbus?

[Ryzhij]

В случае с Modbus/TCP за одним IP-адресом может находится группа устройств с персональными ID-адресами.
Никто не мешает сделать карту регистров на ось, и каждой оси присваивать свой ID.

[Dotarev]

У нас недетерминированное количество осей у изделия

Надеюсь, изделие по собственной инициативе не приделает себе парочку осей? Значит, речь идет о разных модификациях в серии изделий. И хотя сегодня вы не можете сказать, сколько будет модификаций и свойства каждой, но после сборки железа определенной модификации все свойства (в. т.ч. и состав исполнительных механизмов) будут определены и зафиксированы. В этот момент, независимо от протокола обмена, необходимо будет написать программное обеспечение конкретно под эту модификацию (т.е. сделать версию прошивки) и сделать техническое описание, включающее в себя полный перечень регистров (или команд, если хотите) вашего железа+прошивка. Можно, конечно, описание и не делать - но тогда не имеет значения, будет у вас стандартный протокол обмена или проприетарный. Всё равно кроме членов вашего коллектива никто не сможет с этим железом работать.
Основной резон использования Modbus - относительная простота использования чужого железа. Контроллеров RS485/RS422/RS232 полно, они относительно дешевые, сам протокол описывает систему до уровня передачи бит и байт информации, не конкретизируя смысл передаваемой информации. Библиотеку для реализации протокола писать не придется - под любой драйвер найдется готовая и отлаженная.
Если хотите, чтобы ваш продукт сторонние разработчики могли встраивать в свои системы, всё равно придется формализовать обмен данными. Потренируйтесь на реализации на простом протоколе, по ходу дела войдете в тему и сами поймете что нужно.
И кстати, если планируете выдавать информацию во внешний мир с АРМ ("с компьютера на линухе"), тут OPC UA вам в руки. Но тут никакого реального времени не будет, хотя сам протокол предусматривает как обмен по запросу клиента, так и подписку. Однако это другой мир, тут все задержки не детерминированы, никаких гарантий.

[Siluet]

А как решается вопрос с управлением по Modbus в случае, если изделие плохо ложится в формат карты регистров.
P.S. У нас недетерминированное количество осей у изделия и постоянно возникает необходимость в расширении функционала, что, как мне представляется, может негативно отразится на обратной совместимости в случае попытки использования регистровой карты.

Мне один раз пришлось писать программу ПЛК, которая опрашивала несколько веток RS485 на наличие приборов, если находила, то определяла тип, опрашивала и использовала в своей работе. Если прибор пропадал, то она отправляла сигнал на верхний уровень и продолжала работу. Все было реализовано на стандартных функциях модбас.

[Mirmik]

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

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

[Ryzhij]

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

Параметрируемые приборы отнюдь не редкость на рынке вообще, а в сегменте "умных домов" это просто стандарт де-факто.