import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';
import Cards from '@/components/docs/Cards.astro';
import Card from '@/components/docs/Card.astro';
**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.
```mermaid
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"]
```
OHM nije samostalan izveštaj i ne zamenjuje ni sistem SCADA, ni telemetrijski sistem, ni
specijalizovane analitičke dodatke (plugin). Podsistem koristi njihove rezultate kao izvore dokaza
i uspostavlja jedinstven operativni proces upravljanja radom na terenu.
## 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.
```mermaid
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:
```mermaid
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.
```mermaid
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.
```mermaid
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:
| Sloj | Komponente |
| -------------------------------- | ---------------------------------------------------------------- |
| Fizički objekti | merila, korektori, senzori, mrežni prolazi, armatura |
| Sloj IIoT podataka i integracije | telemetrija, arhive, registar, pasoši, događaji |
| Analitika i detekcija | detektori kanonskih problema, detaljni izveštaji, AI, korelacija |
| Operational Health Matrix | Issues, Tasks, SLA, verifikacija, KPI, baza znanja |
| Poslovni sistemi preduzeća | ERP, EAM, CMMS, Service Desk, BI, obaveštenja |
### 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:
| Izvor dokaza | Šta isporučuje podsistemu OHM |
| ---------------------------------- | ------------------------------------------------------------------- |
| Matrica problema parka uređaja | kanonski problemi i dnevni statusi |
| Analitika satne arhive | potpunost, praznine, praznina na kraju perioda, pouzdanost podataka |
| Analiza sesija | trajanje, učestalost, anomalije komunikacije |
| Analiza pritiska | vrednosti van opsega, skokovi, zaglavljena očitavanja |
| Analiza temperature | anomalije, neslaganja, fizička verodostojnost |
| Sumnja na neovlašćenu manipulaciju | forenzički signali i nivo pouzdanosti |
| Analiza baterija | trend, pragovi, prognoza preostalog veka trajanja |
| Kontrola pasoša | nedostajući i protivrečni parametri |
| Kontrola registra | duplikati, fantomski objekti, neusaglašenosti identifikatora |
| Analitika firmvera | klasteri problema po verzijama softvera |
## Upoznajte podsistem