← Back to the learning library
Before you begin: System requirements and interface concepts. TFA-101 and TFA-102 provide the firmware vocabulary used here.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Learning objectives
By the end of this module, you should be able to:
- Define the firmware boundary and operating context.
- Allocate testable system requirements and risk controls.
- Specify interfaces, states and safe behaviour.
- Maintain traceability across system and firmware evidence.
Lesson 1
1. Define the system context first
Identify users, actuators, sensors, processors, applications, networks, power sources and service tools around the firmware. The boundary should show who commands, who monitors, where state is retained and which external failures the firmware must tolerate.
Lesson 2
2. Allocate outcomes, not vague intentions
Translate system needs into measurable firmware requirements with ranges, timing, accuracy, states and failure responses. Allocate risk controls to the element that can implement and verify them credibly.
Lesson 3
3. Own cross-boundary behaviour
Specify start-up, shutdown, update, loss of communication, degraded operation and recovery across hardware and software. A safe state is a system property; firmware cannot invent it alone.
Lesson 4
4. Preserve the evidence chain
Trace system requirements and hazards through firmware architecture and verification. Use interface and integration records to expose gaps where each discipline assumed another team owned the behaviour.
Lesson 5
5. Translate system intent into allocated contracts
A system requirement should describe an outcome at the product boundary. Allocation turns that outcome into responsibilities for hardware, firmware, application software and users. Preserve units, environmental assumptions, timing and validity as the requirement crosses those boundaries.
For example, a system response limit of 100 ms may include sensor detection, transport, firmware processing and actuator settling. Allocating the entire 100 ms to firmware and also allowing other elements additional time creates an impossible system budget. Agree explicit sub-budgets and margin with the disciplines, then verify the complete path.
A requirement for “safe communication loss” needs a defined local response, allowed completion of an active step, timeout origin, stale-command policy and recovery authority. The firmware team can propose mechanisms, but systems engineering must reconcile them with the product’s intended use and hazards.
Lesson 6
6. Review operational modes and shared assumptions
Model normal, degraded, service, manufacturing, update and recovery modes. Define which combinations are allowed: servicing one subsystem while another remains active may introduce shared power or scheduling hazards. Modes should establish permissions, not merely select a screen or compile-time flag.
At each interface, ask who owns time, identity, calibration, configuration and validity. Two components using different timestamps may disagree about data age. An application can reconnect successfully while the controller still retains a partly completed physical operation. Reconnection therefore needs state reconciliation, not just an open transport channel.
| System decision | Firmware allocation | Integration evidence |
|---|---|---|
| Loss of peer | Bounded local response and command invalidation. | Disconnect at each active state. |
| Time integrity | Monotonic timing for deadlines; wall time for records. | Clock adjustment during operation. |
| Version compatibility | Reject unsupported peer/configuration combinations. | Mixed-version start-up and service tests. |
| Recovery | Self-test, state reconciliation and authorised restart. | Power interruption with incomplete operation. |
Review common assumptions explicitly. If every discipline assumes another one prevents an unsafe action, the system has no effective owner. Conversely, duplicated controls may conflict during recovery unless their priorities are designed.
Lesson 7
7. Govern interfaces through change and integration
Use interface control records and staged integration criteria. Before two components are joined, agree representative test doubles, expected error semantics and version identity. A simulator that always answers instantly can conceal a timeout problem until real hardware arrives.
When a requirement changes, trace impacts through allocation, architecture, timing, risk and verification. Revisit the system budget when firmware proposes a longer timeout to improve robustness; that timeout may defeat a system-level fault-response limit.
Maintain an explicit assumptions log with an owner and closure evidence. Assumptions should become verified facts, approved constraints or documented risks. An architecture review is not complete simply because its diagrams are consistent: the unresolved assumptions may still make the product infeasible.
Decision guide
Should a control be allocated to firmware?
| Question | Allocate when | Escalate when |
|---|---|---|
| Can firmware detect it? | Inputs and timing make detection credible. | Detection depends on unavailable system state. |
| Can firmware control it? | A defined output achieves the response. | Hardware independence or energy removal is required. |
| Can it be verified? | Acceptance criteria and test access exist. | Only an indirect claim can be shown. |
Worked example
Worked example — communications loss
The host stops sending commands during an active physical operation.
Systems engineering defines permissible completion, timeout and safe-stop behaviour. Firmware owns the watchdog and local sequence; hardware guarantees actuator-off behaviour after the final command.
The response is a system decision with clear allocation and end-to-end verification.
Engineering evidence
What should the work produce?
System context and boundary
Shows actors, interfaces and responsibilities.
Allocated requirements
Provide measurable firmware obligations.
Interface and state models
Describe cross-boundary behaviour.
Traceability and integration plan
Connect system intent to objective evidence.
Common failure patterns
What goes wrong?
- Allocating “make safe” without defining safe.
- Writing interface requirements from only one side.
- Ignoring bootloader and service modes in the system boundary.
- Treating traceability as an end-of-project exercise.
Applied exercise · approximately 25 minutes
Allocate a loss-of-communication response
A host commands a controller that performs a 300 ms physical step. The controller receives a heartbeat every 50 ms. The product request says “stop safely if communication is lost” but does not define whether the current step may finish.
- Identify the missing system decisions before choosing a heartbeat timeout.
- Propose two possible policies and describe their physical and timing implications.
- Write integration scenarios covering loss just before a step and loss halfway through it.
Review a suggested approach
The system owner must decide whether immediate interruption or controlled completion produces the acceptable physical outcome. The timeout, maximum step completion time, actuator response and detection jitter must fit the resulting system limit. A heartbeat frequency alone cannot answer this question.
One policy inhibits new steps after loss and allows only an already authorised bounded step to finish. Another aborts immediately through a defined hardware/firmware response. Each needs risk justification. Tests should vary heartbeat phase, verify no stale command starts a later step and confirm that reconnecting does not automatically resume an interrupted sequence without state reconciliation.
Completion criteria
- Product behaviour is decided before implementation timing.
- The allocated budget includes detection and physical completion.
- Reconnection and stale commands are included in the contract.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Is the firmware boundary unambiguous?
- Are timing and failure responses measurable?
- Does every control have one owner?
- Are degraded and maintenance states covered?
- Can system claims be traced to firmware tests?
Systems engineering gives firmware a clear contract with the complete product and its risks.
References and further reading
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.