Nivelul de colectare a datelor

Structura și componența nivelului de colectare a datelor

Nivelul de colectare a datelor este o componentă-cheie a subsistemului Data Platform și asigură integrarea cu dispozitivele. Cuprinde un set de aplicații specializate, fiecare proiectată să interacționeze cu un anumit tip de dispozitiv IoT (contoare, senzori etc.). Aceste aplicații funcționează ca servicii de rețea: preiau conexiunile de intrare prin porturi dedicate și gestionează transferul de date între dispozitive și platformă. Această arhitectură garantează scalabilitatea și flexibilitatea în lucrul cu echipamente eterogene.

Structura și componența aplicațiilor din nivelul de colectare a datelor sunt prezentate pe scurt mai jos:

flowchart TD
    A(Contoare de utilități din locuințe) <-->|Transfer de date| B("Serviciu de colectare a datelor (Type-J)")
    C(Contoare de utilități din industrie) <-->|Transfer de date| D("Serviciu de colectare a datelor (Type-T)")
    E(Senzori inteligenți) <-->|Transfer de date| F("Serviciu de colectare a datelor (DDT)")
    subgraph " "
    B("Serviciu de colectare a datelor (Type-J)") <--> I{"Echilibrarea încărcării (Pgbouncer)"}
    D("Serviciu de colectare a datelor (Type-T)") <--> I{"Echilibrarea încărcării (Pgbouncer)"}
    F("Serviciu de colectare a datelor (DDT)") <--> I{"Echilibrarea încărcării (Pgbouncer)"}
    X@{ shape: braces, label: "Componenta de interogare a dispozitivelor" }
    end
    I{"Echilibrarea încărcării (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

Schimbul de date cu dispozitivele finale are loc printr-o conexiune TCP, iar fiecare serviciu de colectare a datelor (daemon) implementează propriul protocol aplicativ de schimb de date pentru a deservi un anumit tip de dispozitiv IoT.

Aceste servicii au în comun mai multe particularități arhitecturale, descrise mai jos.

Particularitățile arhitecturii

• Fiecare container conține o aplicație specializată pentru un anumit protocol.
• Se folosesc imagini de bază ușoare (alpine în configurația de bază) pentru a reduce la minimum consumul suplimentar de resurse. Totuși, imaginile pot fi construite și pentru sistemul de operare al clientului.
• Pentru gestionarea dependențelor dintre servicii (de exemplu, accesul la baza de date), în Docker Compose se definesc secțiunile depends_on și health-check.
• Serviciile de colectare definite în Compose rulează în mai multe instanțe (replici) pentru a distribui încărcarea. În acest caz, fiecare serviciu de colectare poate deservi simultan zeci de mii de conexiuni.
• Un sistem de echilibrare a încărcării (HAProxy, Nginx Stream) direcționează traficul către serviciile disponibile după algoritmul Round Robin sau Least Connections.
• În mediile cloud se poate adăuga scalarea automată pe baza unor metrici (CPU, numărul de conexiuni).
• Toată comunicația cu dispozitivele se jurnalizează detaliat în fișiere, astfel încât să poată fi analizată atunci când se constată probleme sau defecțiuni.

Principiile schimbului de date

Mai jos este prezentată diagrama unei sesiuni de comunicație dintre un dispozitiv IoT și serviciul de colectare:

sequenceDiagram
    autonumber
    participant D as Dispozitiv IoT
    participant I as Serviciu de colectare <br/>a datelor
    Note over I,D: Etapele interacțiunii
    D->>I: Începutul sesiunii, autentificare
    I-->>D: Transmiterea parametrilor cererii
    D->>I: Achiziția datelor
    I-->>D: Transmiterea orei următoarei sesiuni

Principiile de organizare a schimbului de date:

• Inițierea sesiunii de comunicație.
  Sesiunea de comunicație o inițiază întotdeauna dispozitivul IoT. După stabilirea conexiunii cu serviciul de colectare a datelor, dispozitivul transmite un pachet de identificare.

• Procedura de autentificare
  Serviciul de colectare a datelor autentifică dispozitivul. Dacă autentificarea reușește, serviciul efectuează:

  • preluarea din baza de date a configurației salvate a dispozitivului;
  • transmiterea către dispozitiv a setărilor curente ale interfeței.

• Transferul datelor
  Pe baza cererii primite, dispozitivul transmite serverului de colectare:

  • citirile curente ale dispozitivului;
  • înregistrările din arhive (dacă există).

• Programarea următoarei sesiuni
  După încheierea recepției datelor, serviciul de colectare:

  • generează marca temporală a următoarei sesiuni;
  • transmite dispozitivului marca temporală a următoarei sesiuni;
  • inițiază închiderea conexiunii.

• Prelucrarea și stocarea datelor
  Informațiile primite sunt:

  • agregate în obiecte JSON structurate;
  • stocate într-o bază de date PostgreSQL intermediară;
  • formatate conform specificației de protocol a serviciului respectiv.

• Integrarea cu nivelul de gestionare
  Datele devin disponibile pentru nivelul superior al sistemului (componenta de gestionare), în vederea:

  • prelucrării analitice ulterioare;
  • vizualizării în interfețele de gestionare;
  • generării automate a rapoartelor.

Interacțiunea cu nivelul de gestionare al platformei

Arhitectura legăturilor dintre componente

Serviciile de colectare a datelor se integrează cu sistemul de nivel superior (nivelul de gestionare) printr-o bază de date intermediară. Pentru această interacțiune se folosește un container Docker în care este instalat un sistem de gestiune a bazelor de date (DBMS) PostgreSQL.

Serviciile de colectare salvează automat rezultatele interacțiunilor reușite cu dispozitivele într-un tabel specializat din aceeași bază de date, ceea ce asigură transparența transferului de date între nivelul de gestionare și dispozitive.

Schema interacțiunii dintre componente este prezentată mai jos:

flowchart LR
A@{ shape: procs, label: "Componenta de interogare a dispozitivelor"} -->|Datele citirilor| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configurație| A@{ shape: procs, label: "Componenta de interogare a dispozitivelor"}
B[(DBMS PostgreSQL)] -->|Datele citirilor| C@{ shape: procs, label: "Componenta de gestionare"}
C@{ shape: procs, label: "Componenta de gestionare"} -->|Configurație| B[(DBMS PostgreSQL)]

Configurația dispozitivului

Configurația dispozitivului cuprinde următoarele informații:

• Data ultimei citiri din fiecare arhivă: orară, zilnică, lunară. Acești parametri indică data de la care trebuie citite datele din arhiva corespunzătoare.
• Codul dispozitivului de măsurare (pentru dispozitivele IoT care folosesc protocolul Type-T). Acest parametru este necesar numai pentru serviciile de colectare care deservesc protocolul Type-T și indică serverului de colectare ce algoritm trebuie să folosească în lucrul cu dispozitivul.
• Viteza portului serial (pentru dispozitivele IoT care funcționează cu protocolul Type-T). Acest parametru indică dispozitivului IoT viteza cu care trebuie să comunice cu contorul. Serviciul de colectare îl transmite la începutul sesiunii de schimb de date.
• Planificarea comunicației. Componenta de gestionare salvează toate planificările în baza de date intermediară, iar serviciul de colectare calculează din planificările primite cea mai apropiată dată și o transmite dispozitivului.
• Comenzi către dispozitive. În funcție de tipul dispozitivului IoT și de capacitățile lui, comenzile de gestionare includ:
  • Comanda de actualizare a software-ului din partea de telemetrie a dispozitivului IoT. La primirea acestei comenzi, dispozitivul descarcă de pe server firmware-ul nou și efectuează actualizarea.
  • Comanda de recitire a configurației dispozitivului de măsurare.
  • Comanda de închidere sau de deschidere a vanei (dacă vana există și software-ul dispozitivului IoT o acceptă).
  • Comanda de setare a parametrilor de funcționare ai dispozitivului de măsurare (depinde de model).
  • Comanda de repornire a dispozitivului IoT.

Partea principală a configurației dispozitivului se stochează în baza de date intermediară, în format JSON.

Un exemplu de configurație este prezentat mai jos:

{
  "settings": "1",
  "day_event": 1706140800,
  "hour_event": 1706140800,
  "month_event": 1673857740,
  "net_address": 58
}

Aici day_event, hour_event și month_event sunt mărcile temporale în format unixtime ale celor mai recente înregistrări salvate din arhiva zilnică, orară și, respectiv, lunară.

Planificările se stochează separat, tot în format JSON. Șirul planificării propriu-zis se formează și se prelucrează în format CRON. Această abordare permite configurarea și prelucrarea flexibilă a oricăror planificări.

Mai jos este un exemplu de stocare a mai multor planificări pentru un dispozitiv:

[
  { "crontab": "10 * * * *", "schedule_id": 6 },
  { "crontab": "40 * * * *", "schedule_id": 7 }
]

Conform acestor planificări, dispozitivul trebuie să se conecteze la minutul 10 și la minutul 40 al fiecărei ore. Serviciul de colectare stabilește singur, în momentul comunicației cu dispozitivul, planificarea cea mai potrivită și transmite cea mai apropiată dată.