Как мы на промышленном предприятии из цеха в офис мост данных строили

Всем привет! Меня зовут Андрей Беляев, я бизнес-архитектор в компании «Инфосистемы Джет».

Как говорил Тирион Ланнистер в последней серии «Игры Престолов», в мире нет ничего сильнее хорошей истории. Особенно, если нужно было решить типовую задачу по сбору метрик на производстве, и ни на какую историю никто не рассчитывал. А в результате мы придумали архитектуру решения, придумали ее еще раз, поборолись с закрытой промышленной системой и сделали «мост» данных из изолированного цеха в корпоративную сеть.

Как это было, и что у нас в итоге получилось, расскажу под катом.

А в чем, собственно, было дело

Наш заказчик – крупное производственное предприятие с несколькими объектами по стране. Над проектом работали на площадке в Подмосковье – производственным процессом на трех технологических линиях там управляет АСУ ТП Delta V от Emerson.

По опыту работы на десятках промышленных объектов, продукты Emerson – консервативные, но надежные решения, которые могут десятилетиями работать без сбоев. В инфраструктуре заказчика, например, Delta V успешно работает уже более 15 лет. Поэтому о полной замене системы никто даже не задумывался.

Во-первых, работает – не трогай это дорого. Нет смысла вкладывать колоссальные ресурсы на замену того, что и так прекрасно функционирует. Во-вторых, такое вмешательство сломает устоявшийся производственный процесс. И не факт, что новое решение будет работать так же стабильно и предсказуемо, как давно зарекомендовавшая себя Delta V.

Но был один нюанс: в инфраструктуре заказчика система работала в изолированной технологической сети и никуда не отдавала данные. Никаких интеграций, только хардкор: идешь в цех и делаешь выгрузку из локальной операторской станции.

Чтобы получить отчет о результатах работы за смену, технологам приходилось спускаться в цех. Там они в формате Excel выгружали данные из операторских станций, возвращались в кабинет и руками переносили цифры из таблиц в корпоративную систему учета на базе 1С. 

В итоге один недостаток Delta V выливается в несколько проблем и рисков для всего бизнеса:

1. Актуальная информация всегда немного опаздывает. Руководители вынуждены ориентироваться на картинку по состоянию на конец предыдущей смены.

2. Достоверность данных сильно зависит от человеческого фактора. Легко опечататься или перепутать цифры, когда вручную переносишь их из Excel в конце рабочего дня.

3. Технологи тратят время на доставку данных от системы к системе. Даже полчаса в день – это уже несколько часов в неделю на каждого сотрудника, которые можно потратить на другие производственные задачи.  

Так появился план: безопасно прорубить окно из изолированной технологической сети в корпоративную, вытащить более 3000 тегов, сделать на их основе 43 интерактивных дашборда, настроить 17 регулярных отчетов и подружить все это с 1С.

Что мы хотели сделать или как мы зашли в тупик

Сначала мы думали, что обойдемся минимальными архитектурными изменениями. Интеграционные станции Delta V у заказчика работали под управлением операционных систем из семейства Windows.

Логичные следующие шаги:

1. Берем проверенный российский софт для опроса устройств и конвертации данных из стандарта OPC DA в OPC UA (выбрали MasterOPC MultiProtocol).

2. Устанавливаем его на серверы АСУ ТП и собираем необходимые теги по безопасному промышленному протоколу.

3. Отправляем теги в базу данных.

Архитектура получалась компактной, без лишних серверов и сложной маршрутизации. Но мы не учли особенности платформы Emerson, и по закону Мерфи все, что могло пойти не так, пошло не так.

Проблемы начались, когда мы начали тестировать решение и попытались поставить MasterOPC на стендовую станцию Delta V. Оказалось, что любая сторонняя программа, установленная поверх системы Emerson, полностью блокирует работоспособность штатных дельтавишных коммуникаторов. Платформа начинала конфликтовать сама с собой и переставала опрашивать контроллеры нижнего уровня.

В итоге с вариантом «просто поставить софт на сервер АСУ ТП» мы рисковали остановить все производство. От попыток решить проблему в Delta V тоже отказались, трогать промышленную систему, которая безотказно работает годами, — идея плохая.

Как в итоге решили вопрос сбора 3000 тегов

Пришлось менять подход на ходу и создавать промежуточный слой.

Для этого мы развернули отдельные серверы-хабы, под которые мы выделили серверы под управлением ОС Windows. На эти узлы мы установили только базовую операционную систему и конвертер MasterOPC.

Исторически всё общение внутри сети Delta V шло по протоколу OPC DA (Data Access). Это устаревшая технология, которая жестко завязана на стеке технологий Microsoft (DCOM).

Нас это не устраивало: OPC DA – уязвимый протокол обмена данными. Они передаются в открытом виде и требуют сложной настройки DCOM, а это непосредственно влияет на информационную безопасность.

Поэтому схема получилась следующей:

1. Выделенные хабы физически подключаются в технологический сегмент сети.

2. Они опрашивают серверы DeltaV по старому протоколу OPC DA и забирают 3000 тегов.

3. MasterOPC на лету конвертирует этот поток в современный, защищенный и маршрутизируемый промышленный протокол OPC UA (Unified Architecture).

4. В зашифрованном виде данные безопасно отправляются на следующий уровень архитектуры.

Демилитаризованная зона и мост в корпоративную сеть

Собранные технологические данные в формате OPC UA теперь нужно было безопасно передать в корпоративную сеть предприятия.

Однако технологический сегмент сети на производстве физически и логически изолирован от корпоративного контура. Прямая маршрутизация трафика между этими сетями строго запрещена регламентами информационной безопасности.

Чтобы решить эту архитектурную задачу, мы спроектировали демилитаризованную зону (DMZ). Внутри DMZ развернули промежуточный сервер сбора данных и с обеих сторон изолировали его межсетевыми экранами.

Сервер в DMZ выполняет функцию защищенного прокси-узла. Он принимает поток данных с хабов и передает его через второй каскад межсетевых экранов на сервер приложений в корпоративной сети. Такая архитектура позволяет передавать данные из технологического сегмента сети и сохранить физический и логический разрыв между цехом и офисом.

Как построили обработку данных в корпоративной сети

Сервер сбора данных в демилитаризованной зоне передает технологические теги на сервер приложений. За хранение, обработку и визуализацию отвечает платформа AggreGate.

Задачи платформы можно разделить на три больших группы:

1. Технологический мониторинг

   AggreGate помогает отслеживать параметры технологического процесса и контролировать соблюдение регламентов (с уведомлением, если они были нарушены). А еще платформа автоматически формирует оперативные отчеты по запросу пользователя.

2. Контроль состояния оборудования

   Система ведет учет «пробега» оборудования и по признакам его работы фиксирует текущее состояние. Помогает вовремя отследить аномалии и заняться обслуживанием до того, как аномалия превратится в критическую поломку и остановку производства. 

3. Мониторинг и контроль производственных процессов

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

   А еще AggreGate формирует диспетчерские отчеты, оперативный баланс и передает данные в систему корпоративного учета.

Платформа обрабатывает все 3000 тегов и на их основе формирует наглядные дашборды – всего мы настроили 43 интерактивных экрана для мониторинга в режиме реального времени и 17 регулярных аналитических отчетов.

Вопрос с ручной выгрузкой данных и ходьбой к операторским станциям Delta V решили – теперь все можно посмотреть на рабочем ноутбуке. Плюс, если требуется оперативная аналитика, выгружать ничего руками тоже больше не нужно.

С человеческим фактором тоже разобрались – AggreGate автоматически передает отчеты в 1С. Теперь сотрудники не подрабатывают «курьерами» между системами. Когда смена заканчивается, технолог в веб-интерфейсе AggreGate открывает сформированную сводку за прошедшие часы работы. Если контрольные цифры сходятся, он нажимает кнопку «Отправить в 1С». Данные по API уходят в 1С и автоматически разносятся по регистрам учета.

Чему мы научились и что будем делать дальше

У заказчика есть еще одна крупная производственная площадка, и теперь мы прорабатываем архитектуру для тиражирования решения.

В планах – масштабировать платформу на вторую площадку, выстроить там аналогичную безопасную систему сбора метрик через DMZ и объединить информационные потоки обеих сетей. Это позволит создать единый корпоративный диспетчерский центр, в котором руководство сможет в режиме реального времени контролировать ход технологических процессов, сравнивать эффективность линий и управлять ресурсами обеих площадок.

Сейчас мы оттачиваем уже внедренное решение: отлавливаем мелкие баги, адаптируем дашборды под требования пользователей и устраняем шероховатости интеграции. Все это поможет в дальнейшем сократить time-to-market проекта на втором производстве.

Напоследок несколько советов с нашим опытом:

1. Не пытайтесь устанавливать сторонний софт для сбора данных поверх старых, проприетарных АСУ ТП типа DeltaV. Ищите обходные пути, чтобы не «положить» производство экспериментами.

2. Если работаете над проектом с жесткими требованиями к защите КИИ, не используйте протокол OPC DA для передачи данных вне закрытого технологического контура. Для любой маршрутизации и безопасной передачи конвертируйте его в современный OPC UA как можно ближе к источнику данных.

3. Не экономьте на информационной безопасности. EDR, решения для создания резервных копий и средства контроля защищенности на рабочих станциях и серверах – необходимость. Межсетевые экраны – тоже.

Спасибо, что прочитали статью. А если сталкивались со сбоями в Delta V при установке поверх нее стороннего софта и смогли их решить, напишите в комментариях, как вам это удалось.