OCR-Etiketten: Abnahme und SPS-Vertrag

Ziel und Einsatzgrenzen

Feldentscheidung mit Textnachweis und Frist liefern; falschen Text, Unlesbarkeit und Kommunikationsfehler trennen.

Diese Anleitung beschreibt eine technische Bewertung, keine Zertifizierung eines sofort einsatzbereiten Produkts. Das öffentliche PC-Beispiel von Deyi Vision umfasst derzeit einen EAN-13-Ablauf mit bestätigten Musterbildern. Native OCR- und Detektionsfunktionen im Entwicklungscode sind vor Verwendung anhand der installierten Laufzeit, gebundenen Modelle und Prüfaufgabe zu kontrollieren. Eine Browser-Vorlage belegt keine Ausführung im Browser; das geplante OpenCV.js-Backend benötigt eine eigene Prüfung. Cloud-Erkennung erfordert die ausdrückliche Freigabe von Bildumfang, Anbieter, Modell und Kosten. Ein Prüfarchiv ist kein ausführbares Release-Paket. Kamera-, Firmware- und Treiberkompatibilität sind separat zu prüfen. Alle Werte im Arbeitsblatt sind hypothetisch, keine Messungen oder Kundenergebnisse von Deyi Vision.

Nachweise vorbereiten

Felder, Sollquelle, Normalisierung und Paket einfrieren; simulierten Ausgang vor überwachten Etiketten prüfen. Definieren Sie Startzeit und bestätigende Quittierung. Warteschlange und Kommunikationsverzug neben Verarbeitung sichern; ein schneller Algorithmus kann ein spätes Linienergebnis verdecken. Intervalle monoton messen und Geräteuhren separat zuordnen. Lange Verzögerungen, fehlende Ergebnisse und Wiederverbindung statt nur Mittelwert erfassen. Neues Rezept darf laufende Ergebnisse nicht umdeuten: unter gespeicherter Revision beenden oder vereinbart sperren. Ausgangsfolge, Produktposition und Bestätigung zusammenhalten. Klassifikation, Kommunikation und bestätigte physische Route getrennt abnehmen. OCR-Etikettenprüfung schützt Datenintegrität, statt plausible Wörter zu suchen. Für jedes Feld Lage, Alphabet, exakte Vergleichsregel und vertrauenswürdige Quelle des Sollwerts festlegen. Charge, Datum und Produktname können unterschiedliche Regeln benötigen. Textpolygon und Erkennungsausgabe vor Normalisierung von Leerzeichen oder Großschreibung sichern. I nicht still durch 1 und O nicht durch 0 ersetzen: Ein falsches Etikett könnte richtig erscheinen. Die ursprünglichen Entwicklungsnachweise enthalten einen schmalen OCR-Grenzfall mit NoResult oder Review; ein vergrößerter Ausschnitt belegt keine allgemeine Erkennungsbereitschaft. Ein lesbares Feld kann die falsche Charge tragen; ein bekannter Sollwert rechtfertigt nicht, ein unlesbares Feld damit aufzufüllen. Den Linienvertrag vor der Verbindung von Entscheidung und Aktor festlegen: Aufnahmeidentität, Rezeptrevision, Ergebniszustand, Frist, Quittierung und Umgang mit fehlenden oder verspäteten Daten. Zuerst die Kommunikation bei gesperrten Ausgängen prüfen, dann einen überwachten Linienversuch gemäß betrieblichem Abnahmeverfahren durchführen. Jeden Lauf vom gleichen definierten Ereignis messen; reine Rechenzeit lässt Warteschlange, Übertragung und Ausgangsverzögerung aus. Eine wiederkehrende Produktkennung ist keine eindeutige Bildkennung. Stopp, Neustart, Wiederverbindung und Rezeptwechsel mit offenen Vorgängen prüfen. Die gesamte Folge sichern, damit die ausgeschleuste Einheit zu ihren Entscheidungsbelegen zurückverfolgbar bleibt.

Vorgehen

1. Felder als exakten Treffer, Abweichung, Review, NoResult oder Ausführungsfehler vor Gesamturteil definieren.
2. Aufnahme-ID, Revision und Grund senden; verspäteten Treffer nicht über Timeout schreiben.
3. Feldverlust, falsche Charge, fehlende Laufzeit und Neustart mit Arbeit prüfen; Sperrroute bestätigen.
4. Fristbudget mit Aufnahme-bis-Quittierung vergleichen, danach reale Etikettenroute prüfen.

Versuch auswerten

Hypothetisch OCR 55 ms, Regeln 5 ms, Kommunikation 5 ms: 65 ms bei 80 ms Frist, 15 ms Reserve. Keine OCR-Geschwindigkeitsmessung. Richtiger Text nach Frist bleibt verspätet.

Versuchsprotokoll

T = 55 + 5 + 5 = 65 ms
M = 80 - 65 = 15 ms

Zwei technische Ansichten

Fehler eingrenzen

• Gesamtgut ohne Felder kann unlesbares Datum oder Charge verbergen.
• Quittierung fremder Aufnahme bestätigt nicht das aktuelle Etikett.

Abnahme und Übergabe

Vollständigkeit, Datenrichtigkeit, Fehlerroute und Quittierung getrennt abnehmen. Tatsächliche Hardware-/Modellidentität dokumentieren.

Quellbilder, erwartete Entscheidung, genaue Revision und vollständigen Ergebnisdatensatz gemeinsam aufbewahren. Den Bewertungssatz vor der endgültigen Parameterwahl einfrieren. Werden seine Antworten später zum Einstellen verwendet, diesen Satz als Entwicklungsdaten kennzeichnen und einen neuen unabhängigen Abnahmesatz beschaffen. Review, NoResult, Ausführungsfehler und fehlende Aufnahme bleiben im Nenner sichtbar; durch Zeilenfilterung werden sie nicht zu bestandenen Prüfungen. Einen reproduzierbaren Fehler zusammen mit dem erfolgreichen Muster sichern. Die Übergabe benennt Änderungsberechtigte, die Wiederherstellung einer früher freigegebenen Revision und den bis zur Abnahme gesperrten Geräteausgang. Ein Softwareergebnis beweist nicht, dass ein bewegtes Werkstück sein richtiges Ziel erreicht hat.