Comments 16
Так же стандарт МЭК-60870-5-104 поддерживает режим, когда Slave устанавливает соединение с Master.
А можно ссылку на пункт стандарта?
По последнему рисунку: Россети запрещают (по крайней мере на своих объектах) передачу по воздуху для АСУ ТП.
По передаче ОРС DA… выкиньте его и используйте UA.
По передаче ОРС DA… выкиньте его и используйте UA.
Передача по стандарту OPC DA в таких условиях невозможна.Чем не угодил OPC Tunneller? Или OPC шлюз?
в opc da есть асинхронный режим когда клиент оформляет подписку на элементы opc сервера. И когда значения этих элементов меняются, то opc сервер сам посылает клиенты уведомление.
этот режим как-то будет поддерживаться у вас?
этот режим как-то будет поддерживаться у вас?
интересно.
то есть ваш прокси это в итоге настоящий opc сервер внутри локальной сети OPC-клиента (самый правый на картинках), который:
1. содержит все те же элементы, что и удаленный opc сервер
2. поддерживает все интерфейсы и операции, которые поддерживает удаленный opc сервер
3. вызов операции — в итоге приводит к вызову операции на удаленном opc сервере
я правильно понял?
то есть ваш прокси это в итоге настоящий opc сервер внутри локальной сети OPC-клиента (самый правый на картинках), который:
1. содержит все те же элементы, что и удаленный opc сервер
2. поддерживает все интерфейсы и операции, которые поддерживает удаленный opc сервер
3. вызов операции — в итоге приводит к вызову операции на удаленном opc сервере
я правильно понял?
Преобразовать OPC DA во что нибудь, чтобы передать через защиту, или куда то далеко-далеко, на той стороне снова прикинуться ОРС-сервером, чтобы СКАДА ничего не поняла — ну это задача понятная, уже есть и решения по этой теме.
В вашей реализации непонятно другое — зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Зачем нужно такое двойное преобразование? Просто потому что это проще всего реализовать? Но при этом теряется куча функциональности в изначальном ОРС — разные типы значений, временные метки, признаки качества, дата-коллбеки по изменению параметров. Конечно можно выпендриться и придумать формат передачи всего этого и через самопальный Модбас, но это будет жесть, никакому нормальному инженеру АСУТП такая система в работе не нужна, и еще офигенная сложность в настройке.
Использование в этом плане в промежутке протокола МЭК-104 — уже гораздо лучше, понятнее. И мы подобные вещи тоже делали на базе своего ПО, когда надо было передать телеметрию вдаль, и там принять в ОРС в Скаде, которая не знает МЭК-104.
Но главный вопрос, который мне непонятен совершенно — зачем двойное преобразование информации в середине? Зачем в середине делать преобразование из МЭК в ОРС, а потом снова из ОРС в МЭК? Чего бы полученный из сети 1 МЭК сразу не передать в сеть 2, без конвертации в ОРС и обратно?
В вашей реализации непонятно другое — зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Зачем нужно такое двойное преобразование? Просто потому что это проще всего реализовать? Но при этом теряется куча функциональности в изначальном ОРС — разные типы значений, временные метки, признаки качества, дата-коллбеки по изменению параметров. Конечно можно выпендриться и придумать формат передачи всего этого и через самопальный Модбас, но это будет жесть, никакому нормальному инженеру АСУТП такая система в работе не нужна, и еще офигенная сложность в настройке.
Использование в этом плане в промежутке протокола МЭК-104 — уже гораздо лучше, понятнее. И мы подобные вещи тоже делали на базе своего ПО, когда надо было передать телеметрию вдаль, и там принять в ОРС в Скаде, которая не знает МЭК-104.
Но главный вопрос, который мне непонятен совершенно — зачем двойное преобразование информации в середине? Зачем в середине делать преобразование из МЭК в ОРС, а потом снова из ОРС в МЭК? Чего бы полученный из сети 1 МЭК сразу не передать в сеть 2, без конвертации в ОРС и обратно?
Зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Я за стандартизацию. Вам ещё не надоело объединять в одну систему устройства с разными протоколами обмена?
Зачем двойное преобразование информации в середине? Это один из вариантов. Я же писал
Зачем двойное преобразование информации в середине? Это один из вариантов. Я же писал
Опять же эту схему можно упростить с помощью программы TCP connections Convertor.по аналогии с рисунком 3. Не стал разрисовывать для МЭК-104, думал и так понятно будет.
Я не понял из статьи — как «защитить» modbus-протокол?
Sign up to leave a comment.
Построение демилитаризованной зоны DMZ в системах АСУ ТП с помощью протоколов Modbus и МЭК-60870-5-104