Operational Health Matrix (OHM)

Operational Health Matrix (OHM) — центральный операционный модуль IIoT Платформы. Он преобразует поток телеметрии, результаты аналитики и эксплуатационные события в управляемый цикл работ: от автоматического обнаружения проблемы до подтверждённого данными устранения.

OHM объединяет в единой системе:

• детектирование технических, метрологических и интеграционных проблем;
• корреляцию симптомов и определение вероятной первопричины;
• создание и ведение объектов Operational Issue;
• назначение ответственных подразделений и исполнителей;
• управление сроками, приоритетами и SLA;
• ведение задач, комментариев, доказательств и истории действий;
• автоматическую верификацию результата по новым данным;
• управление массовыми инцидентами;
• оценку состояния оборудования и парка;
• расчёт эксплуатационных и командных KPI;
• накопление подтверждённых решений в базе знаний;
• AI-поддержку анализа без передачи искусственному интеллекту права принятия критических решений.

flowchart TD
  A["Телеметрия"] --> B["Детекторы"]
  B --> C["Evidence"]
  C --> D["Корреляция и Root Cause"]
  D --> E["Operational Issue"]
  E --> F["Назначение и выполнение"]
  F --> G["Верификация по данным"]
  G --> H["Закрытие и Knowledge Base"]
  H --> I["KPI и непрерывное улучшение"]

Назначение модуля

Традиционные системы телеметрии хорошо отвечают на вопрос:

Что произошло с устройством или данными?

Но для управления большим парком этого недостаточно. После обнаружения события организация должна определить:

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

OHM закрывает весь этот цикл.

Основной результат работы модуля — не уведомление и не строка отчёта, а управляемый эксплуатационный объект, который имеет:

• идентификатор;
• тип проблемы;
• затронутые активы;
• доказательства;
• критичность;
• уровень уверенности;
• вероятную и подтверждённую первопричину;
• владельца;
• исполнителя;
• срок;
• задачи;
• историю;
• состояние верификации;
• итог устранения;
• связь с базой знаний;
• влияние на KPI.

Ключевое преимущество

Платформа не ограничивается фиксацией отклонений. Платформа сопровождает проблему до подтверждённого результата.

flowchart TD
  subgraph OPS["IIoT Платформа и OHM"]
    direction TB
    O1["Обнаружила проблему"] --> O2["Проверила доказательства"]
    O2 --> O3["Объединила связанные сигналы"]
    O3 --> O4["Определила приоритет"]
    O4 --> O5["Назначила ответственную зону"]
    O5 --> O6["Контролирует срок"]
    O6 --> O7["Проверила результат по данным"]
    O7 --> O8["Сохранила подтверждённое решение"]
  end
  subgraph MON["Система мониторинга"]
    direction TB
    M1["Обнаружила проблему"] --> M2["Работа системы закончена"]
  end

Благодаря этому OHM переводит эксплуатацию из реактивного режима в управляемую модель, где каждое существенное отклонение имеет владельца, срок, доказательства и измеримый результат.

Основные принципы

Issues вместо тревог

Одиночная тревога не всегда равна эксплуатационной проблеме.

Один физический отказ может сформировать десятки или сотни событий:

• нет сеанса связи;
• нет архива;
• устаревшие данные;
• неизвестно состояние батареи;
• нет текущего давления;
• ошибка доставки.

OHM не создаёт отдельную задачу на каждый симптом. Система коррелирует сигналы и формирует один Operational Issue, если они относятся к общей причине.

Операции на основе доказательств

Каждый автоматический вывод должен быть объясним.

Issue содержит:

• исходные значения;
• временные метки;
• идентификатор детектора;
• версию алгоритма;
• применённые пороги;
• ссылку на профильный специализированный отчёт;
• историю повторений;
• связанные сигналы;
• результат корреляции.

Пользователь всегда может проследить путь от исходной телеметрии до созданного Issue.

Сначала первопричина

OHM различает:

• симптом — наблюдаемое отклонение;
• причину — технический или организационный фактор, который породил отклонение;
• корневую причину — первичный фактор, устранение которого предотвращает повторение группы симптомов.

Пример:

flowchart LR
  S1["Симптом 1: отсутствует часовой архив"] --> RC["Вероятная первопричина: деградация источника питания"]
  S2["Симптом 2: последний сеанс был 9 дней назад"] --> RC
  S3["Симптом 3: напряжение батареи снижалось"] --> RC
  S4["Симптом 4: длительность сеансов увеличивалась"] --> RC

Закрытие с подтверждением данными

Исполнитель сообщает, что работа выполнена, но окончательный статус resolved устанавливается только после проверки результата.

flowchart TD
  V1["Работа выполнена"] --> V2["awaiting_verification"]
  V2 --> V3["Новые данные подтверждают нормализацию"]
  V3 --> V4["resolved"]

Для проблем, которые нельзя проверить телеметрией, применяется контролируемая ручная верификация с обязательным комментарием и доказательством.

Актив в центре модели

Все события, Issues, работы и показатели связываются с активами:

• узлом учёта;
• корректором;
• счётчиком;
• датчиком;
• модемом;
• шлюзом;
• SIM-картой;
• серверным компонентом;
• интеграционным каналом;
• программной версией.

Карточка актива показывает текущее здоровье, историю деградации, активные Issues, выполненные работы и повторяемость проблем.

Ответственность на человеке, AI помогает

AI помогает:

• суммировать Evidence;
• ранжировать гипотезы;
• находить похожие случаи;
• предлагать известные решения;
• выявлять новые кластеры;
• прогнозировать риск отказа.

AI не может самостоятельно:

• менять приоритет;
• назначать ответственность;
• закрывать Issue;
• подтверждать root cause как установленный факт;
• изменять SLA;
• выполнять критические действия на оборудовании.

Воспроизводимость по построению

Все значимые расчёты воспроизводимы. Для каждого результата платформа сохраняет:

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

Место OHM в архитектуре IIoT Платформы

OHM расположен между аналитическим слоем и эксплуатационным управлением.

flowchart TD
  PHY["Физические активы"] --> DATA["Слой данных и интеграции IIoT"]
  DATA -->|"Нормализованные данные"| ANL["Аналитика и детектирование"]
  ANL -->|"Evidence и результаты анализа"| OHM["Operational Health Matrix"]
  OHM -->|"API, события, интеграция"| ENT["Корпоративные системы"]

Состав слоёв:

Источники данных

OHM использует:

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

Поставщики Evidence

Любой аналитический модуль платформы может выступать источником доказательств.

Примеры:

Изучите модуль