IEC 61508 — Functional safety
Understand the risk-based safety lifecycle for electrical, electronic and programmable electronic systems, and translate its principles into practical embedded-system work.
After this module, you should be able to:
- Explain functional safety and the role of safety functions
- Relate risk reduction to Safety Integrity Levels
- Connect lifecycle activities, competence and independence
- Recognise the evidence expected from hardware and software
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-106 and TEA-111. This is an introduction to applying a functional-safety lifecycle, not a SIL assessment.
Functional safety manages risk caused by system behaviour.
IEC 61508 is a basic functional-safety standard for safety-related electrical, electronic and programmable electronic systems. It uses a lifecycle approach: identify hazards, determine necessary risk reduction, specify safety functions and integrity, realise them, validate them and control them throughout operation and change.
A Safety Integrity Level (SIL) expresses a target for the dependability of a safety function. It is not a general quality score for a component or an entire product. The complete function—including sensor, logic, output and supporting measures—must be considered.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Safety lifecycle | Which activities, responsibilities and approvals span concept to decommissioning? | Safety plan and lifecycle records |
| Hazard and risk analysis | Which hazardous events require additional risk reduction? | Hazard log and risk assessment |
| Safety requirements | What function, response time, safe state and integrity are required? | Safety requirements specification |
| Architecture | How are independence, diagnostics and fault containment achieved? | Architecture and failure analysis |
| Realisation and validation | How will systematic and random failures be addressed? | Verification, validation and quantitative evidence |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Define equipment under control, operating modes and boundaries
- 2. Identify hazards and estimate the risk without the proposed safety function
- 3. Specify each safety function, including demand conditions, response time and safe state
- 4. Allocate the function across sensing, logic and actuation; analyse common causes
- 5. Apply lifecycle techniques proportionate to integrity and complexity
- 6. Validate the integrated function and manage modification, operation and proof testing
Worked application: overspeed protection
A motor controller detects speed, removes drive energy and prevents restart. The analysis must include the sensor, MCU execution, output stage and contactor—not only the firmware comparator. Independence, diagnostic intervals, response time and a stuck output all affect whether the safety function achieves its target.
Build evidence that explains the reasoning.
Lifecycle, roles, competence, independence and tailoring.
Hazards, risk decisions, safety functions and status.
Function, integrity, timing, safe state and interfaces.
Random hardware, systematic faults and common causes.
Reviews, analysis, tests and anomaly disposition.
Evidence that the complete safety functions meet intent.
Common failure patterns
A part is called “SIL 2” without defining its use in a safety function.
Sensors, actuators, power and external risk controls are excluded.
Techniques are recorded without showing why they address the risk.
A modified function is not reanalysed across the lifecycle.
Distinguish the safety function from its integrity
A safety function states what must happen to reduce a defined risk: for example, detecting overspeed and achieving a specified physical condition within an allocated time. Integrity concerns how dependably that function performs when needed. A fast nominal response and a dependable response are related but different claims.
IEC 61508 addresses systematic failure controls alongside random hardware failure performance. A probability calculation cannot compensate for an undefined requirement, an uncontrolled software change or a common cause that defeats redundant paths. Select the relevant sector framework where one applies and use the controlled source to establish the applicable obligations.
For your own design review, write the function in one sentence, then list its sensing, decision and actuation elements. Include energy supplies, communication and human action only with their justified role and assumptions. This makes hidden dependencies visible before detailed calculations begin.
Make diagnostic and maintenance assumptions operational
Some dangerous faults remain latent until a diagnostic or a proof test reveals them. A proof-test assumption in an analysis becomes a real maintenance obligation: define the procedure, interval, competence, coverage and restoration checks. A theoretical test that cannot be performed safely on installed equipment does not provide the assumed benefit.
Keep the model matched to the demand mode and failure mechanism. Low-demand measures and high-demand or continuous-mode measures are not interchangeable. Do not assign numerical software failure rates without a defensible method simply to complete a spreadsheet.
An independent shutdown path still needs examination of its final element. Two controllers commanding the same welded contactor do not create two effective ways to interrupt energy. Test or analyse the complete path and record the dependencies that limit the claim.
| Illustrative design record | Engineering content |
|---|---|
| Safety-function specification | Trigger, response, time limit, operating modes and recovery. |
| Dependency analysis | Shared sensing, power, clocks, actuators and environment. |
| Diagnostic argument | Faults considered, detection mechanisms and intervals. |
| Maintenance assumptions | Proof-test method, coverage, interval and restoration. |
| Change review | Affected function, evidence and approval before reuse. |
Build an argument a reviewer can challenge
Organise evidence around the safety claim: why the function is needed, why its allocation can achieve it, and why the implementation and lifecycle support the required dependability. Link each important assumption to evidence and identify the remaining uncertainty.
When equipment changes, revisit the whole function. A replacement sensor may improve reliability while slowing detection; a new actuator may meet nominal performance while failing differently. A component certificate is supporting evidence within its conditions of use, not a transfer of responsibility for the integrated design.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Review an overspeed trip with one final contactor
Two independent logic channels detect overspeed, but both rely on one contactor to remove drive power. The contactor can fail welded closed.
- Explain why the two logic channels do not alone establish the required protection.
- Identify alternative design measures and the evidence needed to choose between them.
- Describe the operating and maintenance assumptions that must be retained.
Show the worked answer
The common final element can defeat both trip commands. Assess the hazardous outcome, required response and credible contactor failures before choosing a solution. Options may include another justified energy-interruption mechanism, detection of welded state with prevention of subsequent operation, or a different architecture; their suitability depends on when the risk must be controlled.
Analyse common causes and response time, then verify the physical energy path under the relevant failure. If diagnostics or proof testing are credited, specify their interval, coverage and the response to a failed test. Retain conditions of use, installation assumptions and maintenance instructions. No SIL can be assigned from this short scenario alone.
Review criteria
- The complete safety function includes the final element.
- Proposed measures are justified against the hazard and timing.
- Maintenance assumptions have a practical implementation.
Check your understanding
Is a SIL a general product-quality rating?
No. It relates to the integrity of defined safety functions within the applicable framework and conditions.
Can a passed functional test replace systematic controls?
No. Nominal testing does not establish that requirements, design, implementation and change processes control systematic faults.
Further learning
- IEC — Safety and functional safetyPublisher source supporting this module’s framework discussion.
- IEC · Functional safetyIEC overview of functional-safety principles and standards.
- TEA-106 · Fault handling and safe statesPractical detection, containment and recovery concepts.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.