Wichtige Erkenntnisse
Die meisten Fabriken haben reichlich Daten. SPSen veröffentlichen Tag-Werte im Sub-Sekunden-Takt. SCADA fasst sie zusammen und visualisiert sie. ERPs erhalten Produktionszahlen und Verbrauchsdaten.
Wo es scheitert, ist zwischen diesen Ebenen: Ein Stillstand in der Linie erzeugt am SPS einen Tag-Übergang, wird in SCADA zu einem „Downtime Event“, im ERP als „verlorene Produktion“ zusammengefasst, und keine dieser drei Darstellungen stimmt darüber überein, was das Ereignis war, wann es begann oder zu welchem Asset es gehört.
Das Ergebnis ist, dass niemand einfache operative Fragen sauber beantworten kann. „Wie viel Ausfallzeit hat das Asset L3-PKG-02 gestern verursacht?“ hat drei verschiedene Antworten, je nachdem, welches System man fragt. Das OEE-Tool, das CMMS und das ERP haben jeweils eigene Definitionen, und sie von Hand zu überbrücken ist das, was dem Wartungsleiter die Morgenstunden frisst.
Die übliche Versuchung, besonders bei Projekten, die als „Industry 4.0-Integration“ verkauft werden, ist, SPS-Daten ins ERP zu drücken. Das wirkt wie eine einfache Integration. Fast immer scheitert sie aus drei Gründen.
SPSen erzeugen Tausende von Tag-Übergängen pro Minute. ERPs sind dafür ausgelegt, pro Werk ein paar hundert Datensätze pro Tag zu erhalten. Rohdaten der SPS ins ERP zu pumpen überflutet entweder die Datenbank oder zwingt zu aggressiver Aggregation am Rand, und genau diese Aggregation zerstört die Auflösung, die OEE und CMMS brauchen.
Die SPS kennt Tags. Das ERP kennt Kostenstellen. Keine der beiden kennt die Anlagenhierarchie so, wie die Instandhaltung sie braucht (Line → Station → Asset → Komponente). Ohne eine explizite Hierarchie dazwischen kann man aus ERP-Datensätzen nicht beantworten, „welches Asset diesen Stillstand verursacht hat“.
SPS-Ereignisse sind millisekundenpräzise. ERP-Ereignisse sind normalerweise tagesgenau. Ein Stillstand, der um 14:03:22 begann und um 14:08:45 endete, wird vom ERP als „5 Minuten Ausfallzeit am 27. Juni“ dargestellt. Dieser Präzisionsverlust ist der Grund, warum die meisten ERP-basierten OEE-Berichte unbrauchbar sind.
Die Lösung ist, eine Schicht zwischen der SPS/SCADA-Ebene und dem ERP einzufügen. Diese Schicht hat vier Aufgaben.
Jedes Ereignis, Start, Stopp, Ausschuss, Umrüstung, bekommt überall denselben Namen in derselben Form. Hier lebt in der Praxis die Verlustklassen-Taxonomie aus dem Artikel zu Manufacturing KPIs. Ohne sie stabilisieren sich nachgelagerte Analysen nie.
Die operative Schicht ist die einzige Quelle der Wahrheit dafür, „was ein Asset ist“. Linien, Stationen, Assets und Komponenten werden hier definiert und einerseits auf SPS-Tags und andererseits auf ERP-Kostenstellen abgebildet. Wenn die Instandhaltung einen Arbeitsauftrag erstellt, verweist er auf ein Asset in dieser Hierarchie, nicht auf ein Tag und nicht auf eine Kostenstelle.
Jedes Ereignis, das die Schicht speichert, wird auf eine Uhrzeit gestempelt, üblicherweise UTC mit Millisekundenauflösung, unabhängig davon, welche SPS, welches SCADA-System oder welches Bedienfeld es erzeugt hat. Zeitzonen- und Driftprobleme werden beim Einlesen beseitigt, nicht in Dashboards.
Das ERP erhält das zusammengefasste, finanziell geprägte Bild: Schichtspezifische Produktion, Ausschuss, Stillstand nach Gründen, im täglichen oder schichtspezifischen Rhythmus. Die hochauflösenden Details bleiben in der operativen Schicht, wo OEE, CMMS und Root-Cause-Analysen sie benötigen. Siehe den verwandten Artikel zu Root Cause Analysis dafür, warum diese Details die Verbesserung vorantreiben.
Eine typische Referenzarchitektur für den Mittelstand:
Der Grund, warum die operative Schicht sowohl OEE als auch CMMS hosten sollte, ist, dass die Anlagenhierarchie geteilt wird. Lebt OEE in einem Tool mit eigener Hierarchie und das CMMS in einem anderen Tool mit einer anderen Hierarchie, geht der ganze Sinn der Schicht, eine einzige Quelle der Wahrheit, verloren. Ein einheitliches Work-Order-Management-System, das auf denselben Daten wie die OEE-Engine sitzt, verhindert dieses Auseinanderdriften von vornherein.
Der Fehler, den Werke machen, ist, mit der ERP-Integration zu beginnen, weil sie sich wie die „eigentliche“ Leistung anfühlt. Die richtige Reihenfolge ist das Gegenteil.
Mit der ERP-Integration zuerst zu beginnen garantiert Nacharbeit, weil die operativen Definitionen noch in Bewegung sind und jeder ERP-Datensatz neu ausgegeben werden muss, sobald sich diese Definitionen stabilisieren.
Die oben beschriebene operative Datenschicht ist genau das, was Fabrico ist: eine einzelne Plattform, die die Anlagenhierarchie, den OEE-Ereignisstrom und die CMMS-Arbeitsaufträge in derselben Datenbank hostet, mit Edge-Connectoren für die SPS-Seite und zeitgesteuerten Exporten für die ERP-Seite.
Der Grund, warum wir als ein einheitliches Produkt liefern und nicht als zwei separate, ist, dass die OT/IT-Lücke zusammenbricht, wenn OEE und CMMS eine gemeinsame Hierarchie teilen, und offen bleibt, wenn sie das nicht tun. Um zu sehen, wie das gegen Ihre eigenen Liniendaten aussehen würde, buchen Sie eine Demo .
Nein. Die operative Datenschicht sitzt über dem bestehenden OT-Stack über einen Edge-Connector. Die SPS/SCADA-Ebene macht weiterhin das, was sie tut; die neue Schicht fügt nur eine normalisierte Sicht darüber hinzu.
Ein Data Lake ohne operative Datenschicht enthält hochauflösende Tag-Daten ohne Ereignisse semantics. Man kann Dashboards darüber bauen, aber man kann keine Arbeitsaufträge, OEE-Berechnungen oder Root-Cause-Analysen antreiben, ohne zuerst das Ereignisvokabular und die Anlagenhierarchie zu rekonstruieren, genau das, was die operative Schicht leistet. Das Überspringen dieser Schicht verschiebt das Problem nur.
Wenn ein Werk bereits ein MES hat, übernimmt das MES oft einen Teil der Aufgaben der operativen Datenschicht, insbesondere das Ereignisvokabular. Die Architektur funktioniert gleich: Das MES speist die operative Datenschicht (oder ist die operative Datenschicht, wenn es OEE und CMMS abdeckt), die dann zum ERP hochrollt.
Das Werks-Team, das die Anlagen kennt, nicht die IT. Die operative Schicht muss die Hierarchie für Instandhaltungs- und Produktionsingenieure ohne Entwickler im Loop editierbar machen, sonst driftet sie innerhalb eines Quartals auseinander.
Das Ereignisvokabular. Wenn die Verlustklassen nicht über die Linien hinweg stabil sind, ist jede Analyse und jede Regel downstream unzuverlässig. Verbringen Sie in Woche eins mehr Zeit als vernünftig erscheint mit der Taxonomie.
Anmeldung
Blog
