Кроссплатформенный 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 и хотит его прям в контроллер запихать.
Источник
Шлюзы промышленных протоколов обмена на Linux. Собери сам
Я занимаюсь разработкой, внедрением и эксплуатацией систем автоматического управления технологическими процессами (АСУ ТП). Поначалу работал со SCADA-системами. Потом довольно быстро переключился на работу с протоколами обмена промышленных устройств. Как самостоятельное написание драйверов, так и настройка систем сбора данных. В настоящий момент моя работа проходит атмосфере Modbus-ов, МЭКов-101/104-х, ОРС и прочих протоколов.
Рис. 1. Многообразие протоколов обмена, используемых в АСУ ТП
Кратко о том, как устроена типичная система сбора данных (Немного упрощенно).
Рис. 2. Система сбора данных
Специальное ПО, называемое OPC-сервером ведёт опрос устройств, подключенных к интерфейсу RS-485. OPC-сервер является своего рода прослойкой между SCADA-системой и устройствами, переводя язык на котором общаются устройства в язык, понятный SCADA-системе. Преобразователь Ethernet/RS-485 служит для преобразования TCP/IP-пакетов в пакеты, которые ходят по физической среде RS-485.
Эта схема имеет ряд недостатков:
- Установим, например, в ОРС-сервере таймаут ожидания ответа 200 мс. В идеальном случае, когда пакеты в Ethernet ходят без задержек, обмен с устройствами идёт с хорошей скоростью (интенсивностью). Но если пакет, содержащий ответ, задерживается, например, на 300 мс (это больше таймаута ожидания ответа 200 мс), то ОРС-сервер считает, что ответ на запрос не пришел и отправляет следующий запрос. В это время приходит ответ на предыдущий запрос, но ОРС-сервер думает, что это пришел ответ на текущий запрос и передаёт неправильные данные наверх. Как результат данные на АРМе «скачут». Чтобы уйти от таких ситуаций установим таймаут больше. Возьмём с запасом — 3000 мс. Если ответ приходит раньше 3000 мс, то оставшееся время не ждём, переходим к следующему запросу. Пока всё идёт хорошо, но стоит нескольким устройствам перестать отвечать, как образуются задержки по 3000 мс на каждое устройство. Время опроса увеличивается.
- Большинство протоколов, используемых в АСУ ТП (Modbus, счетчики э/э) основываются на последовательном опросе одних и тех же параметров. Учитывая, что большую часть времени значения параметров остаются неизменными, сеть передачи данных используется для передачи одного и того же. Это нерационально, если среда передачи GPRS, и трафик стоит денег. Кроме того, в среде передачи GPRS задержки прохождения пакетов могут достигать нескольких секунд. Зачем тратить время и ресурсы для передачи одного и того же?
Для вышеперечисленных ситуаций более подходит протокол, в котором данные передаются наверх по изменению (спорадически) и сгруппированными по несколько значений в один TCP-пакет. Такими протоколами являются МЭК-60870-5-104 и OPC UA. Подойдёт и ModBus-TCP, в нём нет передачи по изменению, но зато, если данных немного, их можно упаковать в один пакет. Хорошо бы иметь какой-нибудь контроллер, который можно повесить на DIN-рейку, подключить к нему устройства по RS-485 и передавать данные по Ethernet в SCADA-систему.
В общем какие-то аппаратные шлюзы есть и в немалом количестве. Но в виде готовых неделимых решений. Всё в одном. И это мне не особо нравится. Понадобился мне когда-то шлюз, преобразующий протоколы счетчиков СЭТ-4ТМ в OPC UA с шестью портами RS-485 и двумя Ethernet. У одного производителя есть шлюз с поддержкой нужных протоколов обмена, но мало портов RS-485, у другого есть нужное количество портов RS-485, но нет двух портов Ethernet. У третьего есть два порта Ethernet, но нет всех протоколов обмена. У четвёртого есть почти всё, но нет OPC UA, имеющиеся на борту МЭК-60870-5-104 или ModBus-TCP требуют ОРС-сервера для этих протоколов.
А как бы было замечательно: купить контроллер или мини-ПК с ОС у одного производителя. Купить ПО для контроллера у другого. Если одного производителя ПО не поддерживает что-то, докупить что-то из ПО у другого, объединить между собой компоненты ПО через стандартный программный интерфейс. Казалось бы, вот оно светлое будущее!
Вот поэтому шлюзы протоколов применяются реже чем связка «ОРС-сервер и «Преобразователь Ethernet в RS-485»» — из-за их неделимости на компоненты.
Одна из причин, почему мало развиты SCADA для Linux: SCADA есть, протоколов обмена в ней поддержано мало, а ОРС-серверов для связи с оборудованием нет. SCADA оставляет интегратора один на один с железом.
Читатель уже может задавать вопрос: Что можете предложить? Что уже есть? Есть OPC UA серверы для Linux для следующих протоколов:
- МЭК 60870-5-104;
- МЭК 60870-5-101;
- Счетчики Меркурий 230, 231, 233, 234, 236;
- Счетчики СЭТ-4ТМ, ПСЧ-3ТМ, ПСЧ-4ТМ;
- Счетчики Энергомера;
- SNMP;
- MQTT;
- Счетчики Меркурий 200.
Чтобы на верхний уровень можно было передавать данные не только по протоколу OPC UA, создан «Преобразователь OPC UA в Modbus и МЭК 60870-5-104». Помимо функции передачи данных по этим протоколам, «Преобразователь» имеет встроенный web-сервер. С помощью специального редактора можно нарисовать схему, на неё вывести значения тэгов, а потом открыть её в браузере. Получается мини-SCADA непосредственно в контроллере. Как работает оживление схемы я уже писал здесь, про редактор здесь. В будущем планируется «Преобразователь OPC UA в MQTT».
OPC UA серверы и преобразователь работают на архитектурах x64, ARMv7 и AARCH64.
Таким образом, для аппаратной части можно использовать как проверенные временем решения на базе мини промышленных компьютеров, так и всевозможные «raspberry pi совместимые» ARM миникомпьютеры. Как производится установка и настройка ПО с примерами можно почитать здесь или здесь.
В общем виде структура комплекса выглядит так:
Система обладает масштабируемостью. Используются компоненты необходимые только для решения текущей задачи.
С использованием OPC UA сервера наша схема преобразуется:
У нас получилось следующее:
- OPC UA сервер собирает данные с устройств по RS-485 без больших задержек между запросами;
- Данные в SCADA выдаются по нескольку штук в одном TCP-пакете по изменению;
- К OPC UA серверу можно подключить несколько одинаково настроенных АРМов. Пригодится, если нужно дублирование.
Таким образом, вместо связки ОРС-сервер и «Преобразователь Ethernet в RS-485» у нас получается одно устройство, объединяющее в себе их функциональность. Мне такая схема нравится больше. А Вам?
Источник
