Wichtigste Erkenntnisse
Kurze Antwort: Ein Data Historian und eine relationale Datenbank sind zwei Möglichkeiten, Daten zu speichern, die jeweils für unterschiedliche Datentypen optimiert sind.
Ein Data Historian (oder Prozesshistorian) ist speziell entwickelte Software, um hochfrequente Zeitreihendaten aus industriellen Prozessen zu erfassen, zu komprimieren und zu speichern, tausende Tag-Lesungen pro Sekunde von Sensoren und Steuerungssystemen, mit schneller zeitbasierter Abfrage.
Eine relationale Datenbank ist universell einsetzbare Software, die für strukturierte, transaktionale Daten in Tabellen optimiert ist, mit SQL-Abfragen, Beziehungen und ACID-Transaktionen. Historian-Systeme eignen sich für zeitgestempelte Sensordatenströme; relationale Datenbanken eignen sich für strukturierte Datensätze wie Aufträge, Arbeitsaufträge und Bestände.
Sie ergänzen sich und die meisten Anlagen betreiben beides.
Ein Data Historian, auch Prozess- oder Betriebs-Historian genannt, ist Software, die speziell entwickelt wurde, um hochfrequente Zeitreihendaten aus industriellen Prozessen zu erfassen, zu speichern und abzurufen.
Seine Aufgabe ist es, den kontinuierlichen Strom zeitgestempelter Messwerte von Sensoren, Messgeräten und Steuerungssystemen (PLCs, SCADA, DCS) zu protokollieren, Temperaturen, Drücke, Durchflüsse, Drehzahlen, Zustände, oft tausende „Tags“, die viele Male pro Sekunde, rund um die Uhr, über Jahre hinweg abgetastet werden.
Um dieses Volumen zu bewältigen, verwenden Historian-Systeme spezialisierte Zeitreihen-Speicherung mit aggressiver Kompression (wie Deadband- und Swinging-Door-Algorithmen, die nur aussagekräftige Änderungen speichern) und sind für schnelle Abfragen nach Zeitbereich optimiert: „zeige mir die Werte dieses Tags über die letzte Schicht“ liefert sofort Ergebnisse.
Historian-Systeme sind auf die Realitäten von Anlagendaten ausgelegt: extrem hoher Schreibdurchsatz, lange Aufbewahrungszeiträume, zeitbasierte Abfragen und Ausfallsicherheit. Sie integrieren sich typischerweise direkt mit der Steuerungsebene und bieten Trenddarstellung, Aggregation und Zugriff für Analysen.
Die definierende Stärke eines Historians ist das effiziente Handling massiver, kontinuierlicher, zeitgestempelter Sensordaten, die vollständige Wiedergabe des Verhaltens eines Prozesses über die Zeit in komprimierter und abrufbarer Form.
Er ist nicht dafür ausgelegt, komplexe relationale Abfragen oder transaktionale Aufzeichnungen zu verwalten; er ist als hochschnelles Zeitreihen-Speicher der Werkhalle konzipiert.
Eine relationale Datenbank (RDBMS) ist universell einsetzbare Software zur Speicherung strukturierter Daten in Tabellen, optimiert für Transaktionen, Beziehungen und komplexe Abfragen.
Daten werden in Tabellen mit Zeilen und Spalten und definierten Schemata organisiert, durch Schlüssel miteinander verknüpft und mit SQL abgefragt, was leistungsfähiges Filtern, Joinen und Aggregieren über strukturierte Datensätze ermöglicht.
Relationale Datenbanken bieten ACID-Transaktionen (Atomizität, Konsistenz, Isolation, Dauerhaftigkeit), die die Datenintegrität für Operationen gewährleisten, die nicht teilweise abgeschlossen werden dürfen, essentiell für Dinge wie Aufträge, Zahlungen und Bestandsbewegungen.
Sie glänzen bei strukturierten, transaktionalen, relationalen Daten: Kundenstammdaten, Arbeitsaufträge, Bestände, Produktionsaufzeichnungen, Stücklisten, alles, was sich sauber in verknüpfte Tabellen einordnen lässt und zuverlässige, konsistente Aktualisierungen sowie umfangreiche Abfragen benötigt.
Die definierende Stärke einer relationalen Datenbank ist das Management strukturierter Daten mit Integrität und flexiblen Abfragen: Sie erzwingt Konsistenz, modelliert Beziehungen und beantwortet komplexe Fragestellungen über die Daten hinweg.
Wofür sie nicht optimiert ist, ist der extreme Schreibdurchsatz und die zeitbasierte Abfrage hochfrequenter Sensordaten; Millionen schneller Zeitreihenwerte in einer generischen relationalen Tabelle zu speichern ist im Vergleich zu einem spezialisierten Historian ineffizient.
Die relationale Datenbank ist das Arbeitstier für die strukturierten, transaktionalen Aufzeichnungen der Anlage, nicht für den rohen Sensordaten-Feuerstrom.
Der Kernunterschied ist die Art der Daten, für die jedes System gebaut ist: Ein Historian ist für hochfrequente Zeitreihendaten von Sensoren optimiert, eine relationale Datenbank für strukturierte transaktionale Daten. Dieser Unterschied im Zweck bestimmt alles andere.
Historian-Systeme nutzen zeitreihenorientierte Speicherung mit starker Kompression und zeitindiziertem Abruf, abgestimmt auf enorme Schreibraten und „Wert über Zeit“-Abfragen; relationale Datenbanken nutzen Tabellen, Schemata, Schlüssel, SQL und ACID-Transaktionen, abgestimmt auf strukturierte Datensätze, Beziehungen und konsistente Aktualisierungen.
Sie beantworten unterschiedliche Fragen: Ein Historian beantwortet effizient „Was hat dieser Sensor jede Sekunde letzte Woche gelesen?“; eine relationale Datenbank beantwortet effizient „Welche Arbeitsaufträge für dieses Asset sind überfällig und welche Teile benötigen sie?“
Beide sind schlecht im jeweils anderen Job: Eine relationale Datenbank gerät beim Speichern und Abfragen von Millionen schneller Sensormessungen ins Stocken, und ein Historian ist nicht dafür gebaut, strukturierte relationale Datensätze mit Integrität zu modellieren und zu transagieren.
Deshalb ergänzen sie einander statt zu konkurrieren: Die Anlage erzeugt beide Datentypen, einen kontinuierlichen Messstrom (Historian) und strukturierte operative Aufzeichnungen wie Aufträge und Bestände (relationale Datenbank), und jeder Datentyp gehört in das dafür vorgesehene Speicherfach.
Die Wahl zwischen ihnen ist im Grunde eine Frage, die Daten dem richtigen Werkzeug zuzuordnen. (Moderne Zeitreihendatenbanken verwischen die Grenze und bieten historianähnliche Zeitreihenleistung mit allgemeineren Abfragemöglichkeiten.)
Betrachten Sie die Daten, die eine einzelne Produktionslinie erzeugt. Ihre Maschinen streamen hochfrequente Prozessdaten: Schwingungen, Temperaturen, Motorstrom, Zyklenzählungen, Lauf/Stopp-Zustände, hunderte Tags, die viele Male pro Sekunde kontinuierlich abgetastet werden.
Dieser Datenstrom gehört in einen Data Historian: Er komprimiert und speichert die vollständige Zeitreihe kostengünstig, und ein Ingenieur kann sofort den Trend jedes Tags über beliebige Zeitfenster ziehen, um ein Problem zu untersuchen oder Analysen zu speisen.
Gleichzeitig erzeugt derselbe Betrieb strukturierte, transaktionale Datensätze: Produktionsaufträge, die zur Wartung angelegten Arbeitsaufträge, die aus dem Lager entnommenen Teile, die produzierten Chargen und deren Qualitätsfreigaben.
Diese gehören in eine relationale Datenbank: Sie passen in verknüpfte Tabellen, benötigen konsistente transaktionale Aktualisierungen (eine Lagerbuchung muss vollständig durchgeführt werden oder gar nicht) und werden relational abgefragt („zeige offene Arbeitsaufträge für dieses Asset und die Teile, die sie verbrauchen“).
Der Versuch, den Sensordaten-Feuerstrom in der relationalen Datenbank zu speichern, würde sie überlasten; der Versuch, transaktionale Arbeitsaufträge und Bestände im Historian zu verwalten, wäre nicht praktikabel.
Die Linie braucht beides: den Historian als hochschnelles Gedächtnis dafür, wie sich der Prozess verhalten hat, und die relationale Datenbank als System of Record für strukturierte operative Daten.
Oft sind die beiden verbunden, wobei zusammengefasste Historian-Daten mit den strukturierten Aufzeichnungen für Berichte verknüpft werden.
Wählen Sie nach der Art der Daten.
Verwenden Sie einen Data Historian für hochfrequente, zeitgestempelte Prozess- und Sensordaten, die kontinuierlichen Messungen von Maschinen und Steuerungssystemen, bei denen Sie die volle Auflösung über die Zeit erfassen, massive Volumina komprimieren und zeitbereichsbezogen für Trendanalysen abrufen müssen.
Verwenden Sie eine relationale Datenbank für strukturierte, transaktionale, relationale Daten, Aufträge, Arbeitsaufträge, Bestände, Produktions- und Qualitätsaufzeichnungen, alles, was in verknüpfte Tabellen passt und Integrität, konsistente Aktualisierungen und komplexe Abfragen benötigt.
In nahezu jeder Anlage lautet die Antwort beides, jeweils dort eingesetzt, wo es am stärksten ist: der Historian als Zeitreihenlager für den Prozess-Feuerstrom, die relationale Datenbank als System of Record für strukturierte operative Daten, oft integriert, damit beide zusammen analysiert werden können.
Ein moderner Aspekt sind Zeitreihendatenbanken (und cloudbasierte Zeitreihen-Services), die historianähnliche Leistung für Zeitreihen mit allgemeineren Abfragemöglichkeiten bieten und die Rolle des Historians überlappen können; und im großen Maßstab können Rohdaten aus dem Historian auch in einen Data Lake für fortgeschrittene Analysen eingespeist werden.
Der Entscheidungsrahmen ist einfach: Ordnen Sie den Speicher dem Datentyp zu, Zeitreihen-Sensorströme einem Historian (oder einer Zeitreihendatenbank), strukturierte transaktionale Aufzeichnungen einer relationalen Datenbank, und integrieren Sie die Systeme, anstatt eines das andere tun zu lassen.
Beide Speicher speisen die OEE auf komplementäre Weise.
Die hochfrequenten Maschinendaten, die ein Historian erfasst, Lauf/Stopp-Zustände, Zyklenzählungen, Drehzahlen, Fehlerindikatoren, sind das Rohmaterial, aus dem die Verfügbarkeit und die Leistung (Availability und Performance) der OEE berechnet werden; der Historian ist oft der Ort, an dem die granulare Prozessdatenlage hinter den Verlusten liegt und wo man nachforscht, warum ein Verlust aufgetreten ist.
Die strukturierten Aufzeichnungen, die eine relationale Datenbank hält, Arbeitsaufträge, Produktions- und Qualitätsaufzeichnungen, Stillstandsgründe, liefern den operativen Kontext und die transaktionale Seite der OEE, wie Wartungs- und Qualitätsdaten, die Verluste erklären und bewerten.
Ein vollständiges OEE-Bild verbindet in der Regel beides: die Zeitreihen-Bestätigung dessen, was die Maschine getan hat (Historian), mit den strukturierten Aufzeichnungen zu Aufträgen, Wartung und Gründen (relationale Datenbank).
Das hängt auch damit zusammen, wo rohe gegenüber modellierten Daten im Split zwischen Data Lake und Data Warehouse liegen, und mit den Steuerungssystemen (SCADA und DCS), die die Signale erzeugen.
Wie bei diesen Systemen gilt: Roh gespeicherte Daten sind noch keine OEE, eine Schicht muss die Historian-Tags und die Datenbankeinträge in das Verfügbarkeits-, Leistungs- und Qualitäts-Verlustmodell überführen, das Verbesserungen antreibt.
Fabrico verwandelt die Maschinendaten, egal ob sie gestreamt aus der Steuerungsebene oder im Historian gespeichert sind, in ein strukturiertes OEE-Verlustbild und verknüpft sie mit den operativen Aufzeichnungen (Stillstandsgründe, Arbeitsaufträge, Qualität), die die Verluste erklären und bewerten.
Anstatt rohe Zeitreihen-Tags im Historian und transaktionale Aufzeichnungen in einer separaten Datenbank zu belassen, liefert es die Aufschlüsselung von Availability, Performance und Quality über beide Ebenen, sodass die Daten eine klare Sicht darauf geben, wo produktive Zeit verloren geht.
Demo buchen, um zu sehen, wie Ihre Prozess- und Betriebsdaten zu handlungsfähiger OEE werden.
Ein Data Historian ist Software, die darauf optimiert ist, hochfrequente, zeitgestempelte Sensordaten aus industriellen Prozessen zu erfassen, zu komprimieren und zu speichern, mit schneller zeitbasierter Abfrage. Eine relationale Datenbank ist universell einsetzbar und für strukturierte transaktionale Daten in Tabellen mit SQL und ACID-Transaktionen optimiert. Historian-Systeme eignen sich für Sensordatenströme; Datenbanken eignen sich für strukturierte Datensätze.
Weil hochfrequente Sensordaten (tausende Messwerte pro Sekunde, über Jahre) generische relationale Tabellen überwältigen und zeitbasierte Abfragen langsam machen. Historian-Systeme verwenden spezialisierte Zeitreihenkompression und zeitindizierten Abruf, die für dieses Volumen und Nutzungsmuster gebaut sind, wofür relationale Datenbanken nicht optimiert sind.
Zum Erfassen und Speichern der kontinuierlichen, zeitgestempelten Messwerte von Sensoren und Steuerungssystemen (PLCs, SCADA, DCS), Temperaturen, Drücke, Durchflüsse, Drehzahlen, Zustände, in hoher Frequenz, mit Kompression und schneller Trendabfrage. Er ist das hochschnelle Zeitreihen-Gedächtnis der Anlage, genutzt für Trenddarstellung, Fehleranalyse und Auswertung.
Ja, in der Regel. Der Historian speichert den hochfrequenten Prozess-Feuerstrom; die relationale Datenbank ist das System of Record für strukturierte transaktionale Daten wie Aufträge, Arbeitsaufträge und Bestände. Jedes System wird dort eingesetzt, wo es am stärksten ist, und die beiden werden häufig integriert, damit Daten zusammen analysiert werden können.
Die hochfrequenten Maschinendaten des Historians (Laufzustände, Zählwerte, Drehzahlen) sind das Rohmaterial für die Verfügbarkeit und Leistung der OEE, während die strukturierten Aufzeichnungen der Datenbank (Arbeitsaufträge, Stillstandsgründe, Qualität) Kontext liefern und die Kosten der Verluste darstellen. Ein vollständiges OEE-Bild verbindet beides, und eine Schicht wandelt sie in das Verlustmodell um, das Verbesserungen antreibt.
Anmeldung
Blog