---
title: 'Vrstva sběru dat'
section: 'Concepts'
weight: 1
description: Struktura vrstvy sběru dat Platformy IIoT, její démoni, principy výměny dat a interakce s řídicí vrstvou.
related:
  - architecture
  - architecture/abstract-data-layer
  - protocols
  - equipment
---

import Alert from '@/components/docs/Alert.astro';

## 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.

<Alert type="note">
  Pro vyšší bezpečnost, odolnost a snadnou instalaci i aktualizaci jsou aplikace zabaleny do
  kontejnerů Docker. Sadu kontejnerů spravuje [technologie Docker
  Compose](https://docs.docker.com/compose/), která umožňuje sloučit propojené kontejnery do
  jediného ovládacího panelu.
</Alert>

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

```mermaid
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:

```mermaid
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.

<Alert type="note">
  Řídicí podsystém ukládá do této databáze veškerou potřebnou konfiguraci dotazovaných zařízení IoT.
  Sběrní démoni používají toto nastavení k navázání komunikace se zařízeními a k provádění operací
  výměny dat.
</Alert>

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:

```mermaid
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:

```json
{
  "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í:

```json
[
  { "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žší.