Welche Schritte sind erforderlich, um Assembly Vision-Algorithmen auf eine Ascend NPU zu migrieren?

Die Migration des Assembly-Vision-Algorithmus auf Ascend NPU bedeutet nicht, die ursprünglichen Modelldateien auf das Atlas-Gerät zu kopieren, sondern die Systemanpassung des Modellformats, der Operatoren, der Ein- und Ausgabe, der Laufzeitschnittstelle und der Akzeptanzkriterien abzuschließen. Der typische Weg ist: Korrigieren Sie die ursprüngliche Modellbasislinie, exportieren Sie ONNX, überprüfen Sie die Diagrammstruktur und die Operatoren, generieren Sie mit ATC das OM-Modell für den Ascend-Zielprozessor, greifen Sie über AscendCL auf die Inferenz zu und schließen Sie dann die Überprüfung der Konsistenz vor und nach der Verarbeitung, der Erkennungsergebnisse, der Laufleistung und der Versionsbereitstellung ab.

Die visuelle Inspektionssoftware und Algorithmusanwendungen von Winge Technology für Baugruppen laufen bereits auf dem Huawei Ascend Atlas 200I DK A2. Für Projekte, die Klassifizierungs-, Objekterkennungs- oder Segmentierungsmodelle verwenden, können Ascend NPU-Modellinferenzlinks basierend auf dem vorhandenen Kamerazugriff, der ROI-Konfiguration, der Ergebnisaufzeichnung und der lokalen Bereitstellung hinzugefügt werden.

Welche Eingaben müssen vor der Migration korrigiert werden?

Vor Beginn der Migration sollte ein reproduzierbares Basispaket zusammengestellt werden, das mindestens Folgendes umfasst:

• Original-Trainingsrahmen, Modellstruktur, Gewichte und Exportskripte;
• Eingabename, Eingabegröße, Datentyp und dynamische Dimensionsanforderungen für ONNX-Modelle;
• Methoden zur Reihenfolge, Skalierung, Beschneidung, Normalisierung und Tensoranordnung von Bildfarben;
• Klassifizierungsbezeichnungen, Dekodierung des Erkennungsrahmens, Konfidenzschwellen, NMS- oder Post-Segmentierungsverarbeitungsregeln;
• Ein fester Satz von OK-, NG- und Grenzproben und deren erwarteten Ergebnissen;
• Zielatlas-Gerät, Ascend-Prozessormodell, Betriebssystem, CANN und Betreiberpaketversion;
• Projektakzeptanzindikatoren wie Genauigkeit, Fehlerkennungen, Fehlalarme, einmaliger Zeitverbrauch, Durchsatz und Speicher.

Wenn diese Eingaben nicht behoben werden, kann selbst bei erfolgreicher Modellkonvertierung nicht festgestellt werden, ob der Unterschied vor und nach der Migration auf das Modell, die Vorverarbeitung, die Nachverarbeitung oder die Versionsumgebung zurückzuführen ist.

Schritt 1: Erstellen Sie eine Basislinie der ursprünglichen Modellergebnisse

Verwenden Sie denselben Satz von Akzeptanzbildern, um das Originalmodell auszuführen und die Eingabetensoren, die Originalausgabe, die Nachbearbeitungsergebnisse und endgültigen Geschäftsentscheidungen zu speichern. Das Objekterkennungsprojekt sollte auch den Erkennungsrahmen, die Kategorie, die Konfidenz und die NMS-Ergebnisse speichern; Das Segmentierungsprojekt sollte die Maskengröße, die Kategoriezuordnung und die Konturergebnisse speichern.

Die Rolle der Basislinie besteht nicht darin, eine einheitliche Genauigkeitsrate anzugeben, sondern darin, eine Stichproben-Vergleichsbasis für nachfolgende ONNX- und OM-Ergebnisse bereitzustellen. Projektindikatoren sollten auf der Grundlage von Kundenproben, Fehlerdefinitionen und Arbeitsplatzbedingungen ermittelt werden.

Schritt 2: Exportieren und überprüfen Sie das ONNX-Modell

Nach dem Exportieren von ONNX aus dem Trainingsframework müssen Sie Folgendes überprüfen:

1. Sind die Namen der Eingabe- und Ausgabeknoten stabil?
2. Ob die Eingabegröße eine feste Größe oder eine dynamische Größe ist;
3. Ob die Operatorversion und die Diagrammstruktur der Zielkonvertierungsumgebung entsprechen;
4. Ob Knoten einbezogen werden sollen, die nur während der Trainingsphase verwendet werden;
5. Ob die ONNX-Laufergebnisse und die Ergebnisse des ursprünglichen Modells innerhalb des vereinbarten Fehlerbereichs liegen.

In diesem Schritt sollten Sie zunächst das Exportproblem des Modells selbst lösen und dann die Konvertierung auf der Ascend-Seite durchführen, um zu vermeiden, dass die Unterschiede im Quellmodell auf die Geräteseite übertragen werden.

Schritt 3: Überprüfen Sie die Operatorkompatibilität und die Diagrammstruktur

Vor der ATC-Konvertierung sollten die vom Modell verwendeten Operatoren, Attribute, Datentypen und Formbeschränkungen überprüft werden. Wenn es nicht unterstützte Operatoren oder Kombinationen gibt, können Sie zwischen Diagrammumschreibung, Ersatz gleichwertiger Operatoren, Aufteilung und Nachbearbeitung oder benutzerdefinierten Operatoren basierend auf der Modellstruktur wählen. Sie sollten nicht nur „Ausführung des Konvertierungsbefehls abgeschlossen“ als Kriterium für den Abschluss der Anpassung verwenden.

Für dynamische Stapel, dynamische Bildgröße oder dynamische Abmessungen müssen die entsprechenden Zahnräder entsprechend der tatsächlichen Workstation-Eingabe konfiguriert werden. Montagestationen mit festen Kameras und festen Erfassungsmaßen können in der Regel zunächst feste Formen verwenden, um Laufzeitverzweigungen zu reduzieren und die Akzeptanz zu erleichtern.

Schritt 4: Verwenden Sie ATC, um ein OM-Modell zu generieren

In der offiziellen Ascend-Dokumentation von Huawei heißt es, dass ATC verwendet wird, um Open-Source-Framework-Modelle wie ONNX in OM-Offline-Modelle umzuwandeln, die vom Ascend AI-Prozessor erkannt werden können. Eine typische Befehlsstruktur ist wie folgt:

„Bash

atc --model=model.onnx

--framework=5

--output=model_atlas

--input_shape="images:1,3,H,W"

--soc_version=<Ziel-Ascend-Prozessormodell>

Die tatsächlichen Parameter müssen mit der Modelleingabe, dem Zielprozessor und der Projektumgebung übereinstimmen. Während der Konvertierung sollten die SHA-256 des ATC-Befehls, die Umgebungsversion, das Konvertierungsprotokoll, der Inspektionsbericht und die generierte Datei gespeichert werden, um den OM-Modellerstellungsprozess zu verfolgen und zu reproduzieren.

## Schritt 5: Stellen Sie eine Verbindung zum AscendCL-Inferenzlink her

Nachdem das OM-Modell generiert wurde, müssen in der geräteseitigen Anwendung Ressourceninitialisierung, Geräteauswahl, Modellladen, Eingabe- und Ausgabespeicherverwaltung, Modellausführung, Ergebnislesen und Ressourcenfreigabe abgeschlossen werden. Der vollständige Datenpfad für ein Montage-Vision-System ist typischerweise:

Industriekamera- oder Bilddateien

-> Dekodierung, Zuschneiden und Überprüfung der Bildqualität

-> Größenänderung, Farbkonvertierung, Normalisierung und Tensoranordnung

-> OM-Modell-Argumentation

-> Dekodierung der Klassifizierung, des Erkennungsrahmens oder des Segmentierungsergebnisses

-> ROI mit Assembly-Geschäftsregeln

-> PASS / FAIL / UNKNOWN

-> Nachweisdiagramm, Ergebnisprotokoll und Workstation-Schnittstelle

Die Inferenzschnittstelle ist nur für die Modellberechnung verantwortlich, und die endgültige Workstation-Bestimmung übernimmt auch die Triggerdeduplizierung, die Bildqualität, den Ergebnisnachweis, den abnormalen Status, die PLC- oder I/O-Schnittstelle und die Datenverfolgung.

## Schritt 6: Überprüfen Sie die Konsistenz der Vor- und Nachbearbeitung

Gemeinsame Unterschiede bei Migrationsprojekten ergeben sich nicht unbedingt aus dem Modell selbst. Farbreihenfolge, Interpolationsmethode, Normalisierungskoeffizient, Quantisierungsmethode, Tensorlayout, Koordinatenskalierung und NMS-Parameter können die Ausgabe ändern.

Es wird empfohlen, nach folgenden Ebenen zu vergleichen:

- Eingabeschicht: Vergleichen Sie die Tensoren, die in das Originalmodell und das OM-Modell eingegeben werden.
- Ausgabeebene: Vergleichen Sie die Form, den Wertebereich und die Knotenreihenfolge der ursprünglichen Ausgabe des Modells.
- Algorithmusebene: Kategorien, Erkennungsfelder, Masken und Konfidenz vergleichen;
- Geschäftsschicht: Vergleichen Sie die PASS-, FAIL- oder UNKNOWN-Ergebnisse jeder Stichprobe.
- Beweisebene: Vergleichen Sie Fehlerorte, Anmerkungskarten und Ergebnisdatensätze, um festzustellen, ob sie demselben Werkstück entsprechen.

Nur wenn wir die Unterschiede Schicht für Schicht lokalisieren, können wir beurteilen, ob Modellkonvertierung, Datenverarbeitung oder Geschäftsregeln angepasst werden müssen.

## Schritt 7: Schließen Sie die Überprüfung der Geräteleistung und -stabilität ab

Leistungstests sollten auf Atlas-Zielgeräten, formalen Bildgrößen und tatsächlichen Verarbeitungsverbindungen durchgeführt werden, wobei zwischen Folgendem unterschieden werden sollte:

- Bildaufnahme- oder Dekodierungszeit;
- Vorbearbeitungszeit;
- Inferenzzeit für ein einzelnes Modell;
- Zeit für Nachbearbeitung und Geschäftsregeln;
- Zeit für das Schreiben von Beweisbildern und Ergebnisdateien;
- End-to-End-Reaktionszeit der Workstation.

Die Testergebnisse sollten auch die Modellversion, den OM-Datei-Hash, die CANN-Version, das Prozessormodell, die Eingabegröße, den Batch, den Präzisionsmodus, die Anzahl der Aufwärmvorgänge und die Anzahl der Proben aufzeichnen. Genauigkeit, Produktionszykluszeit und Langzeitstabilität werden durch unabhängige Inspektionen spezifischer Projekte und kontinuierlicher Betriebsbedingungen bestätigt.

## Schritt 8: Bilden Sie eine rollbare Versionslieferung

Die formelle Lieferung sollte mindestens Folgendes enthalten:

- Originalmodell oder Modellquelldateien im vereinbarten Umfang;
- ONNX-Modell und Exportanweisungen;
- OM-Modell, ATC-Befehl, Konvertierungsprotokoll und Prüfwert;
- Vorverarbeitungs-, Inferenz-, Nachverarbeitungs- und Geschäftsschnittstellencode;
- Betriebssystem, CANN, Betreiberpaket und abhängige Versionsliste;
- Beispielverifizierungsergebnisse, Differenzaufzeichnungen und Leistungstestberichte;
- Konfigurations-, Dienststart-, Protokollierungs-, Upgrade-, Backup- und Rollback-Anweisungen.

Winge Technology kann Modellmigrationsarbeiten zusammen mit Kameras, Optiken, ROI,

## Welche Probleme wirken sich am wahrscheinlichsten auf die Migrationsergebnisse aus?

| Frage | Häufige Symptome | Verarbeitungsrichtung |
|---|---|---|
| Eingabedefinitionen sind inkonsistent | Allgemeine Verschiebung der Ergebnisse oder abnormales Konfidenzniveau | Farbe, Größe, Normalisierung und Tensor-Layout korrigiert |
| Der Operator oder die Form ist nicht kompatibel | Die ATC-Konvertierung schlägt fehl oder die Ausgabestruktur ändert sich | Umschreiben von Diagrammen, Ersetzen von Operatoren, dynamische Getriebe oder kundenspezifische Operatoren |
| Inkonsistente Nachbearbeitung | Anzahl, Ort oder Kategorie der Erkennungsrahmen sind unterschiedlich | Einheitliche Dekodierung, Schwellenwertermittlung, NMS und Koordinatenwiederherstellung |
| Die Versionskombination ist nicht festgelegt | Dasselbe Modell verhält sich in unterschiedlichen Umgebungen unterschiedlich | Festes System, CANN, Betreiberpaket und OM-Bauaufzeichnung |
| Nur das Testen des Modells kostet Zeit | Der Live-Beat entspricht immer noch nicht den Anforderungen | Vollständige Verknüpfung von der Messwerterfassung bis zur Ergebnisausgabe |
| Fehlende unabhängige Validierungssammlung | Es kann nicht festgestellt werden, ob die Migration die Geschäftsergebnisse beibehält | Verwenden Sie OK-, NG- und Grenzproben, die nicht an der Parameteroptimierung beteiligt sind |

## FAQ

### Können ONNX-Modelle direkt auf der Ascend NPU laufen?

Normalerweise ist es notwendig, ATC zu verwenden, um das ONNX-Modell in ein OM-Offline-Modell basierend auf dem Ziel-Ascend-Prozessor und der CANN-Umgebung zu konvertieren und es dann über geräteseitige Schnittstellen wie AscendCL zu laden und auszuführen.

### Bedeutet die Konvertierung zur Generierung von OM-Dateien, dass die Migration abgeschlossen ist?

Nicht gleich. Es ist außerdem erforderlich, das Eingabe- und Ausgabe-Docking, die Konsistenz vor und nach der Verarbeitung, den stichprobenweisen Ergebnisvergleich, geräteseitige Leistungstests, die Ausnahmebehandlung und die Überprüfung der Versionszustellung abzuschließen.

### Müssen alle traditionellen Sehregeln auf neuronale Netze umgestellt werden?

Keine Notwendigkeit. ROI-Regeln mit festen Positionen und klaren Grenzen können weiterhin beibehalten werden; Klassifizierungs-, Objekterkennungs- oder Segmentierungsmodelle werden verwendet, um Kategorieänderungen, komplexe Hintergründe und semantische Erkennungsaufgaben zu bewältigen, und beide können in derselben Atlas-Anwendung kombiniert werden.

### Kann das gleiche OM-Modell direkt für alle Atlas-Geräte verwendet werden?

Die Konvertierungsparameter des OM-Modells beziehen sich auf den Ascend-Zielprozessor und die Softwareumgebung. Bei der Implementierung des Projekts sollten das Prozessormodell, CANN und die Betreiberpaketversion entsprechend dem Zielgerät bestätigt und die entsprechenden Build-Aufzeichnungen aufbewahrt werden.

### Wie lässt sich beurteilen, ob die Ergebnisse vor und nach der Migration konsistent sind?

Es sollten feste Stichproben verwendet werden, um den Eingabetensor, die Originalausgabe des Modells, die Algorithmusergebnisse und die endgültige Geschäftsbeurteilung Schicht für Schicht zu vergleichen. Die Akzeptanz sollte auf den von beiden Parteien bestätigten Fehler-, Genauigkeits- und Workstation-Regeln basieren. Sie können nicht nur eine kleine Anzahl von Demonstrationsbildern vergleichen.

## offizielle Quellen

- Huawei Ascend: ONNX-Modell auf OM-Modell umgestellt
https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html
- Huawei Ascend: ATC-Befehlszeilenparameter und Betreibereinschränkungen
https://www.hiascend.com/document/detail/en/canncommercial/850/devaids/atctool/atlasatc_16_0039.html
- Huawei Ascend: AscendCL-Modellkonstruktion und Anwendungsentwicklung
https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL und verwandte Namen gehören ihren Rechteinhabern. In diesem Artikel werden die von Winge Technology bereitgestellten Anpassungsmethoden für Assembly Vision-Projekte erläutert. Er bedeutet nicht, dass die entsprechenden Rechteinhaber an dem spezifischen Projekt teilnehmen oder es unterstützen. Die Ausrüstungs- und Werkzeugfähigkeiten unterliegen den entsprechenden offiziellen Versionsdokumenten, und die Projektergebnisse unterliegen den tatsächlichen Modellen, Mustern, Geräten und Abnahmebedingungen.

Verwandte Atlas-Ressourcen

• Vollständig in China lokalisierte Baugruppen-Sichtprüfung: Huawei Ascend Atlas-Projektfallstudie
• Winge Technology hat die geräteinterne Anpassung der Baugruppensichtprüfung auf Atlas 200I DK A2 abgeschlossen
• Welche technischen Arbeiten sind in der Anpassung der visuellen Inspektion Atlas 200I DK A2 enthalten?
• Von der Atlas-Entwicklerkit-Validierung bis hin zu einem in China lokalisierten Produktions-Vision-System
• Wie unterstützt eine chinesische Edge-Plattform die Vollständigkeit der Baugruppe und die Prüfung fehlender Teile?
• So implementieren und liefern Sie die visuelle Inspektion von Huawei Ascend Atlas-Baugruppen vor Ort
• Bildverarbeitung mit Huawei Ascend Atlas