Einen Unified Namespace vertrauenswürdig machen – eine dreiteilige Serie: 1 · UNS oder Datensumpf · 2 · Data Contracts · 3 · Asset Models.
Teil 2 endete an einer Lücke. Schematische und semantische Contracts halten eine einzelne Nachricht ehrlich – die richtigen Felder, die richtigen Typen, ein Vokabular, an dem du dich nicht vertippen kannst. Aber eine Nachricht wird immer von etwas veröffentlicht: einer Maschine, einer Linie, einer Zelle. Und die Frage, die ein Contract nicht beantwortet, ist, was dieses Ding ist und was es verpflichtet preiszugeben, wenn es behauptet, von dieser Art zu sein. Das ist das Asset Model – die Ebene über den Nachrichten-Contracts – und von dort kommt eine KPI, der du wirklich trauen kannst.
Von Nachrichtenformen zu Asset-Typen
Ein semantischer Contract nagelt fest, was der Wert eines einzelnen Signals bedeutet – LineState sagt, dass der Zustand einer Linie einer von fünf erlaubten Werten ist. Er sagt immer noch nicht, zu welcher Art von Ding dieses Signal gehört. Der nächste Schritt ist, den Asset-Typ selbst als Klasse zu benennen – ein Interface – und die Signale aufzulisten, die jedes Asset dieses Typs preisgeben muss:
name: Machine # die Basis, die jedes vom Connector beobachtete Asset erfüllt
version: '1.0'
signals:
- { name: heartbeat, type: bool, required: true }
- { name: is_connected, type: bool, required: true }
---
name: AvailabilityMachine
version: '1.0'
extends: [Machine] # erbt heartbeat + is_connected
signals:
- name: machine_status
type: int
required: true
description: |
Standardisierter Betriebszustand, eine Definition für die ganze Flotte.
Ein Integer-Enum, angelehnt an das PackML-Zustandsmodell, z. B.
2 Stopped · 4 Idle · 6 Execute · 9 Aborted
Diese Interfaces sind Klassen: Sie haben einen Namen, eine Version, und sie vererben. Ein konkretes Asset deklariert dann, welche Typen es ist – implements: [AvailabilityMachine, OEEProducer] – genau so, wie ein Objekt die Interfaces deklariert, die es erfüllt. Der Nachrichten-Contract aus Teil 2 liegt weiterhin darunter; das Interface ist der Contract eine Ebene höher, am Asset statt an einer einzelnen Nachricht. Das ist der Unterschied zwischen „wir veröffentlichen ein state-Feld“ und „das ist eine verfügbarkeitstragende Maschine, und hier ist, was sie das verpflichtet preiszugeben“.
Der schematische Teil davon ist über Kunden hinweg wiederverwendbar. Die Asset-Typen wachsen fast immer um kundenspezifische Erweiterungen, weil das, was als Verpackungslinie zählt – oder als CNC-Zelle, als Beschichtungslauf –, teils universell und teils spezifisch für einen Betrieb ist. Das ist zu erwarten. Es geht nicht darum, das Asset Model jedes Kunden identisch zu machen. Es geht darum, sicherzustellen, dass es existiert – als Code, auf dem Weg des geringsten Widerstands.
Durchsetzung steigt eine Ebene höher
In Teil 2 hielt Durchsetzung eine Nachricht ehrlich: Die Bibliothek übernimmt Encoding und Validierung, sodass eine falsche Form schwerer zu veröffentlichen ist als eine richtige. Das Asset Model hebt dieselbe Idee eine Ebene höher – von „ist diese Nachricht wohlgeformt“ zu „tut dieses Asset wirklich, was es behauptet“.
Wenn ein Asset implements: [AvailabilityMachine] deklariert, prüft die Plattform (PREKIT) es. Für jedes Pflichtsignal kommt die Coverage als ok, missing oder wrong_type zurück. Eine Maschine, die behauptet, verfügbarkeitstragend zu sein, aber nie machine_status preisgibt, taucht als missing auf – automatisch, über jedes Asset, ohne dass jemand ein PDF auditiert. Ein Tag, der nicht Teil des Standards ist, wird ebenfalls in den Namespace veröffentlicht – das ist unsere Philosophie der schrittweisen Standardisierung –, aber das Topic ist klar als nicht-standardkonform markiert.
Dieser Coverage-Bericht ist kein Fehlerzustand; er ist das Nützlichste, was das Model produziert. Er ist eine lebende Landkarte genau dort, wo Realität und Standard auseinandergehen – welche Linie einen anderen Tag-Namen nutzt, welcher Standort den Status nie verdrahtet hat. Der Standard hört auf, ein Dokument zu sein, von dem du hoffst, dass die Leute ihm gefolgt sind, und wird zu einer Abfrage, die du gegen die Flotte laufen lassen kannst. Und den Typ zu deklarieren ist generativ: Die Pflicht-Tag-Slots (Signale) des Assets werden für dich angelegt, sodass der Weg des geringsten Widerstands den Standard nicht nur validiert – er baut sein Gerüst.
Das Model lebt im Repo des Kunden
Asset-Typen als Code zahlen sich nur aus, wenn der Code einen Eigentümer und ein Zuhause hat. Die Aufteilung, die wir nutzen: Die Plattform liefert einen kleinen Satz Basis-Interfaces – Machine, ein OEEProducer für Stückgut, ein paar weitere –, und der Kunde besitzt alles, was spezifisch für seinen Betrieb ist, in seinem eigenen versionierten Repository. Ein Kunden-Interface ist eine YAML-Datei, die eine Plattform-Basis extends und ergänzt, was seine Maschinen tatsächlich tun. Sie wird beim Deploy geladen und gemeinsam mit den Plattform-Interfaces aufgelöst.
Konkret heisst das: Das Asset Model des Kunden ist ein Git-Repo, das wir mit ihm bauen, keine Spezifikation, die wir ihm hinwerfen. Der erste Workshop ist grösstenteils das Gespräch, um das es in Teil 1 ging – was ist hier eine „Maschine“, in welchen Zuständen darf sie sein, wann beginnt ein Rüstvorgang – und das Ergebnis dieses Gesprächs wird als Interface-Definitionen committet. Von da an ist jede Änderung an „was eine Maschine ist“ ein reviewbarer Diff mit Autor und Datum, ausgerollt über denselben Fluss wie die übrige Topologie, mit Drift-Erkennung gegen das, was tatsächlich live ist. Das Datenmodell hört auf, Herrschaftswissen in den Köpfen dreier Techniker zu sein, und wird zu einem versionierten Artefakt, das der Kunde behält.
Und weil die aufgelösten Interfaces, die deklarierten Typen jedes Assets und seine Live-Konformität alle als retained Topics zurück in den Namespace veröffentlicht werden, ist das Model von innerhalb des UNS selbst auffindbar. Du kannst den Namespace abonnieren und ihn fragen, welche Asset-Typen es gibt, was jede Maschine zu sein behauptet und ob sie diesem Anspruch tatsächlich gerecht wird.
Die Skalenkurve – und die KPI, der du endlich traust
Das erste standardisierte Asset aufzusetzen ist tatsächlich mehr Arbeit, als nur Tags zu veröffentlichen. Du musst dich auf das Vokabular einigen – was running heisst, wann ein Rüstvorgang beginnt, in welchem Zustand eine Linie während eines geplanten Umrüstens ist. Diese Gespräche gibt es nicht umsonst, und auf der ersten Linie fühlen sie sich wie Overhead an.
Die zweite Linie kostet viel weniger. Die meisten Einigungen tragen sich weiter; du wendest denselben Asset-Typ auf eine andere physische Instanz an. Die dritte kostet weniger als die zweite. Bei der fünften ist die Arbeit, eine hinzuzufügen, die Verdrahtung, nicht die Modellierung.
Dann kommt der eigentliche Gewinn. Nimm die Maschinenverfügbarkeit – die KPI aus Teil 1, die alle wollten und der niemand traute, weil „verfügbar“ auf drei Linien auf drei verschiedene Arten berechnet wurde. Sobald Verfügbarkeit gegen das Interface definiert ist – abgeleitet aus einem standardisierten machine_status, den jedes verfügbarkeitstragende Asset nachweislich preisgibt –, entwickelst und validierst du diese Logik gründlich auf einer einzigen Linie, bestätigst, dass die Coverage grün ist, und rollst sie auf jedes Asset aus, das den Typ implementiert. Jeder nachgelagerte Consumer funktioniert weiter, weil sich der Contract nicht geändert hat; was sich geändert hat, ist eine gut getestete Definition, überall auf einmal angewandt.
Das ist der Moment, in dem die Leute anfangen, der Zahl zu trauen. Denn eine Änderung an der Definition von „verfügbar“ ist jetzt etwas, das du über alle Assets angewandt siehst und überprüfen kannst. Die KPI hört auf, das Spreadsheet eines Teams zu sein, und wird zu einer flottenweiten Fähigkeit. Das ist der Unterschied zwischen zehn Maschinen im UNS und einer zehnmal ausgerollten Verfügbarkeits-Fähigkeit. Das Erste ist ein Haufen. Das Zweite ist eine Plattform – genau das, was wir in Teil 1 bauen wollten, als das Einzige zwischen einem Namespace und einem Sumpf ein Standard war, den jemand bereit war durchzusetzen.
Und es geht nicht nur um Dashboards – das ist auch der Moment, in dem die Arbeit deiner Data Scientists zu skalieren beginnt. Ohne Datenmodell ist jede Analyse ein Einzelfall: Bevor jemand einen Anomalie-Detektor oder ein Predictive-Maintenance-Modell baut, verbringt jemand eine Woche damit, die richtigen Tags auf dieser Maschine zu finden, rückzuentwickeln, was ihre Werte bedeuten, und das Ergebnis von Hand zu bereinigen – und macht dann alles für die nächste Maschine von vorn. Wenn Assets einem bekannten Typ entsprechen, ist dieser Overhead weg. Ein Modell, das gegen AvailabilityMachine oder gegen den part_counter von OEEProducer geschrieben ist, läuft unverändert auf jedem Asset, das den Typ implementiert – und die Plattform sagt dir vorab, welche Assets qualifizieren und welche zu kurz greifen. Deine Data Scientists hören auf, Maschine für Maschine Archäologie zu betreiben, und fangen an, Fähigkeiten zu bauen, die über die Flotte hinweg ausgerollt werden; ihr Aufwand summiert sich, statt sich mit jeder neuen Linie zurückzusetzen. Das ist der Wechsel von Einzelaufgaben zu Systemen, die skalieren.
Wenn du an der Asset-Model-Frage in deinem eigenen UNS arbeitest, fork franzmq für die schematische Ebene und bau darauf auf – oder bau dein eigenes Äquivalent. So oder so vergleichen wir gerne Notizen.
Einen Unified Namespace vertrauenswürdig machen – eine dreiteilige Serie: 1 · UNS oder Datensumpf · 2 · Data Contracts · 3 · Asset Models.
Für mehr Hintergrund siehe unseren früheren Beitrag Was genau ist ein Unified Namespace? und die Lücke zwischen ERP und Shopfloor überbrücken.