IEC 61508 (DIN EN IEC 61508) is a series of international standards for Functional Safety safety-related electrical, electronic and programmable electronic systems. In Germany, it has been adopted as DIN EN 61508, with reference to the VDE provision VDE 0803. It describes requirements for systems whose safety functions are intended to avoid or mitigate hazards caused by failures, malfunctions, or incorrect operation.
Content
Fundamentals of IEC 61508
IEC 61508 is titled „Functional safety of safety-related electrical/electronic/programmable electronic systems“. The latter term is frequently abbreviated as E/E/PE, both within the standard and in general.
Overall safety
Functional safety refers to the part of overall safety that depends on safety functions being executed correctly. A safety-related control system must react to inputs, states, or errors in such a way that a dangerous condition is prevented, detected, or its consequences are mitigated. An example from fire protection clarifies the distinction: a smoke detector that triggers a fire extinguishing system is part of functional safety. A fire door acts passively and therefore does not fall under functional safety in the narrower sense.
The standard is designed as a cross-industry basic safety standard. It describes principles and requirements for safety-related E/E/PE systems. Several sector-specific standards are derived from it or aligned with it, such as standards for machinery or vehicles.
Security lifecycle
IEC 61508 works with a safety lifecycle. This lifecycle begins with concept and hazard analysis and extends through specification, development, verification, validation, operation, maintenance, modification, and decommissioning. The standard requires that safety-related activities be planned, performed, audited, and documented.
A starting point is hazard and risk analysis. This involves considering the potential hazards of a system. Risk is understood as a combination of the probability of damage and the severity of damage. The necessary risk reduction is determined by comparing it with tolerable risk. After protective measures are implemented, residual risk remains. This residual risk is not the same as tolerable risk. It is the risk that remains after applying technical, organizational, or other measures, and it must be below the tolerable risk.
Security requirement levels
For safety functions, IEC 61508 uses safety requirement levels referred to as Safety Integrity Level or SIL. There are SIL 1 to SIL 4. The levels describe requirements for the safety integrity of a safety function. For random hardware failures, they refer to probabilities or frequencies of dangerous failures. For systematic failures, requirements for methods, evidence, verification, validation, and organizational separation increase with higher SIL.
IEC 61508 distinguishes between systematic and random failures. Systematic failures arise, for example, from incorrect assumptions, incomplete specifications, design errors, software errors, or unsuitable operating procedures. They are addressed through processes, reviews, tests, verification, validation, documentation, and management measures. Random hardware failures arise from physical failure mechanisms of components. They are controlled through architecture, diagnostics, monitoring, failure rate considerations, and further technical measures.
Structure of the standard series
IEC 61508 consists of seven parts. Additionally, an introductory technical report is sometimes referred to as Part 0, but it is not part of the seven main parts.
The seven parts are:
- IEC 61508-1: General Requirements
- IEC 61508-2: Requirements for safety-related electrical, electronic, and programmable electronic systems
- IEC 61508-3: Software Requirements
- IEC 61508-4: Terms and Abbreviations
- IEC 61508-5: Examples of Determining the Safety Integrity Level
- IEC 61508-6: Application Guide for IEC 61508-2 and IEC 61508-3
- IEC 61508-7: Application guidelines on methods and measures
Part 1 covers safety management, the safety lifecycle, documentation, verification, and validation, among other things. Part 2 concerns system and hardware requirements. Part 3 concerns software. Part 4 contains definitions. Part 5 supports the determination of SIL. Part 6 explains the application of Part 2 and Part 3. Part 7 describes procedures and measures, for example, for controlling random hardware failures, avoiding systematic failures, and for software safety integrity.
Application Framework of IEC 61508
IEC 61508 is used for safety-related E/E/PE systems when safety functions are performed by electrical, electronic, or programmable electronic systems. It is considered for control systems, safety components, automation systems, and safety-related products.
The standard, due to its fundamental nature, primarily targets manufacturers of safety-related systems, manufacturers of safety components, standard setters, and organizations that require a generic foundation for functional safety. For end-users or system integrators in the machinery sector, sector-specific standards such as EN 62061 or EN ISO 13849-1/-2 may be more suitable because they are tailored for machinery applications. For road vehicles, ISO 26262 is cited as the sector-specific standard in the sources.
IEC 61508 can also be used when no suitable harmonized sector-specific standard is available or when a safety-related system is to be assessed for certification based on a generic foundation. IEC 61508 is referenced in IEC and ISO standards, thus influencing technical requirements through derived standards. Interestingly, IEC 61508 is applied in the European region, for example, in weapons technology, because MIL-882 with System Safety is not far-reaching enough.
Properties and requirements
IEC 61508 connects technical requirements with organizational requirements. The standard requires a traceable chain from analysis, specification, design, implementation, testing, operation, and modification.
Procedural framework
The application includes documented responsibilities. Responsibilities must be defined for phases and levels of the security lifecycle. This includes the overall facility or system, hardware, and software. In the case of distributed development, interfaces, work products, and responsibilities must be delineated.
Verification and validation have separate tasks. Verification checks whether the results of a development phase meet the specifications of that phase. Validation checks whether the safety functions meet the safety requirements for the intended use. Both activities must be planned and documented.
The documentation serves as the basis for evidence. This includes, but is not limited to, requirements, architectures, test reports, version statuses, configuration data, change decisions, assumptions about operation, and justifications for chosen measures. For an assessment of functional safety, this information must be consistent and attributable to a product version.
Independence plays a role in functional safety assessment. The required degree depends on factors such as SIL, potential severity of harm, and the technology used. An assessing person must not have the same role as the person whose work is being assessed if the required independence would be compromised.
How is a specific SIL level achieved?
A specific SIL level results from several requirements for the safety function. According to IEC 61508, the safety function must match the required SIL level in design, architecture, and development process.
Essential criteria are:
- random hardware integrity,
- architectural limitations,
- Systematic ability.
Random hardware integrity describes the probability of dangerous random hardware failures. Systematic capability describes the control over systematic errors, for example in specification, development, implementation, verification, and modification processes.
The architecture-related restrictions evaluate the structure of the security-related hardware architecture. They determine which SIL level can be claimed with a specific architecture. The structure of the safety function, hardware fault tolerance, and diagnostic capability play a central role in this.
Architectural Constraints
Architecture-related constraints are requirements from IEC 61508 regarding the construction of a safety-related hardware architecture. They supplement the computational analysis of failure probability with minimum architectural requirements.
The background is the limited reliability data of electronic and programmable electronic components. Field failures are recorded differently depending on the manufacturer, application, and industry. Manufacturer specifications for failure rates are also based on specific databases, assumptions, and operating conditions. IEC 61508 therefore also considers the architecture of the safety function.
A central concept is hardware fault tolerance, or HFT for short. It describes how many dangerous hardware failures a safety function can tolerate while remaining operational.
In a 1oo1 architecture, there is one channel. The hardware fault tolerance is HFT = 0.
In a 1oo2 architecture, there are two channels. One channel is sufficient for the execution of the safety function. The hardware fault tolerance is HFT = 1.
The architecture-related restrictions link the achievable SIL level with hardware fault tolerance and other properties of the architecture. These include, in particular, the proportion of safe failures and the diagnostic coverage. This creates a structural minimum requirement for the safety function that is appropriate for the required SIL level.
The IEC 61508 also strives to provide specifications for achieving a core architecture – in the form of so-called routes.
Route 1H is the classic approach. The achievable SIL level is determined based on hardware fault tolerance and the proportion of safe failures. The proportion of safe failures is referred to as the Safe Failure Fraction, or SFF for short. The architecture is classified in tables. The higher the hardware fault tolerance and the higher the proportion of safe failures, the higher the achievable SIL level can be.
Route 2H is an alternative approach. It is based more heavily on robust operational and field data. This involves considering whether there is sufficient experience from real-world applications for the components and devices used. This experience must be suitable for the respective application, operating mode, and environment. Route 2H presupposes that failure data is systematically recorded, evaluated, and suitable for the specific safety function.
Typical misunderstandings and limitations
IEC 61508 is a basic standard for the functional safety of E/E/PE systems. Sector-specific standards transfer these principles to particular areas. EN 62061 deals with functional safety in the machine sector with reference to safety-related electrical control systems. EN ISO 13849-1/-2 deals with safety-related parts of controls in the machine sector. ISO 26262 deals with functional safety in the road vehicle sector.
Functional safety should not be equated with all forms of safety. Electrical safety, fire protection, mechanical safety measures, or organizational measures can be part of overall safety. Functional safety relates to the portion that depends on the safety functions of active systems. Other measures can also reduce risk but are not always part of functional safety in the narrower sense.
SIL is never a general quality level of a product. SIL refers solely to a safety function and the required safety integrity for it. A safety-related device therefore does not necessarily have to be perceived as fully appealing or satisfactory in terms of quality, because customer requirements alone define quality. A device can be described as SIL-capable for specific conditions and safety functions. This does not automatically mean that every use of the device meets a specific customer requirement. The specific safety function, architecture, diagnostics, operating conditions, and integration into the overall system must be considered.
The standard cannot be fulfilled by subsequent documentation if the required activities were not performed. Documents must reflect the measures that were actually planned, implemented, and verified. Software comments do not replace a safety requirement, an architecture, or proof of verification.
IEC 61508 is extensive and generically formulated. This necessitates the transfer of methods, procedures, and evidence to the respective system. This transfer requires technical justifications. The standard provides principles and requirements but does not replace the technical argumentation for a specific product.