Замена иностранной SCADA на производстве: что оказалось сложнее, чем казалось
Реализуем проект замены иностранной SCADA на значимом объекте КИИ. Разбираем технические и организационные сложности перехода: датчики, ПЛК, протоколы, персонал.
Требования КИИ для промышленных объектов: АСУ ТП на значимых объектах должны использовать отечественные или совместимые SCADA-решения к 2025 году
Когда мы писали про импортозамещение ПО на КИИ в целом, АСУ ТП шли в списке «самого трудного». Сейчас мы внутри одного из таких проектов - замена иностранной SCADA на производственном предприятии со значимым объектом второй категории. Есть что рассказать по свежим следам.
Дедлайн по переходу на отечественные или совместимые решения в части АСУ ТП - 2025 год. Для нашего клиента это значит, что нужно успеть до конца этого года: внедрение, тестирование, опытная эксплуатация, документирование. Бумажная часть тоже занимает время.
Откуда берётся сложность
Со стороны всё выглядит понятно: берём российскую SCADA из реестра, устанавливаем, переносим конфигурации, обучаем операторов. Это примерно как с заменой Windows на Astra Linux - слышали же, да? Только в АСУ ТП сложность другого рода.
Иностранная SCADA - это не изолированный программный продукт. Она встроена в цепочку: датчики передают данные через свои протоколы, ПЛК обрабатывают их своими стеками, SCADA собирает всё это и рисует операторам картинку. Поменять SCADA - значит затронуть весь этот стек, а не просто переустановить приложение.
У нашего клиента стоят контроллеры нескольких производителей - часть немецкие, часть отечественные, приобретённые в разные годы. Они говорят на разных диалектах Modbus и Profibus, плюс кое-где есть OPC DA от Windows-хостов. Отечественные SCADA работают с этим, но по-разному и с оговорками.
Первый реальный барьер - протоколы и драйверы
Отечественные SCADA-системы - мы смотрели несколько решений из реестра Минпромторга - в целом поддерживают Modbus RTU/TCP, OPC UA, МЭК 60870-5. Это основное, и здесь проблем нет.
Но у клиента часть оборудования работает через проприетарный протокол конкретного европейского вендора. Драйвера к нему нет ни у одной из рассмотренных российских систем. Варианта два: писать собственный OPC-сервер, который будет транслировать данные в OPC UA - или менять полевое оборудование. Первый вариант реален, но требует компетенций и времени. Второй - это уже другой бюджет и другой проект.
Мы выбрали первый путь. Написали OPC DA/UA шлюз под конкретный контроллер, протестировали на стенде. Работает, но это несколько недель, которых в первоначальном плане не было.
Второй барьер - историческая база данных
SCADA хранит не только текущие значения тегов, но и историю: временные ряды технологических параметров. У клиента эта история - несколько лет данных. Она используется для анализа режимов работы оборудования, для предсказания обслуживания, иногда для разбора аварий.
Форматы хранения у разных SCADA несовместимы. Импортировать историческую базу из иностранной системы в отечественную - нетривиальная задача. Часть данных удалось конвертировать через промежуточный CSV-экспорт, часть потеряет структуру тегов при переносе. Мы договорились с клиентом: старую систему оставим в режиме архивного хранения ещё какое-то время, чтобы история была доступна для запросов. Это не идеальное решение, но рабочее.
Третий барьер - мнемосхемы и логика операторов
Операторы работают с мнемосхемами - графическими экранами, на которых показан технологический процесс. В иностранной SCADA эти схемы создаются в собственном редакторе, хранятся в собственном формате. Перенести их напрямую невозможно - нужно перерисовывать заново.
На объекте клиента больше ста мнемосхем разной сложности. Часть из них - просто показывают значения датчиков. Часть - содержат встроенную логику: условные цвета, всплывающие окна, кнопки управления с привязкой к командам на ПЛК. Эту логику нужно не просто перерисовать, но и переписать под инструментарий новой системы.
Параллельно с технической частью идёт организационная: операторов нужно обучить. Это не быстро - люди годами работали с конкретным интерфейсом и конкретными реакциями системы. Новый интерфейс даже при схожей функциональности требует адаптации. На производстве с непрерывным процессом это означает обучение посменно, без остановки работы.
Как выглядит план на практике
Мы разбили проект на три этапа. Первый - параллельная работа обеих систем на ограниченном числе точек ввода-вывода. Операторы видят обе системы, сравнивают показания, привыкают к новому интерфейсу без ответственности за него. Это снижает риск и даёт время на выявление расхождений.
Второй этап - расширение охвата новой системы, перевод мнемосхем и обучение. Третий - переключение управляющих функций, вывод иностранной SCADA из контура управления.
Такой подход удорожает проект по сравнению с прямой заменой: нужно поддерживать две системы одновременно, писать интеграцию между ними для синхронизации данных. Но для производства с непрерывным процессом риск прямого переключения неприемлем.
Что пока не решено
Вопрос с проприетарным полевым оборудованием остаётся открытым. Написанный нами шлюз работает, но официальной поддержки от производителя SCADA у него нет - а значит при обновлениях или инцидентах ответственность ложится на нас. Это нормально в рамках проекта интеграции, но клиент должен понимать, что он зависит от этого решения.
Ещё один открытый вопрос - сертификация. Отечественная SCADA в реестре Минпромторга есть, но сертификата ФСТЭК по требованиям приказа 239 у выбранного нами решения пока нет - он в процессе получения. Это риск для клиента: система будет введена в эксплуатацию, а документальное подтверждение соответствия придёт позже. С регулятором на это смотрят по-разному.
Проект идёт. До конца года должны успеть - если не возникнет сюрпризов с оборудованием, которое мы ещё не дошли до проверки.