Импортозамещение SCADA: опыт перевода крупного производства на отечественную платформу
В последние несколько лет российские предприятия столкнулись с необходимостью перевода своих систем управления с импортных SCADA-платформ на отечественные аналоги. Основными причинами стали санкции, разрыв отношений с зарубежными вендорами ПО, невозможность продления лицензий и получения техподдержки. Особенно острой эта проблема оказалась для непрерывных производств, где остановка технологического процесса даже на 30 минут может обернуться серьезными убытками и повреждением оборудования.
Летом 2023 года к к нам обратилось предприятие химической промышленности крупного Российского холдинга. На нем много лет использовалась SCADA-система Wonderware InTouch. Из-за санкционных наложений, иностранный вендор расторг контракт на обслуживание и техподдержку. Более того, была предпринята попытка удаленно остановить производство путем отключения серверов SCADA. Последствия удалось минимизировать, изолировав промышленную сеть, однако функционал системы снизился на треть, а ее развитие и масштабирование оказалось невозможным. Нам было необходимо решить следующие проблемы:
Отсутствие возможности обслуживания данной системы. Ввиду того, что данную SCADA систему разрабатывала и обслуживала иностранная компания, после начала СВО все контракты по обслуживанию и технической поддержке были расторгнуты.
Ограниченный функционал системы. После того как контракты были расторгнуты иностранная компания, имея удалённый доступ, попыталась дистанционно остановить производство путём отключения рабочих серверов. Заказчик, увидев странное в системе предпринял действия по изоляции своей производственной сети, однако иностранной организации всё-таки удалось нарушить состав системы, тем самым снизив её функционал на треть.
Отсутствие возможности расширения производства. Из-за сторонней разработки и обслуживания данной SCADA системы заказчик не имел доступа к проекту. Как следствие внесение правок в проект было невозможным.
Непрерывное производство. Отключение управления от оборудования больше чем на 30 минут могло привести к непоправимым последствиям и большим убыткам.
Необходимо было проработать вариант разработки такой системы, которая решила бы все эти проблемы заказчика
Выбор решения и методология
Критерии выбора новой SCADA-системы:
Интеграция с Postgres SQL
Поддержка производителей Allen Bradley, Siemens, ОВЕН
Возможность глубокой кастомизации
Горячее резервирование
Хорошая техническая поддержка
Наличие среды разработки под Astra Linux
Наличие инструментов для анализа данных, выявления трендов и оптимизации производственных процессов.
При анализе рынка по данным критериям была выбрана SCADA «Каскад цифра» от компании Сибком цифра. Данная SCADA полностью подходила по критериям для реализации проекта.
Наша команда реализовала проект в несколько этапов:
Обследование существующей инфраструктуры АСУ ТП, сбор требований, разработка концепции новой системы. Совместно с технологами предприятия были детально проанализированы все информационные потоки, алгоритмы управления, экраны визуализации, отчеты. Особое внимание уделялось «узким местам» и проблемным участкам, возможностям оптимизации процессов.
Выбор целевой SCADA-платформы с учетом специфики производства, требуемого быстродействия, надежности, функциональности. После анализа рынка решение было принято в пользу SCADA «Каскад» — российской разработки на базе немецкой платформы WinCC OA. Основными факторами стали: поддержка контроллеров Siemens, Allen Bradley, промышленных протоколов (Profinet, Modbus TCP); возможность кастомизации и интеграции со сторонними системами через API и промежуточную БД; многоуровневая архитектура с горячим резервированием серверов.
Реверс-инжиниринг существующих алгоритмов управления и мнемосхем. В связи с отсутствием исходных кодов и документации от иностранного вендора, этот этап оказался наиболее трудоемким. Потребовалось фактически заново спроектировать структуру переменных контроллера, карты адресов, описания сигналов. Для этого использовался метод «черного ящика», когда проектируемая система подключалась параллельно с действующей, считывала данные и сравнивала их в реальном времени. Для проверки правильности алгоритмов использовали заранее согласованные технологические окна, когда заказчик мог отдать ту или иную единицу оборудования без ущерба производственному процессу
Разработка новой системы на платформе «Каскад», перенос алгоритмов, перенос мнемосхем операторского интерфейса. Весь функционал был реализован на языке CONTROL (язык платформы «КАСКАД» с синтаксисом языка С). Дополнительно потребовалась доработка драйверов к контролерам Siemens S7–1500 и разработка механизма обмена рецептурными данными с MES-системой. Для этого была спроектирована отдельная БД на PostgreSQL и настроена интеграция между БД и SCADA системой.
Отладка на стенде, имитирующем ключевые участки производственного процесса. Стенд включал в себя 6 контроллеров, порядка 7000 сигналов ввода/вывода, частотные преобразователи, модели печей, конвейеров, дозирующих комплексов. В течение 2 месяцев непрерывно отрабатывались сценарии запуска, остановки, переключения режимов, нештатных ситуаций, проверялась корректность отработки блокировок и аварийной сигнализации.
Эксплуатация с поэтапным переводом контуров управления. Для минимизации рисков остановки процесса переключение осуществлялось по отдельным единицам оборудования, начиная с наименее критичных. На начальном этапе действующая и новая SCADA работали параллельно, данные записывались в логи и сравнивались между собой. Функция управления передавалась только после полной проверки идентичности поведения системы. Всего за 2 недели удалось без инцидентов перевести управление на новую SCADA более 50 единиц оборудования и 42000 сигналов
Проблемы, с которым мы столкнулись при выполнении проекта
При заключении договора заказчик указал, что система содержит 7 500 тегов. Однако в процессе реверс-инжиниринга выяснилось, что их на самом деле около 50 000. Несмотря на это, мы смогли завершить проект, хотя этот момент стал неожиданностью и потребовал дополнительных усилий. Конечно, отсутствие точной информации на этапе предварительного анализа стало нашей ошибкой.
Еще одной сложностью стала замена верхнего уровня системы управления: после внедрения новой версии «SCADA» оказалось, что ПЛК некоторых устройств продолжают пытаться опрашивать сервер старой системы. Так как на этапе разработки и ПНР обе скада-системы были онлайн, заметить это было невозможно. При переходе в опытно — промышленную эксплуатацию, при отключении старой системы, конечные устройства стали вести себя не так как при разработке. Необходимо было быстро пересмотреть и переделать логику работы с оборудованием со стороны верхнего уровня. Сложности добавляло то, что код в ПЛК устройств менять было нельзя.
Наконец, еще одна проблема возникла из-за того, что оборудование имеет два режима работы: при наличии подключения к «SCADA» и при отсутствии такового. В зависимости от режима меняется логика взаимодействия между компонентами системы. Данная особенность «всплыла» только на переходе к опытно-промышленной эксплуатации, и нам необходимо было в короткое время понять по каким признакам оборудование видит что скада-система онлайн, и заложить это в код.
Результаты проекта подтвердили эффективность импортозамещения SCADA:
Удалось уйти от зависимости от иностранных вендоров, тем самым обеспечив непрерывность работы производства
Время реакции оператора на события сократилось на 20% за счет более удобного и отказоустойчивого интерфейса
Обеспечена интеграция данных между SCADA, MES и ERP для оперативного управления производством и сквозной прослеживаемости партий продукции
