Treating general reliability as if it were safety integrity leads to a function that's durable, not safe

What it is

Safety integrity is about confidence that a specified safety function performs correctly when needed and does not fail dangerously; general reliability is about a device continuing to deliver its intended service over time, usually measured by mean time between failures (MTBF) or availability. A highly available device can still fail dangerously — an alarm system that stays online but never actually detects an abnormal condition — while a device that shuts down safely often, and so looks unreliable, may be doing exactly what functional safety requires of it.

Why it happens

General reliability statistics usually do not separate failure direction — they count "the device is unusable" whether that means it stopped, a safe failure, or kept running while producing a wrong and dangerous output. Functional safety must keep these apart, because only dangerous failure bears directly on risk; a safe failure at worst costs downtime. Substituting MTBF for dangerous-failure probability (PFD/PFH) in a safety argument hides the one number that actually needs controlling behind a coarse pass rate, encouraging the false belief that "reliable" implies "safe." Functional safety also separately controls systematic failure — design flaws and requirement errors present from the start rather than caused by random hardware ageing — which does not show up in conventional random-failure statistics at all.

Where it stops holding

Safety and reliability are not always opposed: an unnecessary safety shutdown can itself create a new hazard in some processes, such as thermal stress from abruptly halting a high-temperature process, making availability itself a safety requirement that must be weighed in. Deciding whether a failure belongs to the safety or the reliability dimension requires a defined safety function and failure direction first; without that, comparing component reliability grades alone says nothing about functional-safety level.

Applying it

For each identified failure mode, record its safety consequence, service consequence, detectability by online diagnostics, and required response, and validate each with its own correct measure — dangerous-failure probability against PFD/PFH, availability against downtime statistics — without substituting one for the other. Review material should report safety-integrity and availability/maintainability arguments separately, and specifically check for conflicts between the two, such as bypassing an interlock to improve availability.

Related

• Same group: Y4.06.1 Safety integrity level determination · Y4.06.2 Architecture and independence at higher SIL · Y4.06.3 Proof testing of safety functions
• Nearby: Y3.10 Parameter limits and safety interlocks · Y4.02 Redundancy and voting
• Search terms: functional safety · dangerous failure · mean time between failures · systematic failure