Signale

Das Herzstück der Datenverarbeitung in der hetida platform ist das Signal-Management. Physische Messwerte aus dem Feld, berechnete Prognosen oder logische Zustände werden plattformintern einheitlich über sogenannte Signale abgebildet.

Ein Signal repräsentiert einen kontinuierlichen Datenstrom, der aus einer Abfolge von Datenpunkten (Wert + Zeitstempel) besteht. Um die Datenflut effizient zu verwalten und Kosten sowie Performance zu optimieren, unterscheidet die Plattform strikt zwischen echten (physischen) und virtuellen (analytischen) Signalen.

---

3.1 Echte Signale (Physische Signale)

Echte Signale bilden die physische Realität Ihrer Anlagen ab. Sie sind direkt an die physische Hardware (Devices) gekoppelt.

• Herkunft: Diese Daten stammen von realen Sensoren im Feld (z. B. Pegelsonden, Durchflussmesser, Temperatursensoren). Sie werden über Protokolle wie MQTT, OPC-UA oder REST-Schnittstellen an die Ingestion-Pipeline der Plattform übertragen.
• Charakteristik: Sie spiegeln unveränderte Rohdaten wider. Fällt ein Sensor aus oder verliert das Gateway die Verbindung, entstehen in diesem Signal Datenlücken.
• Speicherung: Echte Signale werden immer dauerhaft und hochperformant in der Zeitreihendatenbank (TimescaleDB) abgelegt, um historische Analysen und lückenlose Nachweise zu ermöglichen.

---

3.2 Virtuelle Signale (Analytische Signale)

Virtuelle Signale enthalten keine direkt importierten Rohdaten. Stattdessen sind sie das Ergebnis von mathematischen Berechnungen, statistischen Modellen oder KI-Algorithmen, die im hetida designer als Workflow definiert wurden.

Ein virtuelles Signal nimmt beispielsweise die Daten von drei echten Temperatursensoren entgegen und berechnet daraus kontinuierlich den Mittelwert.

Innerhalb der virtuellen Signale wird architektonisch zwischen zwei fundamentalen Formen unterschieden: persistenten und transienten Signalen.

3.2.1 Persistente virtuelle Signale (Gespeicherte Ergebnisse)

Persistente virtuelle Signale verhalten sich nach außen hin fast wie echte Signale, da ihre Ergebnisse fest auf die Festplatte geschrieben werden.

• Funktionsweise: Ein Analytics-Workflow wird zeitgesteuert (z. B. alle 5 Minuten oder einmal pro Stunde) oder eventbasiert ausgeführt. Er berechnet die neuen Werte und schreibt das Ergebnis aktiv in die Zeitreihendatenbank.
• Vorteil (Performance): Da die Daten bereits berechnet und gespeichert vorliegen, können sie auf Dashboards blitzschnell geladen werden – selbst wenn der zugrundeliegende Berechnungsalgorithmus hochkomplex war.
• Typischer Einsatzzweck: Langfristige Prognosemodelle (z. B. 24h-Überflutungsvorhersagen), aggregierte Tages-/Monatsstatistiken oder geschäftskritische Kennzahlen, die für das Reporting historisch dokumentiert sein müssen.

3.2.2 Transiente virtuelle Signale (Berechnung "on-the-fly")

Transiente virtuelle Signale (von lateinisch transire = vergehen, vorübergehen) existieren nicht dauerhaft in der Datenbank. Sie werden flüchtig und nur bei akutem Bedarf erzeugt.

• Funktionsweise: Wenn ein Benutzer ein Dashboard öffnet oder eine API-Abfrage startet, triggert die Plattform im Hintergrund ad hoc den zugehörigen Analytics-Workflow. Die Daten werden exakt für den angeforderten Zeitraum "on-the-fly" berechnet, an das Dashboard übergeben und danach wieder verworfen.
• Vorteil (Flexibilität): Es wird kein Speicherplatz verbraucht. Zudem sind Änderungen am Berechnungsalgorithmus sofort rückwirkend für alle historischen Daten sichtbar, da die Historie bei jedem Laden des Diagramms neu berechnet wird.
• Nachteil: Bei sehr großen Zeitbereichen oder rechenintensiven Algorithmen kann das Laden des Dashboards länger dauern, da die Rechenleistung im Moment der Abfrage aufgebracht werden muss.
• Typischer Einsatzzweck: Mathematische Filter (z. B. Glättung von verrauschten Signalen), dynamische Einheitenumrechnungen (z. B. Celsius in Fahrenheit) oder Sensor-Plausibilisierungen, bei denen sich die Validierungsregeln häufig ändern.

---

3.3 Zusammenfassung und Entscheidungshilfe

Die Wahl des richtigen Signaltyps ist entscheidend für die Systemperformance und den Speicherbedarf der hetida platform.

Kriterium	Echte Signale	Persistente virtuelle Signale	Transiente virtuelle Signale
Datenbasis	Reale Sensoren / Feldgeräte	Workflows (Skripte / Modelle)	Workflows (Skripte / Modelle)
Datenbank-Speicher	Ja (Permanent)	Ja (Permanent)	Nein (Flüchtig im RAM)
Berechnungszeitpunkt	Bei Eintreffen des Messwerts	Zyklisch / Eventbasiert im Hintergrund	Ad-hoc (Nur bei Benutzerabfrage)
Historische Flexibilität	Nachträglich nicht veränderbar	Geänderter Code gilt erst ab Zukunft	Geänderter Code gilt sofort auch für die Vergangenheit
Ladegeschwindigkeit	Extrem schnell	Extrem schnell	Abhängig von der Komplexität des Modells