Всем здравствуйте! Статься предназначена для специалистов в области АСУ ТП. Остальным она может оказаться непонятной из-за обилия специфических терминов.

Как правило в АСУ ТП реализация демилитаризованной зоны выглядит следующим образом:

image

В сети №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

Итак, рассмотрим такую схему:

image

В сети №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. Именно для этого и потребовалось написать свой преобразователь.

Упростим схему:

image

Для сервера демилитаризованной зоны создадим простую программу с условным названием 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 называется контролируемой станцией.

Перерисуем схему:

image

Повторим описание: В сети №1 «преобразователь ОРС в МЭК-104» является slave, он получает данные от ОРС-сервера. «Преобразователь ОРС в МЭК-104» сам устанавливает ТСР соединение с ОРС-сервером МЭК-104 (Master) в DMZ, преобразователь ОРС в МЭК-104 (slave) в демилитаризованной зоне получает данные от ОРС-сервера МЭК-104. ОРС-сервер МЭК-104 (Master) в сети 2 устанавливает соединение с «Преобразователем ОРС в МЭК-104» в DMZ и передает данные ОРС-клиенту.

Опять же эту схему можно упростить с помощью программы TCP connections Convertor. Ещё одна идея!

image

С появлением беспроводных GSM/GPRS-модемов, обеспечивающих передачу данных в сети по стеку протоколов TCP/IP стало удобно организовывать каналы связи с удаленными объектами. Однако не всегда удаётся получить статический IP-адрес для GSM/GPRS-модема. В таком случае статический IP-адрес присваивается серверу. GSM/GPRS-модем устанавливает соединение с сервером, на сервер устанавливается программа TCP connections Convertor. ОРС-сервер отправляет запрос к серверу на порт 1000, GSM/GPRS-модем, подключенный к порту 1001 принимает этот пакет, передает его счетчику, счетчик отвечает, GSM/GPRS-модем передает ответ серверу на порт 1001, сервер через порт 1000 отдает ответ ОРС-серверу. ОРС-сервер «думает», что общается со счетчиком напрямую, компьютер с ОРС-сервером оказывается изолированным от внешней сети (интернета).
Поделиться с друзьями
-->

Комментарии (14)


  1. brn
    14.03.2017 17:06

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

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


    1. Opc-server
      15.03.2017 05:43

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


      • фиксированным выбором (параметром) — в случае двух эквивалентных контролирующих станций или партнеров (см. рисунок 1).


      1. brn
        15.03.2017 09:19

        По моему мнению это не то.


    1. ENTEK
      15.03.2017 05:44

      Да-да, мне тоже интересно про это!


  1. slepowl
    15.03.2017 10:56

    По последнему рисунку: Россети запрещают (по крайней мере на своих объектах) передачу по воздуху для АСУ ТП.

    По передаче ОРС DA… выкиньте его и используйте UA.


    1. Opc-server
      15.03.2017 10:57

      Помимо Россетей есть еще много других организаций.
      В ОРС UA сервер может устанавливать соединение с клиентом?


  1. Segmentq
    15.03.2017 10:59

    Передача по стандарту OPC DA в таких условиях невозможна.
    Чем не угодил OPC Tunneller? Или OPC шлюз?


    1. Opc-server
      15.03.2017 11:00

      В статье как раз и описывается OPC шлюз.


  1. we12
    15.03.2017 12:47

    в opc da есть асинхронный режим когда клиент оформляет подписку на элементы opc сервера. И когда значения этих элементов меняются, то opc сервер сам посылает клиенты уведомление.

    этот режим как-то будет поддерживаться у вас?


    1. Opc-server
      15.03.2017 12:47

      Конечно


  1. we12
    15.03.2017 13:02

    интересно.
    то есть ваш прокси это в итоге настоящий opc сервер внутри локальной сети OPC-клиента (самый правый на картинках), который:
    1. содержит все те же элементы, что и удаленный opc сервер
    2. поддерживает все интерфейсы и операции, которые поддерживает удаленный opc сервер
    3. вызов операции — в итоге приводит к вызову операции на удаленном opc сервере
    я правильно понял?


    1. Opc-server
      15.03.2017 15:02

      Нет.
      OPC-клиент получает те же аналоговые и дискретные значения (или часть их), которые есть в OPC-сервере.


  1. ENTEK
    15.03.2017 13:04
    +1

    Преобразовать OPC DA во что нибудь, чтобы передать через защиту, или куда то далеко-далеко, на той стороне снова прикинуться ОРС-сервером, чтобы СКАДА ничего не поняла — ну это задача понятная, уже есть и решения по этой теме.
    В вашей реализации непонятно другое — зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Зачем нужно такое двойное преобразование? Просто потому что это проще всего реализовать? Но при этом теряется куча функциональности в изначальном ОРС — разные типы значений, временные метки, признаки качества, дата-коллбеки по изменению параметров. Конечно можно выпендриться и придумать формат передачи всего этого и через самопальный Модбас, но это будет жесть, никакому нормальному инженеру АСУТП такая система в работе не нужна, и еще офигенная сложность в настройке.
    Использование в этом плане в промежутке протокола МЭК-104 — уже гораздо лучше, понятнее. И мы подобные вещи тоже делали на базе своего ПО, когда надо было передать телеметрию вдаль, и там принять в ОРС в Скаде, которая не знает МЭК-104.
    Но главный вопрос, который мне непонятен совершенно — зачем двойное преобразование информации в середине? Зачем в середине делать преобразование из МЭК в ОРС, а потом снова из ОРС в МЭК? Чего бы полученный из сети 1 МЭК сразу не передать в сеть 2, без конвертации в ОРС и обратно?


    1. Opc-server
      15.03.2017 15:15

      Зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Я за стандартизацию. Вам ещё не надоело объединять в одну систему устройства с разными протоколами обмена?
      Зачем двойное преобразование информации в середине? Это один из вариантов. Я же писал

      Опять же эту схему можно упростить с помощью программы TCP connections Convertor.
      по аналогии с рисунком 3. Не стал разрисовывать для МЭК-104, думал и так понятно будет.