KI-GESTÜTZTE DOKUMENTATION
Was möchten Sie wissen?
Rezept-Backtesting
Recipe Backtesting ermöglicht es Ihnen, eine kuratierte Sammlung von Bildern erneut durch das aktive Rezept laufen zu lassen und einen objektiven Bericht darüber zu erhalten, wie es Bild für Bild abgeschnitten hat. Es führt das vollständige Rezept aus, jedes Modell, jede Node-RED-Regel, jeden Pass/Fail-Schwellenwert, sodass die Ausgabe exakt das widerspiegelt, was in der Produktion geschehen wäre.
Stellen Sie es sich als Regressionstest-Suite für Ihr Vision-Rezept vor.
Vor Backtesting bestand die einzige Möglichkeit, eine Rezeptänderung zu verifizieren, darin, auf neue Teile auf der Linie zu warten. Mit Backtesting halten Sie eine permanente Bibliothek schwieriger Aufnahmen, lassen das neue Rezept in Sekunden gegen alle laufen und vergleichen den alten Lauf mit dem neuen Lauf nebeneinander. Die Zustimmung des Kunden wird zu einer objektiven Diskussion, nicht zu einem Bauchgefühl.
Lernziele
Am Ende dieser Anleitung können Sie:
- Ein Test Set repräsentativer Bilder mit Pass/Fail-Ground-Truth erstellen
- Einen Backtest gegen das aktive Rezept durchführen und die Confusion-Matrix lesen
- In Escapes und Overkills eintauchen, um zu diagnostizieren, was schiefgelaufen ist
- Ausbeute-Ergebnisse nach Tag, Produktionslinie oder Aufnahmewoche gruppieren, um Modelldrift zu erkennen
- Backtest-Läufe per HTTP auslösen für geplante oder CI-artige Automatisierung
Kernkonzepte
Recipe Backtesting hat zwei Bausteine. Sie befinden sich hinter dem Eintrag Recipe Backtesting in der linken Navigation.
| Konzept | Was es ist |
|---|---|
| Test Set | Eine wiederverwendbare Sammlung von JPEGs zusammen mit deren Ground-Truth-Labels. Test Sets sind unabhängig von einem bestimmten Rezept, dasselbe Test Set kann gegen verschiedene Rezepte oder verschiedene Versionen desselben Rezepts ausgeführt werden. Test Sets können importiert, exportiert und kameraübergreifend geteilt werden. |
| Backtest Run | Eine Momentaufnahme eines Test Sets, ausgeführt gegen das aktuell aktive Rezept. Runs sind unveränderlich, ein späteres Neu-Labeln des Test Sets ändert die Ergebnisse eines vorherigen Runs nicht. |
Test Set erstellen
Öffnen Sie in der linken Navigation Recipe Backtesting → Test Sets und klicken Sie dann auf Create Test Set. Geben Sie ihm einen Namen und eine Beschreibung, die Beschreibung wird durchsuchbar und erscheint im Run-Bericht.
Nach der Erstellung öffnet sich das Test Set im Editor ohne Bilder. Die Kopfzeile enthält die wichtigsten Aktionen: Add Images, Import from Library (im Dropdown neben Add Images), Export und Start Backtest (deaktiviert, bis das Set Bilder enthält).
Bilder hinzufügen
Es gibt zwei Möglichkeiten, ein Test Set zu befüllen:
- JPEG-Bilder per Klick oder Drag-and-Drop in den Upload-Bereich ziehen. Nur JPEG wird akzeptiert, und jedes Bild muss exakt der Aufnahmeauflösung der Kamera entsprechen.
- Import from Library, die schnellere Option für Produktionskameras. Damit werden frühere Aufnahmen direkt von der Kamera übernommen, mit allen eingebetteten Metadaten (Aufnahmezeit, Trigger-ID, ursprüngliches Pass/Fail, Tags, Inspection Target).
Der Import-from-Library-Dialog erlaubt das Filtern nach Capture Number, Trigger-ID, Aufnahmezeitraum (Shortcuts 5m / 30m / 1h / 12h / 1d), Notizen, Rezeptname, Pass/Fail sowie einem Advanced-Filters-Panel für Inspection Target / Region / Search Area. Der Schalter Include Trainset Images ist standardmäßig aktiviert. Der Schalter Alignment Fails Only ist nützlich, wenn Sie speziell einen Aligner-Fix verifizieren.
Aus der Library importierte Bilder behalten die Kamera-Seriennummer, die ursprüngliche Aufnahmezeit, die Rezeptversion, die sie erzeugt hat, und die vollständigen JSON-Metadaten des ursprünglichen Produktionsergebnisses. Das bedeutet, Sie können das ursprüngliche Pass/Fail als Ground Truth wiederverwenden, anstatt von Grund auf neu zu labeln. Sie können es auch korrigieren, falls sich die Standards seitdem geändert haben.
Nach dem Import zeigt der Editor die Bilder mit einer Kurzübersicht (Bildanzahl, Ground-Truth-Anzahl, Gesamtgröße) und einer Test Set Distribution-Aufschlüsselung nach Aufnahmewoche und Systemname.
Ground Truth labeln
Ground Truth ist das tatsächliche Pass/Fail-Urteil für jedes Bild – das, was Sie als Bediener als Ergebnis erwartet hätten. Ground Truth ist die Grundlage, um Werte für Genauigkeit, Escape und Overkill überhaupt berechnen zu können.
Klicken Sie auf ein Bild, um den Image Viewer zu öffnen. Wenn das Bild aus einer Produktionsaufnahme importiert wurde, sind die ursprünglichen Suchbereiche und das Pass/Fail-Ergebnis bereits verfügbar und können wiederverwendet oder korrigiert werden. Wenn das Bild keine eingebetteten Metadaten enthält (z. B. ein älterer Export oder ein manueller Upload), klicken Sie auf Set Up Labeling, um das Bild mit den Suchbereichen des aktuell aktiven Recipes zu verknüpfen.
Sobald das Bild verknüpft ist, erhält jeder Suchbereich einen eigenen Pass-/Fail-/Unknown-Radiobutton. Belassen Sie einen Suchbereich auf Unknown, wenn Sie sich nicht sicher sind – diese Zeilen werden von der Genauigkeitsberechnung ausgeschlossen, fließen aber weiterhin in den Gesamt-Yield ein.
Wenn Ihr Recipe drei Suchbereiche an einem Bauteil hat, benötigt jedes Bild im Testset drei Ground-Truth-Labels – eines pro Bereich. Die Statistiken auf der rechten Seite unterscheiden zwischen Images (Anzahl der Aufnahmen) und Ground Truth Labels (Anzahl der gelabelten Suchbereiche).
Sie können jedem Bild zusätzlich eine Description (was an dieser Aufnahme interessant ist) und Tags (Liniennummer, Schicht, Defekttyp, beliebig) zuweisen. Tags sind im Run-Report durchsuchbar und können den Yield-Breakdown gruppieren.
Einen Backtest-Run starten
Sobald das Testset mindestens ein Bild enthält, klicken Sie auf Start Backtest. Geben Sie dem Run einen Namen. Die Kamera wird:
- Jede aktive Inspektion pausieren – eingehende Trigger werden während des Runs ignoriert.
- Jedes Bild im Testset durchlaufen.
- Das gesamte aktive Recipe für jedes Bild ausführen, einschließlich jedes Node-RED-Nodes, jeder Pass/Fail-Regel sowie aller Aktoren oder I/O-Integrationen, die das Recipe normalerweise in der Produktion ansteuern würde.
- Jedes Ergebnis zurück in die Library und Haystack speichern – genau so, als wäre es eine Produktionsaufnahme gewesen.
Da der Run das vollständige Recipe ausführt, wird jeder Node-RED-Output-Node tatsächlich ausgelöst: Modbus-Writes erfolgen, MQTT-Nachrichten werden veröffentlicht, HTTP-Calls werden gesendet. Führen Sie keine Backtests auf einer Kamera aus, die in eine aktive Produktionslinie eingebunden ist, es sei denn, Sie sind auf diese Nebeneffekte vorbereitet. Idealerweise führen Sie Backtests auf einer zweiten, ausschließlich zur Validierung dedizierten Kamera aus.
Den Run-Report auswerten
Runs sind dauerhaft. Öffnen Sie Recipe Backtesting → Backtest Runs, um alle historischen Runs anzuzeigen, nach Testset zu filtern und beliebige davon zu öffnen.
Der Run-Report besteht aus drei Teilen: der Confusion Matrix, dem Yield-Report und einer Detailansicht pro Bild.
Confusion Matrix
| Ground Truth: Pass | Ground Truth: Fail | |
|---|---|---|
| Recipe: Pass | True Positive | Escape |
| Recipe: Fail | Overkill | Correct Reject |
- True Positive – Recipe und Ground Truth stimmen in einem Pass überein. Das ist erwünscht.
- Correct Reject – Recipe und Ground Truth stimmen in einem Fail überein. Das ist erwünscht.
- Escape – das Recipe meldete Pass, aber das Bild war tatsächlich fehlerhaft. Dies ist fast immer der schlimmste Fehlerfall, da ein schlechtes Teil die Linie verlassen hat.
- Overkill – das Recipe meldete Fail, aber das Bild war tatsächlich in Ordnung. Dies ist eine Falschausschleusung: Die Linie verwirft Gutteile.
Klicken Sie auf eine beliebige Zelle, um die Bildliste auf genau diese Aufnahmen zu filtern, und klicken Sie dann auf ein Bild, um zum zugehörigen Library-Eintrag mit dem vollständigen Haystack-Trace zu springen.
Escapes bedeuten meist, dass das Modell einen Defekt übersehen hat oder ein Node-RED-Schwellenwert zu permissiv ist. Overkills bedeuten meist, dass ein Schwellenwert zu streng ist oder das Trainingsset zu stark auf schwierige Positives ausgerichtet ist. Die Confusion Matrix zeigt Ihnen, welcher Fehler dominiert – beheben Sie diesen zuerst.
Yield und Zykluszeit
Der Run-Header zeigt den Gesamt-Yield (Gesamtanzahl Passes / Gesamtanzahl Captures) sowie die durchschnittliche Zykluszeit, gemessen als Gesamtdauer des Runs geteilt durch die Anzahl der Bilder. Dies ist die genaueste Zykluszeit-Schätzung, die die Kamera liefern kann, da derselbe Node-RED Flow ausgeführt wird, der auch in der Produktion läuft.
Yield-Aufschlüsselung nach Tag oder System
Die Ansicht Yield Report → Advanced Distribution gruppiert den Yield nach Tag oder nach System (Produktionslinie). So erkennen Sie zwei Arten von Problemen, die der Gesamtwert verbirgt:
- Line bias: Linie 37 zeigt 98 % Yield, Linie 59 zeigt 40 %. Ihr Trainingsdatensatz ist wahrscheinlich zu stark mit Daten von Linie 37 belegt.
- Model drift: Der Yield ist bei Captures von vor 2 Monaten in Ordnung, fällt aber bei Captures dieser Woche ab. Bauteile haben sich verändert, oder die Beleuchtung hat sich geändert, und das Rezept muss aktualisiert werden.
Filtern, Tagging und Export
Tags und Beschreibungen ermöglichen es, den Run-Report auf praktische Weise zu segmentieren:
- Filtern nach
line-37, um einen Fix zu bestätigen, bevor er auf die anderen Linien ausgerollt wird - Filtern nach
defect:crack, um zu überprüfen, ob ein bestimmter Fehlermodus jetzt erkannt wird - Filtern nach Kalenderwoche, um zu sehen, wie sich das Rezept bei aktuellen Bauteilen im Vergleich zum Golden Set verhält
Der vollständige Run-Report kann als PDF exportiert werden, um ihn mit Kunden zu teilen – sehr nützlich in Abnahmemeetings, bei denen objektive Zahlen besser sind als nebeneinander gelegte Screenshot-Vergleiche.
Automatisierung mit HTTP
Jede Aktion im Recipe Backtesting ist über die HTTP-API der Kamera verfügbar. Gängige Automatisierungsmuster:
- Node-RED Intervall-Trigger: Nach einem wöchentlichen Zeitplan fügt Node-RED die Produktions-Captures der letzten 7 Tage einem rollierenden Test-Set hinzu und startet einen Run. Fällt der Yield unter einen Schwellenwert, wird ein Alarm ausgelöst.
- CI-Gate: Bevor eine Rezeptversion über den Import-Endpunkt bereitgestellt werden kann, löst ein Skript einen Backtest-Run aus und blockiert das Deployment, falls die Genauigkeit gegenüber der Vorgängerversion zurückgeht.
- PLC-Trigger: Die SPS kann einen digitalen Eingang mit einer bestimmten ID setzen, Node-RED erkennt dies und startet einen Backtest. Die SPS liest das Pass/Fail-Ergebnis nach Abschluss des Runs über Modbus oder Ethernet/IP zurück.
Siehe den Abschnitt API Reference in der Swagger UI der Kamera unter http://CAMERA_IP/edge/v2/docs für den Endpunkt POST /backtest_sets/{id}/runs und die zugehörigen Test-Set-CRUD-Endpunkte. Ersetzen Sie CAMERA_IP durch die tatsächliche IP-Adresse Ihrer Kamera.
Aufbau eines guten Test-Sets
Der Unterschied zwischen einem Test-Set, das echte Regressionen erkennt, und einem, das ein trügerisches Sicherheitsgefühl vermittelt, liegt in der Ausgewogenheit.
- Pass/Fail-Balance: Streben Sie ein etwa gleiches Verhältnis von Gut- und Schlechtteilen an. Ein Set mit 95 % Pass-Anteil lässt jedes Rezept hervorragend aussehen.
- Fehlerabdeckung: Jeder Fehlermodus, der für den Kunden relevant ist, benötigt mindestens einige Beispiele. Wenn ein bestimmter Defekt im Test-Set nie vorkommt, gibt es keinen Nachweis, dass das Rezept ihn erkennt.
- Zeitliche Balance: Verwenden Sie Captures aus mehreren Wochen oder Monaten, nicht nur von heute. Produktionslinien driften (Beleuchtung verändert sich, Lieferanten von Bauteilen wechseln), und Ihr Test-Set sollte diese Drift abbilden.
- Linien-Balance: Wenn das Rezept auf 50 Produktionslinien läuft, sollte das Test-Set Captures von jeder dieser Linien enthalten – nicht nur von der Linie auf Ihrem Prüfstand.
- Edge Cases: Die kniffligen Captures, die knapp bestanden oder knapp durchgefallen sind, sind dort, wo Retraining echten Mehrwert bringt. Reichern Sie das Test-Set mit diesen an.
- Volumen: 10 Bilder reichen für einen Smoke-Test einer Änderung; 100+ sind ausreichend, um statistisch belastbare Genauigkeitsaussagen zu treffen.
Wenn der Kunde seine Pass-Kriterien ändert, müssen Sie Bilder derzeit einzeln neu labeln. Eine praktische Lösung: Pflegen Sie ein stabiles Test-Set, auf das sich alle einigen, und ein zweites aktuelles Test-Set, das die sich entwickelnden Kriterien abbildet. Sobald sich die aktuellen Kriterien stabilisiert haben, können sie wieder in das stabile Set integriert werden.
Was heute getestet wird und was nicht
Backtesting läuft auf der vollständigen Recipe-Ebene und bewertet die finale aggregierte Pass/Fail-Ausgabe. Das bedeutet:
- Funktioniert für Classification-, Segmentation-, Measurement- und OCR-Recipes. Alles, was über Node-RED zu einem einzelnen Pass/Fail führt, ist testbar.
- Roadmap: Backtesting auf Modellebene ist in Vorbereitung. In zukünftigen Releases werden Sie Ground Truth auf ROI-Ebene labeln und die Ausgabe des Segmenters oder Classifiers direkt vergleichen können, ohne auf Node-RED-Schwellenwerte angewiesen zu sein. Numerische Ausgaben (z. B. Messabstände, Multi-Class-Classification) erhalten dedizierte Metriken über Pass/Fail hinaus.