Maschinenzustände in SQL speichern: Data Historian mit Peakboard aufbauen

Peakboard erkennt jede Zustandsänderung an der Maschine – von RUN zu STOP, von SETUP zu RUN – und schreibt sie automatisch mit Zeitstempel in eine SQL-Datenbank. Aus dieser Zustandshistorie lassen sich Laufzeiten, Stillstandsdauern und OEE-Werte direkt berechnen, ohne dass eine einzige Zahl manuell eingetragen wird. Das ist der Peakboard-Ansatz für einen echten Data Historian: schlankes Datenbankschema, robuste Stored Procedure, clevere SQL-Abfragen.

Was ist ein Data Historian und warum brauche ich einen?

Ein Data Historian ist eine Datenbank, die Maschinenzustände und Prozessdaten fortlaufend mit Zeitstempel speichert. Im Unterschied zu einem einfachen Dashboard, das nur den aktuellen Zustand zeigt, entsteht beim Historian eine lückenlose Zustandshistorie: Maschine X war von 06:03 bis 07:41 im Zustand RUN, dann bis 08:15 im Zustand STOP, dann wieder RUN.

Aus dieser Grundlage lassen sich alle wichtigen Kennzahlen ableiten: Gesamtlaufzeit pro Schicht, Stillstandsdauer nach Ursache, OEE-Wert über Wochen, MTBF (Mean Time Between Failures) und MTTR (Mean Time To Repair). Peakboard baut diesen Historian ohne zusätzliche Software direkt auf einer SQL-Datenbank auf.

Das Datenbankschema: zwei Tabellen

Für den grundlegenden Aufbau werden zwei Tabellen benötigt:

Die erste Tabelle Machines hält pro Maschine eine Zeile mit aktuellem Zustand und Maschinennamen. Sie ist der schnelle Lookup für die Visualisierung: Welche Maschine läuft gerade, welche steht?

Die zweite Tabelle MachineStateHistory ist das eigentliche Herzstück des Historians. Sie enthält eine Zeile pro Zustandsänderung:

• ID — Primärschlüssel
• TS — Zeitstempel der Zustandsänderung
• MachineName — Maschinenbezeichnung
• State — neuer Zustand (z.B. RUN, STOP, SETUP)

Jedes Mal, wenn eine Maschine ihren Zustand wechselt, kommt eine neue Zeile dazu. Nie wird etwas überschrieben. Die vollständige Geschichte bleibt erhalten.

Die Stored Procedure: SetNewState

Statt UPDATE und INSERT direkt aus Peakboard zu senden, kapselt eine Stored Procedure die gesamte Logik. Beim Aufruf werden Maschinenname und neuer Zustand übergeben. Die SP aktualisiert dann den aktuellen Zustand in der Machines-Tabelle und schreibt gleichzeitig einen neuen Eintrag in die MachineStateHistory:

CREATE PROCEDURE [dbo].[SetNewState]
 @MachineName nvarchar(20),
 @State nvarchar(20)
AS
BEGIN
 UPDATE Machines SET state=@State WHERE machinename=@MachineName
 INSERT INTO MachineStateHistory (TS, MachineName, State)
 VALUES(getdate(), @MachineName, @State)
END


Warum Stored Procedure statt direkter Befehle? Drei Gründe: Die Logik lebt an einem einzigen Ort. Die Operation ist atomar – entweder beide Schreibvorgänge gelingen oder keiner. Und ein einziger Datenbankaufruf aus Peakboard genügt statt zwei separater Befehle.

In Peakboard wird die SP über einen Building-Block-Aufruf ausgelöst – zum Beispiel wenn ein OPC UA-Signal eine Zustandsänderung meldet oder der Werker am Touchscreen einen Grund einträgt.

Laufzeiten berechnen: der SQL LEAD-Befehl

Die Historian-Tabelle speichert Zeitstempel – aber noch keine Dauern. Um Stillstandszeiten und Laufzeiten zu berechnen, braucht jeder Datensatz den Zeitstempel des nächsten Zustandswechsels derselben Maschine. Genau das leistet der SQL-Befehl LEAD:

SELECT MachineName, State, TS as TimeStart,
 LEAD(TS) OVER (PARTITION BY MachineName ORDER BY TS) AS TimeEnd
FROM MachineStateHistory


PARTITION BY MachineName stellt sicher, dass LEAD nur innerhalb derselben Maschine springt. Das Ergebnis: jede Zeile hat jetzt einen Startzeitpunkt und einen Endzeitpunkt.

Im nächsten Schritt rechnet DATEDIFF die Zeitspanne in Minuten um:

WITH results AS (
 SELECT MachineName, State, TS as TimeStart,
   LEAD(TS) OVER (PARTITION BY MachineName ORDER BY TS) AS TimeEnd
 FROM MachineStateHistory
)
SELECT *, DATEDIFF(mi, TimeStart, TimeEnd) as TimeSpanInMinutes
FROM results;


Mit diesem Ergebnis-Set kann Peakboard per Dataflow aggregieren: Summe aller RUN-Minuten für Maschine A, Summe aller STOP-Minuten, Häufigkeit nach Zustand. Daraus ergibt sich direkt die Verfügbarkeitskomponente des OEE-Werts.

Von der Datenbank zum Dashboard

Peakboard liest das SQL-Ergebnis als Datenquelle ein und verarbeitet es per Dataflow weiter. Ein Dataflow kann die Rohdaten nach Maschine und Zustand gruppieren, die Minutensummen berechnen und als einfache Kennzahl auf dem Dashboard darstellen. Kein separates BI-Tool, keine manuelle Aggregation, keine Verzögerung.

Der Vorteil dieses Ansatzes gegenüber fertigen MES-Systemen: Das Datenbankschema ist selbst definiert und vollständig kontrollierbar. Die Stored Procedure lässt sich jederzeit erweitern – um zusätzliche Zustände, um Schicht-IDs, um Auftrags-Referenzen. Peakboard wächst mit.

Ohne eigene SQL-Pflege: Historisierung über den Peakboard Hub

Der SQL-Weg gibt dir volle Kontrolle über Schema und Abfragen – setzt aber voraus, dass du eine Datenbank selbst betreibst und pflegst. Wenn du das nicht willst oder Maschinendaten aus mehreren Boxen und Standorten zentral zusammenführen musst, übernimmt der Peakboard Hub die Historisierung.

Der Hub speichert Maschinen-, Sensor- und manuell erfasste Daten zentral, statt sie nur momentan anzuzeigen. Zwei Bausteine übernehmen dabei die Aufgaben, für die im SQL-Ansatz eigene Tabellen und die Stored Procedure zuständig sind:

• Hub Lists sind zentrale Datentabellen, die alle angebundenen Boxen gleichzeitig lesen und beschreiben. Hier landet die Zustandshistorie, ohne dass du selbst ein Datenbankschema anlegst.
• Hub Flows sind zentrale Abläufe, die du einmal definierst und auf dem Hub-Server ausführst – etwa das Erfassen jeder Zustandsänderung, das Bündeln vieler Maschinenmeldungen oder das Zurückschreiben von Kennzahlen an ERP und MES.

Besser oder schlechter ist dabei die falsche Frage – es geht um Aufwand und Reichweite. Eine einzelne Linie mit eigener Datenbank ist per SQL schnell abgebildet. Sobald aber mehrere Boxen, mehrere Werke oder laufend neu erfasste Daten zusammenkommen, nimmt dir der Hub die Verwaltung ab: von der zentralen Datenhaltung bis zum automatischen Rollout an die gesamte Geräteflotte.

Verbindung zu OEE und Machine Monitoring

Der Data Historian ist die Datenbasis für alle weiterführenden Auswertungen. Die OEE-Kennzahl braucht Laufzeiten und Stillstandsdaten – beides liefert der Historian. Das Downtime-Tracking nutzt die Zustandshistorie für Musteranalysen über Wochen. Und das Machine Monitoring zeigt den Echtzeit-Status – der Historian speichert alles, was in Echtzeit passiert, für die spätere Analyse.

Wer die historisierten Daten nicht nur in Peakboard, sondern auch in tieferen Reports auswerten möchte, kann die SQL-Datenbank direkt als Datenquelle für Power BI nutzen – Peakboard zeigt die Live-Ansicht am Shopfloor, Power BI liefert die Wochenauswertung für das Management.