Пилот «умных алёртов» на среднем заводе почти всегда начинается одинаково. Подрядчик подключает модуль аномалий к historian, две недели крутит модель на архиве, на совещании показывает график с красивой полосой «нормы». На третью неделю ночная смена получает восемь жёлтых сообщений: «отклонение вибрации насоса», «аномалия температуры масла», «паттерн расхода нетипичен». Механик выходит к агрегату. Агрегат в регламенте, рецепт сменили вчера, датчик чуть плывёт с осени. К пятнице операторы квитируют умные алёрты пачкой, не читая. Через месяц модуль отключают «пока не донастроим». Донастройка не наступает.
Разбираем не предиктивное обслуживание как подход и не выбор платформы. Фокус на ложных срабатываниях первых пилотов: сезон, смена рецепта, дрейф датчика, мёртвая зона архива, обучение на грязной истории. Как не дискредитировать систему перед сменой, пока модель ещё учится. Обзор данных, ролей механика и КИПиА и перехода пилота в регламент уже есть в материале про предиктив на средних заводах. Здесь другая задача: почему алёрт врёт, даже когда тренд на экране «похож на правду».
Первые пилоты умных алёртов дают ложные тревоги не потому, что «нейросеть глупая», а потому что модель учится на архиве без контекста режима. Сезонная температура окружающей среды, смена сорта, CIP, ручной режим, дрейф 4-20 мА и deadband historian выглядят для алгоритма так же, как деградация агрегата. Пока нет маски «линия в работе / рецепт / скорость», любой статистический коридор будет срабатывать на штатные переходы.
Рабочая схема: 14-28 суток теневого режима без звонка оператору, разбор каждого ложного события с причиной, порог не по «красивому графику вендора», а по согласованному проценту ложных за неделю. Умный алёрт не заменяет технологическую аварию ПЛК. Он живёт отдельным классом сообщений. Если смешать его с красным стопом, смена перестанет верить и тому, и другому.
Метрика пилота - не «сколько аномалий нашли», а доля подтверждённых осмотром плюс доля ложных, которые модель больше не должна повторять после правки контекста.
Классическая авария: температура выше 85 °C, задержка 3 с, приоритет. Оператор понимает правило. Умный алёрт: «текущий паттерн тренда не похож на обученную норму». Норма - статистика за выбранный период. Если период кривой, норма кривая. Если период короткий, норма узкая и ловит любой пуск. Если период длинный и включает зиму с летом, коридор широкий и пропускает реальный износ.
Для смены разница критична. Уставку можно оспорить: «у нас всегда 82 на этом режиме». Аномалию оспорить сложнее: подрядчик говорит «модель увидела отклонение», механик говорит «насос как вчера». Без расшифровки на тренде (какой тег, какой участок окна, какой режим) алёрт превращается в шум. Иерархия экранов здесь та же, что для обычных аварий: предупреждение не должно забивать красный список. Это уже разбирали в материале про экраны, аварии и тренды без перегруза.
Ещё одно отличие: классический порог не «учится» на дырах в архиве. Модель учится. Пропущенная ночь записи, подстановка последнего хорошего значения при Bad Quality, ручной force наладчика - всё это становится «нормой» или, наоборот, «аномалией», которой в живом процессе нет.
Пилот почти никогда не стартует с чистого года истории. Берут то, что есть в historian: разные периоды опроса, deadband «чтобы диск не кончился», куски после смены SCADA, интервалы, когда тег был в ручном. Инженер смотрит тренд на экране - линия гладкая. Модель смотрит те же точки как ряд. Если deadband большой, гладкость - артефакт хранения, не стабильность процесса. Как выбирают период и deadband, чтобы архив и жил, и годился для разбора, подробно в материале про архив трендов HMI.
Типичные ловушки обучения:
подстановка last good value при обрыве связи - модель считает, что параметр часами стоял колом, а потом «скачком» вернулся. Скачок помечается аномалией, хотя это восстановление канала;
дыры в записи за ночь - отдельная диагностика, не путать с износом, см. дыру в тренде за ночь;
опрос раз в минуту для экрана и раз в секунду для контура - модель, обученная на минутном ряде, видит «пилу» на секундном пилоте;
ручные уставки и force, которые не выгрузили из обучающей выборки.
Перед обучением нужен фильтр качества: только Good, только автоматический режим, только «агрегат в работе». Иначе пилот измеряет грязь архива, а не состояние машины.
Вибрация подшипника, ток вентилятора, температура масла, расход охлаждающей воды зависят от улицы и от температуры цеха. Модель, обученная с ноября по январь, в мае начинает сыпать алёртами: «температура масла выше базы». База была зимней. Насос тот же.
Обратная ошибка: обучили на полном годе без признака сезона. Коридор включает и −20 °C на улице, и +35. Реальный летний дрейф подшипника тонет в ширине полосы. Алгоритм «не врёт» статистически и бесполезен практически.
Что делать. Либо отдельная модель на сезон (или на диапазон температуры окружающей среды), либо входной тег «Tокр» / «Tцеха» как ковариата. Если такого тега нет, хотя бы календарная маска: не сравнивать январь с июлем на одном коридоре. Для температурных каналов сначала проверяют сам измерительный тракт - тип датчика, компенсацию, обрыв, как в обзоре датчиков температуры в АСУ. Умный алёрт на «плывущей» термопаре - ложная экономия: КИПиА всё равно пойдёт менять кабель, а смена уже не верит модулю.
Линия упаковки перешла с 0,5 л на 1,5 л. Насос дозирования работает на другой частоте. Давление в коллекторе другое. Для технолога это штат. Для модели, обученной на полулитре, это аномалия кластера «не видели такой профиль».
То же на частотнике: ночной сниженный расход, дневной пик, ручной дожим. Без тега задания частоты и без тега «рецепт / сорт» любой multivariate-алгоритм путает смену задания с деградацией рабочего колеса. Связка с производственными цифрами здесь прямая: если OEE и простои собирают криво, контекст режима тоже кривой. Почему цифрам не верят, когда справочник простоев грязный, разбирали в материале про OEE и качество данных.
Минимум контекста для пилота на насосе или вентиляторе:
признак «в работе» (не ток выше нуля на останове с residual);
задание частоты или положение клапана;
код рецепта или хотя бы дискрет «сорт A / сорт B»;
признак CIP / промывка / стерилизация, если они есть на объекте.
Пока этих тегов нет, порог аномалии имеет смысл только внутри одного зафиксированного режима. Иначе пилот будет ловить каждую переналадку.
КИПиА знает картину: 4-20 мА за год уехал на 0,3 мА, на экране +2 °C к реальности, контур компенсирует, продукт в норме. Модель видит медленный тренд «температура растёт» и ближе к границе коридора даёт алёрт. Механик проверяет подшипник - норма. Калибровка датчика в журнале не отмечена, поэтому следующий месяц модель снова учится на смещённом нуле.
Вторая сторона: мёртвая зона (deadband) в архиве. Параметр гуляет в поле на 0,5% шкалы, в historian пишется только при отклонении 2%. На тренде - ступеньки. Алгоритм, чувствительный к форме, считает ступеньку событием. Либо наоборот: реальное начало износа сглажено deadband и не видно, пока не поздно. Перед пилотом для обучаемых тегов deadband уменьшают или заводят отдельный «аналитический» архив с более частой записью, не ломая операторский экран.
Третье: Bad Quality. Если HMI показывает последнее значение без флага, оператор спокоен, модель тоже «видит норму», пока канал не оживёт скачком. Правила флага и фильтра для аналога не меняются от того, что сверху повесили ML. Их нужно соблюдать, как в материале про сигнал 4-20 мА, фильтр и Bad Quality.
Самый частый ложный паттерн на пилоте насосной: ночной останов, утренний пуск, пусковой ток и переходный процесс по давлению. Модель, если её не маскировали, ставит аномалию на каждый пуск. Через неделю таких событий сотни. Смена перестаёт открывать список.
Вторая группа: наладчик в ручном, технолог гоняет контур, механик отключает агрегат на осмотр. В архиве это «невиданные» траектории. Если их не вырезать из обучения и не глушить алёрт по тегу «ручной / сервис», пилот работает против службы, которая его же внедряет.
Правило простое. Умный алёрт активен только в автоматическом установившемся режиме. Переходные окна (пуск N секунд, останов, смена рецепта M минут) - отдельная маска, не «ещё один порог почувствительнее».
Ниже - разбор, который стоит повесить рядом с пилотным сервером. Не список «все причины мира», а те, из-за которых пилоты 2024-2026 года чаще всего выключали.
| Причина ложного алёрта | Как выглядит на тренде | Что сделать с моделью / порогом |
|---|---|---|
| Сезон, Tокр, Tцеха | Медленный уход среднего за недели, «коридор» зимы не покрывает лето | Ковариата температуры или сезонная модель; не один коридор на год |
| Смена рецепта / сорта / частоты | Ступенька задания, новый кластер точек, алёрт в момент переналадки | Маска по коду рецепта и заданию; отдельные базы на режимы |
| Дрейф / калибровка датчика | Медленный сдвиг одного канала без изменения соседних (ток, вибрация) | Сверка с поверкой КИПиА; не учить на смещённом нуле; алёрт на канал измерения, не на «износ» |
| Deadband и редкий опрос | Ступеньки, плоские полки, затем скачок | Отдельный архив для модели; уменьшить deadband на пилотных тегах |
| Дыры, last good, Bad Quality | Плоская линия, затем разрыв формы в момент восстановления связи | Учить только Good; глушить алёрт при Bad; чинить канал, не порог |
| Пуск / стоп / CIP | Короткий выброс на переходном процессе, пачка алёртов к началу смены | Маска переходного окна; не сравнивать пуск с установившимся |
| Ручной режим, force, обход | Траектория «не из регламента», алёрт на работу наладчика | Глушение по тегу режима; вырезать из обучающей выборки |
| Капремонт без переобучения | После замены подшипника «аномалия улучшения» или новая норма как отклонение | Новая базовая линия с даты ремонта; не смешивать до/после в одном окне |
| Слишком узкое окно обучения | Любой штатный разброс дня даёт жёлтый | 2-4 недели в целевом режиме, не 3 суток «чтобы быстрее сдать пилот» |
| Смешение с красной аварией ПЛК | Оператор не отличает стоп от «мнения модели» | Отдельный класс сообщений, ниже приоритет, без звука стопа |
Таблица не заменяет разбор конкретного тега. Она задаёт язык, на котором механик, КИПиА и АСУ могут закрыть алёрт причиной, а не словом «глючит».
Доверие теряется быстрее, чем настраивается модель. Если в первую же ночь умные алёрты падают в тот же список, что и «сухое хода нет», пилот умер. Смена права: она отвечает за линию, а не за эксперимент аналитики.
Рабочая последовательность, которая на средних заводах ещё держится.
Недели 1-2: только запись скора аномалии в архив, без сообщения оператору. Инженер АСУ и механик раз в сутки смотрят 5-10 пиков: ложный / неясный / похоже на дефект.
Недели 3-4: жёлтые только на инженерном экране или в почте ограниченному списку, не на посту. Каждый жёлтый требует комментария из короткого справочника (сезон / рецепт / датчик / пуск / дефект / не ясно).
После того как доля «дефект» стабильно выше согласованного порога (часто начинают с «не больше 30% ложных из разобранных за неделю», затем ужесточают), алёрт можно показать смене. Текст - человеческий: «вибрация P-12 выше базы режима 50 Гц, не авария, осмотреть в смену». Не «Anomaly score 0.87».
Если оператор обходит HMI из-за шума, никакая модель не поможет. Почему так происходит, отдельно разбирали в материале про человеческий фактор на панели. Умный алёрт в этом списке - ускоритель недоверия, если его выкатить сырым.
Даже корректная модель без гистерезиса будет дёргать границу. Скор 0,49 / 0,51 / 0,48 в течение часа - три события в журнале. Для пилота это смертельно.
Ставят persistence: аномалия должна держаться N минут или M циклов опроса. Ставят гистерезис по скору. Ставят эскалацию: сначала тренд на инженерном экране, через 24-48 часов устойчивого отклонения - заявка механику, не пуш каждой минуты.
Квитирование без причины запрещают на пилотных тегах. Иначе статистика ложных обнулится «кнопкой» и вы ничего не узнаете. Короткий список причин обязателен, даже если это пять пунктов в выпадающем списке.
Пересчёт базовой линии - событие, не cron «каждое воскресенье». После капремонта, после смены сорта как постоянного режима, после калибровки датчика. Автоматический weekly retrain на сыром архиве снова смешает CIP с работой и вернёт ложные.
На среднем заводе нет дежурного data scientist. Разбор делят так:
КИПиА - канал измерения, Bad Quality, дрейф, кабель, питание датчика;
механик - осмотр агрегата, смазка, люфт, подшипник, муфта;
АСУ - маска режима, архив, текст сообщения, не попадание в красный список;
технолог - был ли другой рецепт, другая нагрузка, другой продукт.
Если пилот повесили только на АСУ, ложные будут «лечиться» сдвигом порога. Порог уедет, реальный дефект проскочит, пилот объявят бесполезным. Если повесили только на механика, он будет ходить на каждый скачок deadband. Регламент разбора - часть пилота, не «потом, когда заработает».
Успех - не скриншот «модель нашла выброс». Успех - за календарный месяц: число разобранных алёртов, доля ложных с классификацией, число подтверждённых дефектов, число случаев, когда алёрт пришёл раньше технологической аварии. Если подтверждённых ноль, а ложных десятки, модель не готова к смене, сколько бы ни стоил модуль.
Неуспех, который маскируют: отключили звук, оставили виджет для директора. Формально пилот «внедрён». Фактически смена работает как раньше. Через год на совещании снова спросят, «где предиктив».
Связка с OEE полезна как проверка, не как цель пилота. Если умный алёрт стабильно предваряет падение готовности на конкретном агрегате - это аргумент оставить систему. Если OEE скачет из-за грязного справочника простоев, не пришивайте к нему ML. Сначала данные смен, потом аномалии.
Обучить на всём архиве «как есть». В выборку попадают остановы, дыры, ручной режим и прошлогодний другой сорт. Модель либо слишком широкая, либо истерит на штатных пусках.
Показать смене в первую ночь. Один шквал ложных - и модуль в чёрном списке на год, даже после донастройки.
Смешать умный алёрт с аварией ПЛК. Красный стоп и «мнение модели» в одном списке с одним звуком. Оператор выбирает игнорировать оба.
Не дать расшифровку на тренде. Сообщение без участка графика, без режима, без тега. Разбор занимает 20 минут, на которые ни у кого нет времени.
Лечить ложные только порогом. Без маски рецепта порог либо душит чувствительность, либо оставляет пачку переналадок.
Забыть про датчик. Алгоритм честный: канал уехал. Виноват не подшипник. Без строки «проверить КИПиА» механик зря выходит в поле.
Автопереобучение каждую неделю. Новая «норма» включает последние ложные и забывает старый дефект, который как раз начал расти.
Метрика «число аномалий». Подрядчик гордится сотней событий. Эксплуатация видит сотню ложных. Считайте долю подтверждённых.
Можно ли включить умный алёрт без года архива?
Да, если есть 2-4 недели целевого режима с качественной записью и масками. Год грязной истории хуже короткого чистого окна. Для сезонных контуров короткий пилот летом не заменяет проверку зимой.
Нужна ли нейросеть, если хватает статистического коридора по режимам?
На насосе с одним режимом часто хватает коридора mean/sigma или процентилей плюс маска пуска. Multivariate и ML оправданы, когда режимов много и простой порог не различит сорт. Сложность модели не лечит грязный архив.
Куда вешать сообщение: локальный HMI или диспетчерская SCADA?
Пока пилот сырой - только инженерский контур. На операторский HMI - после снижения ложных и с текстом без жаргона модели. Приоритет ниже технологической аварии.
Что делать с алёртом во время калибровки датчика?
Глушить по наряду / тегу сервиса на время работ. После калибровки - новая база, не старый коридор.
Как отличить дрейф датчика от износа агрегата?
Смотреть соседние каналы: ток, вибрация, давление, температура подшипника. Уехал один аналог при стабильных остальных - сначала КИПиА. Уезжают согласованно несколько независимых измерений - механика.
Стоит ли слать умный алёрт в мессенджер смены?
Не на пилоте. Сначала журнал и разбор. Иначе усталость от пушей убьёт канал, который ещё пригодится для настоящих аварий.
Когда переобучать после ремонта?
С даты, когда агрегат вышел на установившийся режим, не с момента пуска «на холодную». Старые дни до ремонта в новую базу не мешать.