Auftragsbezug MDE: Minimaler Datenvertrag

Für den Auftragsbezug zählt nicht nur, dass eine Maschine produziert oder steht, sondern wann der Zustand wechselt. Deshalb ist der Pflichtdatensatz ein Statusereignis mit eventTime, stateCode, sourceType und sourceId. Das gilt unabhängig davon, ob die Zustände aus SPS, Gateway oder externer Sensorik kommen. Fehlt die Ereigniszeit, können Sie Schichtgrenzen und Auftragswechsel später nicht belastbar rekonstruieren.

Bei Novo ist aus der öffentlichen Lösungsseite dokumentiert, dass externe Akustik- und Schwingungssignale Maschinenzustände unterscheiden können. Ebenfalls dokumentiert ist, dass Stillstandsgründe je nach Setup zusätzliche Quellen oder Bedienerrückmeldungen brauchen. Für den Datenvertrag folgt daraus eine saubere Trennung: Zustandserkennung kann automatisiert sein, Ursachenzuordnung bleibt ein separates Regelwerk.

Für Brownfield-Piloten ist eine Regel besonders wertvoll: Mengen werden als Delta-Ereignisse gespeichert. Also nicht „Auftrag hat jetzt 406 Gutteile“, sondern „+4 Ausschuss um 13:58, eingegeben um 14:12“. Diese Form macht Nachbuchungen prüfbar, verhindert stilles Überschreiben und erlaubt später eine saubere Rekonstruktion der Auftragssumme.

Das passt auch zu den dokumentierten Begriffen. In OPC UA for Machinery sind ProducedQuantity und GoodQuantity getrennt beschrieben. Für Ihr Pilotmodell genügt oft eine einfache Regel: Entweder speichern Sie ProducedQuantity direkt und ergänzen Good oder Reject, oder Sie speichern Good und Reject getrennt und leiten Produced daraus ab. Beides ist zulässig, solange die Ableitung im Vertrag festgeschrieben ist.

Ein kritischer Unterschied ist die Schichtzuordnung aus Ereigniszeit statt aus Eingabezeit. Wenn der Bediener einen Ausschuss um 14:12 nachträgt, der reale Fehler aber um 13:58 passierte, gehört die Buchung zur früheren Schicht und zum damals aktiven Auftrag. Deshalb sollte shiftId nie manuell primär erfasst, sondern immer aus eventTime und einem versionierten Schichtkalender abgeleitet werden.

Das reduziert Diskussionen an Übergaben. Statt „Wer hat den Ausschuss verursacht?“ diskutieren Sie eine dokumentierte Regel. Wenn sich der Schichtkalender später ändert, braucht auch die Kalenderregel eine Version. Sonst entstehen rückwirkend andere Berichte, obwohl sich am realen Ereignis nichts geändert hat.

Der Begriff Gutmenge klingt einfach, ist es aber nicht. OEE.com definiert Good Count als Teile, die den Prozess beim ersten Durchlauf fehlerfrei bestehen. OPC UA for Machinery dokumentiert GoodQuantity ebenfalls separat und weist darauf hin, dass spätere Gegenbelege aus nachfolgenden Prozessen entstehen können. Daraus folgt: Sie müssen im Vertrag den Gültigkeitsbereich der Gutmenge benennen.

Für einen minimalen Auftragsbezug ist eine einfache Empfehlung: Gutmenge auf Maschinen- oder Stationsniveau als First-Pass-Sicht definieren. Spätere Qualitätsverluste in einem anderen Prozessschritt gehören in ein separates Qualitätsobjekt statt in eine stille rückwirkende Umwertung der MDE-Basis. Das ist nicht die einzig mögliche Lösung, aber die einfachste, solange noch kein durchgängiges MES-Qualitätsmodell existiert.

Am Schichtwechsel brauchen Sie keine zweite Wahrheit. Der Auftrag, der um 13:58 lief, bleibt der relevante Auftrag für ein um 13:58 entstandenes Ereignis, auch wenn ein Bediener erst um 14:12 bucht. Die Schichtzuordnung muss daher aus eventTime und nicht aus entryTime kommen. Diese Unterscheidung klingt klein, ist aber für belastbare Übergaben zentral.

Empfehlen würde ich außerdem eine feste Regel für Ereignisse genau auf der Grenze, etwa „Schichtwechsel inklusive Startminute der neuen Schicht“. Wichtig ist nicht, welche Variante Sie wählen, sondern dass dieselbe Regel in BDE-Maske, Export, Dashboard und Schichtbericht identisch gilt. Unterschiedliche Grenzlogiken erzeugen sonst unnötige Nacharbeit.

Nachbuchungen sind nicht das Problem. Unsichtbare Nachbuchungen sind das Problem. Der Vertrag sollte deshalb immer zwei Zeiten vorsehen: die Ereigniszeit, zu der Ausschuss oder Gutmenge fachlich gehören, und die Eingabezeit, zu der jemand die Buchung tatsächlich erfasst. Zusätzlich brauchen Sie enteredBy und bookingReason. Erst damit wird aus einer späten Buchung ein prüfbarer Vorgang.

Für das Team hat diese Logik einen praktischen Vorteil. Niemand muss hektisch während einer Störung perfekte Eingaben liefern. Gleichzeitig verhindern Sie, dass Schichtberichte rückwirkend unbemerkt andere Zahlen tragen. Im Zweifel ist eine sichtbare Nachbuchung mit Grund viel vertrauenswürdiger als eine scheinbar „saubere“ Zahl ohne jede Entstehungsgeschichte.

Wenn Teile später in einer nachgelagerten Prüfung ausfallen, kollidieren oft zwei legitime Sichten: die Maschinen-First-Pass-Sicht und die Endqualitäts-Sicht. OPC UA for Machinery weist ausdrücklich darauf hin, dass spätere Gegenbelege entstehen können und die Daten auf dem Server nicht zwingend retrospektiv geändert werden. Für Ihren Pilot heißt das: Entscheiden Sie diese Frage im Vertrag, nicht im Monatsmeeting.

Für den Minimalstart empfehle ich eine enge Definition: Die MDE-nahe Gutmenge beschreibt den Zustand an der betrachteten Maschine oder Station. Spätere Verluste werden separat als nachgelagerter Qualitätsprozess dokumentiert. Wenn Sie beides vermischen, werden Auftrag, OEE und Qualitätskosten zugleich diskutiert, obwohl zunächst nur ein sauberer Auftragsbezug gebraucht wird.