Vrstva sběru dat

Struktura a složení vrstvy sběru dat

Vrstva sběru dat je klíčovou součástí Platformy IIoT, která zajišťuje integraci se zařízeními. Zahrnuje sadu specializovaných aplikací, z nichž každá je navržena pro interakci s určitým typem zařízení IoT (měřidla, snímače a podobně). Tyto aplikace fungují jako síťové služby, obsluhují příchozí spojení prostřednictvím vyhrazených portů a řídí přenos dat mezi zařízeními a platformou. Tato architektura zaručuje škálovatelnost a flexibilitu při práci s různorodým vybavením.

Struktura a složení aplikací vrstvy sběru dat jsou shrnuty níže:

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ýměna dat s koncovými zařízeními probíhá přes spojení TCP, přičemž každý sběrný démon implementuje vlastní aplikační protokol výměny dat určený k obsluze konkrétního typu zařízení IoT.

Tito démoni mají několik společných architektonických rysů, popsaných níže.

Vlastnosti architektury

• Každý kontejner obsahuje aplikaci specializovanou na určitý protokol.
• Používají se odlehčené základní obrazy (alpine v základní konfiguraci), aby se minimalizovala režie. Je však možné sestavit obrazy pro operační systém zákazníka.
• Pro správu závislostí mezi službami (například přístupu k databázi) jsou v Docker Compose uvedeny sekce depends_on a health-check.
• Démoni v Compose běží ve více instancích (replikách), aby se rozložila zátěž. V takovém případě může každý sběrný démon obsluhovat současně desítky tisíc spojení.
• Balancer (HAProxy, Nginx Stream) směruje provoz na dostupné démony pomocí algoritmů Round Robin nebo Least Connections.
• V cloudových prostředích lze přidat automatické škálování na základě metrik (CPU, počet spojení).
• Veškerá komunikace se zařízeními se podrobně zaznamenává do souborů, takže ji lze analyzovat při zjištění problémů a poruch.

Principy výměny dat

Níže je uveden diagram komunikační relace mezi zařízením IoT a sběrným démonem:

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

Principy organizace výměny dat:

• Zahájení komunikační relace.
  Komunikační relaci vždy zahajuje zařízení IoT. Po navázání spojení se sběrným démonem zařízení přenese identifikační paket.

• Postup autentizace
  Sběrný démon autentizuje zařízení. Pokud je autentizace úspěšná, provede:

  • Načtení uložené konfigurace zařízení z databáze.
  • Odeslání aktuálního nastavení rozhraní do zařízení.

• Přenos dat
  Na základě přijatého požadavku zařízení přenáší na sběrný server:

  • Aktuální naměřené hodnoty zařízení.
  • Archivované záznamy (pokud existují).

• Naplánování příští relace
  Po dokončení příjmu dat sběrný démon:

  • Vygeneruje časové razítko příští relace.
  • Odešle časové razítko příští relace do zařízení.
  • Zahájí ukončení spojení.

• Zpracování a uložení dat
  Přijaté informace jsou:

  • Agregovány do strukturovaných objektů JSON.
  • Uloženy do mezilehlé databáze PostgreSQL.
  • Naformátovány podle specifikace protokolu konkrétního démona.

• Integrace s řídicím systémem
  Data se zpřístupní vyšší úrovni systému (řídicímu podsystému) pro:

  • Další analytické zpracování.
  • Vizualizaci v řídicích rozhraních.
  • Generování automatizovaných sestav.

Interakce s řídicí vrstvou platformy

Architektura propojení podsystémů

Sběrní démoni se integrují se systémem vyšší úrovně (řídicí vrstvou) prostřednictvím mezilehlé databáze. Pro umožnění této interakce se používá kontejner Docker s nasazeným systémem řízení databází PostgreSQL.

Výsledky úspěšné interakce se zařízeními démoni automaticky ukládají do specializované tabulky ve stejné databázi, čímž zajišťují transparentnost přenosu dat mezi řídicí úrovní a zařízeními.

Schéma interakce podsystémů je znázorněno níže:

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)]

Konfigurace zařízení

Konfigurace zařízení zahrnuje následující informace:

• Data posledních odečtů podle archivu: hodinový, denní, měsíční. Tyto parametry udávají datum, od něhož se mají číst data příslušného archivu.
• Kód měřidla (pro zařízení IoT používající protokol Type-T). Tento parametr je vyžadován pouze pro sběrné démony obsluhující protokol Type-T a sděluje sběrnému serveru, který algoritmus má použít pro práci se zařízením.
• Rychlost sériového portu (pro zařízení IoT s protokolem Type-T). Tento parametr sděluje zařízení IoT, jak rychle má komunikovat s měřidlem. Sběrný démon jej odesílá na začátku relace výměny dat.
• Komunikační rozvrh. Řídicí podsystém ukládá všechny rozvrhy do mezilehlé databáze a sběrný démon vypočítá z přijatých rozvrhů nejbližší datum a odešle jej zařízení.
• Řídicí příkazy zařízení. V závislosti na typu zařízení IoT a jeho možnostech zahrnují řídicí příkazy:
  • Příkaz k aktualizaci softwaru telemetrické části zařízení IoT. Po přijetí tohoto příkazu zařízení stáhne nový firmware ze serveru a provede aktualizaci.
  • Příkaz ke zpětnému přečtení konfigurace měřidla.
  • Příkaz k uzavření nebo otevření ventilu (pokud je ventil přítomen a podporován softwarem zařízení IoT).
  • Příkaz k nastavení provozních parametrů měřidla (závisí na modelu).
  • Příkaz k restartu zařízení IoT.

Hlavní část konfigurace zařízení je uložena v mezilehlé databázi ve formátu JSON.

Příklad konfigurace je uveden níže:

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

Zde jsou day_event, hour_event a month_event časová razítka ve formátu unixtime posledních uložených záznamů denního, hodinového a měsíčního archivu.

Rozvrhy se ukládají odděleně, rovněž ve formátu JSON. Samotný řetězec rozvrhu se vytváří a zpracovává ve formátu CRON. Tento přístup poskytuje flexibilitu při nastavování a zpracování libovolných rozvrhů.

Níže je uveden příklad uložení několika rozvrhů pro zařízení:

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

Podle těchto rozvrhů se má zařízení připojit v 10. a 40. minutě každé hodiny. Démon sám určuje v okamžiku komunikace se zařízením nejvhodnější rozvrh a přenáší ten nejbližší.