Задача: чинить до поломки, а не после
Типовая ситуация завода: обслуживание — по часам наработки («по регламенту»), но внезапные отказы всё равно случаются, а аварийный простой критичной линии стоит на порядки дороже плановой замены узла. Вдобавок регламентное обслуживание меняет исправные узлы «потому что так в графике». Служба главного механика хочет другого: видеть приближающийся отказ заранее, понимать вероятную причину и успевать вмешаться в плановое окно.
Есть и «знаниевая» часть проблемы: опыт каких отказов и симптомов живут в голове ветеранов и в бумажных журналах ремонтов — и теряется с их уходом. Контур должен этот опыт вернуть в работу: симптом → вероятная причина → что делали в похожих случаях.
Почему это сложно
Первая сложность — данные рассеяны и шумны: телеметрия в SCADA, журналы ремонтов на бумаге или в Excel, режимы работы меняются вручную; без сведения источников модель видит шум. Вторая — отказы редкие: классы событий, которые предсказываем, представлены единицами эпизодов в истории — классическое «обучение на дисбалансе», требующее аномалий-детекции вместо прямого классификатора. Третья — доверие эксплуатационщиков: алерт без объяснения, почему «пора», игнорируется; объяснение обязано опираться на журнал похожих случаев. Четвёртая — интеграция с процессом: прогноз без заявки в 1С:ТОиР и приоритезации остаётся картинкой; контур обязан доводить сигнал до действия.
Архитектура: от датчика до заявки
Архитектура контура предиктивного обслуживания (текстовая схема)
Оборудование: SCADA/АСУТП · датчики вибрации/температуры/тока · счётчики
│ сбор и буферизация (разрывы связи не теряют данные)
▼
Хранилище временных рядов + журнал ремонтов (оцифровка историй!)
▼
Аналитический слой (FastAPI-сервисы):
1) детекция аномалий — без разметки, «поведение изменилось»
2) прогноз остаточного ресурса узла (где хватает истории отказов)
3) LLM-объяснение: аномалия + журнал ремонтов + режим работы
→ «вероятная причина, похожие случаи: …» (строгий шаблон)
▼
Действие: заявка в 1С:ТОиР с приоритетом · дашборд Гл. механика
▼
Обратная связь: подтверждён/не подтверждён отказ ──► дообучение
(каждый эпизод пополняет историю — контур умнеет от работы)
Инженерные решения. Сервисный слой строится по паттернам «FastAPI-оркестрации ИИ-сервисов»: сбор, детекция, прогноз и объяснение — отдельные сервисы с независимым масштабированием. Ядро прогноза — классические ML-методы на признаках временных рядов; LLM здесь не «предсказывает вибрацию», а объясняет: сводит текущую аномалию с оцифрованным журналом ремонтов и выдаёт механику перечень похожих случаев — со ссылками на даты и узлы. Визуальная часть — дашборды в BI-инструменте (наш типовой выбор — «BI АХРОМА с ИИ»); заявки уходят в 1С:ТОиР — паттерны интеграции разобраны в кейсе «GigaChat в 1С-процессе».
Этапы внедрения
| Этап | Что получается | Бюджет | Срок |
|---|---|---|---|
| Аудит парка и данных | карта критичного оборудования, доступность телеметрии, оцифровка журналов ремонтов, план пилота | от 90 000 ₽ | 1–2 недели |
| Пилот на критичном узле | мониторинг и алерты по одному узлу/линии, первые спрогнозированные события, сравнение с базовой линией простоев | от 480 000 ₽ | 4–6 недель |
| Промышленный контур | все критичные узлы, интеграция с 1С:ТОиР, роли, регламент реагирования | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | дообучение на новых эпизодах, контроль ложных алертов, расширение парка | по регламенту | — |
Бюджеты — прайс НЬЮ-ССТ на сентябрь 2026, «от», без НДС (УСН, п. 2 ст. 346.11 НК РФ). Сроки — типовые вилки проектов этого класса.
Типовые метрики «до/после»
Ниже — типовые вилки результатов внедрений предиктивного обслуживания этого класса, а не отчёт конкретного завода. Базовая линия — статистика простоев и ремонтов за сопоставимый период до внедрения, по тем же узлам.
- Внеплановые простои критичного оборудования: типовое снижение на 20–45% за счёт вмешательства в плановые окна.
- Затраты на ремонты и запчасти: −10–30% — аварийные ремонты дороже плановых всегда.
- Заблаговременность предупреждения: от часов до недель в зависимости от узла; фиксируется по каждому спрогнозированному событию.
- Ложные алерты: после калибровки — единицы процентов от общего числа; каждый разбор обратной связи снижает их дальше.
- Использование опыта ремонтников: журнал случаев в контуре — поиск похожей ситуации занимает секунды, а не «спросить Петровича».
Безопасность: периметр АСУТП и ИИ-актив
Правило номер один: аналитический контур читает телеметрию, но не вмешивается в управление — связь с АСУТП однонаправленная через демилитаризованную зону; никаких команд из аналитики в управление. Данные о режимах и отказах — производственная тайна: контур внутри периметра предприятия, внешние API не используются, LLM-объяснения работают на локальных моделях (обзор — «Ollama: локальный LLM»). Накопленная история отказов и обученные модели — ИИ-актив завода, который инвентаризируется и защищается по 243-ФЗ вместе с доступами к нему — практика в кейсе «Защита ИИ-активов по 243-ФЗ».
Об этом разборе. Это обезличенное типовое внедрение из нашей практики проектирования: имена заводов не раскрываются (NDA), метрики даны типовыми вилками класса проектов; фактические значения фиксируются в КП и на приёмке — по конкретным узлам, с базовой линией до внедрения.