Zum Hauptinhalt springen

Betrachtungszeitpunkte und Zeitreise

Industrielle Zeitreihendaten verändern sich nicht nur in der Gegenwart — sie werden nachträglich korrigiert, mit Verzögerung eingespeist oder rückwirkend neu bewertet. Die hetida platform bildet diesen zeitlichen Charakter von Daten konsequent ab: Mit der Funktion Zeitreise können Sie jede Ansicht, jede Analyse und jeden Dashboardstand exakt so rekonstruieren, wie er zu einem beliebigen vergangenen Zeitpunkt ausgesehen hat.


Was ist der Betrachtungszeitpunkt?

Der Betrachtungszeitpunkt (auch: View Time oder As-of-Zeitpunkt) ist derjenige Moment, aus dessen Perspektive die Plattform Daten interpretiert und anzeigt. Er bestimmt, welche Datenpunkte, Metadaten und Konfigurationen als „gültig" gelten.

Standardmäßig ist der Betrachtungszeitpunkt die aktuelle Systemzeit — Sie sehen immer den aktuellen Stand. Wird der Betrachtungszeitpunkt auf einen Zeitpunkt in der Vergangenheit gesetzt, wechselt die Plattform in den Zeitreise-Modus: Alle Ansichten und Berechnungen verhalten sich so, als ob Sie zu diesem historischen Moment auf das System zugreifen würden.


Das bitemporale Datenmodell

Grundlage der Zeitreisefunktion ist das bitemporale Datenmodell: Jeder Datenpunkt in der hetida platform trägt zwei unabhängige Zeitstempel:

ZeitdimensionBedeutungBeispiel
Gültigkeitszeitpunkt (Valid Time)Wann war der Wert in der realen Welt gültig?Messung um 09:00 Uhr aufgezeichnet
Einspeisungszeitpunkt (Transaction Time)Wann wurde der Wert in das System eingetragen?Datenpunkt um 09:05 Uhr in die Datenbank geschrieben

Beide Zeitstempel sind unveränderlich. Nachträgliche Korrekturen fügen keine neuen Einträge mit demselben Gültigkeitszeitpunkt ein, sondern erzeugen einen neuen Datensatz mit einem neuen Einspeisungszeitpunkt — der ursprüngliche Wert bleibt erhalten und ist über den Betrachtungszeitpunkt weiterhin zugänglich.

Dabei werden jedoch echte Duplikate (gleicher Zielzeitstempel + gleicher Wert!) nicht zusätzlich gespeichert, so dass kein unnötiger Storage-Verbrauch entsteht. Hierdurch können auch problemlos regelmäßig überlappende Zeitbereiche aus Drittquellen abgefragt und eingespeist werden: Die hetida Plattform handelt Duplikate wie beschrieben sinnvoll.


Anwendungsfälle

Retrospektive Analysen

Analysen und Berichte können exakt für den Zeitraum und den Datenstand ausgeführt werden, der zum Berichtszeitpunkt vorlag — unabhängig davon, ob seither Korrekturen oder Nachlieferungen stattgefunden haben. Das ist besonders relevant für monatliche oder quartalsweise Berichte, die reproduzierbar sein müssen.

Fehleranalyse und Auditing

Tritt ein unerwartetes Verhalten in einer Anlage auf, lässt sich der genaue Datenzustand zum Zeitpunkt des Ereignisses rekonstruieren. Dashboards, Workflow-Ergebnisse und Signalverläufe können so betrachtet werden, wie sie im Moment der Störung vorlagen — ohne dass nachträgliche Datenkorrekturen die Sicht verfälschen.

Validierung von Datennachlieferungen

In industriellen Umgebungen treffen Messdaten häufig mit Verzögerung ein — etwa wenn Feldgeräte im Offline-Betrieb gepuffert haben und Daten erst später synchronisieren. Mit der Zeitreisefunktion kann überprüft werden, wie sich eine nachgelieferte Datenmenge auf historische Auswertungen auswirkt.

Test und Qualitätssicherung

Neu entwickelte Workflows im hetida designer können rückwirkend gegen historische Datenbestände ausgeführt werden. Durch Vergleich der Ergebnisse aus zwei verschiedenen Betrachtungszeitpunkten lässt sich feststellen, ob eine Algorithmusänderung die erwarteten Auswirkungen hat.


Zeitreise und virtuelle Signale

Virtuelle Signale — berechnete Ergebnisse aus Workflow-Ausführungen — unterliegen ebenfalls dem bitemporalen Modell. Das bedeutet:

  • Persistente virtuelle Signale (zyklisch oder ereignisbasiert erzeugt) sind historisch vollständig nachvollziehbar: Jedes Berechnungsergebnis ist einem Einspeisungszeitpunkt zugeordnet.
  • Transiente virtuelle Signale (bei einer Ad-hoc-Anfrage berechnet) existieren nur für die aktuelle Anfrage und werden nicht persistent gespeichert. Sie stehen im Zeitreise-Modus nur dann zur Verfügung, wenn sie aus historisch zugänglichen Eingangsdaten neu berechnet werden können.

Einschränkungen

  • Der Betrachtungszeitpunkt kann nicht in die Zukunft gesetzt werden. Prognosewerte aus Workflows sind keine historischen Fakten und werden gesondert behandelt.
  • Daten, die vor der Einführung des bitemporalen Modells importiert wurden, besitzen möglicherweise keinen vollständigen Einspeisungszeitpunkt. In diesen Fällen wird der Importzeitpunkt als Näherungswert verwendet.
  • Konfigurationsänderungen an Assets, Devices oder Signalen sind historisch nachvollziehbar, soweit sie nach der Aktivierung des Zeitreise-Supports vorgenommen wurden.

Betrachtungszeitpunkt setzen

Der Betrachtungszeitpunkt wird in der Benutzeroberfläche über den Zeitreise-Schalter in der globalen Navigationsleiste gesetzt. Sobald ein historischer Zeitpunkt aktiv ist, zeigt die Plattform einen deutlich sichtbaren Hinweis an, der den aktuellen Betrachtungszeitpunkt und den Zeitreise-Status ausweist. Alle Ansichten — Dashboards, Signalverläufe, Workflow-Ergebnisse — aktualisieren sich automatisch auf den gewählten Stand.

Über die REST-API kann der Betrachtungszeitpunkt als Query-Parameter übergeben werden, um Zeitreise-Abfragen programmatisch in externe Systeme zu integrieren.