Embedded systems architecture
Define the system before dividing the work: boundaries, behaviours, interfaces and failure responses that keep hardware, firmware and software aligned.
After this module, you should be able to:
- Describe an embedded system from its external behaviour
- Choose boundaries and allocate responsibilities deliberately
- Write useful interface contracts
- Identify the evidence an architecture must produce
Architecture is the set of decisions that make the system understandable.
An architecture is more than a block diagram. It explains what lies inside the system boundary, what the system must do, how responsibilities are divided, how elements interact and which constraints shape those decisions.
For an embedded product, the important boundaries are rarely identical to organisational boundaries. A behaviour such as “stop the motor safely when position feedback is lost” may depend on a sensor, analogue conditioning, an MCU peripheral, an interrupt, firmware state logic, a power stage and the mechanical load.
Make the consequential decisions explicit.
| Decision | Questions to answer | Typical output |
|---|---|---|
| System boundary | What is controlled, assumed or external? Where do power, data and physical effects cross? | Context diagram and assumptions |
| Functional allocation | Which element senses, decides, acts, monitors and records? | Function-to-element allocation |
| State and mode control | What modes exist? Which transitions are permitted? What happens after interruption? | State model and transition rules |
| Interface contracts | What is exchanged, when, in what units and with what response to invalid or missing data? | Interface specification |
| Cross-cutting qualities | What timing, safety, security, power, diagnostic and reliability properties span components? | Budgets, principles and constraints |
| Change boundaries | Which parts must evolve independently? Where is compatibility controlled? | Versioning and configuration strategy |
A useful interface contract is testable
“MCU communicates with sensor” is not a contract. State the physical interface, direction, data representation, range, units, timing, initialisation, ownership, timeout, error detection and response to corrupted, stale or unavailable data.
Build the architecture from behaviour, not from the parts catalogue.
- Set the context. Identify external actors, physical processes, energy sources and trust boundaries.
- Walk critical scenarios. Trace start-up, normal operation, shutdown, update, service and credible fault conditions.
- Partition responsibilities. Allocate sensing, decisions, actuation, monitoring and data retention.
- Define interface contracts. Include timing, validity, ownership and failure behaviour.
- Apply system budgets. Allocate timing, accuracy, memory, power and diagnostic coverage.
- Challenge the design. Examine single failures, common causes, communication loss and unexpected sequences.
- Connect verification. Decide how each important architectural claim will be demonstrated.
Worked example: temperature-controlled chamber
The requirement is not simply “maintain 37 °C”. The architecture must explain how temperature is sensed, how plausibility is checked, how heater energy is controlled and what happens if readings stop changing.
A robust allocation might use firmware for normal closed-loop control, a hardware watchdog for loss of execution and an independent thermal cut-off for an over-temperature condition that must remain controlled even when the MCU fails.
Retain enough evidence to defend the architecture.
External actors, interfaces, environmental constraints and explicit assumptions.
Views showing decomposition, allocation, data flow, control flow and deployment.
Signals, protocols, units, timing, validity rules, errors and ownership.
Modes, states, sequences, start-up, shutdown and fault responses.
Alternatives, rationale, constraints and consequences of major choices.
How architectural properties and interface behaviours will be tested or analysed.
Common failure patterns
The design begins with a preferred MCU or platform before system behaviours and constraints are understood.
Normal data flow is shown, but start-up, loss of communication and degraded operation are absent.
Two components assume the other detects, validates or recovers from the same fault.
Documentation records what was built but no longer guides decisions or verification.
Further learning
- NASA Systems Engineering HandbookSystem design, product realisation and cross-cutting technical management.
- Arm CMSIS documentationA practical example of standardised processor, peripheral and software interfaces.
Design the interactions, not only the components.
A credible embedded architecture makes behaviour, ownership, interfaces and failure responses explicit enough to guide implementation and objective enough to verify.