OEE und der Anlagen-Historian: Wo Zeitreihendaten hingehören

Wesentliche Erkenntnisse

• Historian = hochfrequente Zeitreihen‑Datenbank, die jedes SPS‑Tag mit Unterssekunden‑Takt speichert.
• OEE‑Plattformen benötigen Daten in Historian‑Qualität: jede Zustandsänderung, jeder Zyklus, jeder Fehler, mit Zeitstempel und abrufbar.
• Man kann OEE auch ohne dedizierten Historian betreiben, wenn die OEE‑Plattform selbst in Historian‑Takt speichert. Viele tun das.
• Gängige dedizierte Historian‑Systeme: OSIsoft PI (jetzt AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian. Cloud‑Äquivalente: InfluxDB, TimescaleDB, AWS Timestream.
• Anlagen mit einem bestehenden Historian speisen die OEE‑Plattform meist daraus; Anlagen ohne Historian lassen die OEE‑Plattform typischerweise als Historian für Produktionsdaten fungieren.

Kurzantwort: Ein Anlagen‑Historian ist eine hochfrequente Zeitreihen‑Datenbank, die jedes SPS‑Tag mit Unterssekunden‑Auflösung speichert. OEE‑Plattformen lesen entweder aus einem vorhandenen Historian oder speichern die Daten selbst in Historian‑Takt. Die Frage ist nicht „brauche ich einen Historian oder eine OEE‑Plattform“, sondern „wo liegen die Zeitreihendaten und ist die Auflösung gut genug für OEE‑Analysen“. Siehe auch OEE vs Auslastung.

Was ein Historian ist

Ein Historian ist eine spezialisierte Datenbank, optimiert für Zeitreihendaten, Millionen von (Zeitstempel, Tag, Wert) Tupeln pro Sekunde, über Jahre vorgehalten und für beliebige Zeitfenster abrufbar. Typische Anwendungen:

• Prozesstrend‑Diagramme über lange Zeiträume.
• Regulatorische Rückverfolgbarkeit für Chargendokumentationen.
• Zuverlässigkeitsanalysen des Anlagenverhaltens.
• Ursachenanalysen bei Qualitätsabweichungen.

Gängige dedizierte Historian‑Systeme: OSIsoft PI (jetzt AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian (jetzt AVEVA Insight). In Cloud / Open‑Source: InfluxDB, TimescaleDB, AWS Timestream, Azure Time Series Insights.

Warum OEE Daten in Historian‑Qualität braucht

OEE‑Berechnungen erfordern präzise zeitliche Zustandsverfolgung:

• Zustandswechsel der Produktion mit Sekunden‑Genauigkeit zeitgestempelt.
• Zykluszählungen pro Teil erfasst, nicht stündlich aggregiert.
• Fehlercodes erfasst, wenn sie auftreten, nicht erst wenn jemand sie später einträgt.
• Qualitätssignale dem Zyklus zugeordnet, aus dem sie stammen.

Fehlt eines dieser Elemente, wird OEE ungenau. Ein Historian (oder ein historian‑würdiger Speicher innerhalb der OEE‑Plattform) macht OEE präzise genug, um daraus Maßnahmen abzuleiten.

Zwei Architekturen

Architektur A: dedizierter Historian speist OEE. Die Anlage hat ein bestehendes PI oder InfluxDB. Die OEE‑Plattform abonniert die relevanten Tags und berechnet OEE in Echtzeit, wobei der Historian als Langzeitspeicher dient.

Vorteile: Langzeitspeicherung ist bereits gelöst. Viele Tools können vom selben Historian lesen.

Nachteile: ein weiteres System, das betrieben werden muss. Zusätzliche Latenz durch den Roundtrip.

Architektur B: OEE‑Plattform ist der Historian für Produktionsdaten. Kein dedizierter Historian. Die OEE‑Plattform erfasst SPS‑Signale direkt und speichert sie intern mit hoher Abtastrate.

Vorteile: einfachere Architektur. Geringere Latenz.

Nachteile: Langzeit‑Retention kann begrenzt sein. Andere Nutzer (Engineering, Labor) können nicht so leicht abfragen.

Die meisten KMU‑Anlagen kommen mit Architektur B für Produktionsdaten gut zurecht. Anlagen mit regulatorischer Rückverfolgbarkeit (Pharma, Lebensmittel) benötigen in der Regel trotzdem einen dedizierten Historian.

Worauf man in der Datenebene einer OEE‑Plattform achten sollte

• Native Zeitreihen‑Datenbank. Kein nachträglich angepasstes generisches RDBMS. Zeitreihen­spezifische Speicher (InfluxDB, TimescaleDB, Cassandra+TS‑Schema) bewältigen das Volumen richtig.
• Konfigurierbare Aufbewahrung. Wie lange werden Rohdaten gehalten? Wie lange Aggregationen?
• Downsampling. Automatische Rollups zu niedrigeren Auflösungen, während Daten altern, damit der Speicherbedarf handhabbar bleibt.
• Abfrage‑API. SQL, Flux oder REST, die das Engineering nutzen kann, ohne über die OEE‑UI zu gehen.
• Integration mit externen Historian‑Systemen. Selbst wenn die Plattform eigene Daten speichert, sollte sie PI / Aspen / Honeywell lesen können für Anlagen, die diese Systeme haben.

Häufige Fehler

1. Produktionsdaten mit niedriger Frequenz abtasten. 1‑Minuten‑Durchschnitte übersehen Mikrostopps und kurze Zyklen. OEE, das auf 1‑Minuten‑Aggregaten basiert, ist Fiktion.

2. Die SCADA‑Datenbank als Historian behandeln. SCADA‑Datenbanken sind auf den aktuellen Zustand optimiert, nicht auf langfristige Zeitreihen. Bei großem Umfang versagen sie.

3. Aufbewahrungsplanung überspringen. Drei Jahre hochfrequenter SPS‑Daten sind sehr umfangreich. Planen Sie Downsampling von Tag eins an.

4. Keine Tag‑Governance. Tags ohne einheitliche Benennung machen den Historian unbrauchbar. Legen Sie Benennungsregeln fest, bevor Sie skalieren.

Wie OEE‑Plattformen zu PI und Ähnlichem stehen

Bei Anlagen mit PI ist die OEE‑Plattform üblicherweise ein PI‑Client, der relevante Tags abonniert. PI bleibt das System of Record für Zeitreihendaten; die OEE‑Plattform berechnet und visualisiert OEE darauf aufbauend.

Bei Anlagen ohne PI ist die OEE‑Plattform oft der faktische Historian für Produktionsdaten, das ist für die meisten Anwendungsfälle in Ordnung, ersetzt aber PI nicht für die Prozesstechnik oder regulatorische Archive.

Fabrico's OEE‑Modul wird mit einem internen Zeitreihen‑Speicher ausgeliefert und integriert externe Historian‑Systeme (PI, InfluxDB, TimescaleDB) für Anlagen, die diese haben, das gibt dem Team Flexibilität in der Datenebene.

Sehen Sie, wie Fabrico das automatisch erfasst, OEE für die Fertigung erkunden oder eine Demo buchen.

Weiterführende Lektüre

• OEE vs Auslastung
• OEE und ISO 22400
• OEE für Chargenfertigung
• OEE vs Verfügbarkeit

Häufig gestellte Fragen

Brauche ich einen dedizierten Historian, wenn ich eine OEE‑Plattform habe?

In der Regel nein für reine Produktionsdaten. Ja, wenn Sie regulatorische Rückverfolgbarkeitsanforderungen, mehrere Datenkonsumenten oder prozesstechnische Anforderungen haben, die über OEE hinausgehen.

Kann ich eine normale SQL‑Datenbank als Historian verwenden?

Für kleine Umfänge funktioniert das. Im industriellen Maßstab (Tausende von Tags, Millisekunden‑Auflösung, jahrelange Aufbewahrung) brauchen Sie einen zeitreihen‑spezifischen Speicher.

Wie lange sollte ich Rohdaten aufbewahren?

Kommt auf den Anwendungsfall an. Für Produktions‑Troubleshooting werden üblicherweise 30, 90 Tage Rohdaten benötigt; langfristige Trends können auf heruntergesampelten Aggregaten vorgehalten werden.

Ist InfluxDB dasselbe wie PI?

Beide sind Zeitreihen‑Datenbanken. PI ist der langjährig etablierte industrielle Standard mit ausgereiften Integrationen. InfluxDB ist Open Source und in cloud‑nativen und modernen Stacks populär. Beide eignen sich für OEE.

Kann die OEE‑Plattform in den Historian zurückschreiben?

Einige können das. Nützlich, um berechnete OEE‑Werte neben den rohen SPS‑Tags zu speichern, damit externe Verbraucher OEE aus derselben Quelle lesen können.