Development Scope
Scope and Basic Check
Determine the existing foundation, technical dependencies and content that needs to be developed based on hardware and firmware versions, boot processes, storage partitions, upgrade packages, signatures and recovery channels.
Implementation and integration
Development version identification, package verification, batch release, progress and results, failure recovery and diagnostic logs, distinguishing main controller and communication module upgrades.
Delivery Documentation
Deliver upgrade links, tools and power outage recovery records.
Verification and Constraints
Rollback, anti-rollback, and recovery strategies need to be compatible; being able to download the upgrade package does not mean having a complete upgrade process that can be restored.
Project implementation process
Verification of data and interfaces → Confirmation of technical solutions and verification use cases → Implementation of integration with the target environment → Regression of abnormal scenarios → Transfer of version data.
Verify the implementation results in the target hardware and software environment, and deliver records of associated interface configurations, version dependencies, and problem handling to facilitate subsequent integration and maintenance by the enterprise R&D team.
Project Inputs
- Hardware and firmware versions, boot process, storage partitions, upgrade packages, signatures and recovery channels.
- Design information, code, interface permissions and target test equipment can be provided.
- Source files, programs or tools expected to be delivered, inter-module integration testing responsibilities and project nodes.
- Acceptance samples, environment, test conditions and passing thresholds.
Deliverables and Acceptance
| Deliverables | Delivery content | Verification method |
|---|---|---|
| achieve results | Deliver upgrade links, tools and power outage recovery records. | Testing failed for wrong model, corrupted package, and signature. |
| Integrated data | Versions and dependencies, interface configuration, usage or deployment steps, and integration changes | Verify power-off handling during write and boot phases. |
| Verify records | Test conditions, execution records, problem lists and regression results | Check the grayscale range, failure records and recovery results. |
The delivery scope and acceptance criteria are determined based on the target environment. Third-party SDK, licenses, laboratories, cloud resources, equipment materials and on-site support are listed separately; when the existing information is insufficient, follow-up work will be determined through interface verification or key function verification.
Frequently Asked Questions
Can a single partition device do OTA?+
It is necessary to evaluate the storage margin, bootloader, external storage and recovery channel, and then determine the upgrade and rescue method. The dual-partition switching solution cannot be used directly, and the recovery behavior needs to be tested on the target device.
What information is needed to develop 4G OTA and remote diagnosis system?+
Please give priority to providing hardware and firmware versions, boot processes, storage partitions, upgrade packages, signatures and recovery channels. At the same time, the existing implementation, problems encountered, expected changes, and compatible test conditions are explained to facilitate the determination of implementation scope and reproduction methods.
Can it be implemented on existing products?+
You can first evaluate the scope of existing designs and versions that can be changed, retain the verified parts, and determine the interfaces and dependencies that need to be adjusted. This service requires attention: rollback, anti-rollback, and recovery strategies need to be compatible; being able to download the upgrade package does not mean having a complete upgrade process that can be restored. Existing and new functions must undergo regression testing within the agreed scope after the changes.
Online
Phone
WeChat
Top