Как правило в АСУ ТП реализация демилитаризованной зоны выглядит следующим образом:
В сети №1 есть OPC-сервер от которого должен получать данные OPC-клиент в сети №2. Есть сервер DMZ. Firewall 1 разрешает только соединения из сети 1, остальные соединения запрещает. Firewall 2 разрешает только соединения из сети 2, остальные соединения запрещает. Передача по стандарту OPC DA в таких условиях невозможна.
Какие стандартные протоколы обмена есть в АСУ ТП? Конечно же первым на ум приходит Modbus. Для TCP/IP есть Modbus TCP. Ещё есть режим Modbus-RTU поверх TCP/IP: те же самые пакеты, которые проходят по RS-485 передаются по TCP/IP. Режим Modbus-RTU поверх TCP/IP стал стандартом де-факто, но остался нестандартным де-юре.
Определимся с терминами:
- Modbus-Slave – программа, которая отдаёт данные по протоколу Modbus
- Modbus-Master — программа, которая принимает данные от Slave по протоколу Modbus
Итак, рассмотрим такую схему:
В сети №1 «преобразователь ОРС в Modbus TCP» является Modbus-slave, он получает данные от ОРС-сервера. «Преобразователь ОРС в Modbus TCP» сам устанавливает ТСР соединение с ОРС-сервером Modbus TCP (Modbus-Master) в DMZ (в нем есть режим пассивного ожидания соединений), преобразователь ОРС в Modbus TCP (Modbus-slave) в демилитаризованной зоне получает данные от ОРС-сервера. ОРС-сервер Modbus TCP (Modbus-Master) в сети 2 устанавливает соединение с «Преобразователем ОРС в Modbus TCP» в DMZ и передает данные ОРС-клиенту.
В этой схеме нестандартно то, что «преобразователь ОРС в Modbus TCP», являясь Modbus-slave, сам устанавливает соединение с Modbus-Master. Именно для этого и потребовалось написать свой преобразователь.
Упростим схему:
Для сервера демилитаризованной зоны создадим простую программу с условным названием TCP connections Convertor. Она открывает 2 ТСР порта. Из сети №1 «преобразователь ОРС в Modbus TCP» устанавливает соединение с ней по порту 1000, ОРС-сервер Modbus TCP устанавливает соединение с ней по порту 1001. Пакет, приходящий на порт 1000, отсылается клиенту, подсоединенному к порту 1001. Пакет, приходящий на порт 1001, отсылается клиенту, подсоединенному к порту 1000.
Можно сказать, что потенциальный злоумышленник может взломать «преобразователь ОРС в Modbus TCP», посылая ему нехорошие пакеты. Тогда в TCP connections Convertor можно ввести запрет в подключении к нему с неизвестных IP-адресов, ввести контроль длины пакетов и проверять пакеты на соответствие стандарту Modbus TCP.
Теперь перейдем к МЭК-60870-5-104. Этот протокол более совершенен по сравнению с Modbus. С помощью него можно пересылать достоверности сигналов и метки времени. Так же стандарт МЭК-60870-5-104 поддерживает режим, когда Slave устанавливает соединение с Master.
Master по стандарту называется контролирующей станцией, Slave называется контролируемой станцией.
Перерисуем схему:
Повторим описание: В сети №1 «преобразователь ОРС в МЭК-104» является slave, он получает данные от ОРС-сервера. «Преобразователь ОРС в МЭК-104» сам устанавливает ТСР соединение с ОРС-сервером МЭК-104 (Master) в DMZ, преобразователь ОРС в МЭК-104 (slave) в демилитаризованной зоне получает данные от ОРС-сервера МЭК-104. ОРС-сервер МЭК-104 (Master) в сети 2 устанавливает соединение с «Преобразователем ОРС в МЭК-104» в DMZ и передает данные ОРС-клиенту.
Опять же эту схему можно упростить с помощью программы TCP connections Convertor. Ещё одна идея!
С появлением беспроводных GSM/GPRS-модемов, обеспечивающих передачу данных в сети по стеку протоколов TCP/IP стало удобно организовывать каналы связи с удаленными объектами. Однако не всегда удаётся получить статический IP-адрес для GSM/GPRS-модема. В таком случае статический IP-адрес присваивается серверу. GSM/GPRS-модем устанавливает соединение с сервером, на сервер устанавливается программа TCP connections Convertor. ОРС-сервер отправляет запрос к серверу на порт 1000, GSM/GPRS-модем, подключенный к порту 1001 принимает этот пакет, передает его счетчику, счетчик отвечает, GSM/GPRS-модем передает ответ серверу на порт 1001, сервер через порт 1000 отдает ответ ОРС-серверу. ОРС-сервер «думает», что общается со счетчиком напрямую, компьютер с ОРС-сервером оказывается изолированным от внешней сети (интернета).
Комментарии (14)
slepowl
15.03.2017 10:56По последнему рисунку: Россети запрещают (по крайней мере на своих объектах) передачу по воздуху для АСУ ТП.
По передаче ОРС DA… выкиньте его и используйте UA.Opc-server
15.03.2017 10:57Помимо Россетей есть еще много других организаций.
В ОРС UA сервер может устанавливать соединение с клиентом?
Segmentq
15.03.2017 10:59Передача по стандарту OPC DA в таких условиях невозможна.
Чем не угодил OPC Tunneller? Или OPC шлюз?
we12
15.03.2017 12:47в opc da есть асинхронный режим когда клиент оформляет подписку на элементы opc сервера. И когда значения этих элементов меняются, то opc сервер сам посылает клиенты уведомление.
этот режим как-то будет поддерживаться у вас?
we12
15.03.2017 13:02интересно.
то есть ваш прокси это в итоге настоящий opc сервер внутри локальной сети OPC-клиента (самый правый на картинках), который:
1. содержит все те же элементы, что и удаленный opc сервер
2. поддерживает все интерфейсы и операции, которые поддерживает удаленный opc сервер
3. вызов операции — в итоге приводит к вызову операции на удаленном opc сервере
я правильно понял?Opc-server
15.03.2017 15:02Нет.
OPC-клиент получает те же аналоговые и дискретные значения (или часть их), которые есть в OPC-сервере.
ENTEK
15.03.2017 13:04+1Преобразовать OPC DA во что нибудь, чтобы передать через защиту, или куда то далеко-далеко, на той стороне снова прикинуться ОРС-сервером, чтобы СКАДА ничего не поняла — ну это задача понятная, уже есть и решения по этой теме.
В вашей реализации непонятно другое — зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Зачем нужно такое двойное преобразование? Просто потому что это проще всего реализовать? Но при этом теряется куча функциональности в изначальном ОРС — разные типы значений, временные метки, признаки качества, дата-коллбеки по изменению параметров. Конечно можно выпендриться и придумать формат передачи всего этого и через самопальный Модбас, но это будет жесть, никакому нормальному инженеру АСУТП такая система в работе не нужна, и еще офигенная сложность в настройке.
Использование в этом плане в промежутке протокола МЭК-104 — уже гораздо лучше, понятнее. И мы подобные вещи тоже делали на базе своего ПО, когда надо было передать телеметрию вдаль, и там принять в ОРС в Скаде, которая не знает МЭК-104.
Но главный вопрос, который мне непонятен совершенно — зачем двойное преобразование информации в середине? Зачем в середине делать преобразование из МЭК в ОРС, а потом снова из ОРС в МЭК? Чего бы полученный из сети 1 МЭК сразу не передать в сеть 2, без конвертации в ОРС и обратно?Opc-server
15.03.2017 15:15Зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Я за стандартизацию. Вам ещё не надоело объединять в одну систему устройства с разными протоколами обмена?
Зачем двойное преобразование информации в середине? Это один из вариантов. Я же писалОпять же эту схему можно упростить с помощью программы TCP connections Convertor.
по аналогии с рисунком 3. Не стал разрисовывать для МЭК-104, думал и так понятно будет.
brn
А можно ссылку на пункт стандарта?
Opc-server
7.1 Инициализация станции
Установление соединения проводится:
...
brn
По моему мнению это не то.
ENTEK
Да-да, мне тоже интересно про это!