What steps are required to migrate assembly vision algorithms to an Ascend NPU?

Migrating the assembly vision algorithm to Ascend NPU does not mean copying the original model files to the Atlas device, but completing the system adaptation of the model format, operators, input and output, runtime interface and acceptance criteria. The typical path is: fix the original model baseline, export ONNX, check the graph structure and operators, use ATC to generate the OM model for the target Ascend processor, access inference through AscendCL, and then complete the verification of pre- and post-processing consistency, detection results, running performance and version delivery.

Winge Technology’s assembly visual inspection software and algorithm applications are already running on Huawei Ascend Atlas 200I DK A2. For projects using classification, object detection or segmentation models, Ascend NPU model inference links can be added based on existing camera access, ROI configuration, result recording and local deployment.

What inputs need to be fixed before migration?

Before starting the migration, a reproducible baseline package should be formed, which at least includes:

• Original training framework, model structure, weights and export scripts;
• Input name, input size, data type and dynamic dimension requirements for ONNX models;
• Image color ordering, scaling, cropping, normalization and tensor arrangement methods;
• Classification labels, detection frame decoding, confidence thresholds, NMS or post-segmentation processing rules;
• A fixed set of OK, NG and boundary samples and their expected results;
• Target Atlas device, Ascend processor model, operating system, CANN and operator package version;
• Project acceptance indicators such as accuracy, missed detections, false alarms, single time consumption, throughput and memory.

If these inputs are not fixed, even if the model conversion is successful, it will not be possible to determine whether the difference before and after migration comes from the model, pre-processing, post-processing or version environment.

Step 1: Establish a baseline of original model results

Use the same set of acceptance images to run the original model and save the input tensors, original output, post-processing results and final business decisions. The object detection project should also save the detection frame, category, confidence and NMS results; the segmentation project should save the mask size, category mapping and contour results.

The role of the baseline is not to give a unified accuracy rate, but to provide a sample-by-sample comparison basis for subsequent ONNX and OM results. Project indicators should be determined based on customer samples, defect definitions and workstation conditions.

Step 2: Export and inspect the ONNX model

After exporting ONNX from the training framework, you need to check:

1. Are the input and output node names stable?
2. Whether the input size is a fixed size or a dynamic size;
3. Whether the operator version and graph structure conform to the target conversion environment;
4. Whether to include nodes that are only used during the training phase;
5. Whether the ONNX running results and the original model results are within the agreed error range.

In this step, you should first solve the export problem of the model itself, and then enter the Ascend side conversion to avoid bringing the source model differences into the device side.

Step 3: Check operator compatibility and graph structure

Before ATC conversion, the operators, attributes, data types and shape constraints used by the model should be checked. If there are unsupported operators or combinations, you can choose graph rewriting, equivalent operator replacement, splitting and post-processing, or customized operators based on the model structure. You should not just use "conversion command execution completed" as the adaptation completion criterion.

For dynamic batch, dynamic image size or dynamic dimensions, the corresponding gears need to be configured according to the actual workstation input. Assembly stations with fixed cameras and fixed detection dimensions can usually use fixed shapes first to reduce runtime branches and facilitate acceptance.

Step 4: Use ATC to generate OM model

Huawei's Ascend official documentation states that ATC is used to convert open source framework models such as ONNX into OM offline models that can be recognized by the Ascend AI processor. A typical command structure is as follows:

atc --model=model.onnx 
--framework=5 
--output=model_atlas 
--input_shape="images:1,3,H,W" 
--soc_version=<target Ascend processor model>

Actual parameters must be consistent with the model input, target processor, and project environment. During conversion, the SHA-256 of the ATC command, environment version, conversion log, inspection report and generated file should be saved to trace and reproduce the OM model building process.

Step 5: Connect to AscendCL inference link

After the OM model is generated, resource initialization, device selection, model loading, input and output memory management, model execution, result reading and resource release need to be completed in the device-side application. The complete data path for an assembly vision system is typically:

Industrial camera or image files
-> Decoding, cropping and image quality checking
-> resize, color conversion, normalization and tensor arrangement
-> OM model reasoning
-> Classification, detection frame or segmentation result decoding
-> ROI with assembly business rules
-> PASS / FAIL / UNKNOWN
-> Evidence diagram, result record and workstation interface

The inference interface is only responsible for model calculation, and the final workstation determination also handles trigger deduplication, picture quality, result evidence, abnormal status, PLC or I/O interface and data tracing.

Step 6: Verify the consistency of pre-processing and post-processing

Common differences in migration projects do not necessarily come from the model itself. Color order, interpolation method, normalization coefficient, quantization method, tensor layout, coordinate scaling and NMS parameters may change the output.

It is recommended to compare according to the following levels:

• Input layer: compare the tensors entering the original model and the OM model;
• Output layer: compare the shape, value range and node order of the original output of the model;
• Algorithm layer: compare categories, detection boxes, masks and confidence;
• Business layer: Compare the PASS, FAIL or UNKNOWN results of each sample;
• Evidence layer: Compare defect locations, annotation maps and result records to see if they correspond to the same workpiece.

Only by locating the differences layer by layer can we judge whether model conversion, data processing or business rules need to be adjusted.

Step 7: Complete device performance and stability verification

Performance testing should be performed on target Atlas devices, formal image sizes and actual processing links, distinguishing between:

• Image acquisition or decoding time;
• Pre-processing time;
• Single model inference time;
• Post-processing and business rules time;
• evidence image and result file writing time;
• End-to-end workstation response time.

The test results should also record the model version, OM file hash, CANN version, processor model, input size, batch, precision mode, number of warm-ups and number of samples. Accuracy, production cycle time and long-term stability are confirmed by independent inspections of specific projects and continuous operating conditions.

Step 8: Form a rollable version delivery

Formal delivery should contain at least:

• Original model or model source files within the agreed scope;
• ONNX model and export instructions;
• OM model, ATC command, conversion log and check value;
• Pre-processing, inference, post-processing and business interface code;
• Operating system, CANN, operator package and dependent version list;
• Sample verification results, difference records and performance test reports;
• Configuration, service startup, logging, upgrade, backup and rollback instructions.

Winge Technology can implement model migration work together with cameras, optics, ROI, I/O, interfaces, result traceability and local deployment, making model inference a part of a complete assembly inspection system rather than an isolated model demonstration.

What issues are most likely to affect the migration results?

FAQ

Can ONNX models run directly on Ascend NPU?

It is usually necessary to use ATC to convert the ONNX model into an OM offline model based on the target Ascend processor and CANN environment, and then load and execute it through device-side interfaces such as AscendCL.

Does the conversion to generate OM files mean that the migration is complete?

Not equal to. It is also necessary to complete input and output docking, pre- and post-processing consistency, sample-by-sample result comparison, device-side performance testing, exception handling and version delivery verification.

Do all traditional vision rules have to be changed to neural networks?

No need. ROI rules with fixed positions and clear boundaries can continue to be retained; classification, object detection or segmentation models are used to handle category changes, complex backgrounds and semantic recognition tasks, and the two can be combined in the same Atlas application.

Can the same OM model be used directly for all Atlas devices?

The OM model conversion parameters are related to the target Ascend processor and software environment. When implementing the project, the processor model, CANN and operator package version should be confirmed according to the target device, and the corresponding build records should be kept.

How to judge whether the results before and after migration are consistent?

Fixed samples should be used to compare the input tensor, model original output, algorithm results and final business judgment layer by layer, and acceptance should be based on the error, accuracy and workstation rules confirmed by both parties. You cannot only compare a small number of demonstration pictures.

official sources

• Huawei Ascend: ONNX model converted to OM model

https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html

• Huawei Ascend: ATC command line parameters and operator constraints

https://www.hiascend.com/document/detail/en/canncommercial/850/devaids/atctool/atlasatc_16_0039.html

• Huawei Ascend: AscendCL model construction and application development

https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL and related names belong to their rights holders. This article explains the adaptation methods provided by Winge Technology for assembly vision projects, and does not mean that the relevant rights holders participate in or endorse the specific project. Equipment and tool capabilities are subject to the corresponding official version documents, and project results are subject to the actual model, samples, equipment, and acceptance conditions.

Related Atlas vision inspection resources

• Fully China-localized assembly vision inspection: Huawei Ascend Atlas project case study
• Winge Technology has completed on-device adaptation of assembly vision inspection on Atlas 200I DK A2
• What engineering work is included in Atlas 200I DK A2 vision inspection adaptation?
• From Atlas developer-kit validation to a China-localized production vision system
• How does a Chinese edge platform support assembly completeness and missing-part inspection?
• How to deploy and deliver Huawei Ascend Atlas assembly vision inspection locally
• Huawei Ascend Atlas Vision Inspection