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.

Спершу першопричина (Root Cause)

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

Будь-який аналітичний модуль платформи може виступати джерелом доказів.

Приклади:

Вивчіть модуль