Dokumentation
Datenerfassungsebene

Datenerfassungsebene

Aufbau und Zusammensetzung der Datenerfassungsschicht

Die Datenerfassungsschicht ist eine Schlüsselkomponente der IoT-Plattform, die die Integration mit Geräten ermöglicht. Sie umfasst eine Reihe spezialisierter Anwendungen, die jeweils für die Interaktion mit einer bestimmten Art von IoT-Geräten (Zähler, Sensoren usw.) konzipiert sind. Diese Anwendungen fungieren als Netzwerkdienste, die eingehende Verbindungen über spezielle Ports abwickeln und die Datenübertragung zwischen Geräten und der Plattform verwalten. Diese Architektur garantiert Skalierbarkeit und Flexibilität bei der Arbeit mit heterogenen Geräten.

Notiz

Für zusätzliche Sicherheit, Ausfallsicherheit und einfache Installation und Upgrades werden die Anwendungen in Docker-Containern verpackt. Der Containersatz wird mit der [Docker Compose-Technologie] (https://docs.docker.com/compose/) verwaltet, die es ermöglicht, verknüpfte Container in einem einzigen Bedienfeld zu kombinieren.

Der Aufbau und die Zusammensetzung der Anwendungen der Datenerfassungsschicht sind im Folgenden 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 PostgeSQL)]

Der Austausch mit den Endgeräten erfolgt über eine TCP-Verbindung, wobei jeder der Sammel-Daemons sein eigenes Anwendungsaustauschprotokoll für einen bestimmten Typ von IoT-Geräten implementiert.

Architekturmerkmale

  • Jeder Container enthält eine Anwendung, die für ein bestimmtes Protokoll spezialisiert ist.
  • Es werden leichtgewichtige 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 von Abhängigkeiten zwischen Diensten (z. B. Datenbankzugriff) werden in Docker Compose die Abschnitte depends_on und health-check angegeben.
  • Die Compose-Dämonen laufen in mehreren Instanzen (Replikaten), um die Last zu verteilen. In diesem Fall kann jeder Sammel-Daemon Zehntausende von Verbindungen gleichzeitig bedienen.
  • Der Balancer (HAProxy, Nginx Stream) leitet den Datenverkehr über Round-Robin- oder Least-Connections-Algorithmen an die verfügbaren Daemons weiter.
  • In Cloud-Umgebungen können Sie eine automatische Skalierung auf der Grundlage von Metriken (CPU, Anzahl der Verbindungen) hinzufügen.
  • Die gesamte Kommunikation mit den Appliances wird detailliert in Dateien protokolliert, so dass sie analysiert werden kann, falls Probleme und Ausfälle entdeckt werden.

Datenaustauschprinzipien

Nachfolgend finden Sie ein Diagramm einer Kommunikationssitzung zwischen einem IoT-Gerät und dem Sammeldaemon:

  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

Grundsätze der Organisation des Datenaustauschs:

  • Einleitung einer Kommunikationssitzung. Eine Kommunikationssitzung wird immer durch das IoT-Gerät initiiert. Nach dem Aufbau einer Verbindung zum Datensammeldaemon sendet das Gerät ein Identitätspaket.
  • Authentifizierungsverfahren Der Datenerfassungs-Daemon authentifiziert das Gerät. Wenn die Authentifizierung erfolgreich ist, führt er folgende Schritte aus:
    • Abruf der gespeicherten Gerätekonfiguration aus der Datenbank.
    • Senden der aktuellen Schnittstelleneinstellungen an das Gerät.
  • Datenübertragung Auf der Grundlage der empfangenen Anfrage überträgt das Gerät an den Erfassungsserver:
    • Aktuelle Messwerte des Geräts.
    • Archivierte Datensätze (falls vorhanden). Planen der nächsten Sitzung Nachdem der Datenempfang abgeschlossen ist, erstellt der Erfassungsdämon:
    • Erzeugt den Zeitstempel der nächsten Sitzung.
    • Überträgt den Zeitstempel der nächsten Sitzung an das Gerät.
    • Leitet die Beendigung der Verbindung ein.
  • Datenverarbeitung und -speicherung Empfangene Informationen:
    • Aggregiert in strukturierte JSON-Objekte.
    • Speicherung in einer zwischengeschalteten PostgreSQL-Datenbank.
    • Formatierung gemäß der Protokollspezifikation eines bestimmten Daemons.
  • Integration in das Kontrollsystem Die Daten werden der oberen Ebene des Systems (Management-Subsystem) zur Verfügung gestellt:
    • Weitere analytische Verarbeitung.
    • Visualisierung in Management-Schnittstellen.
    • Generierung von automatisierten Berichten.

Interaktion mit der Verwaltungsschicht der IoT-Plattform

Subsystem-Verbindungsarchitektur

Die Datenerfassungs-Daemons führen die Integration mit dem Top-Level-System (Verwaltungsschicht) über eine dazwischenliegende Datenbank durch. Um diese Interaktion zu realisieren, wird ein Docker-Container mit einem PostgreSQL-DBMS verwendet.

Notiz

Das Management-Subsystem speichert alle notwendigen Konfigurationen der abgefragten IoT-Geräte in dieser Datenbank. Datenerfassungsdämonen verwenden diese Einstellungen, um die Kommunikation mit den Geräten herzustellen und Datenaustauschoperationen durchzuführen.

Die Ergebnisse erfolgreicher Interaktionen mit den Geräten werden von den Dämonen automatisch in einer speziellen Tabelle derselben Datenbank gespeichert, wodurch die Datenübertragung zwischen der Leitebene und den Geräten transparent wird.

Das Schema der Interaktion der Teilsysteme wird im Folgenden dargestellt:

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

Gerätekonfiguration

Die Gerätekonfiguration enthält die folgenden Informationen:

  • Daten der letzten Auslesungen der Archive: stündlich, täglich, monatlich. Diese Parameter geben an, ab welchem Datum die Daten des entsprechenden Archivs ausgelesen werden sollen.
  • Messgerätecode (für IoT-Geräte, die das Typ-T-Protokoll verwenden). Dieser Parameter ist nur für die Erfassungsdämonen erforderlich, die das Type-T-Protokoll verwenden, und gibt dem Erfassungsserver an, welcher Algorithmus für die Arbeit mit dem Gerät verwendet werden soll.
  • Serielle Anschlussgeschwindigkeit (für IoT-Geräte mit Type-T-Protokoll). Dieser Parameter teilt dem IoT-Gerät mit, wie schnell es mit dem Messgerät kommunizieren soll. Der Sammel-Daemon sendet ihn zu Beginn einer Austauschsitzung.
  • Kommunikationszeitplan. Das Verwaltungssubsystem speichert alle Zeitpläne in einer Zwischendatenbank, und der Erfassungsdämon berechnet aus den empfangenen Zeitplänen das nächstliegende Datum und sendet es an das Gerät.
  • Gerätesteuerungsbefehle. Die Verwaltungsbefehle umfassen je nach Art des IoT-Geräts und seiner Fähigkeiten Folgendes:
    • Ein Befehl zur Aktualisierung der Software des Telemetrieteils des IoT-Geräts. Nach Erhalt dieses Befehls lädt das Gerät die neue Firmware vom Server herunter und führt die Aktualisierung durch.
    • Der Befehl, die Konfiguration des Messgeräts zu überprüfen.
    • Befehl zum Schließen/Öffnen des Ventils (sofern ein Ventil vorhanden ist und von der Software des IoT-Geräts unterstützt wird).
    • Befehl zum Einstellen der Parameter für den Betrieb des Messgeräts (je nach Modell).
    • Befehl zum Neustart des IoT-Geräts.

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

Ein Beispiel für eine solche Konfiguration ist unten dargestellt:

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

wobei day_event, hour_event, month_event - Zeitstempel im Format unixtime der zuletzt gespeicherten Datensätze von täglichen, stündlichen bzw. monatlichen Archiven.

Die Zeitpläne werden separat gespeichert, ebenfalls im JSON-Format. Gleichzeitig wird der Zeitplanstring selbst im CRON-Format gebildet und verarbeitet. Die Verwendung dieses Ansatzes bietet Flexibilität bei der Einstellung und Verarbeitung beliebiger Zeitpläne.

Im Folgenden finden Sie ein Beispiel für die Speicherung mehrerer Zeitpläne für das Gerät:

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

Nach diesen Zeitplänen sollte das Gerät zu jeder vollen Stunde um 10 und 40 Minuten erlöschen. In diesem Fall bestimmt der Dämon selbst den zum Zeitpunkt der Gerätekommunikation am besten geeigneten Zeitplan und sendet den nächstgelegenen.

Zuletzt aktualisiert am