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

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

SCADA, серверы, АРМ верхнего уровня, диспетчерские

Автор темы
Mirmik
здесь недавно
здесь недавно
Сообщения: 15
Зарегистрирован: 19 окт 2016, 15:50
Ф.И.О.: Сорокин Николай Федорович

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

Сообщение Mirmik » 19 окт 2016, 16:11

Сделали мы систему. Осями крутит, что нужно измеряет, в общем работает.
Управляется компьютером на линухе по самопальному протоколу. Протокол тяготеет к использованию паттерна 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. Каков порог вхождения и каковы могут быть мои первые действия по части освоения данного вопроса.

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2212
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 22 раза
Контактная информация:

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

Сообщение Михайло » 19 окт 2016, 17:22

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
здесь недавно
здесь недавно
Сообщения: 15
Зарегистрирован: 19 окт 2016, 15:50
Ф.И.О.: Сорокин Николай Федорович

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

Сообщение Mirmik » 19 окт 2016, 17:28

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


Автор темы
Mirmik
здесь недавно
здесь недавно
Сообщения: 15
Зарегистрирован: 19 окт 2016, 15:50
Ф.И.О.: Сорокин Николай Федорович

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

Сообщение Mirmik » 19 окт 2016, 17:35

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2212
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 22 раза
Контактная информация:

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

Сообщение Михайло » 19 окт 2016, 20:24

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


Romcheg
SCADA+
SCADA+
Сообщения: 520
Зарегистрирован: 05 ноя 2009, 11:18
Ф.И.О.: Бузинов Роман Анатольевич
Благодарил (а): 5 раз
Поблагодарили: 14 раз

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

Сообщение Romcheg » 19 окт 2016, 21:27

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

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2212
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 22 раза
Контактная информация:

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

Сообщение Михайло » 20 окт 2016, 05:04

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

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

Romcheg писал(а):Источник цитаты И забудьте про open source насчет ОРС...

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


Romcheg
SCADA+
SCADA+
Сообщения: 520
Зарегистрирован: 05 ноя 2009, 11:18
Ф.И.О.: Бузинов Роман Анатольевич
Благодарил (а): 5 раз
Поблагодарили: 14 раз

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

Сообщение Romcheg » 20 окт 2016, 08:18

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


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


Автор темы
Mirmik
здесь недавно
здесь недавно
Сообщения: 15
Зарегистрирован: 19 окт 2016, 15:50
Ф.И.О.: Сорокин Николай Федорович

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

Сообщение Mirmik » 20 окт 2016, 11:51

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


Romcheg

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


Romcheg
SCADA+
SCADA+
Сообщения: 520
Зарегистрирован: 05 ноя 2009, 11:18
Ф.И.О.: Бузинов Роман Анатольевич
Благодарил (а): 5 раз
Поблагодарили: 14 раз

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

Сообщение Romcheg » 20 окт 2016, 13:15

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

Аватара пользователя

Siluet
здесь недавно
здесь недавно
Сообщения: 68
Зарегистрирован: 05 сен 2014, 12:17
Ф.И.О.: Виталий Анатольевич Куроткин
Откуда: Москва
Благодарил (а): 2 раза
Поблагодарили: 3 раза

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

Сообщение Siluet » 20 окт 2016, 14:11

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


Dotarev
знаток Eplan
знаток Eplan
Сообщения: 115
Зарегистрирован: 12 июн 2014, 05:17
Ф.И.О.: Мишкин Иван
Благодарил (а): 11 раз
Поблагодарили: 20 раз

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

Сообщение Dotarev » 20 окт 2016, 15:07

Romcheg писал(а):Источник цитаты И забудьте про open source насчет ОРС... :-P

Справедливости ради стоит сказать, что 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 20 окт 2016, 15:35, всего редактировалось 1 раз.


Dotarev
знаток Eplan
знаток Eplan
Сообщения: 115
Зарегистрирован: 12 июн 2014, 05:17
Ф.И.О.: Мишкин Иван
Благодарил (а): 11 раз
Поблагодарили: 20 раз

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

Сообщение Dotarev » 20 окт 2016, 15:32

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


Автор темы
Mirmik
здесь недавно
здесь недавно
Сообщения: 15
Зарегистрирован: 19 окт 2016, 15:50
Ф.И.О.: Сорокин Николай Федорович

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

Сообщение Mirmik » 20 окт 2016, 17:42

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


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

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


Ryzhij
почётный участник форума
почётный участник форума
Сообщения: 2555
Зарегистрирован: 07 окт 2011, 08:12
Ф.И.О.: Гаско Вячеслав Эриевич
Откуда: Рязань, Россия
Благодарил (а): 41 раз
Поблагодарили: 70 раз

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

Сообщение Ryzhij » 20 окт 2016, 20:36

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


Dotarev
знаток Eplan
знаток Eplan
Сообщения: 115
Зарегистрирован: 12 июн 2014, 05:17
Ф.И.О.: Мишкин Иван
Благодарил (а): 11 раз
Поблагодарили: 20 раз

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

Сообщение Dotarev » 20 окт 2016, 21:34

Mirmik писал(а):Источник цитаты У нас недетерминированное количество осей у изделия

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

Аватара пользователя

Siluet
здесь недавно
здесь недавно
Сообщения: 68
Зарегистрирован: 05 сен 2014, 12:17
Ф.И.О.: Виталий Анатольевич Куроткин
Откуда: Москва
Благодарил (а): 2 раза
Поблагодарили: 3 раза

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

Сообщение Siluet » 21 окт 2016, 11:34

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

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


Автор темы
Mirmik
здесь недавно
здесь недавно
Сообщения: 15
Зарегистрирован: 19 окт 2016, 15:50
Ф.И.О.: Сорокин Николай Федорович

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

Сообщение Mirmik » 21 окт 2016, 18:02

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


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


Ryzhij
почётный участник форума
почётный участник форума
Сообщения: 2555
Зарегистрирован: 07 окт 2011, 08:12
Ф.И.О.: Гаско Вячеслав Эриевич
Откуда: Рязань, Россия
Благодарил (а): 41 раз
Поблагодарили: 70 раз

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

Сообщение Ryzhij » 21 окт 2016, 20:45

Mirmik писал(а):Источник цитатыА вот этого то как раз хотелось бы избежать. Потому что модификация прошивки и соответствующие отладочные работы - это неделя человеко/часов. В текущем варианте нашего ПО количество осей гибко конфигурируется, изменения карт регистров и соответствующих отладочных мероприятий не требуется.
Параметрируемые приборы отнюдь не редкость на рынке вообще, а в сегменте "умных домов" это просто стандарт де-факто.
---------------------------------------------------
«У человека в душе дыра размером с Бога, и каждый заполняет её как может». Жан-Поль Сартр


Вернуться в «Верхний уровень автоматизации»



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей