Rohdaten & Metadaten

Rohdaten sind unverarbeitete oder nur leicht normalisierte Ereignisse aus Maschinen, Steuerungen, Sensoren, Dateien oder angebundenen IT-Systemen. Sie enthalten häufig technische Feldnamen, herstellerspezifische Kodierungen und Signale, die erst im Anlagenkontext verständlich werden.

Typische Rohdaten enthalten:

• Zeitstempel
• Maschinen- oder Stationskennung
• Produkt- oder Werkstückkennung
• Statusbits, Zähler oder Schaltzustände
• Prozesswerte wie Temperatur, Kraft, Druck oder Weg
• Meldungsnummern, Alarmtexte oder HMI-Zustände

Für Rohdaten gilt: Sie sind, wie sie sind. In den meisten Fällen wollen wir Rohdaten nicht ändern, denn das würde in der Regel bedeuten, das Programm in der Steuerung direkt zu ändern. Es gibt Fälle, in denen das Sinn macht, zum Beispiel finden wir im Verlauf des Onboardings einer neuen Anlage häufig Programmfehler in der Steuerung wie fehlerhaft gesetzte Signale. In den meisten Fällen sollten wir Rohdaten aber so nehmen wie sie sind und der Datenvorverarbeitungsebene überlassen, diese Daten in die richige Form zu bringen.

Rohdaten werden daher zunächst möglichst unverfälscht gespeichert. Dadurch bleiben Spätanalysen möglich, auch wenn sich das fachliche Ziel später ändert.

Für die Weiterverarbeitung werden Rohdaten auf stabile Felder abgebildet. Beispiele sind assetId, partId, timestamp, status, cycleTime, errorId oder Prozessparameter wie temperature und pressure.

Rohdaten sind damit der technische Ursprung. Die produktionsfachliche Aussage entsteht erst später durch Logs, Regeln und Kontext.

Begriffe

Daten, die aus der Steuerung als Rohdaten im System ankommen, werden zunächst in ein bestimmtes Format für die Repräsentation im IT-System überführt. Dafür gibt es verschiedene Möglichkeiten und Wege mit jeweils eigenen Vor- und Nachteilen.

Zur besseren Einordnung nutzen wir die folgenden Begriffe:

• Ein Signal ist ein einzelner Datenpunkt, z.B. temperature.
• Mehrere Signale, die wir gemeinsam abfragen, bilden eine Datenstruktur.
• Diese Datenstruktur benötigt in der Regel noch einen Zeitstempel, welcher den Zeitpunkt der Erzeugung oder Erfassung des Signals abbildet.
• Fragen wir diese Datenstruktur zu bestimmten Zeiträumen aus der Steuerung ab oder erhalten wir bei geänderten Werten eine neue Nachricht aus der Steuerung, liegen diese als kontinuierlicher Datenstrom vor, der aus jeweils einzelnen Datenstrukturen besteht.
• Ein Datenstrom wird in der Regel über einen Kanal (Topic) übertragen, über welchen alle Nachrichten dieses Datenstromtyps übertragen werden. Dies erleichtert später die Auffindbarkeit bestimmter Daten (z.B. alle Messwerte einer Station).

Modellierungsansätze

Wie bereits erwähnt gibt es verschiedene Ansätze, Daten zu strukturieren. Ein besonders einfacher und generischer Ansatz wäre es, jedes Signal zusammen mit einem Zeitstempel zu repräsentieren:

Ein Messwert pro Nachricht

Topic A: Temperature

timestamp_ms: 123
value: 32

Topic B: Pressure

timestamp_ms: 123
value: 580

Bei diesem Ansatz ist die Datenstruktur immer gleich. Jede Nachricht besteht aus einem Zeitstempel und einem Wert. Die Semantik ergibt sich vor allem aus dem Topic, z.B. könnte man Temperaturdaten über das Topic companyA.cnc.temperature und Druck über das Topic companyA.cnc.pressure verschicken. Der Nachteil ist, dass es keine logische Gruppierung von Signalen gibt. In vielen Fällen lesen wir aus der Steuerung zusammengehörende Werte aus, z.B. Achsenmesswerte (X/Y/Z), zu einem Prozess zugehörige IDs wie der DMC-Code des aktuellen Bauteils oder weitere Eigenschaften. Möchte man Auswertungen über mehrere Signale durchführen, entsteht beim Konsumenten ein Synchronisationsaufwand.

Obwohl dieses Datenmodell also auf den ersten Blick einfach erscheint (da es gut übertragbar und daher schnell auf den gesamten Maschinenpark ausrollbar ist), verschiebt es die Komplexität zum Konsumenten. Dies ist aber etwas, was sich in wenigen Fällen geschieht, da nun der Konsument der Daten (z.B. Produktionsmitarbeiter) mit eher technischen Datenaufbereitungsaufgaben befasst wird. Eigentlich zusammengehörende Daten (z.B. Luftfeuchtigkeit und Temperatur) werden in einzelne Nachrichten aufgeteilt, obwohl sie im Analysekontext fast immer zusammen benötigt werden.

Aus diesem Grund empfehlen wir, mehrere Messwerte in eine Nachricht zu integrieren.

Mehrere Messwerte in einer Nachricht

Dieser Ansatz verfolgt eine logische Gruppierung von Daten in einer Struktur.

Wenn wir z.B. eine CNC-Maschine anbinden, würden alle Rohdaten, die den Fertigungsprozess betreffen, in einer Nachricht vorliegen:

timestamp_ms: 123
temperature: 50
pressure: 580
processing: true
dmc: ABC

Diese Datenstruktur bildet den Produktionsprozess gut ab. Die Steuerung setzt den Wert "processing" auf true, sobald die Bearbeitung eines Bauteils beginnt. Die Messwerte können entweder Live-Daten umfassen, die während des Prozesses kontinuierlich aktualisiert werden, oder Prozessparameter beschreiben, die nur am Ende der Bearbeitung gesetzt werden. Die Aufbereitung der Daten aus diesen Rohdaten in ein Produktionslog ist in einem späteren Transformationsprozess einfach, da nur ein einzelner Datenstrom für die Aufbereitung benötigt wird. Für Konsumenten der Daten ist dieses Modell gut verständlich, da es sich unmittelbar in Datenbanktabellen übertragen lässt und z.B. in Reportingtools verfügbar macht.

Wir empfehlen daher, für jeden Bearbeitungsprozess zunächst die Datenstrukturen festzulegen, die Signale aus logischer Sicht zusammenfasst.

In vielen Fällen bilden wir z.B. zwei Datenstrukturen pro Station oder Maschine: Einen für die Prozessdaten, aus welchem wir später das Produktionslog sowie Maschinenzustandslog generieren. Ein weiteres für Meldungsdaten, welche die Basis für das Alarm- und Eventlog bildet.

Metadaten

Neben Live-Maschinendaten sind Metadaten hilfreich, um neben den sich häufig ändernden Rohdaten das Schema der Datenstruktur zu beschreiben. Metadaten sind nicht nur hilfreich, um bei der automatischen Verarbeitung zu helfen, in dem z.B. die konkreten Datentypen modeliert werden. Metadaten machen durch aussagekräftige Beschreibungen Daten auch für Endnutzer zugänglicher, da direkt ersichtlich wird, welche Bedeutung die Daten haben.

Beispiele für Metadaten sind:

• Der Datentyp eines Signals, z.B. die Angabe, dass temperature eine Gleitkommazahl ist.
• Die semantische Bedeutung des Signals, z.B. ob temperature sich auf Getriebetemperatur oder Umgebungstemperatur bezieht
• Die dem Signal zugrundeliegende Messeinheit, z.B. Grad Celsius
• Der Messbereich des Signals, z.B. 0-100
• Der Scope des Signals, in der Regel verwenden wir hier Messwert für Messwerte oder Dimension für Dimensionen wie z.B. Baugruppen. Diese Angabe wird verwendet, um bei der visuellen Analyse von Daten zum Beispiel Messdaten nach Dimensions zu gruppieren und bspw. Temperaturen pro Baugruppe anzuzeigen.
• Zusätzliche Bezeichner wie Beschreibungen, um Nutzern der Daten weitere Hinweise auf deren Bedeutung zu geben.

Eine häufige Frage ist, wo Metadaten gespeichert werden. Grundsätzlich gibt es zwei Ansätze:

Im ersten Fall sind alle Metadaten Teil der Datenstruktur der Livedaten.

Vorgehen und Best Practices

Nutzung von Rohdaten in der Bytefabrik-Platform