От SCADA к предиктиву: почему собрать телеметрию проще, чем предсказать отказ

Коротко о статье

Статья описывает пилотный проект Check Pro — систему предиктивной аналитики для распределённых электростанций, которая дополняет штатную SCADA анализом динамических норм. Из статьи можно понять, какие архитектурные принципы (read-only, on-premise) и ограничения (дефицит размеченных аварийных данных, фактор времени) определяют путь от мониторинга к прогнозу отказов.

Главное

• Языковая модель в проекте не управляет оборудованием и не меняет уставки, а анализ телеметрии выполняется классическим ML и динамическими моделями.
• Check Pro размещён локально (On-premise) и отделён от контура управления: вычислительные ресурсы выделены независимо от ПЛК.
• Штатная SCADA не выявляет медленные отклонения и сочетания параметров, которые не нарушают аварийные уставки, но предшествуют отказу.
• В проекте выделены три уровня: мониторинг (опрос по OPC UA, Modbus), обнаружение аномалий (динамическая норма) и диагностика с прогнозом (исследовательская задача).
• Для обучения моделей не хватает верифицированных аварийных данных, а стендовые и синтетические выборки не отражают реальный эксплуатационный контекст.
• Пилот развёрнут на энергоцентре «ПСМ Прайм» в Тутаеве для накопления наработки и калибровки алгоритмов в фоновом режиме.

Термины и технологии

• SCADA
• АСУ ТП
• ПЛК
• OPC UA
• Modbus
• On-premise
• динамическая норма
• NASA C-MAPSS

Кому полезно: Инженерам АСУ ТП и специалистам по промышленной аналитике

Первоисточник: habr.com

Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.

В предыдущей статье мы рассказывали про пилот RAG-ассистента: инженеры собирают структурированную базу знаний, а языковая модель учится отвечать на технические вопросы по 44 модификациям газопоршневой электростанции. Опыт показал главное: прикладным алгоритмам бесполезно ставить задачу, пока для неё нет выверенного контекста, чистых входных данных и прозрачных критериев проверки результата.

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

Цех против офиса: границы задач и технологий

Когда в одной фразе звучат слова «AI» и «производство», часто возникает образ нейросети, которая непрерывно смотрит на датчики, общается с контроллером и на лету генерирует команды управления.

В реальности у инженеров АСУ ТП такой подход вызывает понятное отторжение. Офисные методы здесь неприменимы из-за принципиальной разницы в решаемых задачах:

1. Граница проходит по задаче

Языковая модель может быть полезна дежурному персоналу: помочь инженеру быстро найти нужный раздел регламента или структурировать сообщения в аварийных журналах. Но в нашем проекте она не выдаёт команды оборудованию и не изменяет защитные уставки. Анализ временных рядов промышленной телеметрии решается другими методами — классическим машинным обучением (ML), динамическими расчетными моделями и математической статистикой.

1. Локальное размещение вместо облака

В веб-разработке привыкли разворачивать сервисы в облаке через сторонние API. Для описываемого пилота мы выбрали локальное размещение (On-premise): оно соответствует внутренним регламентам безопасности энергоцентра и позволяет не зависеть от внешнего канала связи, который на удалённых объектах генерации не всегда стабилен. На других предприятиях архитектура определяется требованиями заказчика и правилами защиты критической информационной инфраструктуры (КИИ).

1. Разделение контуров управления и аналитики

Цикл опроса датчиков и исполнение логики защит в программируемых логических контроллерах (ПЛК) измеряются миллисекундами. Мы решили не добавлять аналитические вычисления в существующий контроллер управления. Для Check Pro выделили отдельные вычислительные ресурсы, чтобы независимо проверять нагрузку, обновлять математические модели и исключить влияние интеграции на штатную автоматику.

Почему телеметрии SCADA недостаточно для ранней диагностики

Идея предиктивного анализа выросла из очень приземлённой практики сервисной службы ПСМ. Когда компания годами производит, монтирует и обслуживает тяжелую генерацию по всей стране, накапливается большой массив статистики о нештатных ситуациях.

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

С инженерной точки зрения это абсолютно оправданно. Штатная система контролирует предусмотренные проектом режимы и опасные состояния. Задача программируемого логического контроллера (ПЛК) удерживать установку в рамках заданного технологического процесса и мгновенно активировать защиту, если параметр пробил аварийную уставку (например, температура масла превысила критические 105 °C).

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

• установка может работать на 35–40% мощности, а температура масла в контуре постепенно приближается к значениям номинальной нагрузки;
• абсолютные температуры выхлопа по цилиндрам укладываются в паспортный диапазон, но разброс между отдельными цилиндрами начинает систематически расти.

Для классической диспетчеризации это нормальный режим: аварийный порог не нарушен, на мнемосхеме горит спокойный «зелёный» статус. Человек физически не может непрерывно отслеживать корреляцию десятков медленно дрейфующих параметров на протяжении сотен часов.

В ПСМ давно прижилась практика внутренних стартапов: если идея решает реальную эксплуатационную проблему и опирается на физику процессов, проект получает ресурсы на прототипирование. Так сервисная гипотеза о выявлении скрытых дефектов оформилась в отдельную разработку — Check Pro.

Check Pro: как не свести с ума главного энергетика

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

1. Мониторинг (базовый работающий уровень). Опрос параметров по стандартным протоколам (OPC UA, Modbus), архивация телеметрии и отображение данных.
2. Обнаружение аномалий (текущий этап пилота). Модель динамической нормы сопоставляет фактические параметры с расчетным коридором исправной машины под текущей нагрузкой. Если параметры систематически расходятся, система фиксирует аномалию: поведение оборудования отличается от ожидаемого для этого режима.
3. Диагностика и прогноз (исследовательская задача). Переход от аномалии к выводу о конкретном дефекте узла и сроке до отказа. Чтобы прогнозная аналитика начала работать, должен пройти минимум год. За это время система накапливает знания и понимает что норма, а что аномалия.

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

Сейчас мы проверяем не способность модели построить красивый график, а её способность давать полезное предупреждение при реальной эксплуатации. Какие сценарии удастся подтвердить и с какой точностью — ещё предстоит установить.

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

Правило 1: «Руки прочь от рубильника» (Read-only)

Первая реакция главного энергетика или начальника цеха при виде любого нового программного модуля в шкафу автоматики абсолютно предсказуема: «Эта штука будет вмешиваться в управление генератором?»

Поэтому принцип проекта сформулирован однозначно: руки прочь от рубильника.

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

Правило 2: Локальный On-premise контур

Архитектура развёрнута внутри закрытого технологического периметра:

• Коммуникационный шлюз: забирает сырую телеметрию с контроллеров и вспомогательных датчиков по защищённой технологической сети.
• Сервер аналитики: расположен непосредственно на объекте и выполняет фильтрацию сигналов и расчет моделей без подключения к внешней сети.
• Интерфейс оператора: выдаёт лаконичные уведомления об отклонении от нормы вместо сотен неструктурированных аварийных сообщений.

Динамическая норма: физика процессов и проверка гипотез

В классической автоматике аварийная уставка статична. В контроллер зашит порог. Однако реальное состояние тяжелого двигателя сильно зависит от условий его работы. Возьмем условный пример: установка работает зимой при температуре окружающего воздуха -30 °C и несет всего треть от номинальной мощности. В таком режиме ее расчетная температура может находиться в районе 70–75 °C. Если параметр постепенно поднимается к 90 °C, для штатной SCADA система остается в полностью «зелёной» зоне: до аварийной уставки еще далеко.

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

Именно по этому пути мы пошли в Check Pro, создавая модель динамической нормы:

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

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

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

Когда переходишь к тяжёлой промышленной генерации — сбор и подготовка обучающей выборки подчиняются совершенно другим ограничениям.

Дефицит размеченных аварийных данных

В академической среде и специализированных исследованиях существуют методы моделирования деградации оборудования — от классических исследовательских датасетов (вроде NASA C-MAPSS для турбин) до стендовых испытаний на ускоренный износ. Однако на действующем производстве искусственно воспроизводить аварийные режимы никто не позволит, потому что тяжёлая генерация — это дорогостоящие основные фонды предприятия, работающие в непрерывном технологическом цикле.

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

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

Именно с такой разметкой в промышленной эксплуатации возникает главный дефицит.

Ограничения лабораторных и синтетических данных

Возникает закономерный вопрос: почему не использовать для обучения моделей стендовые испытания завода-изготовителя или готовые профили других эксплуатантов?

Дело в эксплуатационном контексте. Двигатель, проходящий испытания на заводском стенде в помещении с контролируемым микроклиматом, и точно такой же силовой агрегат, смонтированный в блок-контейнере энергоцентра на производственной площадке, работают в разных условиях:

• Реальный профиль топлива: переменный компонентный состав и калорийность природного или попутного нефтяного газа напрямую влияют на тепловые режимы горения в цилиндрах.
• Климатические колебания: температура приточного воздуха, влажность и барометрическое давление меняют термодинамику рабочего процесса.
• Динамика нагрузки: в отличие от статичных стендовых ступеней, реальный заводской технологический процесс формирует постоянные стохастические колебания мощности.

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

Фактор физического времени

Поэтому для проверки гипотез Check Pro мы выбрали наиболее прозрачный путь — развернули аналитический контур на энергоцентре собственного завода «ПСМ Прайм» в Тутаеве. Энергоцентр снабжает предприятие электроэнергией, обеспечивая работу оборудования под реальной динамической нагрузкой.

В фоновом режиме развернут сбор многопараметрической телеметрии:

• температурный баланс по каждому цилиндру и тракту выхлопных газов;
• гидравлические и температурные параметры масляного и охлаждающего контуров;
• электрические параметры генератора (токи, напряжения, активная и реактивная мощность, гармонический состав).

И здесь разработка сталкивается с фундаментальным ограничением тяжелого машиностроения — фактором времени.

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

Фактический статус: границы применимости и следующие шаги

Если оценивать текущее состояние разработки без преувеличений, статус Check Pro можно охарактеризовать как действующий производственный пилот.

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

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

Именно эту задачу мы сейчас последовательно решаем на энергоцентре:

• Калибруем алгоритмы динамической нормы: учим модели уверенно отделять эксплуатационные переходные режимы (набросы и сбросы цеховой нагрузки) от истинного теплового или механического дрейфа.
• Тестируем влияние опроса: в натурных условиях проверяем стабильность информационного обмена по шинам данных, исключая задержки в основном контуре автоматики.
• Накапливаем размеченную базу: совместно с сервисной службой фиксируем каждый случай регламентного осмотра, сопоставляя записи телеметрии с фактическим состоянием узлов агрегата.

Заменит ли предиктивный анализ классическую автоматику или опытного сервисного инженера? В обозримой перспективе — нет, и такой задачи перед проектом не стоит.

Отдельный слой аналитики способен стать для дежурного персонала надежным «третьим глазом» — инструментом, который непрерывно сопоставляет многомерные корреляции сигналов и вовремя подсвечивает нетипичное поведение узлов задолго до того, как сработает аварийная защита.

Сбор наработки и дообучение моделей продолжаются в фоновом режиме. Для нас этот пилот стал возможностью на собственном оборудовании нащупать честную границу между красивой математической теорией и тем, что действительно работает и приносит пользу дежурному инженеру в машинном зале.

Источник: https://habr.com/ru/companies/psm_unlim/articles/1094860/

🔗 От SCADA к предиктиву: почему собрать телеметрию проще, чем предсказать отказ