← Back to the learning library
Before you begin: Read TFA-104 on fault handling, TFA-103 on timing and TFA-301 on applicability. This introduction assumes that a competent system team owns the hazard and risk analysis.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Publication basis: IEC 61508-3:2010, used in the context of the relevant parts of the IEC 61508 series. Select the governing sector framework and authorised editions before determining project obligations.
Learning objectives
By the end of this module, you should be able to:
- Distinguish system safety integrity from a firmware quality label.
- Translate allocated safety behaviour into reviewable firmware requirements.
- Examine fault detection, response and common dependencies.
- Identify evidence needed for tools, reused software and maintenance changes.
Lesson 1
1. Start with the safety function and governing framework
IEC 61508 provides a general functional-safety framework for relevant electrical, electronic and programmable electronic systems. Part 3 addresses software within that context, including lifecycle activities, systematic capability and support-tool considerations. A sector-specific framework may govern the actual project. Applicability cannot be determined solely from the presence of a microcontroller or the word “critical”.
In a fictional thermal process controller, first identify the hazardous situation and the claimed protective function. Clarify the controlled equipment, sensors, final elements and external measures. Firmware may contribute to detection and shutdown, but it is only one part of the function. Do not assign a SIL from a module exercise or treat a coding-standard report as the integrity assessment.
Lesson 2
2. Separate systematic software concerns from random hardware failure
Software defects arise from specifications, design, implementation and other systematic causes. They are not normally justified by assigning source code the same random failure rate model used for electronic components. A processor’s reliability figure does not establish the correctness of its firmware.
The software argument should address how faults are avoided, found and controlled for the allocated role. A safety integrity level concerns a safety function within its system context; software systematic capability is a related but different concept. Neither should be used as a casual label meaning “well tested”. Record the actual allocation, assumptions and assessment route, with competent review of how the software contribution supports the overall claim.
Lesson 3
3. Allocate detection, response and recovery behaviour
State the conditions firmware must detect, the required response, the timing allocation, the operating modes and the recovery authority. Include startup, maintenance and degraded conditions. “Enter the safe state” is incomplete if the physical outputs, retained energy and transition sequence are unspecified.
For the thermal controller, loss of valid temperature information might require removal of a heater command and prevention of automatic re-energisation. Whether cooling continues, alarms remain active or a process step can finish depends on the system analysis. An output set to zero is not universally safe. Keep these decisions linked to hazard analysis and the physical design rather than embedding undocumented assumptions in fault handlers.
Lesson 4
4. Examine dependencies and fault containment
Identify shared resources that can defeat apparently separate protective paths: clocks, power supplies, processors, memory, scheduling, libraries and physical output devices. A monitor running as another task can fail with the task it monitors if both depend on the same stalled scheduler.
A watchdog may contribute to fault detection, but its service conditions matter. If any regularly running task can refresh it while critical work is blocked, it can report health incorrectly. Consider what evidence establishes meaningful progress, which faults the mechanism can and cannot detect, and what reset actually does to the physical process. Common dependencies require explicit analysis; adding a second software check is not automatically independence.
Lesson 5
5. Make timing and diagnostic claims testable
Suppose a fictional protective path has an allocated 200 ms response limit. The team identifies 40 ms for acquisition and qualification, 20 ms for scheduling, 10 ms for command transmission and 70 ms for physical actuation, leaving 60 ms reserve. These illustrative numbers are useful only if their endpoint definitions and worst-case assumptions are justified.
Test under relevant load, modes and fault sequences. Include a failure immediately after a successful sample, simultaneous communication activity and restart during an active fault. Distinguish measured observations from analytical bounds. A few nominal tests cannot establish every worst case. Diagnostic coverage claims need a defined fault model and evidence about detection, not simply the presence of a self-test routine.
Lesson 6
6. Assess tools and reused components in context
Determine whether a tool could introduce a fault or fail to detect one, and whether other activities would reveal it. Consider compilers, generators, analysers, configuration utilities and test systems. Follow the actual tool provisions of the selected framework; a generic vendor certificate does not automatically cover every use, version or configuration.
Apply the same discipline to reused firmware. Previous field use may provide useful evidence, but only when the usage, environment, configuration and reporting quality are relevant. A library accepted for one processor or timing regime may behave differently on another. Record assumptions, known anomalies, integration constraints and the additional work needed for the new safety role.
Lesson 7
7. Maintain the safety argument through change
A maintenance update can invalidate earlier assumptions without changing the protective algorithm. A new radio stack may increase interrupt blocking; a bootloader change may alter startup output states; a compiler update may affect execution time. Review changes against the safety contribution, not only against edited source files.
Retain the approved safety requirements, architectural assumptions, analyses, verification evidence and unresolved anomalies for each relevant release. Record the authority that accepts the resulting argument. When a field defect reveals a shared assumption was wrong, examine other variants and releases that depend on it. The aim is a maintained system claim, not a one-time document attached to the first production build.
Decision guide
What evidence is needed for this protective mechanism?
| Mechanism | Question | Evidence to seek |
|---|---|---|
| Watchdog | Does servicing indicate required progress? | Service design, failure injection and reset behaviour |
| Redundant checks | What dependencies can defeat both? | Common-cause and independence analysis |
| Fault response | Does the physical process reach the intended condition in time? | Allocated requirements and measured system response |
| Reused library | Are prior assumptions valid in the new role? | Component assessment and integration evidence |
Worked example
Worked example — a watchdog that misses a deadlocked control task
The communication task refreshes the watchdog every 50 ms. A control task can deadlock while communications continue, leaving the previous output command active. Nominal endurance tests report no resets.
The team revisits the protective function and requires evidence of progress from the relevant control activities before watchdog servicing. It analyses failures of the supervision mechanism itself and the dependencies shared with the monitored tasks. It also reviews hardware output behaviour during reset and whether an independent protective path is needed by the system safety argument.
Fault injection now assesses the intended failure scenarios and physical response. The project records the mechanism’s limits; it does not claim that a revised refresh policy alone provides a particular SIL or complete protection.
Engineering evidence
What should the work produce?
Software safety allocation
Links required behaviour and timing to the system analysis.
Architecture and dependency analysis
Explains fault containment, common resources and assumptions.
Verification and tool evidence
Supports relevant methods, mechanisms and tool use.
Maintained safety argument
Connects the identified release to accepted evidence and change decisions.
Common failure patterns
What goes wrong?
- Assigning a SIL to firmware from its test coverage percentage.
- Treating two tasks on one stalled processor as independent protection.
- Assuming reset always produces a safe physical condition.
- Reusing evidence without checking its environmental assumptions.
Applied exercise · approximately 25 minutes
Challenge a “SIL-ready” firmware claim
A team presents a controller as “SIL-ready” because it uses MISRA C, a watchdog and 95% statement coverage. No system safety allocation or physical shutdown test is available.
- Identify the missing foundations of the claim.
- Describe evidence needed to assess the watchdog and output response.
- Rewrite the statement so it accurately describes the available evidence.
Review a suggested approach
The evidence does not establish the governing framework, safety function, integrity allocation, systematic capability or the hardware contribution. Coding discipline and coverage can support particular activities, but they do not supply those missing decisions. Examine watchdog supervision conditions, common dependencies, reset effects and a justified detection-to-physical-response allocation.
An accurate statement might say that the identified build has undergone a specified coding assessment and statement-coverage measurement, and contains a watchdog whose safety contribution remains to be assessed. It should identify scope and open evidence rather than imply a certified or assured integrity level. The next action is a competent system allocation and assurance plan, followed by targeted design and verification work.
Completion criteria
- No integrity level is inferred from the listed implementation features.
- Missing system, hardware and software evidence is distinguished.
- The revised claim is limited to what has actually been demonstrated.
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 governing safety framework and function allocation explicit?
- Are safe behaviour and timing defined at the correct system boundary?
- Are common dependencies and undetected fault cases examined?
- Does each change preserve or revise the supporting safety argument?
Firmware safety assurance must explain how a defined software contribution supports a system safety function under credible faults and changes.
References and further reading
- IEC 61508-3:2010 — software scope and requirements overview
- TFA-104 — Defensive Programming
- TFA-205 — Functional Safety & Reliability Engineers
- TFA-301 — Firmware Standards & Guidance
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.