Die Bedeutung eines Fertigungsereignisses vor seiner Weiterverwendung abstimmen

Bedeutung und Verantwortung rund um das Schema vereinbaren

Der Open Data Contract Standard, kurz ODCS, beschreibt eine Vereinbarung zwischen Datenlieferanten und Datennutzern. Version 3.2.0 umfasst Schema, Datenqualitätsangaben, Teams, Rollen, Unterstützung und Erwartungen an die Bereitstellung. Diese Abschnitte helfen den Beteiligten, mehr als Feldtypen zu erfassen.

Bei einem Fertigungsereignis erklärt die betriebsverantwortliche Person die Messung und ihre erlaubte Verwendung. Die für die Datenlieferung verantwortliche Person pflegt die Zuordnung zur Quelle. Die für die Datennutzung verantwortliche Person hält fest, welche Berechnungen vom Datensatz abhängen. Gemeinsam vereinbaren sie, wer Änderungen prüft, fehlgeschlagene Prüfungen untersucht und wann ein ungelöstes Problem eskaliert wird.

Das Arbeitsblatt dokumentiert die Beispielvereinbarung und die erwarteten Prüfungen. Es ist weder ein vollständiges ODCS-Dokument noch eine OPC-UA-Codierung oder ein Dienst zur Durchsetzung in der Produktion. Es erlaubt keine Steuerungs- oder Sicherheitsaktion.

Was sich aus dem Zählerdatensatz ablesen lässt

Der Datennutzer bewahrt Quell- und Ankunftszeit getrennt auf. Die DataValue-Definition von OPC UA unterscheidet Quell- und Serverzeitstempel. Die Ankunftsaufzeichnung einer Anwendung ist eine weitere, gesondert zu benennende Beobachtung. Eine empfangende Anwendung darf eine fehlende Quellzeit nicht durch die Ankunftszeit ersetzen und diese stillschweigend als Original ausgeben.

In der vorhandenen Darstellung fehlen Kalenderdatum und vereinbarte Aktualitätsgrenze. Die Prüfung kann fünf Sekunden nur unter der ausdrücklichen Annahme desselben UTC-Kalendertags berechnen. Sie hält die nachgelagerte Verwendung zurück, bis die fehlende Aktualitätsregel vereinbart ist. Aus diesen Werten kann sie weder Uhrengenauigkeit noch einen Tageswechsel oder eine tatsächliche Leistungszusage prüfen.

Eine Transportbestätigung klärt noch nicht die Ereignisbedeutung

Der Datennutzer prüft die Ereigniskennung auf Anwendungsebene, bevor er einen Datensatz in eine analytische Berechnung aufnimmt. OASIS MQTT erlaubt Duplikate bei einer Zustellung mindestens einmal und unterscheidet das DUP-Kennzeichen eines Pakets von der Wiederholung einer Anwendungsnachricht. Eine Transportpaketkennung ersetzt deshalb nicht die Ereigniskennung, die die Anwendung braucht.

Im vorhandenen Zählerbeispiel fügt der doppelte Empfang desselben Datensatzes keine weiteren 412 Einheiten hinzu. Ein späterer kumulierter Wert von 413 zeigt nur dann eine zusätzliche akzeptierte Einheit an, wenn dieselbe Zählerfolge ohne Rücksetzung oder Überlauf weiterläuft. Erhalten Sie diese Bedingung, statt jeden niedrigeren Stand als gewöhnlichen negativen Zuwachs zu behandeln.

Die Prüfung meldet ein Duplikat getrennt und addiert dafür null neue Einheiten. Bei der ersten Momentaufnahme lässt sie den Produktionszuwachs unbekannt: Ein Gesamtstand ohne gültigen vorherigen Stand belegt keine Produktion innerhalb eines Intervalls. Rücksetzungen und Überläufe brauchen eine eigene festgelegte Behandlung, bevor ein Datennutzer eine Differenz berechnet.

Siehe auchQualität der Werksdaten

Eine Bedeutungsänderung braucht eine neue Vereinbarung

Ein Datenlieferant kann ein Ganzzahlfeld beibehalten und die Datennutzung trotzdem stören, indem er dessen Bedeutung von einem kumulierten Zähler akzeptierter Einheiten zu einem Zuwachs oder einer Bruttomenge ändert. Eine Feldumbenennung ist leichter erkennbar als eine solche stille Änderung. Versionieren Sie die inhaltliche Definition ebenso wie die Syntax.

Die Lehrprüfung unterstützt Schemaversion 1, die Einheitenkennung units, die kumulierte Bedeutung von accepted-count und die festgelegte Quellkennung. Ihre Tests entfernen eine erforderliche Einheit, ändern die Schemaversion und verändern das Kennzeichen für kumulative Werte. Das sind gezielte Veränderungen des vorhandenen Beispiels für Softwareprüfungen. Es handelt sich nicht um beobachtete Vorfälle in einer Fabrik.

Vor der Freigabe einer Änderung vergleichen beide Verantwortlichen die alten und vorgeschlagenen Datensätze im Hinblick auf die betroffenen Datennutzer. Sie entscheiden, ob die bisherige Datennutzung ihre Bedeutung behält, einen ausdrücklichen Adapter braucht oder die neue Version ablehnen muss. Bewahren Sie Änderungsfreigabe, Gültigkeitsbeginn und Rückkehrentscheidung bei der Vereinbarung auf.

1. Die beabsichtigte Änderung erfassen

   Die für die Datenlieferung verantwortliche Person liefert alte und vorgeschlagene Feldbedeutung, Einheiten, Kennung und Zeitverhalten.

2. Betroffene Datennutzer prüfen

   Jede für die Datennutzung verantwortliche Person benennt die betroffene Berechnung, Annahme und unterstützte Version.

3. Die Annahmeprüfungen ausführen

   Die prüfende Person untersucht bekannte Datensätze, Duplikate, fehlende Felder, Versionsänderungen und festgelegte Zeitgrenzen.

4. Übergang und Reaktion freigeben

   Die Verantwortlichen erfassen gültige Version, Ausnahmeweg und Entscheidung über Rückkehr oder Quarantäne.

Ablehnung, Quarantäne und Zurückhalten unterscheiden

Das empfangende Team bewahrt bei fehlgeschlagener Validierung den Rohdatensatz mit seiner Begründung auf. Ein Quarantäneweg hält ihn aus dem betroffenen Analyseergebnis heraus, während die verantwortliche Person den Fehler untersucht. Reparieren Sie ein Ereignis nicht stillschweigend, löschen Sie das Original nicht und machen Sie aus einem fehlenden Wert keine gemessene null.

Die Prüfung stellt fehlende Felder, nicht unterstützte Bedeutung oder Version, ungültige Zahlen und eine widersprüchliche Uhrenreihenfolge unter der Annahme desselben Tages in Quarantäne. Sie meldet eine exakt wiederholte Kennung als Duplikat. Ein strukturell gültiges Beispiel ohne vereinbarte Aktualitätsgrenze erhält den Status HOLD. Fünf Sekunden bleiben als beobachtete Übertragungsdauer erfasst.

Das Beispiel enthält keine tatsächlichen Namen der Verantwortlichen, keine Eskalationsfrist und keine gemessene Uhrenunsicherheit. Die leere Vereinbarung lässt diese Felder offen. Ein Team muss sie liefern und freigeben, bevor es eine Regel im Betrieb anwendet. Das Bestehen dieser lokalen Softwareprüfung belegt weder eine vertrauenswürdige Quellmessung noch Transportsicherheit oder Eignung für eine Sicherheitsentscheidung.

Den Datensatz vor der Freigabe beim Nutzer prüfen

Das herunterladbare Modul enthält das vorhandene Beispiel, getrennte leere Felder und die Prüfung. Es läuft lokal in einer JavaScript-Laufzeit und stellt keine Netzwerkanfragen. Die Ausgabe meldet den beobachteten Zählerstand und den Grund für HOLD. Sie sendet keine Befehle und verändert kein Fertigungssystem.

Nutzen Sie den Leitfaden zu Ereigniszeitstempeln für Quellzeit, Ankunftszeit und Unsicherheit. Der vorhandene Protokollvergleich behandelt die Kommunikationswahl. Dieser ergänzende Artikel fügt Zuständigkeiten von Datenlieferant und Datennutzer, Änderungsprüfung und ausführbare Ablehnungsregeln hinzu, statt ein weiteres Protokollglossar zu liefern.

Bitten Sie bei der nächsten tatsächlichen Datenübergabe beide Verantwortlichen, eine abhängige Berechnung und eine Änderung zu benennen, die sie ungültig machen würde. Erhalten Sie den Originaldatensatz, führen Sie die vereinbarten Prüfungen aus und halten Sie fest, wer die erste unbelegte Annahme klärt.