Describing Firmware Architecture — ISO/IEC/IEEE 42010

Lesson 1

1. Separate the design from its description

ISO/IEC/IEEE 42010 concerns architecture descriptions, viewpoints and related concepts. It does not prescribe an architecting method, diagram tool or document format. A description represents an architecture; a well-formatted description does not prove that the architecture satisfies its requirements.

For a fictional battery-powered data logger, the source tree shows implementation organisation but says little about acquisition deadlines, update trust or persistent-data ownership. An architecture description should answer the questions people need to assess. It may combine diagrams, tables, decisions and references to analysis. The value lies in the relationships and reasoning, not the number of views or the sophistication of the modelling tool.

Lesson 2

2. Begin with stakeholders and concerns

Identify who must use the description and what they need to decide. Firmware developers may need dependency and ownership rules. Electronics engineers may need pin states during reset. Verification engineers need controllable interfaces and observable endpoints. Service engineers need compatible image combinations and recovery access. Security reviewers need trust boundaries and authority changes.

A concern should be specific enough to guide a view: “Can a flash erase delay sampling?” is more useful than “performance”. Record the requirement or risk behind the question where possible. Several people can share a concern, and one person can hold several roles. Revisit the list when a new board variant, remote service or external supplier changes who depends on the architecture.

Lesson 3

3. Choose viewpoints before drawing views

A viewpoint establishes how a class of concerns will be represented and interpreted. A view applies that approach to the actual product. In the logger example, an execution viewpoint might define tasks, interrupts, queues, timing annotations and ownership conventions. Its view shows the chosen tasks and their actual communication paths.

Agree the meaning of arrows. A dependency, a message, a power connection and a trust relationship are different things. Avoid a diagram where the same arrow silently means all four. Include a legend or a short modelling convention where ambiguity matters. Use familiar notation when it helps, but choose what the audience can assess rather than requiring UML simply because the publication number appears on the cover.

Lesson 4

4. Build a small set of complementary views

The following is an example view set, not a mandatory list from the standard. Add a view when it answers an important question that the existing set cannot answer clearly.

Reference detailed material rather than copying it into every view. For example, the deployment view can point to the controlled compatibility matrix while showing where compatibility is checked.

Lesson 5

5. Check correspondences between views

Independent diagrams can each look plausible while describing different systems. Check whether a message in the execution view has an interface and owner in the structural view. Check whether a recovery path in the deployment view appears in the security analysis. Check whether the memory map permits the queues and buffers assumed by the timing model.

For the logger, a drawing may suggest that an update worker runs alongside sampling. The processor manual might show that flash operations stall instruction fetch from the same bank. The correspondence review should expose this conflict before a scheduler diagram is accepted as proof of independence. Record unresolved inconsistencies and the work needed to resolve them. A shared component name alone is not evidence that two views agree.

Lesson 6

6. Retain decisions and alternatives

Capture why a choice was made, including the conditions under which it remains valid. A decision to use a single cooperative loop might depend on bounded peripheral transactions and a low acquisition rate. Increasing the sampling rate or adding a blocking library should trigger reconsideration of that decision.

A useful decision record states the concern, relevant constraints, considered alternatives, chosen option, consequences and supporting evidence. Include rejected alternatives when they explain a significant trade-off. Avoid retrospective rationalisation that makes every choice appear inevitable. Architectural debt can be acceptable when its consequences and ownership are understood; it becomes dangerous when the assumptions that justify it disappear from the record.

Lesson 7

7. Keep the description aligned with the release

Architecture descriptions need configuration identity. State which product family, board revisions and software baseline the description covers. Distinguish the current design from a planned future variant. Give diagrams stable identifiers so requirements, reviews and tests can reference them without relying on slide numbers that change during editing.

Use change review to find affected concerns and views. A new DMA buffer can change memory ownership, concurrency and test observability even if the public interface is unchanged. During review, sample implementation paths and compare them with the stated dependency rules. Automated dependency checks can support this work, but they will not reveal every mismatch in physical behaviour, timing or security assumptions.

Decision guide

Which view should answer this question?

Engineering evidence

What should the work produce?

Practical check

Questions for your next design review

• Does each view answer an identified concern?
• Are arrows, ownership and boundaries unambiguous?
• Do interfaces and entities agree across views?
• Are architectural assumptions connected to evidence and change triggers?