De la un registru Modbus la decizia managementului

Să presupunem că citim următoarea valoare brută din unul dintre registrele Modbus ale unui contor industrial de putere electrică:

registru: 40001
valoare:  23871

Am terminat, așadar, cu digitalizarea industrială?

De fapt, nici nu am început cu adevărat.

23871 nu este mai mult decât un șir de cifre. Pentru a putea fundamenta o decizie pe el, trebuie să știm ce înseamnă, de unde provine, când a fost valabil, cât de fiabil este, cui aparține, față de ce este considerat anormal și ce trebuie să se întâmple dacă există într-adevăr o problemă.

Să urmărim întregul traseu al datelor.

1. Citirea corectă a registrului

Pe baza documentației Modbus trebuie stabilite:

• codul de funcție utilizat;
• adresa reală a registrului;
• tipul de date;
• interpretarea cu semn sau fără semn;
• ordinea octeților și a cuvintelor;
• factorul de scalare;
• unitatea de măsură;
• indicatorii de validitate și de eroare.

Chiar și notația 40001 poate genera confuzii. Unele documentații folosesc o numerotare „umană”, altele o adresă de protocol care pornește de la zero. O singură deplasare de adresă poate face ca, în locul puterii, să citim un registru învecinat.

Să presupunem că, potrivit documentației, valoarea este un întreg pe 16 biți fără semn, cu o scalare de 1 W. Atunci:

23871 → 23.871 W → 23,871 kW

Acum valoarea are o semnificație fizică. Dar încă nu are un context de business.

2. Identitatea dispozitivului și marca temporală

Datele trebuie asociate unui anumit contor și unui anumit punct de măsurare. Adresa IP sau identificatorul de unitate Modbus (unit ID) nu sunt suficiente, deoarece se pot schimba sau se pot repeta în mai multe locații.

Este nevoie de un identificator stabil al dispozitivului și al punctului de măsurare, precum și de o marcă temporală fiabilă. Sistemul trebuie să distingă totodată:

• când a avut loc măsurarea;
• când a citit-o gateway-ul;
• când a ajuns în sistemul central.

După o întrerupere a rețelei, datele stocate anterior în buffer pot sosi mai târziu. Dacă se stochează doar momentul sosirii, imaginea istorică se decalează, iar regulile o pot evalua greșit.

3. Calitatea și validitatea datelor

Nu orice număr citit este o măsurătoare reală. Poate fi ultima valoare cunoscută după o eroare de comunicație, o depășire (overflow), o stare din timpul pornirii dispozitivului sau un cod de eroare documentat.

De aceea, datelor li se poate atașa un indicator de calitate:

quality: good | uncertain | bad
source: live | buffered | estimated

O regulă de business nu poate trata la fel o măsurătoare live verificată și o valoare estimată, incertă. Acest lucru este deosebit de important într-un proces de facturare sau de reglaj.

4. Mesaj normalizat

Gateway-ul transformă valoarea din teren într-un model de date unitar. De exemplu:

{
  "site_id": "site-etyek-01",
  "asset_id": "compressor-03",
  "measurement": "active_power",
  "value": 23.871,
  "unit": "kW",
  "measured_at": "2026-09-14T06:32:10Z",
  "quality": "good"
}

Din acest punct, procesarea centrală nu mai trebuie să cunoască harta de registre specifică producătorului pentru fiecare contor. Diferențele din teren sunt gestionate de gateway și de profilul dispozitivului, iar platforma lucrează cu concepte unitare.

5. Transmitere securizată și stocare tampon

Mesajul ajunge la sistemul de procesare printr-o conexiune controlată. La proiectarea comunicației trebuie definite autentificarea, criptarea, autorizarea, structura de topicuri sau de endpointuri, relivrarea și tratarea erorilor.

Dacă conexiunea se întrerupe, gateway-ul poate stoca datele local și le poate transmite ulterior cu momentul original al măsurării. Sistemul central trebuie să gestioneze mesajele care sosesc cu întârziere și, eventual, de mai multe ori.

Nu este o funcție spectaculoasă. Dar fără ea graficul are goluri, decontarea poate fi contestată, iar modelul învață din date eronate.

6. Stocare și context de business

Măsurătoarea de 23,871 kW ajunge într-o bază de date de serii temporale. În paralel, din datele de bază ale platformei se știe despre compressor-03:

• în ce locație se află;
• cărei linii tehnologice îi aparține;
• pe ce centru de cost este înregistrat;
• cine este responsabilul de exploatare;
• ce putere nominală are;
• când a fost întreținut ultima dată;
• ce contract sau proiect îl vizează.

Abia acum punctul de măsurare devine parte a funcționării companiei.

7. Interpretarea numărului

Să presupunem că, în acest moment, compresorul funcționează în gol. Potrivit datelor istorice, în această stare este obișnuită o putere între 12 și 15 kW. Valoarea de 23,871 kW este interesantă nu pentru că ar fi în sine un număr mare, ci pentru că reprezintă o abatere semnificativă față de starea de funcționare respectivă.

Regula sau modelul de detectare a anomaliilor poate lua în considerare:

• starea de funcționare;
• valoarea de referință (baseline) a perioadei anterioare;
• temperatura exterioară;
• valoarea presiunii;
• durata abaterii;
• indicatorul de calitate al senzorului.

De exemplu, un eveniment este generat doar dacă puterea la mers în gol rămâne peste 20 kW timp de cel puțin 20 de minute. Astfel, un vârf momentan nu declanșează o alarmă inutilă.

8. De la eveniment la sarcină

Sistemul creează evenimentul:

Tip:           consum ridicat de energie la mers în gol
Echipament:    compresorul nr. 3
Prioritate:    medie
Responsabil:   mentenanța locației
Termen:        24 de ore
Dovezi:        trend, stare de funcționare, măsurători conexe

Din eveniment se poate genera automat o comandă de lucru. La fața locului, tehnicianul de mentenanță vede datele echipamentului, istoricul acestuia și curba care susține semnalarea. În timpul verificării consemnează că, din cauza unei supape care nu se închidea corect, instalația funcționa inutil chiar și fără sarcină.

9. Intervenție și verificare ulterioară

După repararea supapei, sistemul nu se limitează la închiderea sarcinii. Compară noul consum la mers în gol cu starea anterioară.

Să presupunem că valoarea revine la 13,5 kW. Diferența este de aproximativ 10,4 kW ori de câte ori mașina funcționează în gol.

La 120 de astfel de ore de funcționare pe lună, economia estimată este:

10,4 kW × 120 h = 1.248 kWh/lună

Pe baza costului intern sau de achiziție actual al energiei se poate calcula de aici impactul financiar. Astfel, sistemul documentează nu doar faptul că „am reparat supapa”, ci și ce rezultat energetic și financiar a adus intervenția.

10. Decizia managementului

Dintr-un singur caz nu rezultă neapărat o strategie. Dacă însă aceeași platformă gestionează evenimente similare din mai multe locații și echipamente, conducerea poate primi răspunsuri la întrebări precum:

• ce tip de echipament provoacă cele mai mari pierderi;
• unde se amortizează cel mai repede monitorizarea instrumentată a stării;
• care locație reacționează cel mai rapid;
• câtă economie dovedită au adus intervențiile;
• ce echipamente merită renovate sau înlocuite;
• ce proiect-pilot merită extins la nivelul întregii companii.

Managerul nu mai vede registrul 40001. Vede ce cost a generat o problemă tehnică măsurabilă, cum a fost tratată, în cât timp a fost închisă și ce rezultat s-a obținut.

Surse

• Modbus Organization – Technical Resources
• OASIS MQTT Version 5.0
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – Sistem de operare pentru afaceri, bazat pe web