← Back to the learning library
Before you begin: System risk analysis and the defensive mechanisms in TFA-104. Apply the product’s authorised safety framework, not a generic SIL-to-class conversion.
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:
- Connect hazards and failure modes to firmware requirements.
- Assess diagnostic coverage and independence.
- Define safe-state, degradation and recovery behaviour.
- Build fault-injection and lifecycle evidence.
Lesson 1
1. Start from hazardous behaviour
Do not begin with a list of software bugs. Begin with the system behaviour that could cause harm, then determine how firmware can initiate, fail to prevent or detect it. Preserve the assumptions about hardware, users and external controls.
Lesson 2
2. Specify controls precisely
A control needs a detection condition, maximum response time, commanded safe behaviour, diagnostic and recovery rule. Watchdogs, range checks and redundancy are mechanisms whose effectiveness depends on independence and fault coverage.
Lesson 3
3. Analyse common cause and latent faults
Two software checks are not independent when they share the same sensor, clock, memory or specification error. Identify shared resources and ensure latent failures become visible before another fault completes a hazardous sequence.
Lesson 4
4. Demonstrate the safety argument
Link hazard controls to requirements, architecture, detailed behaviour and verification. Use fault injection and timing evidence to show the control works within the assumed conditions and remains effective after change.
Lesson 5
5. Distinguish systematic defects from random failures
Hardware can fail randomly through physical mechanisms; firmware can contain systematic defects that manifest under particular conditions. A software failure frequency cannot generally be justified by assigning a convenient component failure rate to a function. Use the safety framework’s required systematic measures and system-level risk reasoning.
Analyse how a defect or corrupted input could produce hazardous behaviour. A plausibility check may detect an out-of-range signal but not a plausible stuck value. A watchdog may detect a stalled task but not a task repeatedly producing the wrong command. Match each mechanism to the fault model it can actually address.
Reliability and safety objectives overlap but are not identical. A controlled safe shutdown may protect users while reducing availability. An automatic restart may improve uptime while reintroducing a hazard. Agree which response is acceptable in the operating context.
Lesson 6
6. Make independence and timing explicit
Trace the detection and mitigation chain through sensors, calculations, clocks, memory, scheduler and final outputs. Identify common causes and shared resources. Two checks compiled from the same erroneous requirement do not provide diversity against that specification defect.
Allocate the allowed response time across detection interval, confirmation/debounce, scheduling, communication and actuator behaviour. Diagnostic confirmation reduces nuisance trips but consumes time. A repeated-sample rule must be justified against the hazardous progression, including the maximum sampling gap.
| Safety mechanism | What it can address | Important limitation |
|---|---|---|
| Range check | Values outside a defined physical/electrical range. | Plausible wrong values may pass. |
| Progress watchdog | Missing required activity within a window. | Incorrect but progressing behaviour may pass. |
| Independent limit | A separately detected dangerous condition. | Shared reference/sensor can defeat independence. |
| Memory protection | Specified illegal accesses across enforced regions. | Does not prove correct authorised behaviour. |
Diagnostic coverage claims need a defined fault population and evidence. Avoid presenting a percentage without explaining the faults included, detection timing, assumptions and exclusions.
Lesson 7
7. Maintain the argument through service life
Review dormant and latent faults: a protective path may be broken while normal operation appears healthy. Define checks, proof tests or maintenance actions according to the system design and applicable framework. Verify that the diagnostic itself can report or contain failure.
Changes to sensor technology, task priorities, compiler options or update policy may invalidate a safety argument without changing the nominal algorithm. Require impact assessment of control independence, timing and verification whenever shared assumptions change.
For field problems, preserve the affected configuration and operating sequence. Evaluate whether the event reveals a missing fault model, inadequate detection or unintended recovery. Feed the result back into requirements and verification, not only a local code correction.
Decision guide
Is a firmware safety mechanism credible?
| Criterion | Question | Evidence |
|---|---|---|
| Detection | Can the relevant fault be observed in time? | Fault-injection coverage. |
| Independence | What resources and causes are shared? | Architecture and common-cause analysis. |
| Response | Does the action achieve system safety? | End-to-end safe-state test. |
Worked example
Worked example — heater over-temperature
A stuck control output or corrupted sensor could permit uncontrolled heating.
A separate monitor uses an independent limit and bounded response, commands heat off and latches a diagnostic. Analysis documents shared power and sensor assumptions; HIL injects stuck output and implausible readings.
The control has defined coverage, timing, independence and objective evidence.
Engineering evidence
What should the work produce?
Safety requirements allocation
Connects hazards to firmware obligations.
Diagnostic and independence analysis
Justifies coverage and shared assumptions.
Safe-state specification
Defines containment, degradation and recovery.
Fault-injection report
Shows response and timing under credible faults.
Common failure patterns
What goes wrong?
- Calling reset a safe state without system analysis.
- Assuming duplicate code is independent.
- Ignoring diagnostic-test failure.
- Testing detection without verifying the final safe outcome.
Applied exercise · approximately 25 minutes
Challenge a supposedly independent monitor
A controller computes temperature twice in two tasks and stops heating when either result exceeds a limit. Both tasks read the same converted value, use the same clock and call the same output driver.
- List which failures the arrangement might detect and which common causes remain.
- Propose proportionate improvements without assuming that every product needs a second processor.
- Define evidence for detection coverage and final output response.
Review a suggested approach
The design may detect a task-specific scheduling or local calculation problem, depending on implementation, but both tasks can accept a common wrong sensor value or conversion. Shared clock and driver failures remain. Calling the arrangement independent without those qualifications is unsupported.
Possible improvements include separately validated raw-data checks, protected ownership, a distinct hardware limit or an independently controllable output inhibit, selected by the risk analysis. Test the actual fault assumptions: stale plausible input, wrong conversion, delayed monitor and failed output command. Observe the physical output and timing, and document any residual common cause instead of claiming complete coverage.
Completion criteria
- Shared assumptions are traced beyond source-code separation.
- Suggested controls are linked to specific faults.
- Verification includes the final actuator path and latency.
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
- Are hazardous behaviours and assumptions clear?
- Are detection and response times specified?
- Are shared resources analysed?
- Is recovery controlled?
- Does evidence demonstrate end-to-end risk reduction?
A firmware safety control is credible only when its coverage, independence, timing and system effect are demonstrated.
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.