Datenerfassungsschicht

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.

Aufbau und Zusammensetzung der Anwendungen der Datenerfassungsschicht sind nachfolgend zusammengefasst:

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:

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.

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:

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:

{
  "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:

[
  { "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.