Functional safety is about behaviour
It asks whether safety-related functions act correctly when they are needed.
A system can contain high-quality components and still be unsafe if the overall safety function is specified or integrated incorrectly.
OrientSA • Safety Knowledge
12 Functional Safety Facts
That Make You Think
Functional safety can sound complicated. It does not have to. Explore twelve quick facts, a few common myths and a short challenge from the world of high-integrity systems.
Start with the facts Our assurance servicesClick • Reveal • Learn
Functional safety in bite-sized facts
Each fact highlights a principle that often matters during safety engineering, software assurance and independent assessment.
SIL is not a product quality score
A Safety Integrity Level relates to the integrity needed from a safety function—not how “good” a product is generally.
SIL needs to be linked to a defined safety function, risk reduction need and lifecycle evidence.
IEC 61508 has four SILs
SIL 1 to SIL 4 represent increasing levels of safety integrity, with SIL 4 the highest.
Higher integrity generally means tighter targets and more rigorous engineering, verification, independence and evidence.
Testing alone does not prove safety
Passing tests is important—but safety assurance also depends on requirements, design, traceability, analysis and configuration control.
Tests demonstrate selected behaviours. Assurance asks whether the complete safety argument is supported by objective evidence.
Software does not “wear out” like hardware
Software failures usually arise from systematic faults rather than physical ageing.
A latent software fault may remain hidden for years until a particular input, state or sequence triggers it.
Redundancy can still share one weakness
Two channels are not truly independent if the same cause can defeat both.
Common-cause and common-mode failures are why diversity, separation and independence need explicit justification.
Traceability is a safety superpower
A good safety requirement should be traceable from its hazard to implementation, verification and validation.
Traceability helps expose missing requirements, unverified changes and safety claims that are not backed by evidence.
Fail-safe does not mean failure-free
A fail-safe design aims to move or remain in a safe state when defined failures occur.
The safe state must be defined for the actual operating context; it is not always simply “switch everything off.”
Independence adds challenge, not paperwork
An independent assessor asks whether safety conclusions are justified—not merely whether documents exist.
Independent challenge can uncover assumptions, gaps, interface risks and evidence weaknesses before acceptance.
Interfaces are where surprises hide
Individual subsystems may be correct while their interfaces create unsafe behaviour.
Timing, data validity, power, communications, human actions and degraded modes all need interface-level assurance.
A change can reopen old safety arguments
Even a small software or configuration change can affect assumptions made elsewhere in the safety case.
Impact analysis and regression evidence are essential because safety dependencies are often wider than the changed item itself.
The lifecycle does not end at commissioning
Operation, maintenance, modification and decommissioning remain part of functional safety.
Safe operation depends on controlling configuration, incidents, maintenance, competence and future changes throughout service life.
Myth Buster
Two phrases that deserve a second look
“It has redundancy, so it must be safe.”
Redundancy helps only when the architecture, independence, diagnostics, common-cause vulnerabilities and failure responses are understood.
“Safety comes from evidence across the lifecycle.”
Hazards, requirements, architecture, implementation, verification, validation and operation all contribute to confidence in a safety function.
A quick SIL visual
Higher SIL = higher required safety integrity
IEC 61508 defines SIL 1 through SIL 4. The higher the SIL, the greater the required risk reduction and the stronger the corresponding engineering and assurance rigour.
Important: SIL should be assigned to a safety function—not casually used as a label for an entire system or product.
SIL 1
Increasing rigour
SIL 2
↑
SIL 3
↑
SIL 4
Highest SIL
Illustrative only. Actual SIL targets and quantitative limits depend on the applicable demand mode and standard requirements.
30-second safety challenge
A supplier says: “Our safety-related software passed every system test, therefore it is proven safe.” What is the best assurance response?
Think like an independent assessor
- Which hazard or risk drives this requirement?
- Where is the requirement implemented?
- What evidence verifies it?
- What happens when something fails?
- Are interfaces and degraded modes covered?
- Is the assessed configuration clearly identified?
Where OrientSA fits in
OrientSA specialises in assurance of high-integrity systems, including systems assurance, software assurance, safety assessment, audit, training and mentoring.
Our experience includes railway, metro, signalling, SCADA, tunnel and other control-system applications across Asia and Australia.
IEC 61508EN 50126EN 50129EN 50716RAMSSoftware Assurance
Need more than a fun fact?
Talk to OrientSA about practical, independent assurance for your high-integrity system.