---
title: 'Datenerfassungsschicht'
section: 'Concepts'
weight: 1
description: Aufbau der Datenerfassungsschicht der IIoT-Plattform, ihre Daemons, die Prinzipien des Datenaustauschs und das Zusammenwirken mit der Verwaltungsschicht.
related:
  - architecture
  - architecture/abstract-data-layer
  - protocols
  - equipment
---

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

## Aufbau und Zusammensetzung der Datenerfassungsschicht

**Die Datenerfassungsschicht** ist eine zentrale Komponente der IIoT-Plattform, die für die Anbindung der Geräte sorgt. Sie umfasst eine Reihe spezialisierter Anwendungen, von denen jede für das Zusammenwirken mit einem bestimmten Typ von IoT-Gerät (Zähler, Sensoren usw.) ausgelegt ist. Diese Anwendungen arbeiten als Netzwerkdienste, nehmen eingehende Verbindungen über dedizierte Ports entgegen und steuern die Datenübertragung zwischen den Geräten und der Plattform. Diese Architektur gewährleistet Skalierbarkeit und Flexibilität beim Umgang mit heterogener Hardware.

<Alert type="note">
  Zur Erhöhung der Sicherheit und Ausfallsicherheit sowie zur Vereinfachung von Installation und
  Aktualisierung werden die Anwendungen in Docker-Containern bereitgestellt. Der Containerverbund
  wird über die [Technologie Docker Compose](https://docs.docker.com/compose/) verwaltet, mit der
  sich miteinander verknüpfte Container zu einer einzigen Bedienoberfläche zusammenfassen lassen.
</Alert>

Aufbau und Zusammensetzung der Anwendungen der Datenerfassungsschicht sind nachfolgend zusammengefasst:

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

```

Der Austausch mit den Endgeräten erfolgt über eine TCP-Verbindung, wobei jeder Erfassungs-Daemon sein eigenes Austauschprotokoll auf Anwendungsebene implementiert, um einen bestimmten Typ von IoT-Gerät zu bedienen.

Diese Daemons weisen mehrere gemeinsame Architekturmerkmale auf, die nachfolgend beschrieben werden.

### Architekturmerkmale

- Jeder Container enthält eine Anwendung, die auf ein bestimmtes Protokoll spezialisiert ist.
- Es werden schlanke Basis-Images verwendet (`alpine` in der Basiskonfiguration), um den Overhead zu minimieren. Es ist jedoch möglich, Images für das Betriebssystem des Kunden zu erstellen.
- Zur Verwaltung der Abhängigkeiten zwischen den Diensten (etwa des Datenbankzugriffs) werden in Docker Compose die Abschnitte `depends_on` und `health-check` angegeben.
- Die Compose-Daemons laufen in mehreren Instanzen (Replikas), um die Last zu verteilen. Dabei kann jeder Erfassungs-Daemon Zehntausende Verbindungen gleichzeitig bedienen.
- Ein Balancer (HAProxy, Nginx Stream) leitet den Datenverkehr mithilfe der Algorithmen Round Robin oder Least Connections an verfügbare Daemons weiter.
- In Cloud-Umgebungen lässt sich eine automatische Skalierung auf Grundlage von Metriken (CPU, Anzahl der Verbindungen) ergänzen.
- Die gesamte Kommunikation mit den Geräten wird detailliert in Dateien protokolliert, sodass sie bei erkannten Problemen und Störungen analysiert werden kann.

### Prinzipien des Datenaustauschs

Nachfolgend ist ein Diagramm einer Kommunikationssitzung zwischen einem IoT-Gerät und dem Erfassungs-Daemon dargestellt:

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

Prinzipien der Organisation des Datenaustauschs:

- **Initiierung einer Kommunikationssitzung**.  
   Eine Kommunikationssitzung wird stets vom IoT-Gerät initiiert. Nach dem Aufbau einer Verbindung zum Datenerfassungs-Daemon übermittelt das Gerät ein Identifikationspaket.

- **Authentifizierungsverfahren**  
   Der Datenerfassungs-Daemon authentifiziert das Gerät. Verläuft die Authentifizierung erfolgreich, führt er Folgendes aus:
  - Abruf der gespeicherten Gerätekonfiguration aus der Datenbank.
  - Senden der aktuellen Schnittstelleneinstellungen an das Gerät.

- **Datenübertragung**  
   Auf Grundlage der erhaltenen Anfrage überträgt das Gerät an den Erfassungsserver:
  - Aktuelle Geräteablesungen.
  - Archivierte Datensätze (sofern vorhanden).

- **Planung der nächsten Sitzung**  
   Nach Abschluss des Datenempfangs führt der Erfassungs-Daemon Folgendes aus:
  - Erzeugung des Zeitstempels der nächsten Sitzung.
  - Übertragung des Zeitstempels der nächsten Sitzung an das Gerät.
  - Einleitung des Verbindungsabbaus.

- **Datenverarbeitung und Speicherung**  
   Die empfangenen Informationen werden:
  - Zu strukturierten JSON-Objekten aggregiert.
  - In einer zwischengeschalteten PostgreSQL-Datenbank gespeichert.
  - Gemäß der Protokollspezifikation des jeweiligen Daemons formatiert.

- **Integration mit dem Steuerungssystem**  
   Die Daten werden der oberen Ebene des Systems (Verwaltungssubsystem) zur Verfügung gestellt für:
  - Die weitere analytische Verarbeitung.
  - Die Visualisierung in den Verwaltungsoberflächen.
  - Die Erstellung automatisierter Berichte.

## Zusammenwirken mit der Verwaltungsschicht der Plattform

### Architektur der Subsystemverknüpfung

Die Datenerfassungs-Daemons sind über eine zwischengeschaltete Datenbank in das übergeordnete System (Verwaltungsschicht) integriert. Um dieses Zusammenwirken zu ermöglichen, wird ein Docker-Container mit einem bereitgestellten PostgreSQL-DBMS verwendet.

<Alert type="note">
  Das Verwaltungssubsystem speichert die gesamte erforderliche Konfiguration der abgefragten
  IoT-Geräte in dieser Datenbank. Die Datenerfassungs-Daemons nutzen diese Einstellungen, um die
  Kommunikation mit den Geräten aufzubauen und Datenaustauschvorgänge durchzuführen.
</Alert>

Die Ergebnisse des erfolgreichen Zusammenwirkens mit den Geräten werden von den Daemons automatisch in einer speziellen Tabelle derselben Datenbank gespeichert, was die Transparenz der Datenübertragung zwischen der Steuerungsebene und den Geräten gewährleistet.

Das Schema des Zusammenwirkens der Subsysteme ist nachfolgend dargestellt:

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

### Gerätekonfiguration

Die Gerätekonfiguration umfasst die folgenden Informationen:

- **Datum der letzten Ablesungen je Archiv**: stündlich, täglich, monatlich. Diese Parameter geben das Datum an, ab dem die Daten des entsprechenden Archivs ausgelesen werden sollen.
- **Code des Messgeräts** (für IoT-Geräte, die das Type-T-Protokoll verwenden). Dieser Parameter ist nur für die Erfassungs-Daemons erforderlich, die das Type-T-Protokoll bedienen, und teilt dem Erfassungsserver mit, welcher Algorithmus für die Arbeit mit dem Gerät zu verwenden ist.
- **Geschwindigkeit der seriellen Schnittstelle** (für IoT-Geräte, die das Type-T-Protokoll ausführen). Dieser Parameter teilt dem IoT-Gerät mit, wie schnell es mit dem Zähler kommunizieren soll. Der Erfassungs-Daemon sendet ihn zu Beginn einer Austauschsitzung.
- **Kommunikationszeitplan**. Das Verwaltungssubsystem speichert alle Zeitpläne in einer zwischengeschalteten Datenbank, und der Erfassungs-Daemon berechnet aus den erhaltenen Zeitplänen das nächstgelegene Datum und sendet es an das Gerät.
- **Gerätesteuerungsbefehle**. Je nach Typ des IoT-Geräts und dessen Fähigkeiten umfassen die Verwaltungsbefehle:
  - Einen Befehl zur Aktualisierung der Software des Telemetrieteils des IoT-Geräts. Beim Empfang dieses Befehls lädt das Gerät neue Firmware vom Server herunter und führt die Aktualisierung durch.
  - Einen Befehl zum Zurücklesen der Konfiguration des Messgeräts.
  - Einen Befehl zum Schließen oder Öffnen des Ventils (sofern ein Ventil vorhanden und von der Software des IoT-Geräts unterstützt wird).
  - Einen Befehl zum Setzen der Betriebsparameter des Messgeräts (modellabhängig).
  - Einen Befehl zum Neustart des IoT-Geräts.

Der Hauptteil der Gerätekonfiguration wird in einer zwischengeschalteten Datenbank im JSON-Format gespeichert.

Nachfolgend ein Beispiel für die Konfiguration:

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

Dabei sind `day_event`, `hour_event` und `month_event` Zeitstempel im Format `unixtime` der zuletzt gespeicherten Datensätze des täglichen, stündlichen bzw. monatlichen Archivs.

Zeitpläne werden separat gespeichert, ebenfalls im JSON-Format. Die Zeitplanzeichenkette selbst wird im CRON-Format gebildet und verarbeitet. Dieser Ansatz bietet Flexibilität bei der Einrichtung und Verarbeitung beliebiger Zeitpläne.

Nachfolgend ein Beispiel für die Speicherung mehrerer Zeitpläne für ein Gerät:

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

Gemäß diesen Zeitplänen soll sich das Gerät jeweils 10 und 40 Minuten nach jeder vollen Stunde verbinden. Der Daemon selbst bestimmt zum Zeitpunkt der Gerätekommunikation den am besten geeigneten Zeitplan und übermittelt den nächstgelegenen.