Переход на российскую SCADA: переносить проект или пересматривать архитектуру?

Переход на российское ПО в рамках модернизации автоматизированной системы управления – это возможность пересмотреть архитектуру старого проекта и улучшить его. В статье рассматриваются два подхода к миграции: перенос проекта один в один и модернизация после технического аудита. Д. Ю. Алексеев, менеджер продуктового маркетинга АО «Атомик Софт», рассказывает об отношении российских компаний к этому вопросу.

АО «Атомик Софт», г. Томск

Замена зарубежной SCADA российским ПО обычно начинается с обсуждения совместимости оборудования, сроков внедрения и объема работ. При этом один вопрос нередко остается в стороне: что именно предприятие переносит в новую программную среду?

Вместе с алгоритмами управления, базой тегов и операторскими мнемосхемами в новую SCADA-систему часто переходят инженерные решения, принятые десять лет назад или больше. Многие проекты создавались в середине 2000‑х или начале 2010‑х годов. За это время менялись технологические процессы, подключалось новое оборудование, расширялись производственные линии, внедрялись дополнительные системы контроля. Сам проект то­же менялся, но далеко не всегда последовательно. Одни решения появлялись в хо­де модернизации, другие – во время пусконаладочных работ, третьи могли сохраниться просто потому, что система уже работала и вмешиваться в нее бы­ло рискованно. В результате к моменту внедрения нового российского ПО предприятие имеет не только действующую систему автоматизации, но и законсервированный за го­ды эксплуатации опыт ее развития вместе со всеми сильными сторонами и ошибками.

АО «Атомик Софт», разработчик инструментального ПО для автоматизации технологических процессов промышленных и гражданских объектов, рекомендует использовать перевод существующей SCADA-системы на отечественное ПО как возможность оценить качество архитектуры существующего проекта и внести улучшения. Са­мо по се­бе это не означает, что существующий проект является некачественным. Большинство ограничений появляются по вполне понятным причинам: вводится новое оборудование, меняется технология, появляются дополнительные требования к диагностике или отчетности. Каждая доработка решает конкретную производственную задачу. Проблема возникает позже, когда накопленные изменения начинают влиять на сопровождение системы. В этот момент становится заметно, что часть мнемосхем перегружена информацией, одинаковые технологические объекты описаны по-разному, аварийные сообщения формировались в разное время по разным правилам, а объектные библиотеки постепенно утратили единообразие. Такие особенности усложняют развитие проекта.

Если просто перевести такую систему автоматизации на отечественное ПО без изменений, вместе с алгоритмами управления будет перенесен и технический долг, появившийся за время существования системы. По этой причине перед миграцией рекомендуется проанализировать архитектуру проекта, организацию визуализации, систему аварийной сигнализации, хранение исторических данных и объектную модель. Аудит проекта помогает понять, какие решения стоит сохранить, а какие целесообразно пересмотреть одновременно с переходом на новую платформу.

Перенос существующей системы один в один в некоторых случаях нельзя считать неправильным или неполноценным. Иногда он приемлем. Если технологический процесс устойчив и длительная остановка производства недопустима, сохранение привычных операторских экранов и логики работы позволяет сократить продолжительность внедрения и избежать масштабного переобучения персонала. Решив задачу импортозамещения ПО, предприятие может позже, во время запланированной модернизации производства, вернуться к вопросам дальнейшего развития системы автоматизации.

Примером переноса один в один является проект, реализованный компанией «Коралайна Инжиниринг» на угольной фабрике. Основная задача проекта заключалась в том, чтобы заместить устаревшее иностранное ПО Wonderware InTouch отечественной «Альфа платформой» без потери управленческой логики и истории процессов. Это удалось сделать в полном объеме. Специалисты перенесли все алгоритмы управления, настроили связь с контроллерами и архивацию данных. Вся логика работы оборудования сохранилась, а исторические данные не только не потерялись, но и стали доступнее – выборка из Alpha.Historian (высокопроизводительного сервера хранения производственных и исторических данных) выполняется быстрее, чем раньше. При этом производительность системы выросла: отказоустойчивое ядро и настройка опроса обеспечили стабильную работу без задержек (рис. 1, 2).

Рис. 1. Основная мнемосхема: а – ПО Wonderware InTouch;  б – ПО «Альфа платформа»

Рис. 2. Окно состояния: а – ПО Wonderware InTouch; б – ПО «Альфа платформа»

В этом проекте проявились плюсы «Альфа платформы», такие как гибкость построения системы и возможность адаптации под проект заказчика. Компоненты оперативного сбора данных, визуализации, хранения истории, диагностики и другие сервисы работают независимо друг от друга и могут быть изменены без полной перезагрузки системы. Это позволяет в дальнейшем, уже после переноса проекта на новое ПО без существенных изменений, пересматривать, модернизировать отдельные подсистемы по ме­ре развития производства. Экраны, объекты на них и функциональность бы­ли полностью перенесены со старого проекта. Все это позволило провести переход на отечественное ПО без проведения обучения персонала. Также «Альфа платформа» позволяет выполнять широкое масштабирование системы автоматизации вплоть до построения в рамках одного проекта всей АСУ ТП предприятия путем интеграции и последовательного добавления в проект цехов и других объектов.

Теперь рассмотрим другой подход – импортозамещение после аудита, с внедрением перемен. Практика показывает, что наиболее сложные проблемы при переносе проекта на новое ПО связаны не столько с программным обеспечением, сколько с качеством самого проекта автоматизации. Если оператору приходится последовательно открывать несколько экранов для оценки состояния одного технологического участка, если одинаковые объекты отображаются по-разному, а аварийные сообщения поступают одновременно без понятной структуры, причина обычно заключается не в возможностях SCADA, а в особенностях проектирования, которые привели к накоплению ошибок.

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

Примером такого подхода служит проект, реализованный компанией «РТСофт» для холдинга VIRIDIAN – производителя хлебобулочных и кондитерских изделий без глютена под маркой FOODCODE. От интегратора требовалось не просто заменить импортное ПО, а построить более современную автоматизированную систему диспетчерского управления (АСДУ). Специалисты «РТСофт» решили эту задачу с помощью перехода на отечественную «Альфа платформу», кардинально улучшив архитектуру системы.

Что было улучшено:
- вместо разрозненных АРМ создали единое отказоустойчивое ядро, объединившее более 30 контроллеров и 300 источников данных (инженерные системы и производственное оборудование);
- обеспечили масштабируемость – теперь легко подключать новые линии, че­го не давали старые закрытые решения;
- сформировали единый исторический архив с быстрым доступом для глубокого анализа эффективности.

В результате удалось исключить человеческий фактор, сократить рутину и обеспечить прозрачный онлайн-контроль 24/7. Таким образом, отечественное ПО позволило не просто заместить импорт, а создать архитектуру, готовую к развитию, что напрямую повысило производительность всего завода.

По наблюдениям специалистов «Атомик Софт», в последние го­ды подход к импортозамещению ПО постепенно меняется. Если первоначально основная задача заключалась в замене зарубежного программного обеспечения, то сегодня все ча­ще обсуждается качество будущей архитектуры АСУ ТП. Опыт проектов, реализованных с использованием «Альфа платформы», показывает, что перенос существующей системы и ее последовательная модернизация не противоречат друг другу. Выбор между этими сценариями определяется состоянием конкретного проекта, производственными ограничениями и задачами, которые предприятие планирует решать после завершения миграции.

Мы попросили специалиста компании «Атомик Софт» рассказать о тех нюансах, которые редко отражены в технической документации, но хорошо знакомы инженерам, выполняющим проекты по импортозамещению ПО.

Интервью с Денисом Алексеевым, менеджером продуктового маркетинга АО «Атомик Софт»

Денис Юрьевич! Часто ли при переводе АСУ ТП на российское ПО компании используют этот процесс для усовершенствования существующего решения?

К сожалению, нет. Ча­ще при переводе автоматизированных систем на российское ПО компании идут по самому простому пу­ти – делают так же, как бы­ло, вне зависимости от технического прогресса и развития инженерной мысли. Не далее, как на последней выставке «Нефтегаз», интеграторы, рассказывая о переводе проекта на российское ПО, демонстрировали рабочий экран оператора. Он полностью копировал исходный проект с дизайном десятилетней давности и был ядовито-синего цвета. Возникли вопросы – зачем сохранили старый дизайн? На что последовал ответ: «Так захотел клиент».

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

Может быть, мы са­ми виноваты. Когда у нас спрашивали насчет вариантов перехода, мы отвечали: «У вас будет все то же, что и раньше». Например, при переходе с Siemense на «Альфа платформу» оператор получает дисплей с те­ми же фейсплейтами, алгоритмами, той же логикой работы. Это бесшовный переход, который обычно воспринимается как преимущество. И рынок да­же не задумывался над тем, что переходом можно воспользоваться и сделать лучше. «О! Будет то же самое? Отлично!» Люди радовались и повторяли все, что у них бы­ло, за счет гибкости «Альфа платформы», используя которую, можно реализовать любую архитектуру, да­же не очень удачную.

Когда предприятию, по вашему мнению, на­до обязательно вносить изменения в проект, а когда можно перевести на российское ПО один в один?

Переход один в один оправдан, если система автоматизации старая и ее модернизация не за горами, то есть, скорее всего, состоится в ближайшие 2–3 го­да. При этом переход на отечественное ПО государство ограничило определенными сроками, и вам все равно на­до его пройти до завершения этого срока. У компаний может не быть денег или специалистов, чтобы написать ТЗ и быстро выполнить задачу. Поэтому можно перенести ПО один в один, а уже на этапе модернизации системы переработать. Другой вариант – это когда система достаточно проста и не вызывает сложностей, в ней не накопилось внутренних ошибок, от которых хотелось бы избавиться (что редко, но бывает). Тогда то­же оправдан перенос один в один. Но в других обстоятельствах на­до проводить переработку на этапе переноса.

Что обычно оказывается самым сложным при миграции: архитектура, интерфейсы или логика управления?

Вытащить логику управления – самое сложное. Также сложно заменить старые интерфейсы или древние протоколы. Есть одна проблема: у зарубежных компаний, занимающихся OPC-серверами, был широкий набор поддерживаемых протоколов. И раньше, если какая-то SCADA определенный протокол не поддерживала, интегратор покупал OPC-сервер и подключал нужные системы в SCADA. Но сегодня в России, к сожалению, нет мощных производителей OPC-серверов и не всегда можно провести интеграцию таким способом. А что касается архитектуры, то мы практически любую фантазию можем реализовать на «Альфа платформе».

А с чего вы рекомендуете начинать технический аудит существующей SCADA?

Можно начать с небольшого интервью и спросить у технических специалистов, которые пользуются SCADA-системой, как им с ней живется и работается. Но в принципе неважно, с че­го начинать технический аудит. Главное – провести его полноценно, потому что в процессе аудита формируется представление о том, что в системе автоматизации имеется, и вылезают проблемы, ошибки, недостатки архитектуры. Например, где и с помощью какого «костыля» бы­ла реализована поддержка определенного протокола.

Какие изменения заказчики ча­ще всего откладывают на потом, а после жалеют об этом?

Если в рамках проекта по импортозамещению компания переходит на отечественный софт, то ТЗ на модернизацию, составленное без учета последующего развития АСУ ТП, может это развитие затормозить. На­до сразу заложить больше возможностей, купить лицензию на большее количество тегов. Но компании в целях экономии иногда покупают лицензии впритык, не предусматривая дальнейшего роста и развития. В результате они упираются в размер лицензии. Такие сожаления мы частенько слышим. Ограничили се­бя на этапе покупки, а через год начались проблемы с масштабированием и т. д.

Как меняются требования заказчиков после завершения импортозамещения? Я имею в ви­ду их взгляд на ситуацию уже с точки зрения приобретенного опыта.

Во‑первых, в компаниях меняется представление о российском ПО. Например, лю­ди, которые перешли на «Альфа платформу» с импортных SCADA-систем, осознают, что российское ПО достигло мирового уровня, в то время как те, кто этим не занимается, считают, что российские программные продукты еще недостаточно зрелые и нам следовало бы подрасти. Однако на практике мы сможем удовлетворить практически все запросы предприятий по автоматизации в плане программного обеспечения.

Опубликовано в журнале «ИСУП» № 4(124)_2026

Беседовали: С. В. Бодрышев,
главный редактор журнала «ИСУП»;
Д. Ю. Алексеев,
менеджер продуктового маркетинга,
АО «Атомик Софт», г. Томск,
тел.: +7 (3822) 281-914,
эл. почта: info@automiq.ru

Иллюстрации предоставлены АО «Атомик Софт»