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
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: No previous Academy module is required. Familiarity with a sensor, controller and actuator will help.
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.
Allocate a behaviour across the whole system
Start with an observable outcome, such as preventing a chamber from exceeding an agreed temperature after a controller fault. Trace the physical chain: thermal coupling, sensor, analogue input, acquisition, decision, output driver, stored energy and heater. Allocate each responsibility and identify the observation that proves it happened. An output register reading zero is not proof that energy stopped flowing.
Distinguish a functional boundary from a containment boundary. A software module can make responsibilities clear without preventing another module from corrupting its memory. A separate MCU may still share the same power supply, oscillator, sensor or update image. Describe the actual mechanism that prevents one failure from defeating both control and protection.
Record assumptions alongside the allocation: maximum thermal rise, sensor response time, host availability and allowed restart conditions. Give each assumption an owner and a way to confirm it. An assumption that is never checked can quietly become a missing requirement.
Make budgets and trade-offs visible
A system budget divides a measurable limit between contributors. A response deadline may contain acquisition delay, filtering, transport, scheduling, decision and physical stopping time. Accuracy contains sensor, reference, conditioning, conversion and calibration effects. Keep margin explicit so a later change cannot spend the same allowance twice.
Budget against relevant operating conditions, including low supply, high temperature, maximum traffic and service activity. A design that works only with diagnostics disabled may have made observability incompatible with normal operation. Review the worst credible combination rather than adding unrelated maxima without a model.
Capture major choices in a short decision record: the problem, alternatives, evidence, choice, consequences and revisit trigger. This preserves why an independent cut-off was selected and what would have to change before it could be removed.
| Boundary | Contract to agree | Evidence |
|---|---|---|
| Sensor → controller | Units, sample age, calibration identity and invalid-data rules. | Recorded input and reported value under a known stimulus. |
| Host → controller | Acceptance, completion, cancellation and loss-of-link behaviour. | A sequence including a lost acknowledgement. |
| Controller → actuator | Permitted states, command limits and confirmed physical response. | Output and physical-effect measurements. |
Review architecture through adverse scenarios
Walk a scenario with engineers from both sides of each interface. Ask who knows the current state after a reset, which data survives, and whether an old command can become valid again. Include manufacturing and service: a production fixture may enable outputs before the normal application runs.
Use the architecture to choose early experiments. If the main uncertainty is whether the actuator can stop within the hazard limit, test that physical path before refining the user interface. If the risk is a shared supply defeating two monitors, analyse and inject that fault. Update the architecture when observations contradict its assumptions; do not preserve an attractive diagram at the expense of the product model.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Allocate a chamber over-temperature response
A chamber has an application computer, an MCU controlling a heater and a separate thermal cut-off. The host can freeze while the MCU continues its last command.
- Allocate normal temperature control, host-loss detection, over-temperature protection and restart authority.
- Specify what the MCU may do after host communication stops and what condition the cut-off must independently observe.
- Define two tests that distinguish an accepted command from a confirmed physical response.
Show the worked answer
One defensible allocation keeps time-critical control on the MCU, gives the host authority to request bounded targets, and uses a separate protection path for a hazardous over-temperature condition. The correct host-loss response follows from the chamber’s use: stop heating, finish a bounded safe step or maintain a justified local condition. It must not be an accidental consequence of retaining the last target.
The cut-off should respond to the relevant physical hazard through a path whose independence is justified, including sensing, power and output interruption. Specify whether restoration requires inspection or an authorised reset. Freeze the host during heating and observe heater energy and temperature. Then force the main output path into its credible failed condition and verify the independent protective response within its allocated limit.
Review criteria
- Every safety-relevant action has an owner and an observable result.
- Host loss and controller failure are treated as distinct scenarios.
- Restart conditions and shared dependencies are explicit.
Check your understanding
Does a second MCU prove independence?
No. Check shared sensing, power, clocks, software, communications and environmental exposure. Independence is a supported architectural property.
Why retain a decision record after testing?
Tests show behaviour in their conditions. The record preserves the assumptions and trade-offs that determine when those results remain applicable.
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.