Operational Health Matrix (OHM)

Operational Health Matrix (OHM) je centralni operativni podsistem povezan sa podsistemom Data Platform. OHM pretvara tok telemetrijskih podataka, rezultate analitike i operativne događaje u upravljani radni ciklus: od automatskog otkrivanja problema do rešenja potvrđenog podacima.

U jedinstvenom sistemu OHM objedinjuje:

• otkrivanje tehničkih, metroloških i integracionih problema;
• korelaciju simptoma i utvrđivanje verovatnog osnovnog uzroka (Root Cause);
• kreiranje i vođenje operativnih problema (Operational Issue);
• određivanje odgovornih timova i izvršilaca;
• upravljanje rokovima, prioritetima i sporazumima o nivou usluge (SLA);
• praćenje zadataka (Tasks), komentara, dokaza (Evidence) i istorije radnji;
• automatsku verifikaciju rezultata na osnovu novih podataka;
• upravljanje masovnim incidentima (Massive Incidents);
• ocenu stanja opreme i parka uređaja;
• izračunavanje ključnih pokazatelja učinka (KPI) operativnog rada i timova;
• prikupljanje potvrđenih rešenja u bazi znanja (Knowledge Base);
• analizu uz podršku veštačke inteligencije (AI), bez prenošenja ovlašćenja za donošenje kritičnih odluka na AI.

flowchart TD
  A["Telemetrija"] --> B["Detectors"]
  B --> C["Evidence"]
  C --> D["Korelacija i Root Cause"]
  D --> E["Operational Issue"]
  E --> F["Dodela i izvršenje"]
  F --> G["Verifikacija na osnovu podataka"]
  G --> H["Zatvaranje i Knowledge Base"]
  H --> I["KPI i stalno poboljšavanje"]

Svrha podsistema

Klasični telemetrijski sistemi dobro odgovaraju na pitanje:

Šta se dogodilo sa uređajem ili sa podacima?

Za upravljanje velikim parkom uređaja to, međutim, nije dovoljno. Kada se događaj otkrije, organizacija mora da utvrdi:

• da li signal predstavlja stvaran problem;
• da li pogađa jedan uređaj ili je reč o incidentu na nivou celog sistema;
• koji su još simptomi povezani sa istim osnovnim uzrokom;
• ko je odgovoran za rešavanje;
• do kada radovi moraju da budu završeni;
• koje su radnje već preduzete;
• da li je rešenje potvrđeno objektivnim podacima;
• da li se problem ponavlja;
• koliko je operativni proces delotvoran.

OHM zatvara ceo taj ciklus.

Glavni rezultat rada podsistema nije ni obaveštenje ni red u izveštaju, već operativni entitet kojim se upravlja i koji ima:

• identifikator;
• tip problema;
• pogođene objekte (Assets);
• dokaze;
• ozbiljnost (Severity);
• nivo pouzdanosti;
• verovatan i potvrđen osnovni uzrok;
• odgovorno lice;
• izvršioca;
• rok;
• zadatke;
• istoriju;
• status verifikacije;
• ishod rešavanja;
• vezu sa bazom znanja;
• uticaj na KPI.

Ključna prednost

Platforma se ne zaustavlja na beleženju odstupanja. Platforma prati problem sve do potvrđenog rezultata.

flowchart TD
  subgraph OPS["Data Platform i OHM"]
    direction TB
    O1["Otkrio problem"] --> O2["Proverio dokaze"]
    O2 --> O3["Objedinio povezane signale"]
    O3 --> O4["Odredio prioritet"]
    O4 --> O5["Dodelio zonu odgovornosti"]
    O5 --> O6["Prati rok"]
    O6 --> O7["Verifikovao rezultat na osnovu podataka"]
    O7 --> O8["Sačuvao potvrđeno rešenje"]
  end
  subgraph MON["Sistem praćenja"]
    direction TB
    M1["Otkrio problem"] --> M2["Ovde se rad sistema završava"]
  end

Zahvaljujući tome, OHM prevodi operativni rad iz reaktivnog režima u upravljani model u kome svako značajno odstupanje ima odgovorno lice, rok, dokaze i merljiv ishod.

Osnovni principi

Problemi umesto alarma

Pojedinačni alarm nije uvek isto što i operativni problem.

Jedan fizički kvar može da izazove desetine ili stotine događaja:

• nema komunikacione sesije;
• nema arhive;
• zastareli podaci;
• nepoznato stanje baterije;
• nema trenutne vrednosti pritiska;
• greška pri isporuci.

OHM ne kreira posebnu radnu stavku za svaki simptom. Sistem korelira signale i, kada oni imaju zajednički uzrok, kreira jedan Operational Issue.

Rad zasnovan na dokazima

Svaki automatski zaključak mora da bude objašnjiv.

Problem (Issue) sadrži:

• izvorne vrednosti;
• vremenske oznake;
• identifikator detektora;
• verziju algoritma;
• primenjene pragove;
• link ka odgovarajućem specijalizovanom izveštaju;
• istoriju ponavljanja;
• povezane signale;
• rezultat korelacije.

Korisnici uvek mogu da prate put od sirovih telemetrijskih podataka do kreiranog problema.

Najpre osnovni uzrok

OHM razlikuje:

• simptom – uočeno odstupanje;
• uzrok – tehnički ili organizacioni faktor koji je izazvao odstupanje;
• osnovni uzrok – primarni faktor čije otklanjanje sprečava ponavljanje grupe simptoma.

Primer:

flowchart LR
  S1["Simptom 1: nedostaje satna arhiva"] --> RC["Verovatan osnovni uzrok: degradacija izvora napajanja"]
  S2["Simptom 2: poslednja sesija bila je pre 9 dana"] --> RC
  S3["Simptom 3: napon baterije je opadao"] --> RC
  S4["Simptom 4: sesije su trajale sve duže"] --> RC

Zatvaranje potvrđeno podacima

Izvršilac prijavljuje da je posao završen, ali se konačni status resolved postavlja tek kada rezultat bude verifikovan.

flowchart TD
  V1["Posao završen"] --> V2["awaiting_verification"]
  V2 --> V3["Novi podaci potvrđuju normalizaciju"]
  V3 --> V4["resolved"]

Kod problema koji se ne mogu verifikovati na osnovu telemetrije primenjuje se kontrolisana ručna verifikacija, uz obavezan komentar i prateće dokaze.

Pogled usmeren na objekte

Svi događaji, problemi, radne stavke i metrike vezuju se za objekte:

• merna mesta;
• korektore;
• merila;
• senzore;
• modeme;
• mrežne prolaze;
• SIM kartice;
• serverske komponente;
• integracione kanale;
• verzije softvera.

Karton objekta prikazuje trenutno stanje (Asset Health), istoriju degradacije, aktivne probleme, završene radove i ponavljanje problema.

Čovek odgovara, AI pomaže

AI pomaže da se:

• sažmu dokazi;
• rangiraju hipoteze;
• pronađu slični slučajevi;
• predlože poznata rešenja;
• otkriju novi klasteri;
• predvidi rizik od otkaza.

AI ne može samostalno da:

• promeni prioritet;
• dodeli odgovornost;
• zatvori problem;
• potvrdi osnovni uzrok kao utvrđenu činjenicu;
• izmeni SLA rokove;
• izvrši kritične radnje na opremi.

Ugrađena ponovljivost

Svi značajni proračuni su ponovljivi. Za svaki rezultat platforma čuva:

• verziju detektora;
• verziju kanonskog problema (Canon);
• verziju modela korelacije;
• korišćeni skup podataka;
• vreme proračuna;
• pragove;
• konfiguraciju;
• izvor izmene.

OHM u arhitekturi podsistema Data Platform

OHM se nalazi između analitičkog sloja i upravljanja operativnim radom.

flowchart TD
  PHY["Fizički objekti"] --> DATA["Sloj IIoT podataka i integracije"]
  DATA -->|"Normalizovani podaci"| ANL["Analitika i detekcija"]
  ANL -->|"Evidence i nalazi"| OHM["Operational Health Matrix"]
  OHM -->|"API, događaji, integracija"| ENT["Poslovni sistemi preduzeća"]

Sadržaj slojeva:

Izvori podataka

OHM koristi:

• trenutnu telemetriju;
• satne i dnevne arhive i arhive događaja;
• dnevnike komunikacionih sesija;
• podatke iz pasoša i registra;
• statuse uređaja;
• podatke o baterijama;
• pritisak, temperaturu, protok i zapreminu;
• događaje neovlašćene manipulacije;
• verzije firmvera;
• parametre komunikacije;
• rezultate specijalizovanih izveštaja;
• ručno unesena zapažanja korisnika;
• događaje iz spoljnih sistema.

Izvori dokaza

Svaka analitička funkcija platforme može da bude izvor dokaza.

Primeri:

Upoznajte podsistem