Time-Series Database: Zeitreihendaten für Fertigung & Shopfloor

Was ist eine Time-Series Database?

Eine Time-Series Database (TSDB) ist eine Datenbank, die speziell für Zeitreihendaten optimiert ist – also Messwerte, die immer aus zwei Teilen bestehen:

• einem Zeitstempel (wann wurde gemessen?)

• einem Wert (was wurde gemessen?)

Beispiele im Produktionsumfeld:

• Temperatur, Druck, Drehmoment, Spindellast im Sekunden- oder Millisekunden-Takt

• Maschinenzustände (RUN/STOP/FAULT), Zählerstände, Takte

• Energie- und Medienverbräuche

• KPIs wie OEE, Durchsatz oder Defect Rate in kurzen Intervallen

Im Unterschied zu klassischen SQL-Datenbanken ist eine TSDB darauf ausgelegt, sehr viele Messpunkte mit hoher Frequenz über lange Zeiträume performant zu speichern und auszuwerten.

Warum braucht man eine Time-Series Database im Shopfloor?

Im Digital-Shopfloor-Kontext fallen drei harte Anforderungen zusammen:

1. Hohe Schreiblast
   Viele Maschinen, Sensoren, Linien schreiben permanent Daten.

2. Lange Historie
   Daten sollen über Monate/Jahre für Analysen, Audits und Optimierung verfügbar bleiben.

3. Zeitachsen-Analysen
   Man will Trends, Verläufe, Vergleiche („heute vs. letzte Woche“, „vor/nach Umbau“) sehen – nicht nur einzelne Werte.

Eine Time-Series Database ist genau dafür ausgelegt:

• Kompression von Zeitreihen (weniger Speicher, trotzdem präzise Verläufe)

• schnelle Abfragen über Zeitfenster („letzte 24h“, „Schicht 2“, „Batch 4711“)

• Aggregationen (Min/Max/Mittelwerte, Resampling auf 1s/1min/5min) direkt in der DB

TSDB vs. Historian, MES & klassisches SQL

• Prozessdaten-Historian
  Ein Historian ist im Kern eine spezialisierte Time-Series Database mit Industrie-Fokus (OT-Protokolle, Tag-Management, Visualisierung).
  → Jede Historian-Engine ist technisch eine TSDB, aber mit zusätzlicher Industrie-Funktionalität.

• MES / Cloud-MES
  MES speichert typischerweise kontextbezogene Ereignisse (Auftrag gestartet, Störung, NOK-Teil) und aggregierte Kennzahlen. Roh-Prozesswerte werden oft im Historian/TSDB gehalten und bei Bedarf angebunden.
  → MES = „Was ist passiert, mit welchem Auftrag/Teil?“
  → TSDB = „Wie sahen die Prozesskurven genau aus, Sekunde für Sekunde?“

• Relationale SQL-Datenbank
  Kann Zeitreihen theoretisch auch speichern, skaliert aber bei Industrie-Workloads (viele Tags, hohe Frequenz, lange Historie) deutlich schlechter und erfordert viel Tuning.

Typische Use Cases für Time-Series Databases in der Produktion

1. Process Monitoring & Troubleshooting

   • Trendkurven bei Störungen: „Was ist kurz vor dem Ausfall passiert?“

   • Overlay von Kurven („gute“ vs. „schlechte“ Zyklen) zur Mustererkennung.

2. OEE- & Performance-Analysen

   • Belastungsprofile, Mikrostopps, Geschwindigkeitsverluste aus Signalen ableiten.

   • Vergleich von Schichten/Linien auf Basis realer Laufprofile.

3. PAT & Predictive Quality

   • Multivariate Analysen auf Prozesskurven (Druck-/Temperaturverläufe, Kraft-Weg-Kurven).

   • Erkennen von Drifts und Abweichungen, bevor Qualitätsprobleme sichtbar werden.

4. Predictive Maintenance

   • Auswertung von Vibrations-, Strom- und Temperaturverläufen zur Vorhersage von Verschleiß und Ausfällen.

5. Energie- & Ressourcenmonitoring

   • Zeitreihen von Energie, Luft, Wasser, Gas als Basis für Energieeffizienz-Projekte und Nachweise.

Wie fügt sich eine TSDB in die Digital-Factory-Architektur ein?

Typische Architektur:

1. Shopfloor / OT
   SPS, Sensoren, Roboter, Prüfstände → OPC UA, MQTT, Feldbus, Gateways.

2. Time-Series Database / Historian

   • nimmt hochfrequente Daten auf,

   • speichert sie komprimiert als Zeitreihen,

   • bietet API/Abfrage-Schnittstellen.

3. MES / Cloud-MES & Analytics

   • nutzt verdichtete Kennzahlen und ausgewählte Signale für OEE, Quality, Maintenance, Dashboards, Alarme, Reports.

   • Data-Science-/BI-Tools greifen direkt auf die TSDB oder replizierte Daten (Data Lake) zu.

Ergebnis: Rohdaten bleiben in einer spezialisierten TSDB, während MES und Analytik aufbereitet mit ihnen arbeiten. Damit bleibt das System performant und skalierbar – auch wenn später weitere Use Cases (PAT, Predictive, Digital Twin) hinzukommen.