Pull to refresh

Comments 16

Так же стандарт МЭК-60870-5-104 поддерживает режим, когда Slave устанавливает соединение с Master.

А можно ссылку на пункт стандарта?

7.1 Инициализация станции
Установление соединения проводится:
...


  • фиксированным выбором (параметром) — в случае двух эквивалентных контролирующих станций или партнеров (см. рисунок 1).
По моему мнению это не то.
Да-да, мне тоже интересно про это!
По последнему рисунку: Россети запрещают (по крайней мере на своих объектах) передачу по воздуху для АСУ ТП.

По передаче ОРС DA… выкиньте его и используйте UA.
Помимо Россетей есть еще много других организаций.
В ОРС UA сервер может устанавливать соединение с клиентом?
Передача по стандарту OPC DA в таких условиях невозможна.
Чем не угодил OPC Tunneller? Или OPC шлюз?
В статье как раз и описывается OPC шлюз.
в opc da есть асинхронный режим когда клиент оформляет подписку на элементы opc сервера. И когда значения этих элементов меняются, то opc сервер сам посылает клиенты уведомление.

этот режим как-то будет поддерживаться у вас?
интересно.
то есть ваш прокси это в итоге настоящий opc сервер внутри локальной сети OPC-клиента (самый правый на картинках), который:
1. содержит все те же элементы, что и удаленный opc сервер
2. поддерживает все интерфейсы и операции, которые поддерживает удаленный opc сервер
3. вызов операции — в итоге приводит к вызову операции на удаленном opc сервере
я правильно понял?
Нет.
OPC-клиент получает те же аналоговые и дискретные значения (или часть их), которые есть в OPC-сервере.
Преобразовать OPC DA во что нибудь, чтобы передать через защиту, или куда то далеко-далеко, на той стороне снова прикинуться ОРС-сервером, чтобы СКАДА ничего не поняла — ну это задача понятная, уже есть и решения по этой теме.
В вашей реализации непонятно другое — зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Зачем нужно такое двойное преобразование? Просто потому что это проще всего реализовать? Но при этом теряется куча функциональности в изначальном ОРС — разные типы значений, временные метки, признаки качества, дата-коллбеки по изменению параметров. Конечно можно выпендриться и придумать формат передачи всего этого и через самопальный Модбас, но это будет жесть, никакому нормальному инженеру АСУТП такая система в работе не нужна, и еще офигенная сложность в настройке.
Использование в этом плане в промежутке протокола МЭК-104 — уже гораздо лучше, понятнее. И мы подобные вещи тоже делали на базе своего ПО, когда надо было передать телеметрию вдаль, и там принять в ОРС в Скаде, которая не знает МЭК-104.
Но главный вопрос, который мне непонятен совершенно — зачем двойное преобразование информации в середине? Зачем в середине делать преобразование из МЭК в ОРС, а потом снова из ОРС в МЭК? Чего бы полученный из сети 1 МЭК сразу не передать в сеть 2, без конвертации в ОРС и обратно?
Зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Я за стандартизацию. Вам ещё не надоело объединять в одну систему устройства с разными протоколами обмена?
Зачем двойное преобразование информации в середине? Это один из вариантов. Я же писал
Опять же эту схему можно упростить с помощью программы TCP connections Convertor.
по аналогии с рисунком 3. Не стал разрисовывать для МЭК-104, думал и так понятно будет.
Я не понял из статьи — как «защитить» modbus-протокол?

Ваш вопрос непонятен. В статье даже слова "защита" нет.

Sign up to leave a comment.

Articles

Change theme settings