Vrstva zberu dát

Štruktúra a zloženie vrstvy zberu dát

Vrstva zberu dát je kľúčovým komponentom Platformy IIoT, ktorý zabezpečuje integráciu so zariadeniami. Zahŕňa súbor špecializovaných aplikácií, z ktorých každá je určená na interakciu s konkrétnym typom IoT zariadenia (merače, snímače a podobne). Tieto aplikácie fungujú ako sieťové služby, spracúvajú prichádzajúce spojenia cez vyhradené porty a riadia prenos dát medzi zariadeniami a platformou. Táto architektúra zaručuje škálovateľnosť a flexibilitu pri práci s heterogénnym vybavením.

Štruktúra a zloženie aplikácií vrstvy zberu dát sú zhrnuté nižšie:

flowchart TD
    A(Household energy meters) <-->|Data transfer| B("Data collection daemon (Type-J)")
    C(Industrial energy meters) <-->|Data transfer| D("Data collection daemon (Type-T)")
    E(Smart sensors) <-->|Data transfer| F("Data collection daemon (DDT)")
    subgraph " "
    B("Data collection daemon (Type-J)") <--> I{"Balancer (Pgbouncer)"}
    D("Data collection daemon (Type-T)") <--> I{"Balancer (Pgbouncer)"}
    F("Data collection daemon (DDT)") <--> I{"Balancer (Pgbouncer)"}
    X@{ shape: braces, label: "Data Polling Subsystem" }
    end
    I{"Balancer (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

Výmena dát s koncovými zariadeniami prebieha cez spojenie TCP, pričom každý démon zberu implementuje vlastný aplikačný protokol výmeny na obsluhu konkrétneho typu IoT zariadenia.

Títo démoni majú spoločných niekoľko architektonických čŕt, ktoré sú opísané nižšie.

Vlastnosti architektúry

• Každý kontajner obsahuje aplikáciu špecializovanú na konkrétny protokol.
• Používajú sa odľahčené základné obrazy (alpine v základnej konfigurácii) na minimalizáciu réžie. Je však možné zostaviť obrazy pre operačný systém zákazníka.
• Na správu závislostí medzi službami (napríklad prístupu k databáze) sa v Docker Compose uvádzajú sekcie depends_on a health-check.
• Démoni compose bežia vo viacerých inštanciách (replikách) na rozdelenie záťaže. V takom prípade dokáže každý démon zberu obsluhovať desiatky tisíc spojení súčasne.
• Vyvažovač záťaže (HAProxy, Nginx Stream) smeruje prevádzku na dostupných démonov pomocou algoritmov Round Robin alebo Least Connections.
• V cloudových prostrediach môžete pridať automatické škálovanie na základe metrík (CPU, počet spojení).
• Všetka komunikácia so zariadeniami sa podrobne zaznamenáva do súborov, takže ju možno analyzovať pri zistení problémov a zlyhaní.

Princípy výmeny dát

Nižšie je uvedená schéma komunikačnej relácie medzi IoT zariadením a démonom zberu:

sequenceDiagram
    autonumber
    participant D as IoT device
    participant I as Data collection <br/>daemon
    Note over I,D: Stages of interaction
    D->>I: Session start, authentication
    I-->>D: Sending request parameters
    D->>I: Data acquisition
    I-->>D: Sending the next session time

Princípy organizácie výmeny dát:

• Iniciovanie komunikačnej relácie.
  Komunikačnú reláciu vždy iniciuje IoT zariadenie. Po nadviazaní spojenia s démonom zberu dát zariadenie odošle identifikačný paket.

• Postup autentifikácie
  Démon zberu dát autentifikuje zariadenie. Ak je autentifikácia úspešná, vykoná:

  • Načítanie uloženej konfigurácie zariadenia z databázy.
  • Odoslanie aktuálnych nastavení rozhrania do zariadenia.

• Prenos dát
  Na základe prijatej požiadavky zariadenie prenáša na server zberu:

  • Aktuálne namerané hodnoty zariadenia.
  • Archivované záznamy (ak existujú).

• Naplánovanie ďalšej relácie
  Po dokončení prijatia dát démon zberu:

  • Vygeneruje časovú značku ďalšej relácie.
  • Prenesie časovú značku ďalšej relácie do zariadenia.
  • Iniciuje ukončenie spojenia.

• Spracovanie a uloženie dát
  Prijaté informácie sú:

  • Agregované do štruktúrovaných objektov JSON.
  • Uložené do medziľahlej databázy PostgreSQL.
  • Naformátované podľa špecifikácie protokolu konkrétneho démona.

• Integrácia s riadiacim systémom
  Dáta sa stávajú dostupnými pre vyššiu úroveň systému (riadiaci subsystém) na:

  • Ďalšie analytické spracovanie.
  • Vizualizáciu v riadiacich rozhraniach.
  • Generovanie automatizovaných zostáv.

Interakcia s riadiacou vrstvou platformy

Architektúra prepojenia subsystémov

Démoni zberu dát sa integrujú so systémom vyššej úrovne (riadiacou vrstvou) prostredníctvom medziľahlej databázy. Na umožnenie tejto interakcie sa používa kontajner Docker s nasadeným systémom riadenia databázy PostgreSQL.

Výsledky úspešnej interakcie so zariadeniami démoni automaticky ukladajú do špecializovanej tabuľky v tej istej databáze, čím sa zabezpečuje transparentnosť prenosu dát medzi riadiacou úrovňou a zariadeniami.

Schéma interakcie subsystémov je znázornená nižšie:

flowchart LR
A@{ shape: procs, label: "Data Polling Subsystem"} -->|Readings data| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configuration| A@{ shape: procs, label: "Data Polling Subsystem"}
B[(DBMS PostgreSQL)] -->|Readings data| C@{ shape: procs, label: "Control Subsystem"}
C@{ shape: procs, label: "Control Subsystem"} -->|Configuration| B[(DBMS PostgreSQL)]

Konfigurácia zariadenia

Konfigurácia zariadenia zahŕňa nasledujúce informácie:

• Dátumy posledných nameraných hodnôt podľa archívu: hodinový, denný, mesačný. Tieto parametre udávajú dátum, od ktorého sa majú vyčítať dáta príslušného archívu.
• Kód meracieho zariadenia (pre IoT zariadenia používajúce protokol Type-T). Tento parameter je potrebný iba pre démonov zberu obsluhujúcich protokol Type-T a oznamuje serveru zberu, ktorý algoritmus má použiť pri práci so zariadením.
• Rýchlosť sériového portu (pre IoT zariadenia bežiace na protokole Type-T). Tento parameter oznamuje IoT zariadeniu, ako rýchlo má komunikovať s meračom. Démon zberu ho odosiela na začiatku relácie výmeny.
• Komunikačný rozvrh. Riadiaci subsystém ukladá všetky rozvrhy do medziľahlej databázy a démon zberu vypočíta najbližší dátum z prijatých rozvrhov a odošle ho do zariadenia.
• Riadiace príkazy zariadenia. V závislosti od typu IoT zariadenia a jeho možností riadiace príkazy zahŕňajú:
  • Príkaz na aktualizáciu softvéru telemetrickej časti IoT zariadenia. Po prijatí tohto príkazu zariadenie stiahne nový firmvér zo servera a vykoná aktualizáciu.
  • Príkaz na spätné vyčítanie konfigurácie meracieho zariadenia.
  • Príkaz na zatvorenie alebo otvorenie ventilu (ak je ventil prítomný a podporovaný softvérom IoT zariadenia).
  • Príkaz na nastavenie prevádzkových parametrov meracieho zariadenia (závisí od modelu).
  • Príkaz na reštart IoT zariadenia.

Hlavná časť konfigurácie zariadenia sa ukladá do medziľahlej databázy vo formáte JSON.

Príklad konfigurácie je uvedený nižšie:

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

Tu sú day_event, hour_event a month_event časové značky vo formáte unixtime posledných uložených záznamov denného, hodinového a mesačného archívu v uvedenom poradí.

Rozvrhy sa ukladajú samostatne, takisto vo formáte JSON. Samotný reťazec rozvrhu sa tvorí a spracúva vo formáte CRON. Tento prístup poskytuje flexibilitu pri nastavovaní a spracúvaní ľubovoľných rozvrhov.

Nižšie je uvedený príklad uloženia niekoľkých rozvrhov pre zariadenie:

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

Podľa týchto rozvrhov by sa zariadenie malo pripojiť v 10. a 40. minúte každej hodiny. Démon sám určuje najvhodnejší rozvrh v okamihu komunikácie so zariadením a prenáša ten najbližší.