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
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.
Further learning
- 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.