Electronics Guide

Safety Functions and Safety-Related Systems

A safety function is a specific action that must be performed to achieve or maintain a safe state for a defined hazard. An example is shutting off fuel to a burner when a flame-failure sensor reports loss of flame. The safety-related system is the combination of sensors, logic, and actuators that carries out the safety function, together with any supporting infrastructure such as power supplies and communications. Functional safety is concerned with how dependably this combination performs its function when called upon.

The framework distinguishes the safety function from the equipment under control and its ordinary control system. The equipment under control is the machinery or process that presents the hazard; its control system manages normal operation. The safety-related system exists specifically to reduce the residual risk that remains after all other measures, and its reliability is therefore subject to quantitative requirements that ordinary control functions are not.

Random and Systematic Failures

IEC 61508 separates failures into two kinds, because they are controlled by different means. Random hardware failures arise from physical mechanisms such as component wear-out and are described probabilistically; they can be quantified with failure-rate data and reduced with redundancy and diagnostics. Systematic failures arise from errors in specification, design, or implementation, including software faults; they cannot be meaningfully assigned a failure rate and are instead controlled by the rigor of the development process.

This distinction shapes the whole standard. Quantitative targets address random hardware failures, setting a maximum tolerable probability of dangerous failure for each safety function. Process requirements address systematic failures, prescribing techniques and measures, design reviews, and verification activities whose thoroughness scales with the required integrity. A safety function meets its target only when both kinds of failure are adequately controlled, since the most reliable hardware cannot compensate for a flawed specification.

Low Demand and High Demand Modes

The standard recognizes that safety functions are called upon at very different rates, and it quantifies integrity accordingly. The dividing line is one demand per year. A low-demand function faces demands no more often than once a year, such as an emergency shutdown that may be needed only once in a decade; its integrity is expressed as the average probability of dangerous failure on demand, written PFD_avg, the chance that it fails to act when finally required. A high-demand or continuous function faces demands more often than once a year, or holds the equipment within safe limits continuously, such as a function that supervises the speed of a moving machine; its integrity is expressed as the average frequency of dangerous failure per hour, written PFH.

The mode of operation determines which metric applies and therefore how the target is stated and verified. The distinction has practical consequences. A low-demand function accumulates undetected dangerous failures quietly between proof tests, so its probability of failure on demand depends strongly on how often it is tested. A high-demand function is exercised so frequently that the proof-test interval matters far less, and its dangerous failure rate governs the result. Misclassifying the mode is a common and costly error, because it leads to verifying the wrong quantity against the wrong target.

Definition and Scale

IEC 61508 defines four safety integrity levels, from SIL 1 to SIL 4, with SIL 4 representing the highest integrity and the greatest risk reduction. Each level corresponds to a band of tolerable dangerous-failure probability, and the bands are spaced by factors of ten. For a low-demand function, SIL 1 permits an average probability of failure on demand between one in ten and one in one hundred, SIL 2 between one in one hundred and one in one thousand, SIL 3 between one in one thousand and one in ten thousand, and SIL 4 between one in ten thousand and one in one hundred thousand. The high-demand metric follows the same ten-to-one structure expressed as dangerous failures per hour: SIL 1 spans one in one million to one in one hundred thousand per hour, and SIL 4 spans one in one billion to one in one hundred million per hour.

Read the other way, a safety integrity level is a risk reduction factor. A SIL 1 function is credited with reducing the risk of the hazard it addresses by a factor between ten and one hundred, and a SIL 4 function by a factor between ten thousand and one hundred thousand. SIL 4 is rare in industrial practice; the process and machinery sectors normally prefer to reduce the underlying hazard rather than depend on a single instrumented function of such extreme reliability.

A higher SIL is therefore not a vague indication of importance but a specific, order-of-magnitude tighter reliability requirement. It also attaches to a safety function rather than to a product. No device is of a given SIL in the abstract; a certified component is instead declared suitable for use in a safety function of a stated integrity level, subject to the assumptions recorded in its safety manual. Because each step demands roughly ten times better performance, the cost and difficulty of achieving a SIL rise steeply with the level. Designers aim to specify the SIL that genuinely matches the risk, since over-specifying wastes resources while under-specifying leaves unacceptable residual risk.

Hardware and Systematic Capability

Achieving a SIL requires meeting requirements on two fronts simultaneously. The hardware must satisfy the quantitative target for dangerous-failure probability and must also respect architectural constraints that limit how much can be claimed from a given redundancy structure. In parallel, the development must demonstrate systematic capability, graded SC 1 to SC 4 to match the four integrity levels, meaning that the process used to specify, design, implement, and verify the element was rigorous enough to control systematic faults at that level. Every element carries both a hardware figure and a systematic capability, and the safety function is limited by whichever is weaker.

The architectural constraints deserve emphasis because they prevent over-claiming, and IEC 61508 offers two routes to satisfying them. The first tabulates the maximum SIL claimable from the combination of hardware fault tolerance, the number of faults an element can withstand while still performing its function, and safe failure fraction, the proportion of failures that are either inherently safe or revealed by diagnostics. That table is stricter for so-called Type B elements, those of complex design whose failure modes cannot be fully determined and which typically contain a microprocessor, than for the simpler Type A elements such as relays and mechanical switches. This is why a programmable logic solver usually needs redundancy at an integrity level that a hard-wired contactor chain can reach on its own. The second route allows reliability data drawn from documented field experience, subject to statistical confidence requirements and a minimum fault tolerance at the higher levels.

Either way, a safety function does not earn a high SIL merely by calculating a favorable failure probability. The constraint guards against designs that look reliable on paper but depend on optimistic assumptions, ensuring that high-integrity claims rest on genuinely fault-tolerant, well-diagnosed structures.

Hazard Analysis and Requirements

The lifecycle begins by understanding the system, its boundaries, and the hazards it can present. Hazard and risk analysis identifies the hazardous events, estimates their consequence and likelihood, and determines the risk reduction that safety functions must provide. From this analysis the safety requirements are derived: each safety function is specified together with its required safety integrity level. This specification phase is critical, because an error here propagates through every later phase, and specification errors are a leading cause of systematic failure.

Design, Realization, and Verification

With requirements established, the safety functions are designed and realized in hardware and software. The architecture is chosen to meet the hardware integrity targets, components are selected with appropriate failure data, and software is developed under the discipline appropriate to its SIL. Verification accompanies each step, confirming through review, analysis, and testing that the realization satisfies its requirements. Software in safety systems receives particular attention, with techniques and coding constraints that grow stricter as the SIL increases, because software faults are purely systematic and cannot be reduced by redundancy of identical copies.

Validation then confirms, against the original safety requirements, that the integrated system actually performs its safety functions correctly under realistic conditions. Where the verification activities check that each phase was carried out correctly, validation checks that the finished system is the right system, delivering the intended risk reduction. The distinction matters because a system can be built correctly to a flawed specification, and only validation against the requirements catches that mismatch.

Operation, Maintenance, and Modification

Functional safety does not end when a system is commissioned. Operation and maintenance procedures preserve the integrity that was designed in: proof tests periodically reveal dangerous failures that diagnostics did not detect, and maintenance restores the system after faults. The interval between proof tests directly affects the achieved probability of failure on demand, so it is part of the safety design, not merely an operational detail. Any modification reopens the lifecycle, requiring impact analysis and re-verification so that a change intended to improve the system does not silently degrade its safety integrity.

Risk as Consequence and Likelihood

Risk combines the severity of a possible harm with the likelihood of its occurrence. A hazard with grave consequences but a remote likelihood may carry the same risk as a less severe hazard that occurs frequently. Functional safety uses this combination to decide how much risk reduction is needed: the gap between the inherent risk of the unprotected equipment and the tolerable risk defines the required performance of the safety functions. The larger that gap, the higher the integrity demanded.

Several techniques support the analysis. Hazard and operability studies systematically examine deviations from intended operation. Failure mode and effects analysis works upward from component failures to their system consequences. Fault tree analysis works downward from an undesired event to the combinations of causes that could produce it. These methods complement one another, and rigorous practice often applies more than one to cross-check the identified hazards and their causes.

Risk Graphs and Target Setting

To assign integrity targets consistently, standards offer structured methods such as risk graphs and layer-of-protection analysis. A risk graph guides the analyst through a few parameters, the severity of harm, the frequency and duration of exposure, the possibility of avoiding the hazard, and the probability of the unwanted occurrence, leading to a recommended safety integrity level. Layer-of-protection analysis instead accounts for the independent protective layers already present and calculates the additional risk reduction the safety function must supply.

These methods discipline what could otherwise be a subjective judgment. By making the parameters explicit, they ensure that similar hazards receive similar treatment and that the basis for each SIL assignment is documented and reviewable. The goal is a defensible, traceable link from the identified hazard to the integrity level of the safety function that protects against it, so that the chosen target can be justified to operators, auditors, and regulators alike.

Redundant Architectures

Redundancy provides fault tolerance by duplicating elements so that the failure of one does not defeat the safety function. Architectures are commonly described by the number of channels that must function out of the number provided. A one-out-of-two arrangement performs the safety action if either channel demands it, favoring safety over availability; a two-out-of-three voting arrangement tolerates the failure of any single channel while resisting spurious trips, balancing safety with availability. The choice reflects the relative cost of a dangerous failure and of an unnecessary shutdown.

Redundancy guards effectively against random hardware failures but not against systematic ones, because identical channels share identical design faults and would fail together under the same conditions. Where systematic failures, including software faults, are a concern, diversity is used: channels are implemented differently, with different designs or technologies, so that a common flaw is unlikely to disable them simultaneously. Diversity is costly and is reserved for the highest integrity requirements, where common-cause systematic failure would otherwise dominate the risk.

Common-Cause Failure

Redundancy delivers its benefit only to the extent that channels fail independently. A common cause defeats several channels at once: a shared power supply or shared field wiring, a shared calibration error, a burst of electrical interference, a flood or fire, or a maintenance technician who repeats the same mistake on every channel. Quantitative models capture this with a common-cause factor, conventionally called beta, the fraction of a channel's dangerous failures that also disable the redundant partner. IEC 61508 provides a scoring checklist for estimating beta from features such as physical separation, diversity of design and technology, environmental protection, and the competence and procedures of the maintenance staff.

Beta dominates high-integrity designs. Once redundancy has driven independent failures far down, the residual probability is governed almost entirely by the common-cause term, so a beta of a few percent can cap the achievable integrity no matter how many channels are added. This is why the standard rewards genuine separation and diversity over mere duplication, and why electromagnetic immunity, surge withstand, and environmental qualification are treated as functional-safety concerns rather than as unrelated compliance chores.

Diagnostic Coverage and the Safe State

Diagnostics detect failures before they can defeat the safety function, converting otherwise dangerous undetected failures into detected ones that can be acted upon. Diagnostic coverage is the fraction of dangerous failures that the diagnostics reveal, and the standards band it conventionally as low at about sixty percent, medium at about ninety percent, and high at about ninety-nine percent. High coverage allows more credit to be taken for a given architecture, because it raises the safe failure fraction on which the architectural constraint depends. Self-tests of memory and processor, plausibility and range checks on sensor signals, watchdog timers, line monitoring of field wiring, comparison between redundant channels, and read-back of actuator state all contribute to coverage. The diagnostic test interval matters as well: a fault must be detected and acted upon within the process safety time, the interval between the onset of a fault and the point at which the hazard could occur, or the diagnostic earns no credit.

What happens after detection is equally important. A safety function is designed so that detected failures, and ideally the loss of the function itself, lead to a defined safe state, the condition in which the equipment presents no unacceptable hazard. For many processes the safe state is de-energized or shut down, achieved by a fail-safe design in which loss of power or signal causes the protective action. Designing toward a clear safe state ensures that when the system cannot guarantee correct operation, it errs on the side of safety.

ISO 26262 for Automotive Systems

ISO 26262 adapts functional safety to road vehicles, addressing the electrical and electronic systems whose failure could endanger occupants or other road users. Its second edition, published in 2018, grew to twelve parts and widened the scope from passenger cars to road vehicles generally, excluding mopeds, adding dedicated parts for semiconductors and for motorcycles. In place of the SIL it defines the automotive safety integrity level, or ASIL, with four grades from ASIL A to ASIL D, the last being the most stringent; a hazard that warrants no ASIL is classified QM, meaning that ordinary quality management suffices. The ASIL of a given hazard is determined not by a single parameter but by combining three: the severity of potential harm, the probability of exposure to the operating situation, and the controllability of the situation by a typical driver.

This three-factor approach reflects the automotive context, where the same fault can be far more dangerous in one driving situation than another, and where a driver may sometimes intervene to avoid harm. The standard also permits ASIL decomposition, in which a requirement at a high ASIL is discharged by redundant and sufficiently independent elements each developed to a lower ASIL, provided the independence is demonstrated. ISO 26262 carries the lifecycle, hazard analysis, and verification principles of IEC 61508 into the specific activities of vehicle development, from the concept phase through production and field operation, including the management of safety across the supply chain that characterizes the automotive industry.

ISO 26262 addresses malfunctions of the electronics. A companion standard, ISO 21448 on the safety of the intended functionality, addresses a different problem that automated driving has made urgent: hazards that arise when a fault-free system behaves unsafely because of the limits of its sensing or its algorithms, such as a camera-based function misreading an unusual scene. The two are complementary, and advanced driver assistance and automated driving programs generally apply both.

IEC 62061 for Machinery

IEC 62061 applies functional safety to the safety-related control systems of machinery, providing a route for machine builders to specify and realize electrical, electronic, and programmable safety functions in compliance with machinery safety regulations. Its second edition appeared in 2021 and was amended in 2024. It retains the safety integrity level as its measure of integrity and derives its methods from IEC 61508, while focusing on the demand modes and architectures typical of industrial machines, where safety functions often operate frequently to keep machinery within safe limits. The standard addresses SIL 1 through SIL 3 only; hazards demanding more than that fall outside the machinery framework and are handled by reducing the risk at its source.

In the machinery sector IEC 62061 coexists with ISO 13849-1, whose fourth edition was published in 2023 and which addresses the same problem through the related concept of the performance level, graded from PL a to PL e. The two scales are deliberately comparable: PL b and PL c correspond broadly to SIL 1, PL d to SIL 2, and PL e to SIL 3, while PL a has no SIL equivalent. The two standards offer complementary paths to the same goal of safe machine control, and machine builders select the one better suited to the complexity and technology of their safety functions. ISO 13849-1 applies regardless of the control technology, covering electrical, hydraulic, pneumatic, and mechanical elements, and it reaches a performance level through designated architectures, or categories, together with component lifetime and diagnostic coverage. IEC 62061 is specific to electrical, electronic, and programmable systems and treats complex programmable subsystems and their software in greater depth.

Long-running work to merge the two documents into a single machinery standard did not reach that goal, but the current editions were revised in coordination so that a subsystem developed under one may be used within a safety function assessed under the other. Both require the same essentials: hazard analysis, integrity targets matched to risk, and verification that the realized control system meets those targets.

Other Sector Adaptations

Many other industries maintain their own derivatives. The process industries apply IEC 61511, which interprets IEC 61508 for safety instrumented systems in chemical plants, refineries, and similar facilities; it retains the safety integrity level and, in practice, expects safety instrumented functions above SIL 3 to be avoided by reducing the underlying risk rather than relying on an ever more reliable instrumented layer. Railways follow the CENELEC standards, EN 50126 for the management of reliability, availability, maintainability, and safety across the railway lifecycle and EN 50129 for safety-related electronic systems in signaling; software requirements now rest with EN 50716, published in 2023, which superseded both EN 50128 for signaling software and EN 50657 for rolling-stock software. Nuclear instrumentation and control follows IEC 61513 and its supporting standards, and software in medical devices follows IEC 62304 within the risk-management framework of ISO 14971. Civil aviation is the notable exception, having developed its own assurance framework independently of IEC 61508, built around SAE ARP4754 for system development together with DO-178C and DO-254 for airborne software and electronic hardware, and grading rigor by design assurance level rather than by SIL. Despite differing terminology, these standards share the common DNA of functional safety: integrity levels matched to risk, a disciplined lifecycle, and the joint control of random and systematic failures. The software provisions of these sector standards are compared side by side in Software Safety Standards (Beyond Medical), and the wider automotive compliance picture surrounding ISO 26262 is treated in Automotive Electronics Standards.