Was ist ein Industrial Historian? Die Prozessdatenbank für Zeitreihen

Ein Historian speichert Prozessdaten: einfache Datenpunkte, die kontinuierlich oder bei Änderung aufgezeichnet werden, jeweils als Wert mit Zeitstempel. Dazu kommt bei industriellen Quellen die Qualität, also die Auskunft, ob einem Wert zu trauen ist. Aus diesen Reihen lässt sich der Zustand einer Anlage über die Zeit analysieren.

Drei Verfahren prägen, was am Ende in einem Historian steht, und sie greifen an verschiedenen Stellen:

Das Totband ist ein Band um den zuletzt übertragenen Wert. Ein neuer Wert wird erst weitergegeben, wenn er dieses Band verlässt, danach zentriert sich das Band auf den neuen Wert. Kompression dagegen ist eine Eigenschaft des Historians selbst. Wie sie arbeitet, legt jeder Hersteller fest.

Ein Historian ist ausdrücklich nicht der Ort, an dem der aktuelle Wert verteilt wird. Das leistet ein Unified Namespace; wie Werte in ihn hinein- und wieder herauskommen, beschreibt Unified Namespace anbinden. Ein Unified Namespace ersetzt keine Langzeithistorie; diese liegt typischerweise in einem Historian, einer Zeitreihendatenbank oder einem Data Lake, der laut pronubes aus dem Namespace liest. Auch ein Zwischenspeicher, der je Topic nur die letzte Nachricht aufbewahrt, ist kein Historian.

Die beiden beantworten verschiedene Fragen, und in vielen Werken stehen sie nebeneinander.

Der Unterschied liegt vor allem im Bezug. Zusammenhängende Datensätze tragen Referenzen auf Auftrag, Charge oder Material, und dafür ist die relationale Datenbank gebaut. Eine Zeitreihe macht sich dort an der Schreiblast bemerkbar: Indizes beschleunigen Abfragen, verlangsamen aber jedes Einfügen, und häufig aktualisierte indizierte Spalten fragmentieren. Ob das stört, ist eine Frage der Menge. Laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) speicherten zwei Automobilzulieferer in der Türkei ihre Produktionsdaten in einer SQL-Datenbank; beide Fälle nennen dabei ausdrücklich die historische Datenerfassung. Wie sich Datenbankarten unterscheiden, erklärt Was ist eine Datenbank? auf manubes.de.

Ein SCADA-Server übernimmt Datenhaltung, Alarmlogik und Historie, und auch Bedienpanels können eigene Historien führen. Der Trend im SCADA dient der laufenden Schicht: Er zeigt, was eben passiert ist. Ein Historian sammelt über viele Quellen hinweg und für Jahre.

Praktisch zählt eine zweite Frage: Kommt man an die Daten heran? Ein Historian ist dafür gebaut, gelesen zu werden. Der Artikel Was ist SCADA? erklärt, wann ein SCADA seine Trends nach außen gibt und warum ein aggregierter Wert aus der Historie eine Rechnung ist und keine Messung. Dieser Artikel behandelt die Frage davor: Was ist bei der Ankunft im Historian schon verdichtet worden?

Er liest aus Steuerungen, OPC-Servern und SCADA und liefert an Auswertung, MES und Cloud. In der Automatisierungspyramide ist er damit weniger eine eigene Ebene als ein Speicher, den mehrere Ebenen benutzen. Die OPC Foundation führt Historians in ihrer ISA-95-Spezifikation OPC 10030 unter Level 3. Was auf dem Weg dorthin verdichtet oder verworfen wurde, steht dort nicht mehr.

Der Markt reicht von klassischen Industrie-Historians bis zu allgemeinen Zeitreihendatenbanken. Die Auswahl hier beschreibt, sie bewertet nicht.

• AVEVA PI System, früher OSIsoft PI: ein in der Prozessindustrie verbreiteter Historian.
• Proficy Historian: speichert unternehmensweit Prozess- und Produktionsdaten und bietet eine REST-API zum Abruf.
• Canary Historian: ein eigenständiger Industrie-Historian.
• InfluxDB: eine Zeitreihendatenbank, nicht auf die Industrie beschränkt.
• TimescaleDB: eine Erweiterung für PostgreSQL, die Zeitreihen in einer SQL-Datenbank hält.
• Ignition bringt Historie als eines seiner Module mit.
• Kepware Server (bis Version 6.18 KEPServerEX) führt in seiner Plug-in-Liste „Local Historian und OPC HDA“ sowie einen DataLogger, der Werte in ODBC-Datenbanken schreibt.

Über eine Anbindung, die aus Steuerung, OPC-Server oder SCADA liest und die Werte über die Schnittstelle ablegt, die der Historian zum Schreiben anbietet. Welche Werte überhaupt im Historian ankommen, bestimmt dabei die Auslösung.

Wertgesteuert überträgt der Data-Change-Trigger bei Änderung, auf Wunsch erst ab einer prozentualen oder absoluten Differenz. Gruppenweise bewertet der Multi-Datachange-Trigger bei OPC UA jeden Datenpunkt einer Gruppe mit eigenem Totband und erzeugt weniger und schlankere Transfers. Zyklisch liest der Cron-Trigger zu festen Terminen, bei vielen gleichartigen Adressen zusammen mit OPC Batch Read. Wo kein Ereignis fehlen darf, gehört ein Handshake mit Zähler in die Steuerung.

Als Ziel schreibt der OPC Router mit seinem Plug-in in InfluxDB, in relationale Datenbanken und mit dem Transferobjekt DB Log Table in eine Tabelle, die er bei Bedarf selbst anlegt. Bei anderen Historians hängt der Weg davon ab, welche Schnittstelle sie zum Schreiben anbieten. Der MQTT Data Storage des OPC Router ist kein solches Ziel: Er bewahrt nur die jeweils letzte Nachricht je Topic auf, eine Historie entsteht dabei nicht. Zu den Anwendern, die den OPC Router zusammen mit InfluxDB oder einem Historian eingesetzt haben, gehören laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) die folgenden:

• Ein spanischer Hersteller von Molkereiprodukten sammelte Daten von einem OPC-Server und versorgte damit seine PI-Systeme.
• Ein weltweit tätiger Hersteller von Getränkeverpackungen, in der Übersicht unter Belgien geführt, erfasste Auslöser aus der Fertigung und sandte sie an den Historian.
• Ein Hersteller von Haushaltsprodukten in den USA speiste Daten von OPC-Servern in InfluxDB ein und standardisierte die Anbindung über dynamische Vorlagen innerhalb und zwischen den Werken.
• Eine kanadische Universität protokollierte den Energieverbrauch ihrer Gebäude in InfluxDB, mit über 80 Verbindungen.
• Ein Hersteller von Dämmstoffen, in der Übersicht unter Japan geführt, ersetzte einen DCS-Historian durch InfluxDB, die alle paar Sekunden über 10.000 Datenpunkte übertrug.
• Ein Chemieunternehmen in Österreich setzte den OPC Router in mehreren Werken als Datendrehscheibe ein, je nach Standort unter anderem mit dem InfluxDB-Plug-in.

Die Qualität geht beim Schreiben in InfluxDB oder eine SQL-Tabelle verloren, wenn sie nicht als eigenes Feld mitgeschrieben wird. Der Data-Change-Trigger gibt sie mit „Metadaten ausgeben“ zusammen mit dem Zeitstempel aus, und Quality-String und Quality-ID lassen sich neben dem Wert in der Datenbank ablegen.

Wie viel eine Instanz schafft, zeigen zwei der Messreihen im Handbuch, gemessen mit einer früheren Version des OPC Router und KEPServerEX auf Servern mit 4 Kernen. Gelesen wurde per Batch Read aus zwei KEPServerEX-Simulatoren, geschrieben gleichzeitig an MQTT und InfluxDB, geprüft nach 30 Minuten Laufzeit: 320.000 Datenpunkte je 30 Sekunden kamen vollständig in InfluxDB an, bei 640.000 waren es mehr als 99 Prozent. In der zweiten Messreihe mit dem Multi-Datachange-Trigger gingen rund 28.500 Datenpunkte pro Sekunde an MQTT und InfluxDB; dort begrenzte der OPC-Server. Beide Messreihen stehen mit ihren Projektdateien im Kapitel Performanceanalyse des Handbuchs. Neuere Messungen dieser Art enthält das Handbuch nicht.

Auf drei Wegen, je nachdem, was der Historian anbietet.

Über OPC UA Historical Access. Das Transferobjekt „OPC HA Lesen“ liest aus einem OPC-UA-Historian, roh oder verarbeitet. Für periodische Berichte nützlich ist die Zeitsyntax: -1month day(1) bezeichnet den Monatsersten des Vormonats, -1year month(1) day(1) den Jahresersten des Vorjahres. Voraussetzung ist, dass der Server Historical Access nach der OPC-UA-Spezifikation unterstützt. Was das vom Server verlangt und was die Lesemodi roh und verarbeitet unterscheidet, steht im Artikel Was ist SCADA?, was Historical Access ist, in Was ist OPC UA?

Über eine Programmierschnittstelle. Proficy Historian lässt sich über seine REST-API abfragen, der OPC Router tut das mit dem REST-Plug-in, wie fünf Anwendungsfälle der REST-API zeigen.

Über SQL. Liegt die Historie in einer relationalen Datenbank, liest ein Select mit Filter. Grafana liest direkt aus InfluxDB und aus SQL-Datenbanken. Power BI liest die SQL-Datenbank direkt, für InfluxDB braucht es einen zusätzlichen Connector oder Treiber. Eine Middleware ist auf diesem Weg nicht nötig.

Eine Anbindungsschicht entkoppelt an dieser Stelle Analyse und Datenextraktion. Laut der Anwenderübersicht (Stand der Seite: Juli 2026) konnte der spanische Molkereihersteller seine Datenanalysesysteme ändern, ohne die Art der Datenextraktion aus dem Prozess zu ändern. Den Fall beschreibt auch der Artikel Was ist SCADA?

Die Einstellungen auf dem Weg in den Historian sind jede für sich vertretbar. Sie wirken erst zusammen, und die Folge zeigt sich an anderer Stelle als dort, wo eingestellt wurde. Eine weitere Ursache liegt im Ziel selbst: Ist der Historian nicht erreichbar, fehlen die Werte aus dieser Zeit, sofern die Anbindung sie nicht zwischenspeichert und nachreicht (Store and Forward). Woran sich eine solche Lücke zeigt, steht in Was ist SCADA?

Zweimal verdichtet: Totband an der Anbindung, Kompression im Historian

Der Historian zeigt über Stunden eine flache Linie ohne jede Stützstelle, und Extremwerte, die im Leitsystem stehen, fehlen im Historian. Die flache Linie kann ein ruhiger Wert sein oder eine Quelle, die nichts mehr liefert. Eine Anbindung, die nur bei Änderung schreibt, schreibt bei Stillstand der Quelle ebenfalls nichts; „kein neuer Wert“ und „kein Wert“ sehen gleich aus. Die fehlenden Spitzen hat schon das Totband verworfen, bevor sie die Kompression des Historians erreichten. Beides zusammen ergibt eine Auflösung, die so nicht festgelegt wurde.

Beim Betreiber liegt die fachliche Entscheidung über das Totband je Größe. Sie muss zur Kompression passen, die im Historian eingestellt wird; werden beide getrennt festgelegt, wird zweimal verdichtet. Dazu kommt das Totband, das der OPC-Server selbst schon anwenden kann; Was ist ein Prozessleitsystem? beschreibt es. Bei der Auswertung ist außerdem zu berücksichtigen, dass eine flache Linie innerhalb des Totbands eine Änderung enthalten kann.

Im OPC Router lässt sich das Totband im Flow an mehreren Stellen einstellen: am Data-Change-Trigger als prozentuale oder absolute Differenz, im Change Gate, das nachgelagerte Schritte nur bei relevanter Änderung ausführt, als absolute oder prozentuale Schwelle und am Multi-Datachange-Trigger je Datenpunkt im Reiter „Auslöseverhalten je Datenpunkt“, wo es sich über „Ausnahmen für Teilbäume“ je Anlagenteil anders setzen lässt. Diese Bewertung je Datenpunkt liegt im Arbeitsspeicher und beginnt nach einem Verbindungsabbruch neu. „Mindestens alle“ überträgt den aktuellen Wert nach Ablauf des Intervalls auch ohne Änderung und liefert damit eine Stützstelle.

Diese Stützstelle zeigt, dass die Anbindung lebt, nicht, dass der Wert frisch ist: Bei einer eingefrorenen Quelle schreibt sie den eingefrorenen Wert fort. Dafür sind Zeitstempel oder Qualität der Quelle mitzuschreiben, die „Metadaten ausgeben“ liefert. Der Data-Change-Missing-Trigger löst aus, wenn sich ein Datenpunkt innerhalb eines Prüfzeitraums nicht ändert. Das Change Gate verwirft Werte aus seiner Sperrzeit. Mit „Nachholen blockierter Öffnungen“ holt es den zuletzt eingetroffenen Wert nach, nicht den auffälligsten, und das erst, wenn nach Ablauf der Sperrzeit der nächste Zyklus eintrifft.

Vorverdichtet heißt nicht zeitgewichtet

Der Mittelwert im Historian weicht in Phasen mit schnellen Wechseln von dem ab, den der Historian aus Rohdaten gerechnet hätte, und in ruhigen Phasen fehlen Zeilen. Gemittelt wurde vorher in der Middleware, um den Historian zu entlasten: bei sekündlicher Erfassung ein Wert je 15 Minuten statt 900 Einzelwerten. Ein arithmetisches Mittel über wertgesteuert geschriebene Werte gewichtet nach Anzahl, nicht nach Zeit. Ein Wert, der zehn Minuten anstand, zählt so viel wie einer, der eine Sekunde dauerte, und eine Phase mit schnellen Wechseln zieht den Mittelwert zu sich. Mehr dazu steht im SCADA-Artikel. Außerdem schließt ein Zeitfenster erst mit dem ersten Schreibvorgang nach seinem Ende, und ein Fenster ohne Schreibvorgang liefert keinen neuen Wert. Das ist der Fall, wenn ein Totband davor einen ruhigen Wert zurückhält.

Beim Betreiber liegt die Entscheidung, welcher Mittelwert gilt, und sie richtet sich nach der Auswertung: zeitgewichtet für Zustandsgrößen wie eine Temperatur, arithmetisch für gezählte Ereignisse. Außerdem muss feststehen, ob die Rohwerte zusätzlich in den Historian gehen.

Ein vorverdichteter Wert lässt sich später nicht mehr aufschlüsseln.

Im OPC Router lassen sich Kennzahlen je Zeitfenster bilden. Eingestellt wird das im Variablen-Plug-in im Bearbeiten-Dialog einer globalen Variable mit Aufbewahrung: „Aggregation aktivieren“, „Fensterdauer“ und die Kennzahlen. Zur Wahl stehen unter anderem Average, das arithmetische Mittel, und TimeAverage, das Werte nach ihrer Haltedauer zählt, dazu Total als Zeitintegral und Count. Count mitzuschreiben macht dünne Fenster sichtbar. Die Fenster liegen auf einem festen UTC-Raster. Gelesen wird die Kennzahl mit dem Variablen-Trigger, denn ein Time-Trigger liegt nicht auf dem Fensterraster und kann noch das vorherige Fenster lesen. Zwei identische Fenster nacheinander lösen nicht aus.

Gebündelt geschrieben, einzeln verloren

Der Flow ist grün, im Historian fehlen trotzdem Werte. Sichtbar wird das nur im Log und im Vergleich der Anzahl geschriebener mit der Anzahl gelesener Werte. Für den Durchsatz wird in Paketen geschrieben, und ein Fehler in einem Paket lässt sich dann keinem Flow mehr zuordnen. Null-Werte können je nach Einstellung ohne Meldung verworfen werden, und nahe an der Lastgrenze kommt nicht mehr jeder Wert an.

Beim Betreiber liegt die Entscheidung, wo Durchsatz wichtiger ist als die Fehlerzuordnung je Flow; dort ist das Log zu überwachen. Er legt fest, ob eine fehlende Zahl als Lücke sichtbar werden soll oder ersetzt werden darf, und plant die Last mit Abstand zur gemessenen Grenze.

Im OPC Router schaltet im Plug-in InfluxDB 2.0/3.0 & Cloud die Option „Verwenden Sie gestapelte und verzögerte/asynchrone Inserts“ das gebündelte Schreiben ein. Laut Handbuch bleiben Flows dann grün, auch wenn Inserts fehlschlagen; die Fehler werden geloggt. Bei gebündeltem Schreiben sollte die „Zeitstempel Quelle“ im Transferobjekt nicht „InfluxDB“ sein. InfluxDB stempelt die Werte dann erst beim Empfang, und Werte, die in derselben Nanosekunde verarbeitet werden, können zusammengefasst werden. Das Handbuch warnt in diesem Fall vor Datenverlust und empfiehlt „OPC Router (UTC)“ oder einen dynamisch übergebenen Zeitstempel. Das Null-Handling steht als Vorgabe im Plug-in und je Transferobjekt: „Fehler“ bricht den Transfer ab, „Einfügen Verwerfen“ verwirft ohne Fehlermeldung, dazu „Wert weglassen“ und „Wert Ersetzen“. Für mehr Last lassen sich die Anbindungen auf mehrere Instanzen verteilen.