Пример структуры кодов — отказ, причина, действие, обнаружение

Автор статьи: Антон Орлов Главный специалист по развитию системы управления надежности, Группа цифрового развития ТОиР, ПАО «Северсталь»

Чтобы анализировать отказы не «на глаз», а системно, нужно, чтобы каждое сообщение о неисправности / отказе «говорило» на одном языке: что отказало, почему, что сделали и как обнаружили. Ниже — пример такой структуры на абстрактной технологической линии и как это реализуется в системе и в ПО «Надёжность» / ПО «Мониторинг и Диагностика».

1. Четыре группы кодов

Минимальный набор справочников для нормальной аналитики:

• Код отказа — что конкретно вышло из строя и в каком режиме.
• Код причины — из‑за чего отказ произошёл.
• Код действия — что было выполнено для устранения.
• Код обнаружения — как отказ был выявлен.

Важно: это не свободный текст, а выбор из заранее подготовленных списков для конкретного класса оборудования.

2. Пример для технологической линии

Представим линию упаковки: конвейер, редуктор, электродвигатель, датчики, рольганги.

2.1. Коды отказа (узел + режим)

Уровень 1 — узел:

• DV — электродвигатель
• RD — редуктор
• MU — муфта
• CN — конвейерная лента
• DT — датчик (концевик, фото, т. п.)

Уровень 2 — режим отказа (пример):

• IZ — износ
• TL — течь
• LU — люфт
• ZA — заклинивание
• PR — проскальзывание
• OT — перегрев

В сообщении о неисправности / отказе это может выглядеть так:

• Код отказа: RD IZ (редуктор — износ),
• или MU LU (муфта — люфт).
  
  

2.2. Коды причины

Примеры:

• NSM — недостаток смазки
• PRG — перегрузка по моменту
• NSO — несоосность валов
• MNT — ошибка монтажа / сборки
• EXP — превышение условия эксплуатации (температура, пыль и т. п.)
• OPR — ошибка оператора (неправильный режим, удары и т. д.)

В сообщении о неисправности / отказе:

• Код причины: NSM (нет смазки) или NSO (несоосность).
  
  

2.3. Коды действия

Примеры:

• ZAM — замена узла / детали
• REG — регулировка / наладка
• SMZ — смазка / долив масла
• CHS — очистка / промывка
• UKR — укрепление крепежа
• MOD — доработка / изменение конструкции

В сообщении о неисправности / отказе:

• Код действия: ZAM (замена), REG (регулировка), SMZ (смазка).
  
  

2.4. Коды обнаружения

Примеры:

• OPRN — оператор заметил визуально / на слух
• OBH — обход/осмотр персоналом
• PLAN — плановое техническое обслуживание
• VIB — вибродиагностика
• TEMP — тепловизионный контроль
• DAT — сигнал от датчика / системы мониторинга

В сообщении о неисправности / отказе:

• Код обнаружения: VIB (по вибрации) или OPRN (заметил оператор).
  
  

3. Как это выглядит в системе при закрытии наряда

Представьте экран сообщения о неисправности / отказе редуктора конвейера:

1. Поле «Оборудование» — выбрана линия УП 01, редуктор RD 01.

2. Ниже блок «Результаты выполнения»:

• Код отказа (обязателен): выпадающий список, отфильтрованный по классу «редукторы».
  Мастер выбирает: RD IZ — «редуктор, износ зубьев».
• Код причины (обязателен для внеплановых ремонтов): список причин.
  Выбор: NSM — «недостаток смазки» или PRG — «перегрузка».
• Код действия (обязателен):
  Выбор: ZAM — «заменён редуктор в сборе» или REG — «регулировка зазора, долив масла».
• Код обнаружения (желательно обязательный):
  Выбор: VIB — «обнаружено по вибродиагностике» или OPRN — «жалоба оператора на шум».

3. Для кода «прочее» во всех выпадающих списках система требует обязательно заполнить комментарий (не менее N символов) для последующего анализа справочника.

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

4. Как это реализовано в ПО «Надёжность» / ПО «Мониторинг и Диагностика»

В отраслевых решениях «Северстали» логика примерно такая:

1. Справочники по классам оборудования

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

2. Привязка к объекту

При выборе оборудования система заранее знает его класс и подставляет соответствующие списки кодов (как в примере с линией упаковки).

3. Обязательность и проверки

• Обработать сообщение о неисправности / отказе без заполнения кода отказа и действия нельзя.
• Для кода «прочее» обязателен комментарий.
• Периодически автоматически считаются показатели качества данных: доля «прочее», незаполненных полей и т. п.

4. Интеграция с SAP

Из SAP приходят либо сами коды, либо их агрегированная проекция (например, только отказ и причина), а полный анализ ведётся в «Надёжности» / ПО «Мониторинг и Диагностика». Там через отчёты и панели можно посмотреть:

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

5. Связь с анализом надёжности

Справочники кодов связаны с матрицами видов отказов и последствий: один режим отказа в FMECA соответствует набору кодов в нарядах. Это позволяет замыкать цикл: модель → факт → пересмотр модели.

5. Что это даёт на практике

• Мастеру — быстрый и понятный выбор (несколько десятков осмысленных кодов по его оборудованию, а не хаотичный длинный список).
• Инженеру по надёжности — «строительные блоки» для анализа: таблицу «отказ–причина–действие–обнаружение» по всей линии или заводу.
• Цифровым решениям и моделям прогноза — чистую разметку: на что смотреть в датчиках и к какому типу отказа это в итоге привело.

Схема простая: один раз потратились на настройку справочников и обязательных полей — потом каждый наряд работает как маленький кейс, который учит систему становиться надёжнее.