Embedded software architecture
Structure software so that responsibilities, control flow, data ownership and failure containment remain understandable as the product grows and changes.
After this module, you should be able to:
- Decompose software around stable responsibilities
- Describe structure and runtime behaviour using complementary views
- Control dependencies, state and shared resources
- Connect architectural decisions to verification evidence
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: Read TEA-101 and TEA-105. Familiarity with functions, tasks and interfaces is useful.
Architecture makes the difficult software decisions visible.
Embedded software architecture defines the major elements, their responsibilities, the rules by which they interact and the constraints that protect important system qualities. It sits between system allocation and detailed implementation.
A useful architecture explains more than a source tree. It shows where behaviour lives, which component owns each state and item of data, how events flow, what may block, how faults are contained and which elements depend on hardware.
Separate policies from mechanisms and hardware detail.
| Area | Architectural decision | Questions to answer |
|---|---|---|
| Application behaviour | State machines, use-case controllers or event handlers. | Who owns the operational state and validates transitions? |
| Domain logic | Algorithms and decisions independent of device drivers. | Can core behaviour be tested without target hardware? |
| Hardware abstraction | Typed interfaces above registers, buses and vendor libraries. | Which hardware differences are hidden and which must remain visible? |
| Execution | Tasks, interrupts, priorities, queues and synchronisation. | Where may code block, pre-empt or share a resource? |
| Data | Ownership, lifetime, validity, persistence and configuration. | Who may change the value, and how does a consumer know it is current? |
| Fault management | Detection, reporting, containment, safe response and recovery. | Can failure in one element corrupt control elsewhere? |
| External interfaces | Protocol adaptation, validation and version boundaries. | Where is untrusted or malformed input converted into trusted internal data? |
Common patterns—layers, pipelines, publish/subscribe, active objects, supervisors and hardware-abstraction layers—are useful only when their trade-offs match the system. Combining patterns deliberately is normal; allowing accidental dependencies is not.
Use several views because no single diagram answers every question.
- Context and allocation. Show external interfaces and the system behaviours assigned to software.
- Static structure. Show components, responsibilities, provided interfaces and permitted dependencies.
- Runtime behaviour. Trace critical scenarios across interrupts, tasks, queues and state transitions.
- Data view. Define important data, ownership, units, validity, retention and concurrency controls.
- Deployment view. Map executables, boot stages and software elements to processors and memory regions.
- Safety and security view. Show trust boundaries, privilege, isolation, monitors and protection mechanisms.
- Decision records. Capture alternatives, rationale, assumptions and consequences for major choices.
Worked example: multi-channel thermal controller
Four channels share an MCU, but each channel must retain independent state, sensor validity and output limits.
Drivers publish typed observations rather than changing application state directly. Each channel service owns its state machine. A separate supervisor compares commanded and measured behaviour, while one output arbiter is the only component permitted to energise heaters. This makes authority explicit and enables algorithms and state logic to run in host-based tests.
Show that the implemented software preserves the architecture.
Complementary views, component responsibilities, interfaces, constraints and conventions.
Allocation of system and software requirements, hazards and security controls to elements.
Types, units, ownership, timing, errors, preconditions and postconditions.
Alternatives, rationale, assumptions, quality-attribute impact and approval.
Dependency rules, static analysis, code review and tests that detect architectural erosion.
Traces showing start-up, control, shutdown, update and fault behaviour across elements.
Common failure patterns
Any component can change shared data, so ownership and sequencing become unknowable.
Application decisions leak into hardware drivers and cannot be tested or changed independently.
Boxes look orderly, but nothing prevents forbidden calls, blocking or cross-layer access.
The description is not updated after learning from implementation, integration or risk analysis.
Define ownership before selecting a framework
Give each mutable state and hardware resource a clear owner. A motor service can own targets, operating mode and output authority while other components submit requests. If the user interface, communications callback and safety monitor all write PWM directly, behaviour depends on execution order rather than a reviewed policy.
Define interfaces in terms of responsibility: accepted input, legal states, units, blocking behaviour, buffer lifetime and reported outcomes. An asynchronous request needs a completion or failure event and a way to distinguish it from an older operation. A return value of success should not conceal whether work was merely queued.
Separate mechanism from policy where change justifies it. A bus driver transfers bytes; a device service interprets register behaviour; a product controller decides which measurements permit operation. Keep this separation understandable rather than creating layers with no clear responsibility.
Make concurrency and resource limits architectural
Draw the execution view as well as the dependency view. Show tasks, interrupts, DMA activity, queues and shared memory. A call that looks harmless on a component diagram may block the highest-priority task on flash storage or a network reply.
Set queue limits and overflow policies from workload assumptions. Telemetry may coalesce to the latest value, but operation completions and critical events require a different treatment. Identify which events can be discarded, rejected or escalated. A finite queue is useful only when the product defines what full means.
Partitioning should state its enforcement. Coding conventions, static checks, memory protection and separate processors offer different containment properties. Do not describe two unrestricted tasks as isolated merely because the source lives in separate directories.
| Interface property | Example decision |
|---|---|
| Ownership | The acquisition service owns sample buffers until publication. |
| Validity | Published values include age, calibration identity and status. |
| Blocking | Control never waits for diagnostic storage. |
| Overflow | Latest display value may replace an older one; a fault event is preserved. |
| Cancellation | Completion events carry the operation ID that authorised them. |
Use change scenarios to review the decomposition
Ask what changes when a sensor is replaced, a second channel is added or an update needs extra storage. If product policy is duplicated in several layers, the change will reveal inconsistent decisions. Record the permitted dependency direction and check that implementation follows it.
Define how components start, stop and recover. A service restart must reconcile its resources and outstanding messages before it becomes available. Test an old completion arriving after cancellation or restart. Architecture remains useful when it predicts these behaviours and identifies the evidence needed to demonstrate them.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Refactor a shared output into an owned service
Three tasks write an actuator target: a control loop, a service command handler and a fault monitor. The last writer currently wins.
- Define one owner and the request interface for each caller.
- Specify precedence between normal control, service mode and a latched fault.
- Show how a delayed service completion is rejected after leaving service mode.
Show the worked answer
An actuator service can own the output and enforce a state-dependent authority policy. The control loop requests a bounded target only in the permitted operating mode. Service requests require an authorised service state; a latched fault inhibits or constrains outputs according to the safety concept. Merely moving all writes into one function is insufficient if callers can still bypass policy.
Tag service operations with an identifier and session or mode generation. Leaving service mode invalidates that authority. A delayed completion cannot restore the old target. Verify simultaneous requests, service exit during activity and fault arrival at each transition. Observe the physical output and the state record together.
Review criteria
- There is one final output owner.
- Priority is defined by product state, not scheduling luck.
- Delayed events cannot regain revoked authority.
Check your understanding
Does a layered diagram establish runtime isolation?
No. It describes structure; containment depends on enforcement and shared-resource behaviour.
What makes queue capacity an architectural decision?
It affects memory, response time and overload behaviour across components, so its assumptions and failure policy must be agreed.
Further learning
- NASA Software Engineering Handbook: Software Design DescriptionArchitectural elements, interfaces, decisions, multiple views and quality attributes.
- Arm CMSIS documentationA practical example of standard interfaces between processor, peripherals, drivers and software frameworks.
Make ownership and dependency rules explicit.
A durable embedded software architecture shows who owns behaviour and data, how execution flows and which constraints protect timing, safety, security and testability.