Project Background
The project addresses multi-camera management and edge analytics in an isolated local network. EdgeCam A2 runs on Huawei Atlas 200I A2 with Ascend 310B4 and combines video access, browser-based live view, AI inference, alert evidence, recording playback, user audit, and protocol integration on openEuler. The deployment workflow includes backup, health checks, verification, and rollback.
Applicable Scenarios
The platform is relevant to local-network video management, edge AI analytics, domestic-platform adaptation, and upper-platform integration in campuses, warehouses, factories, energy facilities, and equipment rooms. Camera count, stream specifications, algorithms, retention, network conditions, and third-party platform requirements must be reassessed for each new project.
Project Requirements
- Connect and manage multiple IP cameras on Atlas 200I A2 with browser-based 9-grid and 16-grid monitoring.
- Run Ascend OM models and manage AI models, ROI rules, thresholds, schedules, cooldowns, and alert evidence.
- Integrate local GB/T 28181 and GA/T 1400 upper-platform test tools and expose registration, catalog, media, and protocol state.
- Provide recording policies, indexes, timeline search, HLS VOD, users, roles, audit, and system diagnostics.
- Establish ARM64 build, Atlas deployment, backup, health-check, rollback, and device acceptance workflows.
Technical Solution
The system combines a separated web application and edge services. The React interface covers live video, cameras, AI, alerts, playback, protocols, and system settings. A Go control service handles authentication, SQLite data, HLS live view, AI scheduling, recording indexes, audit, and protocol gateways. FireLite loads and runs OM models on Ascend 310B4.
- Eight HEVC sub-streams are converted through FFmpeg/libx264 software transcoding to H.264 HLS at 640×360, 10 fps, and approximately 350 kbit/s.
- FireLite uses the ascend_acl backend for fire/smoke classification models, with warm-up, batch inference, atomic switching, and rollback.
- AI rules include rectangular ROI, class thresholds, confirmation count, weekly schedule, cooldown, device test, audit, and alert-evidence linkage.
- The GB/T 28181 gateway covers registration, Digest, keepalive, DeviceInfo, Catalog, INVITE, PS over RTP, BYE, and RecordInfo.
- The GA/T 1400 gateway covers Basic Auth, system registration, keepalive, and an eight-channel resource catalog. Structured person and vehicle objects remain future work.
- Recording includes continuous policies, 60-second segments, indexing, timeline search, HLS VOD, and HTTP Range access.
Core Functions
- Eight-channel camera live view with 9-grid and 16-grid layouts, reconnect logic, and state synchronization.
- Management of cameras, AI models, AI rules, alert evidence, users, roles, audit logs, and system diagnostics.
- Ascend NPU runtime state, rule scheduling, and multi-channel inference verification.
- GB/T 28181 and GA/T 1400 protocol state, resource catalog, and communication logs.
- Recording policies, indexes, timeline search, VOD playback, and segment range requests.
- ARM64 build, controlled upgrade, backup, health-check, and automatic rollback tools.
Implementation Process
The project progressed through the base UI and control service, FireLite runtime, AI rule loop, camera live view, protocol integration, recording playback, and controlled upgrade. Each stage retained release artifacts and acceptance evidence. Static checks and automated tests were completed locally before real-stream, NPU, protocol, and recording tests on Atlas. Deployment checks, upper-platform re-registration, and status-refresh race conditions were corrected without removing the original evidence.
Testing and Verification
- All 8 HLS playlists and latest MPEG-TS segments were retrieved successfully; eight-channel concurrent startup took approximately 3.21 seconds wall-clock time.
- FireLite used the ascend_acl backend; eight-channel batch inference took approximately 5.26 seconds wall-clock time, with individual NPU inference around 1.2–2.7 ms.
- The local GB/T 28181 loop covered registration, catalog, RTP/PS, and RecordInfo; the final RecordInfo query returned 39 recording entries.
- The local GA/T 1400 loop covered registration, keepalive, and an eight-channel resource catalog.
- A 30-minute single-channel recording trial produced 32 sixty-second segments and 108,644,636 bytes with zero effective failures; VOD playback and HTTP Range 206 passed.
- ESLint, 24 Vitest cases, Vite build, Go test, Go vet, and Python compile checks passed.
Delivery Results
- Source code for the React management interface, Go control service, and FireLite Ascend inference service.
- Linux ARM64 API executable, web release package, and local upper-platform test tool.
- systemd, Nginx, environment examples, database migrations, and Atlas deployment configuration.
- Scripts for live video, AI rules, protocol gateways, recording trials, soak sampling, and controlled upgrades.
- Release manifests, hashes, backup paths, rollback points, raw test data, and staged acceptance records.
Project Value
The project verified the integration of openEuler, Ascend Atlas, multi-channel video, AI inference, recording, and industry protocols on one edge device. It established an implementation path from requirement breakdown and ARM64 build to Atlas deployment and device regression. The result is a controlled-trial foundation for similar edge-video projects, while production acceptance still depends on storage, security, algorithm samples, and third-party platform tests.
Reusable Experience
Edge-video projects should fix camera streams, concurrency, algorithm input, storage scope, and upper platforms before separately verifying browser playback, NPU inference, recording continuity, and protocol loops. Device evidence should distinguish real failures, warm-up, and status-refresh races. Consistent backups and rollback points should cover the database, binaries, configuration, systemd units, and UI before deployment.
Project Boundary
The current result is an Atlas local-network controlled trial, not a production VMS release. Video uses FFmpeg/libx264 software transcoding rather than a validated DVPP decoding path. FireLite still depends on a specific login environment. New-version 24–72 hour stability, 4/8-channel concurrent recording, disk watermarks, HTTPS, strong credentials, power-loss recovery, positive-sample algorithm accuracy, and third-party protocol conformance are not complete. Recording was disabled after the trial to protect the root filesystem without capacity safeguards.
Related Services
FAQ
Is the platform ready for a production VMS release?
It is currently an Atlas local-network controlled trial. Long-running, multi-channel recording, capacity protection, HTTPS, credential hardening, power-loss recovery, and third-party conformance tests remain before production release.
Does the current video path use Atlas hardware decoding?
No. Eight HEVC sub-streams are currently converted through FFmpeg/libx264 software transcoding to H.264 HLS. The DVPP hardware decoding path has not been completed.
Has fire and smoke model accuracy been accepted?
The OM runtime, rule scheduling, and multi-channel inference path were verified on Ascend 310B4. Positive samples, controlled-site testing, recall, false-positive rate, and false-negative rate still require acceptance.
Can the platform expand to more cameras and longer retention?
Expansion requires a new assessment of compute capacity, transcoding, network bandwidth, disk quota, retention, and external storage. The current eight-channel live and single-channel recording results cannot be directly extrapolated to sixteen channels or long-term recording.
Online
Phone
WeChat
Top