Шлюзы промышленных протоколов обмена на Linux. Собери сам

    Я занимаюсь разработкой, внедрением и эксплуатацией систем автоматического управления технологическими процессами (АСУ ТП). Поначалу работал со SCADA-системами. Потом довольно быстро переключился на работу с протоколами обмена промышленных устройств. Как самостоятельное написание драйверов, так и настройка систем сбора данных. В настоящий момент моя работа проходит атмосфере Modbus-ов, МЭКов-101/104-х, ОРС и прочих протоколов.

    image
    Рис. 1. Многообразие протоколов обмена, используемых в АСУ ТП

    Кратко о том, как устроена типичная система сбора данных (Немного упрощенно).

    image
    Рис. 2. Система сбора данных

    Специальное ПО, называемое OPC-сервером ведёт опрос устройств, подключенных к интерфейсу RS-485. OPC-сервер является своего рода прослойкой между SCADA-системой и устройствами, переводя язык на котором общаются устройства в язык, понятный SCADA-системе. Преобразователь Ethernet/RS-485 служит для преобразования TCP/IP-пакетов в пакеты, которые ходят по физической среде RS-485.

    Эта схема имеет ряд недостатков:

    1. Установим, например, в ОРС-сервере таймаут ожидания ответа 200 мс. В идеальном случае, когда пакеты в Ethernet ходят без задержек, обмен с устройствами идёт с хорошей скоростью (интенсивностью). Но если пакет, содержащий ответ, задерживается, например, на 300 мс (это больше таймаута ожидания ответа 200 мс), то ОРС-сервер считает, что ответ на запрос не пришел и отправляет следующий запрос. В это время приходит ответ на предыдущий запрос, но ОРС-сервер думает, что это пришел ответ на текущий запрос и передаёт неправильные данные наверх. Как результат данные на АРМе «скачут». Чтобы уйти от таких ситуаций установим таймаут больше. Возьмём с запасом — 3000 мс. Если ответ приходит раньше 3000 мс, то оставшееся время не ждём, переходим к следующему запросу. Пока всё идёт хорошо, но стоит нескольким устройствам перестать отвечать, как образуются задержки по 3000 мс на каждое устройство. Время опроса увеличивается.
    2. Большинство протоколов, используемых в АСУ ТП (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 для следующих протоколов:


    Чтобы на верхний уровень можно было передавать данные не только по протоколу OPC UA, создан «Преобразователь OPC UA в Modbus и МЭК 60870-5-104». Помимо функции передачи данных по этим протоколам, «Преобразователь» имеет встроенный web-сервер. С помощью специального редактора можно нарисовать схему, на неё вывести значения тэгов, а потом открыть её в браузере. Получается мини-SCADA непосредственно в контроллере. Как работает оживление схемы я уже писал здесь, про редактор здесь. В будущем планируется «Преобразователь OPC UA в MQTT».

    OPC UA серверы и преобразователь работают на архитектурах x64, ARMv7 и AARCH64.
    Таким образом, для аппаратной части можно использовать как проверенные временем решения на базе мини промышленных компьютеров, так и всевозможные «raspberry pi совместимые» ARM миникомпьютеры. Как производится установка и настройка ПО с примерами можно почитать здесь или здесь.

    В общем виде структура комплекса выглядит так:

    image

    Система обладает масштабируемостью. Используются компоненты необходимые только для решения текущей задачи.

    С использованием OPC UA сервера наша схема преобразуется:

    image

    У нас получилось следующее:

    • OPC UA сервер собирает данные с устройств по RS-485 без больших задержек между запросами;
    • Данные в SCADA выдаются по нескольку штук в одном TCP-пакете по изменению;
    • К OPC UA серверу можно подключить несколько одинаково настроенных АРМов. Пригодится, если нужно дублирование.

    Таким образом, вместо связки ОРС-сервер и «Преобразователь Ethernet в RS-485» у нас получается одно устройство, объединяющее в себе их функциональность. Мне такая схема нравится больше. А Вам?

    Комментарии 73

      0
      А как вы на «raspberry pi» добиваетесь промышленной устойчивости к внешним факторам? Пыль, ЭМС…
        0
        Не «raspberry pi», а «raspberry pi совместимые». Есть специальные платы с расширенным диапазоном температур.
          0
          Вопрос был не только про температуру. Про какие платы речь, ссылку плиз или название.
              0
              Спасибо. Моха, да, согласено. А beagleboard, хоть и industrial — весьма спорный вариант (корпус, сертификация, самодельный велосипед получается).
                0
                и какие у моха можно отнести к «raspberry pi совместимые»?
                  +1
                  а beagleboard? я так понимаю, у автора всё что маленькое, то «raspberry pi совместимые»
                    0
                    Компьютеры с архитектурой ARMv7.
                      0
                      Бинарники, запускающиеся на raspberry pi ARMv7, запускаются и там.
                0

                В семье Распберри есть вполне промышленный модуль Raspberry Pi Compute Module 3
                Для него есть вполне индустриальные платы и корпуса, типа Revolution Pi и прочее.

                  0
                  Посмотрел — там от промышленного, если только то, что он модуль, а не торчащая во все стороны разьемами плата. Называть модуль промышленным изделием, даже не имея индустриального диапазона, как то странно.
                    0

                    Уточняю, если не понятно: этот модуль предназначен для встраивания в промышленные изделия. Тем параметрам, которые от него зависят, он отвечает в полной мере — например имеет индустриальный диапазон температур. А соответствие остальным требованиям уже должно обеспечиваться самим изделием — защита от радиопомех, пыли и т.д. — соответствующим корпусом, I/O — схемами защиты на материнской плате и т.д.
                    Также замечу немаловажный для промышленности фактор — доступность. Данные модули будут гарантированно производиться как минимум до 2023 года. Кто вложился в разработку своей платы, тот поймет.
                    Как выглядит в реале промышленный Raspberry Pi на базе этого модуля, можно посмотреть тут.


                    Вообще даже обычный Raspberry Pi можно довести до вполне "промышленного" уровня, засунув его в металлический заземляемый корпус, в качестве блока питания взяв не китайскую фигню, а что-то более подходящее из индустриальной автоматизации, и подключив его к тому же свитчу Moxа коротким кабелем. И естественно никаких других подключений к периферии самой платы. Тогда по ЭМС он выдержит практически все, и только по температуре и влажности будет похуже.

                      0
                      А устойчивость к вибрации как он обеспечивает? за счет корпуса?
                      Доступность до 2023 года почти ниочём для промышленных изделий, к нам требование, к примеру, 20 лет. И поставка запасных частей в любое время этого срока в течение 3-6 месяцев после заказа.

                      Засунутая малинка в корпус металлический, весьма вероятно пройдет по ЭМСу по питанию, но скорее всего не пройдёт наведенное на нее поле — разьемы то присутствуют.
                        0
                        Там для разъемов которые наружу, отдельная плата идет, так что можно скорее достичь защиты.
                        Но вот вибрация и температура, это под большим вопросом.
                          0
                          А устойчивость к вибрации как он обеспечивает? за счет корпуса?

                          Вы проходили испытания на вибрацию? Я проходил и если на плате нету особо тяжелых компонентов, типа электролитов (а на CM их нету), они проходятся на ура. DIMM разъемы в промышленном оборудовании используются.
                          Ну и кстати за счет корпуса — а почему бы и нет? Прикрутить все это дело через резинки — и ее в космос можно будет запускать.


                          Доступность до 2023 года почти ниочём для промышленных изделий, к нам требование, к примеру, 20 лет.

                          Ваши требования производителям микропроцессоров пофиг. Найдите хоть один микрокомпьютер, который будет гарантированно доступен так долго. Подсказка — у Intel на встроенные процессоры гарантия доступности всего 7 лет и потом переходите на другую железяку. Не стоит это путать с готовыми промышленными изделиями — вы можете абстрагировать свое железо как хотите и через 20 лет эмулировать своим клиентам 8-и битную железяку с 10кБ памяти, хотя по настоящему у вас там будет стоять уже 3-я ревизия 32-х битного ARMа.
                          Но это не отменяет того факта, что когда вами используемый ARM перестанут производить — а это произойдет гораздо раньше назначенного срока в 20 лет, вам придется перелазить на что-то следующее, переразводить плату, опять проводить типовые испытания — а это деньги.


                          но скорее всего не пройдёт наведенное на нее поле — разьемы то присутствуют.

                          Чего? Что это за испытание такое?

                          0
                          он отвечает в полной мере — например имеет индустриальный диапазон температур

                          А можно пруф где сказано что он удовлетворяет хотя бы температурам. На сайте не нашел подтверждения этому.
                            0
                              0
                              Попутал, на самом деле я спрашивал про Revolution Pi, у которого заявлено
                              Operating temperature -40 °C....+55 °C2

                              И это при том что для модуля нижняя -25 °C
                              но и сам модуль по верхней границе в +85 °C не влезает, не говоря уже о каком-то запасе.
                    0

                    Это в пределах одного помещения. А если разнесены территориально, как это повсеместно в энергетике, то преобразуется в tcp и по существующим сетям уходит в центральный узел сбора и обработки.

                      0
                      > Подойдёт и ModBus-TCP, в нём нет передачи по изменению…
                      Действительно нет, но можно извратиться (производителю счетчиков) и поменять местами Modbus Клиент (SCADA)-Modbus Сервер (Счетчик) и заставить счетчик писать в регистры SCADA системы по изменению вместо того что бы опрашивать его со стороны SCADA системы.
                        0
                        А если счетчиков несколько на RS-485?
                          0
                          Вам ответили про Вашу же фразу про ModbusTCP (никакого 485), теоретически предположив возможность поднять сервер протокола на стороне верхнего уровня, клиента — на устройствах, и передавать данные спорадикой (зачем нужно при наличии 104 протокола — ХЕЗ, но, безусловно, мысль интересная своей нетривиальностью)
                            0
                            Это будет не стандартный ModbusTCP. Зачем ещё один протокол обмена, непонятно.
                              0
                              Оценить полет мысли
                        0
                        Не совсем понятно, каким образом предлагаемая система решает проблему таймаутов удаленных устройств. Ведь с этого все начиналось. Не проще-ли использовать многопортовые преобразователи COM-TCP?
                        Еще не очень понятно, откуда появляются задержки в ответах аппаратных серверов Modbus, тем более на простые запросы.
                          0

                          В сети RS-485 хватит таймаута 50-100 мсек. В Ethernet необходим гораздо больше.

                            0
                            С чего вдруг такой постулат, что 50-100 мсек хватит всем? А если через оборудование ВЧ-связи, к примеру? а если составной канал, с неизвестным оборудованием? Таймаут должен быть регулируемым, уже наступали на грабли что некоторые ТМщики считают таймаут от скорости соединения по Ethernet (10 Мбит или 100 Мбит), совершенно не задумываясь, что бывают и другие каналы со временем совсем НЕоптическим.
                              0
                              На 9600-38400 кбит/сек 50-100 мсек хватит всем. Обращаю ваше внимание, что в статье рассматривается сеть RS-485.
                              > а если составной канал с неизвестным оборудованием?
                              Ага, и с неизвестным протоколом обмена.
                              > Таймаут должен быть регулируемым,
                              Регулируйте, пожалуйста.
                                0
                                На 9600-38400 кбит/сек 50-100 мсек хватит всем. Обращаю ваше внимание, что в статье рассматривается сеть RS-485.


                                Я Вам про 485 и говорю. И как раз на скоростях 9600-38400 бит/c весьма возможны соединения через медленный тракт — как примеру, в одну сторону (обращаю внимание !) время прохождение порядка 70 мс.
                                  0
                                  сеть RS-485 — это два провода длинной до 1.2 км. Как в проводе с такой длинной может быть задержка 70 мс?
                                    0
                                    Ну почему же просто ДВА провода, это может быть и удлинение через любую аппаратуру (а-ля мост в терминологии Ethernet), через геостационарный спутник, к примеру — там вообще задержки секундные будут.
                                      0
                                      Перечитайте первую часть статьи, где я писал про Ethernet.
                                        0
                                        Перечитал, я к тому, что задержки до нескольких сот мс НЕ только через Ethernet, но и просто в 485 возможны (вообще без конвертации в Ethernet)! и говорить о том, что 50-100 мсек хватит всем, как минимум неправильно.
                                          0
                                          Погуглите с интернете скорость распространения электромагнитной волны.
                                            0
                                            Перечитайте мои комментарии, попытайтесь понять. Я не говорю про «просто два провода 485».
                                              0
                                              А я про просто два провода 485. Если в сети есть что-то вносящее задержку, то ОРС UA Сервер нужно ставить как можно ближе к устройству.
                                                0
                                                А с чего вдруг столь категорично? а если сеть из 10 устройств 485 и только одно из них «удален вдаль» физически за десяток мс (каким либо каналом), зачем мне разоряться на второй OPC UA в таком случае, когда можно обойтись одним, который просто учитывает что задержка по 485 может быть до 150 мс, к примеру.
                                                  0
                                                  Довольно редкая конфигурация.
                                                  Ставьте какую хотите задержку, кто не даёт?
                                                    0
                                                    Я всего лишь несогласен с заявлением, что «640 кбайт хватит всем». Конфигурация не столь редка, натыкались на грабли когда некоторые производители в принципе НЕ дают регулировать задержку, а ставят ее, к примеру, в зависимости от выбранной скорости 485.
                                                      0
                                                      У меня можно регулировать задержку.
                              0
                              А параметры буферов регулировать не пробовали? Преобразователь не будет каждый байт отдельным пакетом пересылать.
                              Для интегрированного в плату (либо платы-адаптера) рекомендую размер приемного FIFO буфера установить в 1. Это резко уменьшает задержки в приеме пакета, так как таймаут стандартного драйвера работает по частотной сетке 55мс.
                                0
                                Обычно все байты в одном пакете приходят. Но если приходят несколько неполных пакетов, ПО это распознаёт и программно соединяет.
                                  0
                                  Преобразователь НЕ ЗНАЕТ, сколько байт будет в посылке. Поэтому он ждет таймаута, после чего накопленные данные сбрасывает в пакет и отправляет по TCP. Отсюда такие чудовищные задержки при передаче 10-20 байт. Если буфер наполняется, то данные отправляются сразу.
                                    0
                                    А в чем вопрос то? Настройка буфера не защищает от случайных задержек в сети Ethernet, пусть даже и редких.
                                      0
                                      У вас выделенная сеть, а траффик не достигает и единиц процента от пропускной способности. Поэтому ваши задержки не случайные, а систематические. При правильно настроенных размерах буферов задержки будут определяться только скоростью передачи данных в сети RS-485 и временем ответа сервера. Если размер буфера не настроен, то добавляйте по 50 мс на каждую пару запрос-ответ. Для скорости 9600 это уже разница в 2 раза.
                                0
                                Кстати, подскажите, где в настройках MOXA Nport можно установить размер приемного FIFO буфера?
                                  0
                                  Хм… Operating Settings/Port X/Packing Length — это размер посылки, имеет смысл выставить значение, соответствующее ответу на наиболее частый запрос.
                                  Force Transmit — имеет смысл выставить значение в единицы мс.
                                    0
                                    Как-то давненько запнулся на этом месте — Мокса мне Модбас пакеты кусками пересылала, пришлось подкручивать.
                            0
                            Del
                              0
                              Очень сомнительно выглядит идея совместить в одном флаконе OPC DA (текущие данные), OPC HDA (исторические данные), и МЭК60870 (передача по инициативе сервера, а не клиента)

                              Сужу только по практическому отсутствию реализаций OPC UA — даже не интересовался (было не нужно), что из этой тройки он умеет.

                              А еще ведь есть 60870-5-103 и 61850. Сомневаюсь, что настолько разнородные идеи можно в одну коробку.

                              Отдельный вопрос про OLE и Linux и SCADA и Linux. Второе еще реализуемо, но первое…
                              (OPC это и есть OLE 4 Process Control, кто не в курсе)
                                0
                                Где Вы в статье нашли OPC DA, OPC HDA?
                                > Сужу только по практическому отсутствию реализаций OPC UA
                                Уже есть. Поинтересуйтесть.
                                > А еще ведь есть 60870-5-103 и 61850. Сомневаюсь, что настолько разнородные идеи можно в одну коробку
                                Вы сомневаетесь, а уже есть спрос на преобразователь modbus в 61850.
                                OLE в Linux нет!
                                  0
                                  Для работы с приборами нужно OPC DA, со счетчиками — OPC HDA. Аксиома.

                                  >Уже есть. Поинтересуйтесть.
                                  Есть Кепварь. Просто слишком мало есть, чтобы создать рынок

                                  >Вы сомневаетесь, а уже есть спрос на преобразователь modbus в 61850.
                                  очень нужен, но нужен читатель 61850 (в modbus просят из-за ограниченности какого то софта). а еще по 61850 есть управление
                                  не уверен, что твоя схема (можно на ты в ответ), сможет читать 61850 в UA

                                  >OLE в Linux нет!
                                  а ОРС, которое поверх OLE, есть ????
                                    0
                                    > а ОРС, которое поверх OLE, есть ????
                                    OPC UA не поверх OLE, а поверх TCP IP в рассматриваемом в статье случае. Изучайте матчасть.
                                      0
                                      Так я же написал, что даже не интересовался UA.

                                      Ну и OPC — оно же клиентам отдается (скадам там всяким и экселям) — и это позиционируется как его уникальное преимущество, и как так если в OPC UA его вдруг нету?

                                      т.е если нету такого св-ва, то оно нафиг никому не нужно. и это все объясняет (0 на рынке)
                                        0
                                        >, и как так если в OPC UA его вдруг нету?
                                        > т.е если нету такого св-ва,
                                        Чего нету? Того что сервер отдаёт данные клиенту?
                                          0
                                          поддержки ОРС. и действительно нету, спс за ссылку.

                                          ИМХО это никому не нужно/ на картинках из статьи — фикция, ибо СКАДЫ, поддерживающие OPC UA еще нужно поискать
                              0

                              Кстати нам тоже надо аналогичное решение, только для диспетчеризации. В данном случае шлюз должен собирать данные по CANopen, а передавать наверх в виде того, что поддерживает диспетчеризация — MODBUS TCP, OPC UA, REST итд.
                              Прельщает то, что такой шлюз будет работать независимо от основной системы и в случае чего ничего страшного не будет.
                              И думал также сделать это на том же Raspberry Pi — соответствующая плата уже есть.


                              Можете реализовать софтверную часть? Можно в личку.

                                0
                                Если нужно промышленное решение, можно взять практический любой ПЛК, имеющий CAN и Ethernet. А сваять опрос по CAN сможет любой пром. программист.
                                +1

                                В статье, к сожалению, не рассмотрен один из серьезных аспектов в данном бизнесе — Кибербезопасность (Cybersecurity).
                                Вы пробовали проходить сертификацию или хотя бы что-то делать в этом направлении? Вроде у Microsofta были неплохие курсы по этому делу — Threat Attack Modelling, Password Policy, сертификаты и т.д.
                                Без всего этого ваш сервер будет очень опасно выпускать в открытый интернет.

                                  0
                                  Какой сертификат? В каком ведомстве проходить сертификацию? Поподробнее об этом.
                                  > Без всего этого ваш сервер будет очень опасно выпускать в открытый интернет.
                                  Я и сам против этого.
                                    0

                                    Это сравнительно новый вид сертификации, который еще далек от совершенства. Есть определенные стандарты, но скорей всего у нас о них ничего не известно, даже в мире в них мало кто разбирается.
                                    Сравнительно хорошая методика раписана в NERC-CIP и они в открытом доступе. И это хоть для подстанций, но протоколоы DNP3 и 870-5-104 там тоже используются, поэтому более или менее подойдет и для индустрии.
                                    Вот пример SCADA Гейтвея и что они пишут о Кибербезопасности:


                                    Strengthen cybersecurity
                                    Create an NERC CIP-compliant electronic perimeter to protect substation devices
                                    Secure SCADA protocols using TLS and X.509 certificates as per IEC 62351-3
                                    Implement DNP3 secure authentication V5 as per IEC 62351-5
                                    Protect your system with a built-in firewall and integrity check
                                    Secure SCADA communications and certificate-based authentication.
                                    Signed firmware updates.
                                    Malware protection.
                                    Field-upgradable firmware to address technical and cybersecurity issues.

                                    В общем надо разбираться, что там за Compliance нужен и где это можно исследовать.

                                      0
                                      Я думал про Российские стандарты… Про это не слышал.
                                        +1

                                        Интернет, к сожалению, не ориентируется на российские стандарты. Может про сертификацию я и загнул, но в качестве методички:


                                        Security features
                                        Integrated firewall
                                        Secure maintenance connection (SSL/TLS)
                                        Secure SCADA protocol (SSL/TLS)
                                        AES-128/256 encryption
                                        X.509 certificates
                                        Secure remote access for IED maintenance (Passthrough)
                                        Account management: Strong passwords, User accounts and user groups, Detailed group permissions
                                        Access management
                                        Access attempts logs
                                        Account lock upon failed access attempts
                                        Retrievable access logs for auditing
                                        Syslog support for remote log storage
                                        All system components digitally signed
                                        Continuous file monitoring for system integrity
                                        Achilles certification
                                        Nessus compliance

                                        По всему этому должно быть достаточно документации, и если это все реализовать, то можно надеяться, что ваш сервер выстоит против достаточно большого спектра атак. Но все это только надежды.

                                          0
                                          К отечественным устр-вам начинают предьявлять требования сертификации во ФСТЭКе… но пока мало кто прошёл…
                                  0
                                  А с каких это пор технология OPC стала вдруг протоколом? Раз. Про Modbus TCP — в пакете данных содержится поле TransactionID по которому совершенно спокойно, на стороне OPC сервера, если он грамотно спроектирован, возможно отслеживать принадлежность ответа. Этим исключается неопределенность TCP/IP против UDP, а также минимизируются задержки, если при каком то запросе данные долго не приходят. Многопоточность наше все.
                                    0
                                    > А с каких это пор технология OPC стала вдруг протоколом?
                                    В статье речь идёт об OPC UA.
                                    Изучите мат часть ru.wikipedia.org/wiki/OPC_UA#Протоколы далее находите фразу 1. Двоичный протокол
                                    > Про Modbus TCP — в пакете данных содержится поле TransactionID
                                    В протоколах сэт-4 и меркурий 230 таких полей нет. Как с ними предлагаете быть?
                                      0
                                      Про OPC UA у меня не было ни слова.
                                      Изучите мат часть ru.wikipedia.org/wiki/OPC_UA#Протоколы далее находите фразу 1. Двоичный протокол

                                      Вы склонны верить всему, что в Вики написано? Это не протокол, а сериализация данных в бинарный поток, а на транспортном уровне это может быть как TCP, так и UDP. Да хоть в тот же Modbus RTU «заворачивать» можно, используя функции из пользовательского диапазона функций.
                                        –2
                                        > Вы склонны верить всему, что в Вики написано?
                                        То есть вы предлагаете поверить Вам на слово?
                                        Чем сериализация данных в бинарный поток отличается от протокола?
                                    0
                                    Не помню как с остальными производителями ПЛК, но у Schneider Electric в линейке Quantum давно присутствуют Ethernet модули с собственным Web сервером, на котором никто не мешает поднять, например, на Jave OPC UA шлюз (Modbus TCP идет из «коробки»). И не надо никаких лишних шлюзов. А если система распределенная, так там уже само собой надо ставить сервер ввода/вывода, который и будет являться шлюзом данных. ИМХО.
                                      0
                                      Schneider Electric поддерживает протокол какого-нибудь меркурия 230, если мне это вдруг понадобится?
                                        0
                                        квантум стоит как автомобиль (реально).

                                        да и свободно-программируемый модулей связи я не наблюдал. можно партномер?

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое