An embedded software development process is an evidence-producing lifecycle, not a straight path from requirements to code. Teams repeatedly connect product intent, hardware constraints, architecture, implementation, integration, verification, release and field feedback, and scale the rigor to the risk of the product.
Key takeaways
- Lifecycle: 9 connected phases run from discovery to operations, and iteration between them is normal.
- Requirements: Testable requirements name units, tolerances, failure behavior and a verification method.
- Testing: Six test layers, from static checks to validation, are weighted by risk.
- Evidence: Reproducible builds, traceability and recorded results make a release attributable.
- Dev Station: Dev Station runs this process for embedded and IoT teams in the US and UK.
What should a team decide before estimating embedded software?
Before estimating, a team should frame the system: product intent, system boundary, constraints and an evidence plan that grows with the design.
Product intent
Describe users, operating scenarios, hazards, misuse, environment, service life, manufacturing volume assumptions, and what success means at system level.
System boundary
Identify sensors, actuators, processors, radios, power, cloud services, mobile apps, manufacturing systems, accessories, and external dependencies.
Constraints
Capture timing, memory, energy, boot, thermal, cost, availability, cybersecurity, privacy, safety, regulatory, and maintenance constraints.
Evidence plan
Decide what reviews, analyses, tests, traceability, records, and approvals will demonstrate the product is ready. Evidence should grow with the design, not be reconstructed at release.
What are the phases of embedded software development?
Embedded software development runs through nine connected phases, from discovery and feasibility to operations and maintenance, with iteration expected between them.
Iteration is expected. A failed timing test may change architecture; a component shortage may change hardware; a threat analysis may alter boot and update design. Configuration control keeps these loops understandable.
Discovery and feasibility
Resolve the riskiest assumptions with datasheet analysis, prototypes, measurements, regulatory research, supplier checks, and architecture options. Label prototype code clearly.
Requirements
Write testable system and software requirements with rationale, source, priority, units, tolerances, failure behavior, and verification method.
Architecture
Partition hardware and software; define execution contexts, interfaces, data flows, timing, memory, power states, trust boundaries, diagnostics, and update strategy.
Detailed design
Specify state machines, task priorities, buffers, persistence, driver contracts, error handling, algorithms, configuration, and test seams.
Implementation
Apply coding standards, review, static analysis, unit tests, dependency controls, secure practices, and small integrations against known hardware revisions.
Integration
Bring up boot stages, clocks, memory, peripherals, RTOS or OS, middleware, applications, and external systems in a planned order with observable checkpoints.
Verification and validation
Prove requirements, interfaces, reliability, performance, safety and security controls; then confirm the integrated product supports intended use in representative conditions.
Release and production transfer
Freeze controlled inputs, reproduce artifacts, approve known issues, provision identities and keys, support factory test, and preserve release evidence.
Operations and maintenance
Monitor field health, triage incidents, manage vulnerabilities and dependencies, issue recoverable updates, support variants, and plan end of support.
How do you make embedded requirements measurable?
Replace vague statements with defined conditions, thresholds and a verification method, as the table below shows.
| Weak statement | Stronger direction | Verification idea |
|---|---|---|
| The device starts quickly | Define power condition, hardware revision, readiness event, maximum time, and measurement point | Automated power-cycle timing across voltage and temperature conditions |
| The battery lasts a long time | Define battery, duty cycle, radio conditions, operating profile, shelf time, and end threshold | State-level current measurements plus representative-duration testing and model |
| Communications are secure | Name assets, attackers, interfaces, authentication, confidentiality, integrity, replay, key lifecycle, and update duties | Threat-linked tests, protocol review, key and update failure tests |
| Errors are handled | List detectable faults, safe or degraded response, retries, logging, user indication, recovery, and persistence | Fault injection with expected state and diagnostic evidence |
Traceability links the evidence
A useful trace links stakeholder need to system and software requirements, design, code or configuration, tests, results, anomalies, and release. It helps impact analysis; it should not become paperwork detached from engineering.
Which cross-cutting concerns need early decisions?
Timing, memory, power, safety, security and maintainability need early decisions, because each constrains architecture and is expensive to change late.
Timing and concurrency
Budget deadlines, interrupt latency, task execution, blocking, bus contention, priority inversion, jitter, and overload behavior. Measure on representative targets.
Memory and storage
Budget flash, RAM, stacks, heaps, buffers, logs, filesystems, update slots, wear, corruption recovery, and growth margin by variant.
Power and thermal
Define states, wake sources, sequencing, peripheral leakage, radio retries, clock strategy, thermal throttling, and measurement points.
Safety and resilience
Analyze hazardous behavior, single points of failure, watchdog strategy, brownout, sensor plausibility, actuator defaults, fault containment, and recovery.
Security and privacy
Model assets and threats; design identity, secure boot, debug access, least privilege, encrypted transport, protected storage, logging, updates, and decommissioning.
Maintainability
Plan diagnostics, telemetry, feature flags where safe, compatibility, manufacturing mode, service tools, component replacement, and support documentation.
How should a team bring up an embedded system?
Bring it up in observable slices, one diagnosable path at a time, with a compatibility matrix and a board bring-up checklist.
- Maintain a hardware to software compatibility matrix covering boards, BOM substitutions, bootloader, programmable logic, radio, OS, application, and calibration.
- Create a board bring-up checklist for rails, reset, clocks, debug, memory, console, storage, buses, network, sensors, actuators, low-power states, and production interfaces.
- Use stable test doubles and simulators for unavailable hardware, while preserving tests on real boards for electrical, timing, radio, power, and peripheral behavior.
- Integrate one diagnosable path at a time. A heartbeat, console, reset reason, and traceable build identifier shorten fault isolation.
- Record bench setup, instrument configuration, firmware version, hardware revision, environmental condition, and raw evidence for failures.
- Keep exploratory patches out of release branches until reviewed, tested, and connected to a tracked change.
How should embedded testing be layered?
Layer tests around risk, from static analysis and unit tests up to system tests and validation in representative conditions.
| Layer | Primary purpose | Representative methods |
|---|---|---|
| Static | Find defects without execution | Review, compiler warnings, static analysis, dependency and configuration scans |
| Unit | Check isolated logic and boundaries | Host or target tests, mocks, property and boundary tests |
| Component | Exercise drivers, services, and protocols | Target tests, peripheral fixtures, protocol simulators |
| Integration | Check interfaces and interactions | Hardware-in-loop, network and backend test environments, fault injection |
| System | Verify product requirements | Environmental, performance, power, EMC-related prechecks, endurance and recovery tests |
| Validation | Assess intended use and workflow | Representative users, scenarios, environments, and operational procedures |
ChatGPT →
Perplexity →
Claude →
Gemini →
