SKU-Farbsortierung: Abnahme und unbekannt

Ziel und Einsatzgrenzen

Abdeckung bekannter Klassen, neue Teile und physische Zuordnung getrennt statt einer günstigen Gesamtzahl bewerten.

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

Klassen, Unbekannt-Regel, Masken und SKU mit unabhängigem Satz einfrieren; simuliert und beaufsichtigt routen, unbestätigte Wege sperren. 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. Farbsortierung und SKU-Erkennung beantworten verschiedene Fragen. Eine Fläche kann zum roten Referenzwert passen, obwohl Größe, Etikett oder Verpackungsvariante falsch sind. Festlegen, ob physische Farbe sortiert, die erwartete SKU geprüft oder beides unabhängig gefordert wird. Farbbilder mit bekannter Kanalreihenfolge verwenden; Belichtung, Weißabgleich und Lichtspektrum im Rezept speichern. Zulässige Materialchargen, Glanz, Schatten und Fremdprodukte statt nur einer sauberen Farbkarte prüfen. Bei geringer Sättigung ist Farbton unzuverlässig; übersteuerte Glanzstellen verlieren nicht rekonstruierbare Informationen. Unbekannte, unbeobachtbare und mehrfarbige Artikel benötigen einen klaren Weg. Modellbasierte SKU-Erkennung separat von der Farbschwelle validieren und Cloud-Übertragung vorab freigeben lassen. 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. Matrix mit Unbekannt-Spalte sowie fehlenden, Review- und Fehlerfällen aufbauen.
2. Farbe unabhängig von SKU prüfen; gleiche Farbe beweist kein gleiches Produkt.
3. Ereignis, Klasse/Unbekannt-Grund und Revision senden, Quittierung und Ziel beobachten.
4. Unklare Farbe, neue SKU, Bildverlust und Verspätung prüfen; unbekannte/Sperrroute ohne Ersatzklasse bestätigen.

Versuch auswerten

Hypothetisch 20 rot, 20 blau, 10 neu. Bekannte Route deckt 37 von 40 = 92.5% ab, keine Gesamtgenauigkeit. Bei neuen werden 2 von 10 = 20% falsch bekannt zugeordnet. Sichtbare Fehler zeigen, was reine Erfolgsquote verbirgt.

Versuchsprotokoll

known_coverage = (18 + 19) / (20 + 20) = 37 / 40 = 92.5%
novel_wrong_known = (1 + 1) / 10 = 2 / 10 = 20%
N = 20 + 20 + 10 = 50

Zwei technische Ansichten

Fehler eingrenzen

• Dashboard ohne Unbekannte bläht Leistung auf.
• Richtige Klasse an falschem Ereignis oder Behälter bleibt Abnahmefehler.

Abnahme und Übergabe

Grenzen für bekannte, neue, vollständige Zählung und Route separat abnehmen. Rechenblatt zeigt Metrik; Ergebnis braucht unabhängige echte Muster und beobachtete Linie.

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.