Was ist eigentlich ein “Historian”?

In einer Industrie-4.0-Architektur fungiert ein Historian wie das Langzeitgedächtnis der Produktion. Während der Unified Namespace (UNS) immer den aktuellen Zustand Ihrer Anlagen, Sensoren und Prozesse zeigt, sammelt und speichert der Historian fortlaufend alle relevanten Daten über längere Zeiträume hinweg.

Was bringen solche Daten?

In meiner Erfahrung werden historische Daten umso wertvoller, je zugänglicher sie für die richtigen Leute sind. Der Historian erlaubt es Prozessexperten und Produktionsleitern, vergangene Maschinen- und Prozessdaten geordnet abzurufen. Anstatt mühselig alte Tabellen oder verstreute Aufzeichnungen zu durchforsten und auszuwerten, stehen dir in Visualisierungstools wie Grafana dann verlässliche und vollständige Informationen jederzeit zur Verfügung.

Ganz konkret:

• Das Engineering bei einem Kunden hat in den historischen Daten aus dem Betrieb seiner Anlagen erkannt, dass die Motoren ihrer Maschinen von Kunden nur selten nahe ihrer Nennleistung genutzt wurden. In der nächsten Produktgeneration konnten die Motoren kleiner dimensioniert werden – ohne Einbußen bei der Performance. Das spart nicht nur Kosten für das Unternehmen und seine Kunden, sondern schont auch die Umwelt.
• Im Vorfeld einer wichtigen Messe nutzte das Marketingteam eines Kunden historische Daten, um entscheidende Verkaufsargumente für die eigene Automatisierungslösung zu schaffen. Denn die Daten belegten: die Lösung spart Energie und führt zu einer besseren Qualität.
• Ein Projektpartner setzt mit einem Kunden ein ambitioniertes Machine Learning Projekt um, mit dem Ziel mehrere kritische Fehlerarten in der Stahlfertigung vorherzusagen. Eine InfluxDB auf der Edge sammelt und speichert alle Datenpunkte, auf die es ankommt.
  

Je nach Einsatzzweck kann ein Historian auf unterschiedliche Art realisiert werden.

1. Edge Historian:
   Dieser befindet sich direkt an der Anlage oder in der Fabrikhalle. Er zeichnet lokale Prozesswerte auf, liefert schnelle Einblicke in aktuelle Geschehnisse und unterstützt kurzfristige Analysen, etwa um sofort auf Veränderungen reagieren zu können.
2. Enterprise Historian:
   Hier werden Daten mehrerer Produktionslinien oder gar -Standorte zentral zusammengeführt und harmonisiert. Der Historian liefert ein umfassendes Gesamtbild, ermöglicht Vergleiche zwischen verschiedenen Anlagen oder vereinfacht es Zusammenhänge zu erkennen, die sich nur dann zu erkennen sind, wenn Daten über die ganze Prozesskette hinweg zusammenfliessen.
3. Data Lakes als „Historian“:
   Ein Data Lake ist eine große, oft Cloud-basierte Datenablage, in der alle Zeitreihen-Ereignisse (Maschinendaten, Logbuch-Einträge, Qualitätsinformationen) ohne starre Strukturen gespeichert werden. Zwar benötigt man zusätzliche Tools, um Daten für Analysen oder Visualisierungen aufzubereiten, doch bietet ein Data Lake enorme Flexibilität und Skalierbarkeit – besonders, wenn es um komplexe Auswertungen oder Machine-Learning-Modelle geht.

Historian Software kaufen oder Open Source Datenbanken nutzen?

Der Gedanke, der eigenen Fertigung ein Langzeitgedächntnis zu verleihen kein ganz Neuer. Auch bevor “reif für den KI-Einsatz” als neue Zielgrösse in den IT-Strategien von Unternehmen auftauchte, hatten viele Produktionsleiter und Prozessexperten für sich erkannt, welche Potenziale in der Problemursachenforschung oder Prozessoptimierung auf der Strecke blieben, wenn Prozessdaten nicht in Datenbanken erhalten bleiben. Mit dem Anwendungsfall “Historian” gehen für die Datenspeicherung ein paar Spezialanforderungen einher.

• Im Fertigungsprozess entstehen binnen kurzer Zeit immense Datenmengen. Bei den ca. 100 Maschinen in der “Smart Factory” von Rittal sind das zum Beispiel 16 Terabyte an Rohdaten pro Tag. Um zu gewährleisten, dass Datenbanken performant bleiben, rücken Fragen in den Vordergrund, wie diese Datenmengen zu beherrschen sind: Welche Daten werden als Rohdaten abgespeichert und welche aggregiert? Reichen mir die informationsverlustfreie Datenkomprimierungsalgorithmen, wie sie in jeder Datenbank implementiert sind, oder bin ich bereit einen gewissen Informationsverlust zugunsten einer viel stärkeren Kompression einzugehen?

• Gewöhlich strebt man an, jeden Datenpunkt (man redet hier typischerweise von “Tags”) mit seiner Bedeutung verknüpft abzuspeichern. Das heisst, ausgehend von dem Temperaturwert eines des Temperatursensors PT344X2 sollte ich zum Beispiel auch in der Lage sein, genau nachvollziehen zu können, um die Temperatur welches Systemelements es sich dabei handelt, ob es sich um °C oder °F handelt und in welchem Wertebereich der Sensor aufzeichnet. Und das sollte auch dann möglich sein, wenn die Fertigung deren Daten ich speichere, einem kontinuierlichen Veränderungsprozess unterliegen.

Spezialisierte Historian Softwarelösungen (z.B. Canary Labs, AVEVA oder OSIsoft Pi) wurden speziell entwickelt, um derartige Anforderungen von Haus aus abzudecken. Man braucht aber keine Historian Software, um einen Historian zu realisieren, weshalb sich immer mehr Unternehmen dafür entscheiden, ihre Lösung auf erprobten Open Source Technologien aufzubauen. Eine tiefgehendere Erklärung, warum man das in Betracht ziehen sollte liefert Jeremy Theocharis vom United Manufacturing Hub in diesem Video.

‍

In der Praxis könnte das ganz konkret so aussehen.

Ein Datenlogger sammelt nahezu in Echtzeit alle relevanten Prozessdaten deiner Maschine und streamt die über MQTT, wo eine InfluxDB (eine auf Zeitreihen optimierte Datenbank) unmittelbar an der Maschine auf Updates hört und diese dann speichert (Edge Historian). Wichtige Datenpunkte werden aggregiert und gemeinsam mit den Daten weiterer Produktionsprozesse, mit Auftragsdaten und Qualitätsdaten in einer SQL-Datenbank im Unternehmensnetzwerk abgespeichert (Enterprise Historian). Damit die Datenbanken nicht zu gross werden, landen alte Zeitreihen komprimiert als Parquet-Dateien im unternehmenseigenen Data Lake - ebenfalls Bilddaten und Dokumente. Von dort aus können sie jederzeit zu Visualisiserungs- und Auswertungszwecken geladen werden.

Jetzt wirst du dir vielleicht denken: “Der Aufbau einer solchen Datenarchitektur muss ein ziemliches Ressourcenmonster sein, oder?”

Und damit liegst du nicht falsch, denn ich spreche regelmässig mit Mittelständlern, die mit ganz konkreten Innovationsideen gestartet sind und dann:

• nach der Blaupause von Grosskonzernen sich in Kollaboration mit externen Solutions Architects eine aufgeblasene Datenarchitektur haben entwerfen lassen,
• über einen Zeitraum von 3 Jahren hunderttausende Euro bis hin zu einem kleinen Millionenbetrag an Entwicklungspartner überwiesen haben,
• sich dabei sind, eine Lösung zu schaffen, die ohne Weiteres nur einer oder wenige Entwicklungspartner weiterentwickeln können (Vendor-Lock-In ist nichts dagegen!),
• unterwegs so viele Learnings gemacht haben, dass sie noch vor dem ersten wirklichen Roll-Out, sich mit der Frage auseinandersetzen, ob es nicht sinnvoll wäre das Projekt einzustampfen und direkt mit der Version 2.0 anzufangen.

Wir sind der Meinung, dass der Weg zur “Smart Factory” des Mittelstands einer schlanker sein muss. Aus dieser Meinung leiten wir unsere Prinzipien bei der Entwicklung von PREKIT her. Der erste PREKIT Baustein kommt als vorkonfigurierter Industriecomputer, von Haus aus bereits mit einer integrierten InfluxDB, die lokal an der Maschine alle Prozessdaten einspeichert und per Apps für die Visualisierung und Auswertung verfügbar macht. Später kann, flexibel zu jedem Zeitpunkt, eine übergeordnete PREKIT-Instanz als Service im eigenen Netzwerk oder der Cloud die Daten der ganzen Fertigung zusammenführen. Somit lässt sich die gesamte zuvor beschriebene Referenzarchitektur nahezu “out of the box” realisieren - als flexible und komplett offene Plattform.

‍