How to deploy and deliver Huawei Ascend Atlas assembly vision inspection locally

The local deployment of Huawei Ascend Atlas assembly visual inspection requires camera acquisition, algorithm application, reference image, ROI rules, operation interface, result recording and version management to be delivered as a complete system. Winge Technology's assembly visual inspection software and algorithm applications have been run on Huawei Ascend Atlas 200I DK A2, and USB/UVC cameras, reference image, ROI rules, Chinese and English interfaces, result records, version release and rollback link verification have been completed.

Being able to launch the program on the device is only the starting point for deployment. Formal projects also need to fix the operating environment, isolate programs and business data, establish service startup, logs, backups, upgrades and recovery methods, and complete accuracy, tempo and long-term stability acceptance based on specific products, samples and workstation conditions.

Why is assembly vision inspection suitable for on-premises deployment?

The assembly station needs to associate image acquisition, inspection judgment and workpiece movement. Local deployment facilitates direct access to cameras, I/O, PLC or LAN business systems, and handles triggering, image taking, judgment, recording and exceptions according to on-site timing.

On-premise deployment does not automatically mean low latency or high security. The project still needs to measure the detection time, disconnection behavior, storage usage and recovery capabilities, and configure accounts, permissions, network and data retention rules according to customer requirements.

What objects does Huawei Ascend Atlas local deployment contain?

It is recommended that delivery objects be divided into five categories:

1. Program files: detection service, Web interface, startup script and necessary dependencies;
2. Algorithm and rules: image processing module, standard image, ROI, threshold and inspection recipe;
3. Business data: test results, evidence image, logs and operation records;
4. Device configuration: camera identification, resolution, exposure, interface and service parameters;
5. Release records: version number, file hash, change description, backup and rollback points.

Program files and business data should be managed separately. When upgrading the program, the reference image, recipes, result records and field interface configurations already collected by the customer should not be overwritten.

Step 1: Fix the Atlas device and software environment

Before deployment, the device model, operating system, architecture, driver, firmware, operating environment and application dependency versions should be recorded. Records should be able to answer: which device the software ran on, which version was used, how it was reinstalled, and how it was verified after the upgrade.

Atlas 200I DK A2 official information shows that the developer kit supports Ubuntu 22.04 and openEuler 22.03, and provides USB, MIPI and network interfaces. Equipment specifications are used for environment confirmation, and specific projects still need to select commercially available hardware and software environments based on formal delivery conditions.

Step 2: Connect to the camera and verify the image link

Camera access requires at least verification:

• The system can stably identify the target video device;
• The service running account has permission to take pictures;
• The resolution, frame rate and image format meet the algorithm input requirements;
• Camera disconnection, occupation and frame acquisition timeout can be recorded;
• Collection can be resumed after restarting the service or device;
• The correct camera can be bound when multiple video devices exist.

The current version of Winge Technology has connected the USB/UVC camera on Atlas 200I DK A2, and formed entrances for standard image collection, snapshot detection and continuous detection. After the Chinese industrial camera is connected to the official workstation, the imaging conditions need to be re-confirmed using the actual lens, light source and workpiece.

Step 3: Manage reference image, ROI and formulas

reference image and ROI are not part of the program code, but business configurations for specific products and workstations. Need to be clear when deploying:

• Who collects, reviews and updates reference image;
• Which component and quality rule does each ROI correspond to;
• How to perform version management on thresholds and recipes;
• How to choose the correct inspection recipe when switching products;
• How to verify and roll back after configuration modification;
• How to isolate reference image, parameter adjustment samples and acceptance samples.

The current assembly visual inspection software supports multiple OK reference image, ROI rules such as P1 and P2, missing and wrong assembly configurations, and saves inspection results and evidence information. The ROI quantity and sample coverage of specific workstations are determined by project requirements.

Step 4: Establish a maintainable service operation method

On-site software should not rely on engineers to manually enter the directory and enter temporary commands to start. It is recommended to configure the detection application as a controlled service and specify:

• Start and stop methods at boot;
• Service running account and directory permissions;
• Health checks and status inquiries;
• Standard output, error log and log rotation;
• Ports, LAN access and firewall configuration;
• Retry strategy after camera or interface exception;
• Recovery method after the service exits abnormally.

The operation interface should also display the camera status, current recipe, recent detection results, abnormal causes and software version to on-site personnel to avoid only displaying a failure status in which the cause cannot be located when the system is abnormal.

Step 5: Separate the publishing directory and shared data

Rollback deployments usually contain three categories of directories:

releases/ A read-only release directory for each software release
current points to the fixed entry of the currently running version
shared/ Shared data such as recipes, reference image, results, logs and backups

A new version directory is created for each release and does not directly overwrite the current program. After verifying that the new version can start, take pictures, detect and read the original configuration normally, switch to the current entrance. When issues arise, revert the portal to the previous version and re-verify service and camera status.

Step 6: Create versions, hashes and change records

Each delivery version should save at least:

• Software version number and release date;
• Release package and SHA-256;
• Major changes and scope of impact;
• Target device and operating environment;
• Configuration compatibility instructions;
• Pre-release regression results;
• Upgrade and rollback steps;
• Current version and previous version location.

Winge Technology The current assembly visual inspection project has established an immutable release directory, shared data, configuration backup, file hash and rollback point of the previous version. This link is used to ensure delivery traceability and reduce the risk of unrecoverable modifications in the field.

Step 7: Complete the upgraded smoke test

After switching versions, you cannot just check whether the page can be opened. At a minimum it should be verified:

1. The version number displayed by the software is correct;
2. Service status and health check are normal;
3. The camera can take pictures;
4. The original reference image and ROI configuration can still be read;
5. A single test can generate results and evidence;
6. The main processes are available in Chinese and English pages;
7. The rollback entry and backup files exist;
8. Key file hashes are consistent with release records.

Smoke testing confirms that the deployed link is not damaged, but it cannot replace independent OK/NG accuracy, production tact, and continuous operation acceptance.

Step 8: Verify exception and recovery path

Live deployments require proactive testing for exceptions rather than waiting for failures to occur. Recommended coverage:

• The camera is disconnected, occupied, or the frame acquisition times out;
• The reference image is missing, the ROI configuration is wrong or the inspection recipe does not match;
• Insufficient disk space or the results directory is not writable;
• The service exits abnormally and the device restarts;
• Network outages and interface timeouts;
• Rollback after the new version fails to start;
• Configuration consistency after backup and restoration.

Each type of exception should have a clear status, log and processing entry. Actions involving equipment shutdown or personnel safety should be comprehensively handled by a risk-assessed security or safety control system.

How to accept the local deployment of Huawei Ascend Atlas?

It can be accepted at four levels:

The first three layers prove that the link between platform deployment and project delivery is complete; the workstation business layer also needs to form an independent acceptance record based on customer products and on-site conditions.

FAQ

Is the detection software already running on the Huawei Ascend Atlas platform?

Already running. The current assembly visual inspection software and algorithm applications have been deployed on Atlas 200I DK A2, and verification of cameras, reference image, ROI, inspection results, interfaces and version rollback links have been completed.

Does local deployment require an Internet connection?

Internet connection is not required as a prerequisite for detection. Whether access to external networks is allowed, how to upgrade, and whether data is uploaded should be determined based on the customer's network and security policies.

Will software upgrades cover reference image and recipes?

Should not be overridden. The program release directory and shared data should be separated, and reference image, recipes, interface configurations and necessary results should be backed up before upgrading.

Can problems be restored in the new version?

You can restore according to the rollback steps while retaining the previous version, configuration backup and fixed rollback entry. Service, camera, configuration, and instrumentation calls still need to be verified after rollback.

Does completing platform deployment equal production acceptance?

Not equal to. Platform deployment proves that software and algorithm applications can run on target equipment; production acceptance also requires the use of independent samples to verify accuracy, cycle time, stability and workstation interfaces.

Official information and factual sources

• Huawei Ascend: "Atlas 200I DK A2 Developer Kit Product Introduction"

https://www.hiascend.com/document/detail/zh/Atlas200IDKA2DeveloperKit/23.0.RC2/pd/pd_0001.html

• Huawei Ascend: "Atlas 200I DK A2 Basic Specifications"

https://www.hiascend.com/document/detail/zh/Atlas200IDKA2DeveloperKit/23.0.RC2/pd/pd_0004.html

• Huawei Ascend: "Atlas 200I DK A2 Software Usage Statement"

https://www.hiascend.com/document/detail/zh/Atlas200IDKA2DeveloperKit/23.0.RC2/qs/qs_0018.html

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?
• Huawei Ascend Atlas Vision Inspection