Welke stappen zijn vereist om Assembly Vision-algoritmen naar een Ascend NPU te migreren?-Beeldverwerking met Huawei Ascend Atlas-Winge Technology

Technisch artikel

Het migreren van het assemblage vision-algoritme naar Ascend NPU betekent niet dat de originele modelbestanden naar het Atlas-apparaat worden gekopieerd, maar dat de systeemaanpassing van het modelformaat, operators, invoer en uitvoer, runtime-interface en acceptatiecriteria wordt voltooid. De typische manier is: corrigeer de originele modelbasislijn, exporteer ONNX, controleer de grafiekstructuur en operatoren, gebruik ATC om het OM-model voor de Ascend-doelprocessor te genereren, toegang tot de gevolgtrekking via AscendCL, en voltooi vervolgens de verificatie van de consistentie voor en na verwerking, detectieresultaten, lopende prestaties en versie-implementatie.

De visuele inspectiesoftware en algoritmetoepassingen van Winge Technology voor assemblages draaien al op de Huawei Ascend Atlas 200I DK A2. Voor projecten die classificatie-, objectdetectie- of segmentatiemodellen gebruiken, kunnen Ascend NPU-modelinferentielinks worden toegevoegd op basis van bestaande cameratoegang, ROI-configuratie, resultatenregistratie en lokale implementatie.

Welke gegevens moeten vóór de migratie worden gecorrigeerd?

Voordat met de migratie wordt begonnen, moet een reproduceerbaar basispakket worden samengesteld dat minimaal het volgende omvat:

Origineel trainingsframework, modelstructuur, gewichten en exportscripts;
Invoernaam, invoergrootte, gegevenstype en dynamische dimensievereisten voor ONNX-modellen;
Methoden voor het ordenen, schalen, bijsnijden, normaliseren en versterken van afbeeldingskleuren;
Classificatielabels, herkenningsframe-decodering, betrouwbaarheidsdrempels, NMS of verwerkingsregels na segmentatie;
Een vaste set OK-, NG- en limietmonsters en hun verwachte resultaten;
Target Atlas-apparaat, Ascend-processormodel, besturingssysteem, CANN en operatorpakketversie;
Projectacceptatie-indicatoren zoals nauwkeurigheid, valse positieven, valse positieven, uniek tijdverbruik, doorvoer en opslag.

Als deze input niet wordt aangepakt, zelfs als de modelconversie succesvol is, kan niet worden vastgesteld of het verschil vóór en na de migratie te wijten is aan de model-, preprocessing-, postprocessing- of versiebeheeromgeving.

Stap 1: Creëer een basislijn van de originele modelresultaten

Gebruik dezelfde set acceptatiebeelden om het originele model uit te voeren en de inputtensoren, originele output, nabewerkingsresultaten en uiteindelijke zakelijke beslissingen op te slaan. Het objectdetectieproject moet ook het detectieframe, de categorie, het vertrouwen en de NMS-resultaten opslaan; Het segmentatieproject moet de maskergrootte, categorietoewijzing en contourresultaten opslaan.

De rol van de basislijn is niet het bieden van een uniforme nauwkeurigheidsgraad, maar eerder het bieden van een steekproefbasis voor vergelijking voor daaropvolgende ONNX- en OM-resultaten. Projectindicatoren moeten worden bepaald op basis van klantmonsters, defectdefinities en werkplekomstandigheden.

Stap 2: Exporteer en verifieer het ONNX-model

Nadat u ONNX uit het trainingsframework heeft geëxporteerd, moet u het volgende verifiëren:

Zijn de namen van de invoer- en uitvoerknooppunten stabiel?
Of de invoergrootte een vast formaat of een dynamisch formaat is;
Of de operatorversie en grafiekstructuur overeenkomen met de doelconversieomgeving;
Of knooppunten moeten worden opgenomen die alleen tijdens de trainingsfase worden gebruikt;
Of de runresultaten van ONNX en de originele modelresultaten binnen het overeengekomen foutbereik liggen.

In deze stap moet u eerst het exportprobleem van het model zelf oplossen en vervolgens de conversie aan de Ascend-zijde uitvoeren om te voorkomen dat de verschillen in het bronmodel naar de apparaatzijde worden overgebracht.

Stap 3: Controleer de operatorcompatibiliteit en kaartstructuur

Vóór ATC-conversie moeten de operators, attributen, gegevenstypen en vormbeperkingen die door het model worden gebruikt, worden gecontroleerd. Als er niet-ondersteunde operators of combinaties zijn, kunt u kiezen tussen het herschrijven van grafieken, het vervangen van gelijkwaardige operators, het splitsen en nabewerken, of aangepaste operators op basis van de modelstructuur. U moet niet alleen 'uitvoering van conversieopdracht voltooid' gebruiken als criterium voor voltooiing van de aanpassing.

Voor dynamische stapels, dynamische afbeeldingsgrootte of dynamische afmetingen moeten de overeenkomstige tandwielen worden geconfigureerd op basis van de daadwerkelijke werkstationinvoer. Assemblagestations met vaste camera's en vaste opnameafmetingen kunnen in eerste instantie doorgaans vaste vormen gebruiken om de vertakking van de looptijd te verminderen en de acceptatie te vergemakkelijken.

Stap 4: Gebruik ATC om een OM-model te genereren

In de officiële Ascend-documentatie van Huawei staat dat ATC wordt gebruikt om open source framework-modellen zoals ONNX om te zetten in OM offline-modellen die kunnen worden herkend door de Ascend AI-processor. Een typische commandostructuur is als volgt:

“Bas

atc --model=model.onnx

--framework=5

--output=model_atlas

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

--soc_version=<doel Ascend-processormodel>

De feitelijke parameters moeten overeenkomen met de modelinvoer, de doelprocessor en de projectomgeving. Tijdens de conversie moeten het ATC-commando SHA-256, de omgevingsversie, het conversielogboek, het inspectierapport en het gegenereerde bestand worden opgeslagen om het creatieproces van het OM-model te volgen en te reproduceren.

Stap 5: Maak verbinding met de AscendCL-inferentielink

Nadat het OM-model is gegenereerd, moet de applicatie aan de apparaatzijde de initialisatie van de bronnen, de apparaatselectie, het laden van het model, het beheer van het invoer- en uitvoergeheugen, het uitvoeren van het model, het lezen van resultaten en het vrijgeven van de bronnen voltooien. Het volledige gegevenspad voor een assemblagevisiesysteem is doorgaans:

Industriële camera- of afbeeldingsbestanden

-> Decoderen, bijsnijden en controleren van de beeldkwaliteit

-> Formaat wijzigen, kleurconversie, normalisatie en tensorschikking

-> OM-modelredenering

-> Het decoderen van het classificatie-, detectieframework of segmentatieresultaat

-> ROI met bedrijfsregels voor montage

-> PASS / FAIL / ONBEKEND

-> Bewijsgrafiek, resultatenlogboek en werkstationinterface

De inferentie-interface is alleen verantwoordelijk voor de modelberekening, en de uiteindelijke bepaling van het werkstation zorgt ook voor trigger-deduplicatie, beeldkwaliteit, resultaatbewijs, abnormale status, PLC- of I/O-interface en gegevenstracering.

Stap 6: Controleer de consistentie van de voor- en nabewerking

Gemeenschappelijke verschillen in migratieprojecten vloeien niet noodzakelijkerwijs voort uit het model zelf. Kleurvolgorde, interpolatiemethode, normalisatiecoëfficiënt, kwantiseringsmethode, tensorlay-out, coördinatenschaling en NMS-parameters kunnen de uitvoer veranderen.

Het wordt aanbevolen om op de volgende niveaus te vergelijken:

- Invoerlaag: vergelijk de tensoren die zijn ingevoerd in het originele model en het OM-model. - Uitvoerlaag: vergelijk de vorm, het waardenbereik en de knooppuntvolgorde van de oorspronkelijke uitvoer van het model. - Algoritmeniveau: vergelijk categorieën, detectievelden, maskers en vertrouwen; - Bedrijfslaag: vergelijk de PASS-, FAIL- of UNKNOWN-resultaten van elk monster. - Bewijsniveau: vergelijk defectlocaties, annotatiekaarten en resultatenrecords om te bepalen of ze overeenkomen met hetzelfde werkstuk.

Alleen door de verschillen laag voor laag in kaart te brengen, kunnen we beoordelen of modelconversie, dataverwerking of bedrijfsregels aangepast moeten worden.

Stap 7: Voltooi de prestatie- en stabiliteitscontrole van het apparaat

Prestatietests moeten worden uitgevoerd op Atlas-doelapparaten, formele beeldformaten en daadwerkelijke verwerkingsverbindingen, waarbij onderscheid wordt gemaakt tussen:

- beeldopname- of decoderingstijd; - voorbewerkingstijd; - Inferentietijd voor één enkel model; - Tijd voor nabewerking en bedrijfsregels; - Tijd voor het schrijven van bewijsafbeeldingen en resultatenbestanden; - End-to-end responstijd van het werkstation.

De testresultaten moeten ook de modelversie, OM-bestandshash, CANN-versie, processormodel, invoergrootte, batch, precisiemodus, aantal opwarmingen en aantal monsters registreren. Nauwkeurigheid, productiecyclustijd en stabiliteit op lange termijn worden bevestigd door onafhankelijke inspecties van specifieke projecten en continue bedrijfsomstandigheden.

Stap 8: Vorm een oprolbare versie levering

De formele levering dient in ieder geval het volgende te bevatten:

- Origineel model of modelbronbestanden in de overeengekomen omvang; - ONNX model- en exportinstructies; - OM-model, ATC-commando, conversieprotocol en controlewaarde; - Voorverwerking, gevolgtrekking, naverwerking en bedrijfsinterfacecode; - Besturingssysteem, CANN, operatorpakket en lijst met afhankelijke versies; - Monsterverificatieresultaten, verschilregistraties en prestatietestrapporten; - Instructies voor configuratie, opstarten van de service, loggen, upgraden, back-up en terugdraaien.

Winge Technology kan modelmigratiewerkzaamheden uitvoeren in combinatie met camera's, optica, ROI,

Welke problemen zullen waarschijnlijk de migratieresultaten beïnvloeden?

| Vraag | Veel voorkomende symptomen | Verwerkingsrichting | |---|---|---| | Invoerdefinities zijn inconsistent | Algemene verschuiving in resultaten of abnormaal vertrouwensniveau | Kleur, grootte, normalisatie en tensorlay-out gecorrigeerd | | De operator of het formulier is niet compatibel | ATC-conversie mislukt of uitvoerstructuur verandert | Grafieken herschrijven, operators vervangen, dynamische versnellingen of aangepaste operators | | Inconsistente nabewerking | Aantal, locatie of categorie van herkenningsframes zijn verschillend | Uniforme decodering, drempelwaarde, NMS en coördinatenherstel | | De versiecombinatie staat niet vast | Hetzelfde model gedraagt zich anders in verschillende omgevingen | Vast systeem, CANN, operatorpakket en OM-bouwrecord | | Alleen al het testen van het model kost tijd | De livebeat voldoet nog steeds niet aan de eisen | Volledige koppeling van meetverwerving tot resultaatuitvoer | | Ontbrekende onafhankelijke validatieverzameling | Er is geen manier om te bepalen of de migratie de bedrijfsresultaten zal behouden | Gebruik OK-, NG- en limietmonsters die niet betrokken zijn bij parameteroptimalisatie |

Veelgestelde vragen

### Kunnen ONNX-modellen rechtstreeks op de Ascend NPU draaien?

Normaal gesproken is het nodig om ATC te gebruiken om het ONNX-model om te zetten in een OM offline-model op basis van de Ascend-doelprocessor en CANN-omgeving, en het vervolgens te laden en uit te voeren via apparaatinterfaces zoals AscendCL.

### Betekent de conversie om OM-bestanden te genereren dat de migratie voltooid is?

Niet meteen. Het is ook noodzakelijk om de invoer- en uitvoerdocking, de consistentie vóór en na de verwerking, de vergelijking van willekeurige resultaten, het testen van de prestaties van het apparaat, de afhandeling van uitzonderingen en de verificatie van de versielevering te voltooien.

### Moeten alle traditionele visieregels worden omgezet in neurale netwerken?

Geen behoefte. ROI-regels met vaste posities en duidelijke grenzen kunnen nog steeds worden gehandhaafd; Classificatie-, objectdetectie- of segmentatiemodellen worden gebruikt om categoriewijzigingen, complexe achtergronden en semantische herkenningstaken af te handelen, en beide kunnen worden gecombineerd in dezelfde Atlas-applicatie.

### Kan hetzelfde OM-model rechtstreeks voor alle Atlas-apparaten worden gebruikt?

De conversieparameters van het OM-model hebben betrekking op de Ascend-doelprocessor en de softwareomgeving. Bij de implementatie van het project moeten het processormodel, de CANN en de operatorpakketversie worden bevestigd volgens het doelapparaat en moeten de bijbehorende buildrecords worden bewaard.

### Hoe kan ik beoordelen of de resultaten voor en na de migratie consistent zijn?

Er moet gebruik worden gemaakt van vaste steekproeven om de inputtensor, de oorspronkelijke output van het model, de algoritmeresultaten en het uiteindelijke zakelijke oordeel laag voor laag te vergelijken. Acceptatie moet gebaseerd zijn op fouten, nauwkeurigheid en werkstationregels die door beide partijen zijn bevestigd. Je kunt niet zomaar een klein aantal demonstratiebeelden vergelijken.

officiële bronnen

- Huawei Ascend: ONNX model overgeschakeld naar OM-model https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html - Huawei Ascend: ATC-opdrachtregelparameters en operatorbeperkingen https://www.hiascend.com/document/detail/nl/canncommercial/850/devaids/atctool/atlasatc_16_0039.html - Huawei Ascend: AscendCL-modelconstructie en applicatie-ontwikkeling https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL en verwante namen zijn eigendom van hun auteursrechthouders. In dit artikel worden de aanpassingsmethoden voor Assembly Vision-projecten van Winge Technology uitgelegd. Het betekent niet dat de relevante rechthebbenden deelnemen aan of het specifieke project ondersteunen. De uitrusting en gereedschapsmogelijkheden zijn onderworpen aan de relevante officiële vrijgavedocumenten, en de projectresultaten zijn onderworpen aan de feitelijke modellen, monsters, uitrusting en acceptatievoorwaarden.