IEC 61508

Two families of fault

Random hardware faults occur unpredictably during the operating life of a hardware element — a motor driver degrades, an encoder connector corrodes, a sensor drifts out of calibration. They cannot be designed out, only detected and controlled, and they are quantified with failure rates and metrics.

Systematic faults are built in: a requirement was ambiguous, an interface was misunderstood, a timing budget was wrong, a firmware update changed behaviour nobody re-verified. They exist in every copy of the product from the moment of manufacture, and the only defence is process rigour — which is why so much of the standard is about how you work rather than what you build.

SIL: how much rigour, and why

Each safety function is assessed for the severity of the potential harm, the frequency and duration of exposure to the hazard, the possibility of avoidance once something starts to go wrong, and the likelihood of the unwanted event. The combination yields a Safety Integrity Level, SIL 1 through SIL 4.

The SIL then drives everything downstream: which architectural constraints apply (hardware fault tolerance, safe failure fraction), what PFD or PFH figure the system must achieve, which software techniques are required or highly recommended, and how independent the functional safety assessment must be. It is the single most consequential judgement in the whole lifecycle.

From safety functions to a safety case

The lifecycle moves from the definition of the equipment under control (EUC) and a hazard and risk analysis, to a set of safety functions with their required SILs, to a system architecture that allocates each function across E/E/PE subsystems with defined safe states and fault-tolerant time intervals. Hardware development adds quantitative evidence — FMEDA, hardware fault tolerance, safe failure fraction, PFD or PFH against the target SIL — and software development adds architecture, coding measures and verification against the SIL-appropriate technique tables.

Around all of it sits safety management: the safety plan, competence management, the interface agreement with each supplier or integrator, tool classification, and the confirmation measures — reviews, verification, and functional safety assessment — that make the argument independent rather than self-declared. The output is the functional safety case: the reasoned argument, supported by the work products, that the safety-related system is acceptably safe.