Skip to main content

Какая ситуация сейчас и какие сложные задачи она порождает?

Любая промышленная электростанция является сложным техническим объектом с большим количеством измеряемых или рассчитываемых параметров. На нижнем (полевом) уровне находятся тысячи датчиков разных производителей, которые связываются с контроллерами аналоговыми сигналами или по различным протоколам, зачастую очень старым (насчитывают до нескольких десятков протоколов). Связь с датчиками и управление технологическими процессами производится с помощью АСУТП разных производителей, которые состоят из контроллеров и серверов и используют различные протоколы связи, зачастую закрытые (проприетарные). Контроллеры, в свою очередь, передают данные в SCADA системы, которые позволяют машинистам установок и начальникам смен станций наблюдать и управлять процессом через HMI интерфейсы на своих рабочих местах. SCADA системы уже относятся к ИТ решениям и связываются с различными ИТ продуктами присутствующими на электростанции: вибромониторинг и термоконтроль, водоподготовка, расчеты ТЭП, СОТИ АССО, формирование макетов для СО ЕЭС, АСУРЭО, МодесТерминал, подача заявок на ОРЭМ, мониторинг ОПРЧ и другие системы.

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

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

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

Отдельно стоит рассказать о проблеме OT/IT границы. В системах АСУТП (Operational Technology) нет задачи сохранения и систематизации используемых измерений, так как основная задача АСУТП это управление процессами в реальном времени -- для этого нет нужды сохранять данные. Архивная база (historian) является вспомогательным компонентом. До 2010-х годов у нас в стране даже продвинутые иностранные проекты внедрения АСУТП не внедряли такой компонент и архивной базы данных не было. Тем более, в АСУТП нет задачи систематизации, сохранения контекста измерений, так как измерения в АСУТП используются в жестко заданных проектом алгоритмах управления, которые и содержат необходимый им контекст. Важно отметить, что каждый контроллер в АСУТП обрабатывает небольшое количество измерений, в которых можно легко разобраться инженеру на объекте. Процесс наполнения ИТ-систем измерениями из АСУТП на сегодняшний день происходит с обязательным привлечением инженеров с объекта, которые вручную помогают поставить в соответствие измерения из АСУТП сущностям в систематизированной базе данных ИТ-системы. В ИТ-системах с десятками тысяч измерений без систематизации обойтись невозможно, так как собранные измерения превращаются в «болото» данных из которого можно опять же только вручную получить сигналы. В то же время, для решения задач оптимизации, предиктивной аналитики и других, нужен контекст в котором порождаются измерения: точность и состояние датчиков, месторасположение компонента системы, наработка детали и другие. На сегодняшний день контекст приходится порождать и хранить в IT системах, что автоматически влечет проблему сопоставления и привязки информации из разных систем.