Chuyển tới nội dung chính

Firmware Engineering Process

This section describes the standard firmware development workflow used in ACLab for robotics, embedded systems, and electronic products. It covers the complete process from system requirements to production-ready firmware release.

Workflow Overview​

StepRequiredDescription
System & Firmware Discovery✅Understand the system, stakeholders, constraints, and expected firmware behavior.
Requirements & Interface Definition✅Define testable firmware requirements and hardware-firmware interfaces.
Architecture & Technical Planning✅Define modules, data flow, states, resources, risks, and development strategy.
Development Environment Setup✅Prepare repositories, toolchains, build configuration, coding rules, and CI.
Firmware Implementation✅Develop firmware modules according to the approved requirements and architecture.
Module Verification✅Perform code review, static analysis, unit tests, and module-level testing.
Hardware Bring-up & Integration✅Verify startup, drivers, peripherals, communication, and target hardware behavior.
System Validation✅Validate complete firmware behavior against requirements and product use cases.
Production Release✅Version, package, document, and release production-ready firmware.
Maintenance & Change ManagementAfter ReleaseControl defects, updates, compatibility, and future firmware revisions.

Minimum workflow: Discovery → Requirements → Architecture → Setup → Implementation → Verification → Integration → Validation → Release

1. System and Firmware Discovery​

Understand the product, system context, and expected firmware responsibilities.

Key Activities​

  • Identify stakeholders and users.
  • Review product use cases.
  • Review the system and hardware architecture.
  • Define firmware responsibilities and boundaries.
  • Identify safety, security, timing, memory, power, and production constraints.
  • Review existing firmware, prototypes, and technical risks.
  • Align expectations between relevant engineering teams.

Output Keypoints​

  • Product and firmware scope
  • Firmware responsibilities
  • Stakeholder expectations
  • Known constraints
  • Assumptions and open questions
  • Major technical risks

2. Requirements and Interface Definition​

Convert system expectations into clear and testable firmware requirements.

Key Activities​

  • Define functional requirements.
  • Define timing, memory, power, reliability, safety, and security requirements.
  • Define startup, shutdown, update, recovery, and fault behavior.
  • Define hardware and firmware interfaces.
  • Define communication protocols and data formats.
  • Define logging, diagnostics, calibration, and production-test requirements.
  • Define acceptance criteria for each requirement.

Output Keypoints​

  • Firmware requirements
  • Hardware and firmware interface specification
  • Communication interface definitions
  • Acceptance criteria
  • Requirement-to-test traceability

3. Architecture and Development Planning​

Define how the firmware will satisfy the requirements.

Key Activities​

  • Divide the firmware into modules and layers.
  • Define boot, initialization, operating, fault, update, and recovery flows.
  • Define tasks, interrupts, states, events, queues, and data flow.
  • Define processor, memory, storage, timing, and power budgets.
  • Select the RTOS, libraries, middleware, bootloader, and dependencies.
  • Define error handling, diagnostics, security, and update mechanisms.
  • Identify high-risk functions.
  • Plan implementation, integration, and testing milestones.

Output Keypoints​

  • Firmware architecture
  • Module responsibilities
  • Execution model
  • Data-flow model
  • Resource budgets
  • Technical decisions
  • Development plan

4. Environment and Repository Setup​

Create a controlled and reproducible development environment.

Key Activities​

  • Create the source repository.
  • Define the repository structure.
  • Define branch and merge rules.
  • Configure the compiler, SDK, debugger, programmer, and build system.
  • Store build configurations under version control.
  • Define coding, review, commit, and versioning rules.
  • Configure static analysis, automated builds, and tests.
  • Define access permissions and artifact storage.
  • Verify that a clean environment can reproduce the build.

Output Keypoints​

  • Source repository
  • Reproducible build environment
  • Development instructions
  • Debugging instructions
  • Coding and review rules
  • CI configuration
  • Artifact structure

5. Implementation and Continuous Verification​

Implement the firmware incrementally and verify each change.

Key Activities​

  • Implement small and reviewable changes.
  • Follow approved requirements and architecture.
  • Perform peer review before integration.
  • Enable compiler warnings.
  • Run static analysis.
  • Create unit, module, and interface tests.
  • Test normal, boundary, timeout, error, and recovery behavior.
  • Maintain requirement and issue traceability.
  • Record important design changes.

Output Keypoints​

  • Reviewed source code
  • Unit-test results
  • Module-test results
  • Static-analysis results
  • Updated technical documentation
  • Traceable issues and changes

6. Hardware Bring-up and Integration​

Integrate the firmware with the target hardware in controlled stages.

  1. Power, reset, clock, boot, and debug access
  2. Memory and storage
  3. GPIO and basic peripherals
  4. Communication interfaces
  5. Sensors and actuators
  6. Application functions
  7. Diagnostics, update, recovery, and production-test functions

Key Activities​

  • Confirm the board revision and configuration.
  • Verify startup and initialization.
  • Test peripheral drivers.
  • Test hardware interfaces.
  • Verify timing, interrupts, concurrency, and resource usage.
  • Test communication under normal and failure conditions.
  • Verify reset, watchdog, brownout, and recovery behavior.
  • Separate firmware defects from hardware defects.
  • Record board-specific limitations and workarounds.

Output Keypoints​

  • Bring-up checklist
  • Hardware integration results
  • Known hardware and firmware issues
  • Verified board compatibility
  • Debug procedures
  • Recovery procedures

7. System Validation and Release Readiness​

Confirm that the integrated product satisfies its requirements and intended use.

Key Activities​

  • Validate all approved firmware requirements.
  • Test complete product use cases.
  • Test timing, memory, performance, power, and long-duration operation.
  • Test invalid input, communication loss, reset, and power interruption.
  • Test fault detection and recovery.
  • Perform regression testing.
  • Confirm update, rollback, programming, and recovery procedures.
  • Review unresolved defects and release risks.
  • Confirm documentation and production readiness.

Output Keypoints​

  • System validation report
  • Requirement coverage
  • Regression-test results
  • Performance measurements
  • Resource measurements
  • Known limitations
  • Release-readiness decision

8. Release, Production Handover, and Maintenance​

Create a controlled firmware release and support future changes.

Release Activities​

  • Freeze the approved source revision.
  • Assign a firmware version.
  • Create a release tag.
  • Generate binaries from a clean environment.
  • Record the compiler, SDK, dependencies, configuration, and build commands.
  • Generate checksums or signatures when required.
  • Prepare release notes.
  • Archive source code, binaries, map files, symbols, configuration, and test evidence.
  • Provide programming, verification, recovery, and update instructions.
  • Verify hardware revision compatibility.

Production Handover Outputs​

  • Approved programming image
  • Programming configuration
  • Device configuration data
  • Calibration data
  • Firmware verification method
  • Expected firmware version
  • Expected firmware checksum
  • Recovery procedure
  • Production-test interface information
  • Supported hardware revision list

Maintenance Activities​

  • Record defects and field issues.
  • Evaluate the impact of each change.
  • Maintain hardware and firmware compatibility.
  • Repeat affected verification and validation tests.
  • Create a new version for every approved release.
  • Never overwrite an existing released artifact.

Process Inputs​

Firmware development may receive:

  • Product requirements
  • System requirements
  • Hardware architecture
  • Electrical schematics
  • PCB revision information
  • Component datasheets
  • Interface specifications
  • Communication protocol specifications
  • Safety requirements
  • Security requirements
  • Mechanical constraints
  • Power constraints
  • Thermal constraints
  • Manufacturing requirements
  • Production-test requirements
  • Existing firmware
  • Reference implementations
  • Stakeholder expectations
  • Product use cases

Process Outputs​

Firmware engineering typically produces:

  • Firmware requirements
  • Hardware and firmware interface specification
  • Firmware architecture
  • Source code
  • Build configuration
  • Test specifications
  • Test reports
  • Firmware binaries
  • Programming files
  • Release notes
  • Version records
  • Debugging instructions
  • Update instructions
  • Recovery instructions
  • Production programming package
  • Maintenance history
  • Change history

Cross-Cutting Controls​

The following controls apply throughout the process:

  • Requirements management
  • Change management
  • Configuration management
  • Version control
  • Code review
  • Technical review
  • Verification
  • Traceability
  • Safety engineering
  • Security engineering
  • Risk management
  • Issue management
  • Documentation management
  • Artifact management
  • Hardware revision compatibility

Engineering Principles​

  • Requirements must be clear, testable, and traceable.
  • Hardware and firmware responsibilities must be explicit.
  • Interfaces must be documented before integration.
  • Architecture decisions must be recorded.
  • Verification must begin during development.
  • Integration must proceed from basic hardware functions to complete system behavior.
  • Validation should use the real product environment whenever practical.
  • Every released binary must be reproducible.
  • Every released binary must be traceable to its source, configuration, toolchain, tests, and hardware revision.
  • Released artifacts must be immutable and revision-controlled.
  • Process depth should match project risk and complexity.