YHT Cover qxd raising standards worldwide™ NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW BSI Standards Publication Functional safety of electrical/ electronic/programmable ele[.]
Safety terms
3.1.1 harm physical injury or damage to the health of people or damage to property or the environment [ISO/IEC Guide 51:1999, definition 3.3]
3.1.2 hazard potential source of harm
The term encompasses immediate dangers to individuals, such as fire and explosion, as well as long-term health risks, like exposure to toxic substances.
3.1.3 hazardous situation circumstance in which people, property or the environment are exposed to one or more hazards
[ISO/IEC Guide 51:1999, definition 3.6, modified]
3.1.4 hazardous event event that may result in harm
The impact of a hazardous event on individuals, property, or the environment hinges on exposure to its consequences For harm to occur to people, it is crucial that those exposed have the ability to escape the aftermath of the event.
3.1.5 harmful event occurrence in which a hazardous situation or hazardous event results in harm
NOTE Adapted from ISO/IEC Guide 51, definition 3.4, to allow for a hazardous event
3.1.6 risk combination of the probability of occurrence of harm and the severity of that harm
NOTE For more discussion on this concept see Annex A of IEC 61508-5
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
3.1.7 tolerable risk risk which is accepted in a given context based on the current values of society
NOTE See Annex C of IEC 61508-5
3.1.8 residual risk risk remaining after protective measures have been taken
EUC risk risk arising from the EUC or its interaction with the EUC control system
In this context, the risk pertains to the specific harmful events where E/E/PE safety-related systems and other risk reduction measures are implemented to achieve essential risk mitigation, specifically concerning functional safety.
The EUC risk, as illustrated in Figure A.1 of IEC 61508-5, serves to establish a baseline for risk assessment, excluding the influence of E/E/PE safety-related systems and other risk mitigation strategies.
NOTE 3 Assessment of this risk will include associated human factor issues
Target risk refers to the specific level of risk that is aimed to be achieved for a particular hazard This assessment considers the EUC risk alongside the safety-related systems, including E/E/PE, and other measures implemented for risk reduction.
3.1.11 safety freedom from unacceptable risk
Functional safety is a crucial aspect of overall safety concerning the Equipment Under Control (EUC) and its control system It relies on the proper operation of electrical, electronic, and programmable electronic (E/E/PE) safety-related systems, along with other measures aimed at reducing risks.
3.1.13 safe state state of the EUC when safety is achieved
In transitioning from a potentially hazardous condition to a final safe state, the Equipment Under Control (EUC) may need to pass through several intermediate safe states In certain scenarios, a safe state is maintained only with continuous control of the EUC, which may be required for either a brief or an indefinite duration.
3.1.14 reasonably foreseeable misuse use of a product, process or service in a way not intended by the supplier, but which may result from readily predictable human behaviour
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
Equipment and devices
EUC equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical or other activities
NOTE The EUC control system is separate and distinct from the EUC
3.2.2 environment all relevant parameters that can affect the achievement of functional safety in the specific application under consideration and in any safety lifecycle phase
NOTE This would include, for example, physical environment, operating environment, legal environment and maintenance environment
3.2.3 functional unit entity of hardware or software, or both, capable of accomplishing a specified purpose
NOTE In IEV 191-01-01 the more general term “item” is used in place of functional unit An item may sometimes include people
3.2.4 application task related to the EUC rather than to the E/E/PE system
3.2.5 software intellectual creation comprising the programs, procedures, data, rules and any associated documentation pertaining to the operation of a data processing system
NOTE 1 Software is independent of the medium on which it is recorded
NOTE 2 This definition without Note 1 differs from ISO/IEC 2382-1 (reference [7] in the Bibliography) by the addition of the word data
System software is a crucial component of a programmable device within a PE system, focusing on its operational functionality and the services it provides This differs from application software, which is designed to execute specific tasks related to the safety of the End User Computing (EUC) environment.
NOTE Refer to IEC 61508-7 for examples
Application software refers to the specific software components of a programmable electronic system that define the functions necessary to perform tasks related to the end-user computing (EUC) This software is distinct from the underlying operations and services provided by the programmable device itself.
3.2.8 pre-existing software software element which already exists and is not developed specifically for the current project or safety-related system
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
The software in question may either be a commercially available product or one developed by an organization for a prior system It is important to note that pre-existing software may not necessarily comply with the requirements of this standard.
3.2.9 data information represented in a manner suitable for communication, interpretation, or processing by computers
Data can be categorized as either static information, such as configuration settings or geographical representations, or as instructions that define a sequence of existing functions For further examples, consult IEC 61508-7.
3.2.10 software on-line support tool software tool that can directly influence the safety-related system during its run time
Software off-line support tools are essential for specific phases of the software development lifecycle, as they do not directly impact the safety-related system during its runtime These tools can be categorized into various classes based on their functionalities.
– T1 generates no outputs which can directly or indirectly contribute to the executable code (including data) of the safety related system;
NOTE 1 T1 examples include: a text editor or a requirements or design support tool with no automatic code generation capabilities; configuration control tools
T2 aids in testing or verifying design and executable code, ensuring that while tool errors may fail to identify defects, they do not directly introduce errors into the executable software.
NOTE 2 T2 examples include: a test harness generator; a test coverage measurement tool; a static analysis tool
– T3 generates outputs which can directly or indirectly contribute to the executable code of the safety related system
Examples of NOTE 3 T3 include an optimizing compiler, where the connection between the source code and the generated object code is not clear, and a compiler that integrates an executable run-time package into the final executable code.
PE based on computer technology which may be comprised of hardware, software, and of input and/or output units
NOTE This term covers microelectronic devices based on one or more central processing units (CPUs) together with associated memories, etc
EXAMPLE The following are all programmable electronic devices:
– application specific integrated circuits (ASICs);
– other computer-based devices (for example smart sensors, transmitters, actuators)
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
E/E/PE based on electrical (E) and/or electronic (E) and/or programmable electronic (PE) technology
NOTE The term is intended to cover any and all devices or systems operating on electrical principles
EXAMPLE Electrical/electronic/programmable electronic devices include:
– solid-state non-programmable electronic devices (electronic);
– electronic devices based on computer technology (programmable electronic); see 3.2.12
Limited variability language is a software programming language designed for commercial and industrial programmable electronic controllers Its notation can be either textual, graphical, or a combination of both, and its capabilities are specifically tailored to its intended applications.
EXAMPLE The following are limited variability languages, from IEC 61131-3 (reference [8] in the Bibliography) and other sources, which are used to represent the application program for a PLC system:
A ladder diagram is a graphical representation that utilizes a series of input symbols, which mimic the behavior of devices like normally open and normally closed contacts These symbols are interconnected by lines that illustrate the flow of current, leading to output symbols that represent the behavior of relays.
– Boolean algebra: a low-level language based on Boolean operators such as AND, OR and NOT with the ability to add some mnemonic instructions;
– function block diagram: in addition to Boolean operators, allows the use of more complex functions such as data transfer file, block transfer read/write, shift register and sequencer instructions;
– sequential function chart: a graphical representation of a sequential program consisting of interconnected steps, actions and directed links with transition conditions
ASIC integrated circuit designed and manufactured for specific function, where its functionality is defined by the product developer
NOTE The term ASIC as a stand-alone covers all types of the following integrated circuits:
– Full custom ASIC: ASIC where design and production is similar to a standard integrated circuit with the functionality defined by the product developer
Standard integrated circuits are produced in high volumes for various applications, with their functionality, validation, and testing managed exclusively by semiconductor vendors To minimize area requirements, manual adjustments and optimizations at the layout level are commonly employed, although these circuits are not intended for safety-critical systems Additionally, frequent modifications in production processes, technologies, and layouts are implemented to enhance cost efficiency and yield, while the specific quantities of components produced using particular process or mask revisions remain undisclosed.
– Core based ASIC: ASIC based on a pre-layout, designed or generated macro cores, supported by additional logic
EXAMPLE 1 Examples for pre-layout macros are standard microprocessor cores, peripheral components, communication interfaces, analogue blocks, special function I/O cells
Pre-designed macros, recognized as Intellectual Property (IP), include various similar components Unlike the examples in Example 1, these designs utilize high-level hardware description languages such as VHDL and Verilog, specifically tailored for cell-based ASICs.
Generated macros, such as embedded RAM, ROM, EEPROM, or FLASH memory, are designed to be correct by construction according to established design rules While these pre-layout macros are specific to certain processes, they can often be adapted for use in different technologies It is important to note that the macro cores typically differ from the original discrete off-the-shelf components, as they are produced using different processes and may be sourced from third-party providers.
– Cell based ASIC: ASIC based on logic primitives (like AND, OR, Flip-Flop, Latch) taken from a cell library
The gate-level netlist, which includes logic primitives and their interconnections, is typically generated from high-level hardware description languages like VHDL or Verilog HDL through synthesis tools This process ensures accurate functional and timing representation of the design.
The characteristics of logic primitives are defined within the cell library, which provides essential parameters for both synthesis tools and simulation processes Additionally, layout tools are employed to position the cells and manage the routing of interconnects.
– Gate array: pre-manufactured silicon masters with a fixed number of cells that provide a common starting point for different components
The functionality of the system is determined by the interconnection matrix, or metal layer, that links the pre-manufactured cells The design process closely resembles that of a cell-based ASIC, with the layout phase being substituted by a routing step to connect the pre-existing cells.
Systems – general aspects
The PE system is designed for control, protection, or monitoring and consists of one or more programmable electronic devices It includes essential components such as power supplies, sensors, input devices, data highways, communication paths, actuators, and output devices.
The structure of a Programmable Electronic System (PES) is depicted in Figure 2 a), while Figure 2 b) demonstrates its representation in the International Standard, highlighting the programmable electronics as a separate unit from the sensors and actuators on the Equipment Under Control (EUC) and their interfaces Notably, the programmable electronics can be located in multiple areas within the PES Figure 2 c) showcases a PES featuring two distinct units of programmable electronics, whereas Figure 2 d) presents a PES with dual programmable electronics (two-channel) that utilizes a single sensor and actuator.
The article discusses the basic structure of Programmable Electronic Systems (PES), highlighting four key configurations First, it describes a single PES system featuring a single programmable electronic device, which consists of one channel of programmable electronics Next, it outlines a single PES element that incorporates dual programmable electronic devices linked serially, such as an intelligent sensor paired with a programmable controller Additionally, it presents a configuration with dual programmable electronic devices that share sensors and final elements, effectively forming a single PES with two channels of programmable electronics.
Output in terfaces D-A converters Extent of E/E/PE system
Programmable Electronics (PE) (see note)
Input devices (fo r example sen sors)
Outp ut devices/final elements (fo r example actuators)
3.3.2 electrical/electronic/programmable electronic system
The E/E/PE system is designed for control, protection, or monitoring, utilizing one or more electrical/electronic programmable electronic devices This system encompasses all components, including power supplies, sensors, input devices, data highways, communication paths, actuators, and output devices.
Input devices (for example sensors)
Output devices/ final elements (for example actuators)
Extent of E/E/PE system E/E/PE device
NOTE THE E/E/PE device is shown centrally located but such device(s) could exist at several places in the E/E/PE system
Figure 3 – Electrical/electronic/programmable electronic system (E/E/PE system) – structure and terminology
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
The EUC control system is designed to respond to input signals from both the process and the operator, generating output signals that ensure the EUC operates as intended.
NOTE The EUC control system includes input devices and final elements
3.3.4 architecture specific configuration of hardware and software elements in a system
3.3.5 software module construct that consists of procedures and/or data declarations and that can also interact with other such constructs
3.3.6 channel element or group of elements that independently implement an element safety function
EXAMPLE A two-channel (or dual-channel) configuration is one with two channels that independently perform the same function
NOTE The term can be used to describe a complete system, or a portion of a system (for example, sensors or final elements)
3.3.7 diversity different means of performing a required function
NOTE Diversity may be achieved by different physical methods or different design approaches.
Systems – safety-related aspects
3.4.1 safety-related system designated system that both
– implements the required safety functions necessary to achieve or maintain a safe state for the EUC; and
– is intended to achieve, on its own or with other E/E/PE safety-related systems and other risk reduction measures, the necessary safety integrity for the required safety functions
Safety-related systems are designed to achieve necessary risk reduction in conjunction with other risk reduction measures, ensuring compliance with the required tolerable risk standards For further details, refer to Annex A of IEC 61508-5.
Safety-related systems are essential for preventing equipment under control (EUC) from entering dangerous states by taking appropriate actions upon detecting potentially hazardous conditions The failure of these systems contributes to events that may lead to identified hazards While other systems may possess safety functions, only safety-related systems are specifically designated to achieve the necessary tolerable risk These systems can be categorized into two main types: safety-related control systems and safety-related protection systems.
Safety-related systems can either be integrated into the EUC control system or connect through sensors and actuators The necessary safety integrity level can be attained by incorporating safety functions within the EUC control system, potentially alongside additional independent systems, or by utilizing separate systems specifically designed for safety functions.
A safety-related system can be designed to either prevent hazardous events by ensuring that safety functions are performed effectively, or to mitigate the effects of harmful events, thereby reducing associated risks and consequences.
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI c) be designed to achieve a combination of a) and b)
A person can play a crucial role in a safety-related system by either receiving information from a programmable electronic device to take appropriate safety actions or by executing safety actions directly through the device itself.
A safety-related system encompasses all essential hardware, software, and supporting services, such as power supplies, required to perform a designated safety function This includes components like sensors, input devices, actuators, and other output devices integral to the system's operation.
NOTE 7 A safety-related system may be based on a wide range of technologies including electrical, electronic, programmable electronic, hydraulic and pneumatic
3.4.2 other risk reduction measure measure to reduce or mitigate risk that is separate and distinct from, and does not use, E/E/PE safety-related systems
EXAMPLE A relief valve is an other risk reduction measure
3.4.3 low complexity E/E/PE safety-related system
E/E/PE safety-related system (see 3.2.13 and 3.4.1), in which
– the failure modes of each individual component are well defined;
– the behaviour of the system under fault conditions can be completely determined
NOTE Behaviour of the system under fault conditions may be determined by analytical and/or test methods
A low-complexity E/E/PE safety-related system consists of one or more limit switches that may operate through electro-mechanical relays to control contactors, ultimately de-energizing an electric motor.
3.4.4 subsystem entity of the top-level architectural design of a safety-related system where a dangerous failure according to 3.6.7 (a) of the subsystem results in dangerous failure of a safety function according to 3.6.7 (a)
3.4.5 element part of a subsystem comprising a single component or any group of components that performs one or more element safety functions
NOTE 1 An element may comprise hardware and/or software
NOTE 2 A typical element is a sensor, programmable controller or final element
3.4.6 redundancy the existence of more than one means for performing a required function or for representing information
EXAMPLE Duplicated functional components and the addition of parity bits are both instances of redundancy
Redundancy is mainly employed to enhance reliability, which refers to the likelihood of proper functioning over a specified duration, and availability, indicating the probability of functioning at a particular moment Additionally, it can help reduce erroneous actions through architectures like 2oo3.
NOTE 2 The definition in IEV 191-15-01 is less complete
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
Redundancy can be categorized into three types: "hot" or "active," where all redundant items operate simultaneously; "cold" or "stand-by," where only one redundant item is active at a time; and "mixed," which involves some items running while others remain in stand-by mode.
Safety functions and safety integrity
A safety function is a critical component of an E/E/PE safety-related system or other risk reduction measures, designed to achieve or maintain a safe state for the equipment under control (EUC) in relation to specific hazardous events.
EXAMPLE Examples of safety functions include:
– functions that are required to be carried out as positive actions to avoid hazardous situations (for example switching off a motor); and
– functions that prevent actions being taken (for example preventing a motor starting)
3.5.2 overall safety function means of achieving or maintaining a safe state for the EUC, in respect of a specific hazardous event
3.5.3 element safety function that part of a safety function (see 3.5.1) which is implemented by an element
3.5.4 safety integrity probability of an E/E/PE safety-related system satisfactorily performing the specified safety functions under all the stated conditions within a stated period of time
A higher level of safety integrity significantly reduces the likelihood of failure in safety-related systems, ensuring they effectively perform designated safety functions or achieve a required state when necessary.
NOTE 2 There are four levels of safety integrity (see 3.5.8)
In assessing safety integrity, it is essential to account for all failure causes, including random hardware failures, systematic failures, software-induced failures, and those arising from electrical interference While some failures, particularly random hardware failures, can be quantified through metrics like the average frequency of dangerous mode failures or the probability of a safety system failing to activate when needed, safety integrity is also influenced by numerous qualitative factors that resist precise measurement.
NOTE 4 Safety integrity comprises hardware safety integrity (see 3.5.7) and systematic safety integrity (see 3.5.6)
NOTE 5 This definition focuses on the reliability of the safety-related systems to perform the safety functions (see IEV 191-12-01 for a definition of reliability)
3.5.5 software safety integrity part of the safety integrity of a safety-related system relating to systematic failures in a dangerous mode of failure that are attributable to software
3.5.6 systematic safety integrity part of the safety integrity of a safety-related system relating to systematic failures in a dangerous mode of failure
NOTE Systematic safety integrity cannot usually be quantified (as distinct from hardware safety integrity which usually can)
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
3.5.7 hardware safety integrity part of the safety integrity of a safety-related system relating to random hardware failures in a dangerous mode of failure
The term refers to failures in a dangerous mode, specifically those that compromise the safety integrity of a safety-related system Key parameters in this context include the average frequency of dangerous failures and the probability of failure to operate on demand The average frequency is crucial for maintaining continuous safety control, while the probability of failure is significant for safety-related protection systems.
Safety Integrity Levels (SIL) are categorized into four discrete levels, with Safety Integrity Level 4 representing the highest safety integrity and Safety Integrity Level 1 indicating the lowest.
NOTE 1 The target failure measures (see 3.5.17) for the four safety integrity levels are specified in Tables 2 and 3 of IEC 61508-1
NOTE 2 Safety integrity levels are used for specifying the safety integrity requirements of the safety functions to be allocated to the E/E/PE safety-related systems
A safety integrity level (SIL) is not an inherent characteristic of a system, subsystem, element, or component Instead, the term “SIL n safety-related system” (where n represents 1, 2, 3, or 4) indicates that the system has the potential to support safety functions with a safety integrity level of up to n.
The systematic capability measure, ranging from SC 1 to SC 4, assesses the confidence that the systematic safety integrity of an element fulfills the requirements of the designated Safety Integrity Level (SIL) This evaluation pertains to the specific safety function of the element when it is utilized according to the guidelines outlined in the compliant item safety manual.
NOTE 1 Systematic capability is determined with reference to the requirements for the avoidance and control of systematic faults (see IEC 61508-2 and IEC 61508-3)
The relevant systematic failure mechanism varies based on the element's nature For elements consisting solely of software, only software failure mechanisms are relevant In contrast, for elements that include both hardware and software, it is essential to consider both systematic hardware and software failure mechanisms.
A systematic capability of SC N for an element indicates that the systematic safety integrity of SIL N is achieved when the element is used according to the guidelines outlined in the compliant item safety manual.
3.5.10 software safety integrity level systematic capability of a software element that forms part of a subsystem of a safety-related system
The Safety Integrity Level (SIL) defines the overall safety function but does not apply to individual subsystems or components that contribute to that function Software, like any other element, does not possess a SIL on its own However, the term "SIL N software" is used to refer to software that has justified confidence, rated on a scale from 1 to 4, indicating that its safety function will not fail due to relevant systematic failure mechanisms when used according to the guidelines in the compliant item safety manual.
E/E/PE system safety requirements specification specification containing the requirements for the safety functions and their associated safety integrity levels
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
E/E/PE system safety functions requirements specification specification containing the requirements for the safety functions that have to be performed by the safety-related systems
This specification outlines the safety functions required for the E/E/PE system, as detailed in sections 7.10 and 7.10.2.6 of IEC 61508-1 It provides specific information on the safety functions that safety-related systems must execute.
NOTE 2 Specifications may be documented in text, flow diagrams, matrices, logic diagrams, etc., providing that the safety functions are clearly conveyed
E/E/PE system safety integrity requirements specification specification containing the safety integrity requirements of the safety functions that have to be performed by the safety-related systems
NOTE This specification is one part (the safety integrity part) of the E/E/PE system safety requirements specification (see 7.10 and 7.10.2.7 of IEC 61508-1)
E/E/PE system design requirements specification specification containing the design requirements for the E/E/PE safety-related system in terms of the subsystems and elements
3.5.15 safety-related software software that is used to implement safety functions in a safety-related system
3.5.16 mode of operation way in which a safety function operates, which may be either
In low demand mode, the safety function is activated solely upon request to transition the Equipment Under Control (EUC) into a designated safe state, with the frequency of such requests not exceeding one per year.
The E/E/PE safety-related system typically does not affect the Equipment Under Control (EUC) or its control system until a demand for safety arises However, if this safety-related system fails and cannot perform its safety function, it may lead the EUC to transition to a safe state, as outlined in section 7.4.6 of IEC 61508-2.
In high demand mode, the safety function is activated solely upon request to transition the equipment under control (EUC) into a designated safe state, with the frequency of such demands exceeding one per year.
– continuous mode: where the safety function retains the EUC in a safe state as part of normal operation
3.5.17 target failure measure target probability of dangerous mode failures to be achieved in respect of the safety integrity requirements, specified in terms of either
– the average probability of a dangerous failure of the safety function on demand, (for a low demand mode of operation);
– the average frequency of a dangerous failure [h -1 ] (for a high demand mode of operation or a continuous mode of operation)
NOTE The numerical values for the target failure measures are given in Tables 2 and 3 of IEC 61508-1
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
Effective risk reduction is essential to ensure that the tolerable risk levels are not surpassed This can be achieved through the implementation of E/E/PE safety-related systems and other risk reduction measures.
Fault, failure and error (see Figure 4)
3.6.1 fault abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function
According to NOTE IEV 191-05-01, a "fault" is defined as a condition where a required function cannot be performed, excluding instances that occur during preventative maintenance, planned actions, or due to insufficient external resources For a visual representation of these concepts, refer to Figure 4.
3.6.2 fault avoidance use of techniques and procedures that aim to avoid the introduction of faults during any phase of the safety lifecycle of the safety-related system
3.6.3 fault tolerance ability of a functional unit to continue to perform a required function in the presence of faults or errors
NOTE The definition in IEV 191-15-05 refers only to sub-item faults See the Note for the term “fault” in 3.6.1
3.6.4 failure termination of the ability of a functional unit to provide a required function or operation of a functional unit in any way other than as required
NOTE 1 This is based on IEV 191-04-01 with changes to include systematic failures due to, for example, deficiencies in specification or software
NOTE 2 See Figure 4 for the relationship between faults and failures, both in the IEC 61508 series and IEC 60050-191
NOTE 3 Performance of required functions necessarily excludes certain behaviour, and some functions may be specified in terms of behaviour to be avoided The occurrence of such behaviour is a failure
NOTE 4 Failures are either random (in hardware) or systematic (in hardware or software), see 3.6.5 and 3.6.6
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI a) Configuration of a functional unit
(L = level; i = 1, 2, 3 etc.; FU = functional unit) cause cause Failure
"Entity X" c) From the point of view of IEC 61508 and ISO/IEC 2382-14
"Entity X" d) From the point of view of IEC 60050(191)
A functional unit can be understood as a hierarchical structure composed of multiple levels, where each level can also be considered a functional unit At level (i), a "cause" may appear as an error, representing a deviation from the correct value or state If this error is not addressed, it can lead to the failure of the level (i) functional unit, resulting in an "F" state where it can no longer perform its required function This failure can subsequently manifest as an error in the level (i-1) functional unit, potentially causing its failure if not corrected.
In the cause and effect chain, "Entity X" represents both a state ("F" state) of the level (i) functional unit due to its failure and the cause of the failure in the level (i-1) functional unit This concept merges the definition of "fault" from IEC 61508 and ISO/IEC 2382-14, which focuses on its causative aspect, with the definition from IEC 60050-191, which highlights its state aspect While the "F" state is referred to as a fault in IEC 60050-191, it is not explicitly defined in the IEC 61508 series or ISO/IEC 2382-14.
External events like lightning or electrostatic noise can sometimes cause failures or errors, rather than internal faults Additionally, a fault, such as a design flaw, can exist without any prior failure occurring.
3.6.5 random hardware failure failure, occurring at a random time, which results from one or more of the possible degradation mechanisms in the hardware
Various degradation mechanisms affect components at different rates, leading to failures that occur at predictable rates but at random times due to manufacturing tolerances.
A key difference between random hardware failures and systematic failures is that the failure rates from random hardware issues can be predicted with reasonable accuracy, while systematic failures cannot be accurately forecasted This means that while random hardware failures allow for quantifiable system failure rates, systematic failures remain unpredictable and cannot be statistically quantified due to the nature of the events that lead to them.
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
Systematic failure is a type of failure that is deterministically linked to a specific cause To eliminate this failure, it is necessary to modify the design, manufacturing process, operational procedures, documentation, or other relevant factors.
NOTE 1 Corrective maintenance without modification will usually not eliminate the failure cause
NOTE 2 A systematic failure can be induced by simulating the failure cause
NOTE 3 Examples of causes of systematic failures include human error in
– the design, manufacture, installation, operation of the hardware;
– the design, implementation, etc of the software
NOTE 4 In this standard, failures in a safety-related system are categorized as random hardware failures (see 3.6.5) or systematic failures
A dangerous failure occurs when an element, subsystem, or system essential for executing a safety function either fails to operate when needed (demand mode) or malfunctions during continuous operation, leading to the equipment under control (EUC) being in a hazardous or potentially hazardous state Additionally, such failures reduce the likelihood of the safety function performing correctly when necessary.
Safe failure refers to the failure of an element, subsystem, or system involved in executing a safety function This failure can lead to either a spurious operation that places the equipment under control (EUC) into a safe state or maintains that safe state, or it may increase the likelihood of such spurious operations occurring.
3.6.9 dependent failure failure whose probability cannot be expressed as the simple product of the unconditional probabilities of the individual events that caused it
NOTE Two events A and B are dependent, only if: P(A and B) > P(A) × P(B)
Common cause failure occurs when one or more events lead to simultaneous failures in two or more separate channels within a multiple channel system, ultimately resulting in system failure.
3.6.11 error discrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
3.6.12 soft-error erroneous changes to data content but no changes to the physical circuit itself
NOTE 1 When a soft error has occurred and the data is rewritten, the circuit will be restored to its original state
Soft errors can arise in various components such as memory, digital logic, analog circuits, and transmission lines, with a significant prevalence in semiconductor memory, including registers and latches Information regarding these errors can often be sourced from manufacturers.
NOTE 3 Soft errors are transient and should not be confused with software programming errors
3.6.13 no part failure failure of a component that plays no part in implementing the safety function
NOTE The no part failure is not used for SFF calculations
3.6.14 no effect failure failure of an element that plays a part in implementing the safety function but has no direct effect on the safety function
NOTE 1 The no effect failure has by definition no effect on the safety function so it cannot contribute to the failure rate of the safety function
NOTE 2 The no effect failure is not used for SFF calculations
The Safety Function Failure (SFF) property of a safety-related element is defined by the ratio of the average failure rates of safe plus dangerous detected failures to safe plus dangerous failures This relationship can be expressed mathematically through a specific equation.
SFF = (ΣλS avg + ΣλDd avg)/(ΣλS avg + ΣλDd avg+ ΣλDu avg ) when the failure rates are based on constant failure rates the equation can be simplified to: SFF = (ΣλS + ΣλDd)/(ΣλS + ΣλDd + ΣλDu)
The reliability parameter, denoted as \$\lambda(t)\$, represents the failure rate of an entity, whether it be a single component or an entire system The expression \$\lambda(t) \cdot dt\$ quantifies the probability of failure occurring within the interval \([t, t+dt]\), given that the entity has not experienced any failures from time \([0, t]\).
The conditional probability of failure per unit of time, denoted as λ(t), is mathematically defined over the interval [t, t+dt] This concept is closely linked to the reliability function, which represents the probability of no failure occurring from time 0 to time t, as expressed by a general formula.
( λ τ τ Reversely it is defined from the reliability function by
Failure rates and their uncertainties can be assessed through field feedback utilizing conventional statistics Throughout the "useful life" of a simple item, which is defined as the period after burn-in and before wear-out, the failure rate remains relatively constant, denoted as \$\lambda(t) \equiv \lambda\$.
NOTE 3 The average of λ(t) over a given period [0, T], T d T
Lifecycle activities
The safety lifecycle encompasses essential activities for implementing safety-related systems, beginning at the project's concept phase and concluding when all E/E/PE safety-related systems and other risk reduction measures are no longer in use.
NOTE 1 The term “functional safety lifecycle” is more accurate, but the adjective “functional” is not considered necessary in this case within the context of this standard
NOTE 2 The safety lifecycle models used in this standard are specified in Figures 2, 3 and 4 of IEC 61508-1
3.7.2 software lifecycle activities occurring during a period of time that starts when software is conceived and ends when the software is permanently decommissioned
NOTE 1 A software lifecycle typically includes a requirements phase, development phase, test phase, integration phase, installation phase and a modification phase
NOTE 2 Software is not capable of being maintained; rather, it is modified
3.7.3 configuration management discipline of identifying the components of an evolving system for the purposes of controlling changes to those components and maintaining continuity and traceability throughout the lifecycle
NOTE For details on software configuration management see C.5.24 of IEC 61508-7
A configuration baseline is essential for systematically and audibly recreating a software release It includes all necessary components such as source code, data, runtime files, documentation, configuration files, and installation scripts Additionally, it encompasses details about the compilers, operating systems, and development tools utilized in the software's creation.
Impact analysis involves assessing how changes to a function or component within a system affect other functions or components, as well as their influence on external systems.
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
NOTE In the context of software, see C.5.23 of IEC 61508-7.
Confirmation of safety measures
3.8.1 verification confirmation by examination and provision of objective evidence that the requirements have been fulfilled
Verification, as defined by this standard, involves demonstrating through analysis, mathematical reasoning, and testing that the outputs of each phase of the safety lifecycle—encompassing the overall system, E/E/PE system, and software—align with the established objectives and requirements for that specific phase, based on the given inputs.
Reviews of outputs from all phases of the safety lifecycle are essential to ensure compliance with the objectives and requirements of each phase, while also considering the specific inputs relevant to that phase.
– tests performed on the designed products to ensure that they perform according to their specification;
Integration tests involve systematically assembling various components of a system and conducting environmental tests to verify that all parts function together as intended.
3.8.2 validation confirmation by examination and provision of objective evidence that the particular require- ments for a specific intended use are fulfilled
NOTE 1 In this standard there are three validation phases:
– overall safety validation (see Figure 2 of IEC 61508-1);
– E/E/PE system validation (see Figure 3 of IEC 61508-1);
– software validation (see Figure 4 of IEC 61508-1)
Validation is the process of ensuring that a safety-related system meets all safety requirements specifications, whether before or after installation Specifically, software validation involves confirming through examination and objective evidence that the software complies with its safety requirements.
3.8.3 functional safety assessment investigation, based on evidence, to judge the functional safety achieved by one or more E/E/PE safety-related systems and/or other risk reduction measures
A functional safety audit is a systematic and independent examination that assesses whether the procedures related to functional safety requirements are effectively implemented and aligned with the planned arrangements to achieve the specified objectives.
NOTE A functional safety audit may be carried out as part of a functional safety assessment
A proof test is a periodic assessment conducted to identify potentially dangerous hidden failures within a safety-related system This testing ensures that, if needed, repairs can be made to restore the system to an "as new" condition or as close to it as possible.
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
NOTE 1 In this standard the term “proof test” is used but it is recognised that a synonymous term is “periodical test”
The effectiveness of proof tests relies on both failure coverage and repair effectiveness, making it challenging to detect 100% of hidden dangerous failures, especially in complex E/E/PE safety-related systems While achieving this target is ideal, it is essential to verify that all executed safety functions comply with the E/E/EP system safety requirements specification When separate channels are utilized, tests must be conducted for each channel individually For complex components, a thorough analysis may be necessary to ensure that the probability of undetected hidden dangerous failures remains negligible throughout the entire lifespan of the E/E/EP safety-related system.
A proof test requires a certain amount of time to complete, during which the E/E/PE safety-related system may be partially or fully inhibited The duration of the proof test can be disregarded only if the tested portion of the E/E/PE safety-related system remains operational in case of a demand or if the equipment under control (EUC) is shut down during the test.
During a proof test, the E/E/PE safety-related system may be partially or fully unavailable to respond to operational demands The Mean Time to Repair (MTTR) can be disregarded in Safety Integrity Level (SIL) calculations only if the Equipment Under Control (EUC) is shut down during repairs or if alternative risk measures of equivalent effectiveness are implemented.
The DC fraction represents the proportion of dangerous failures identified through automatic online diagnostic tests It is calculated by dividing the rate of detected dangerous failures by the overall rate of dangerous failures.
The dangerous failure diagnostic coverage (DC) is calculated using the equation that relates the detected dangerous failure rate (\(\lambda_{DD}\)) to the total dangerous failure rate (\(\lambda_{D \, total}\)).
NOTE 2 This definition is applicable providing the individual components have constant failure rates
3.8.7 diagnostic test interval interval between on-line tests to detect faults in a safety-related system that has a specified diagnostic coverage
3.8.8 detected revealed overt in relation to hardware, detected by the diagnostic tests, proof tests, operator intervention (for example physical inspection and manual tests), or through normal operation
EXAMPLE These adjectives are used in detected fault and detected failure
NOTE A dangerous failure detected by diagnostic test is a revealed failure and can be considered a safe failure only if effective measures, automatic of manual, are taken
3.8.9 undetected unrevealed covert in relation to hardware, undetected by the diagnostic tests, proof tests, operator intervention (for example physical inspection and manual tests), or through normal operation
EXAMPLE These adjectives are used in undetected fault and undetected failure
Licensed Copy: Science & Technology Facilities Council, 25/08/2010 10:14, Uncontrolled Copy, (c) BSI
An assessor is an individual or organization responsible for conducting functional safety assessments to evaluate the functional safety of electrical, electronic, and programmable electronic safety-related systems, as well as other risk reduction measures.
NOTE See also Clause 8 of IEC 61508-1
An independent person is defined as an individual who is separate and distinct from the activities occurring during a specific phase of the overall E/E/PE system or software safety lifecycle This person is not directly responsible for the activities being assessed or validated in the functional safety process.
An independent department is defined as a distinct entity that operates separately from the departments overseeing activities during a specific phase of the overall E/E/PE system or software safety lifecycle This department is specifically responsible for conducting functional safety assessments or validations.
An independent organization is defined as a separate entity, distinct in its management and resources, from the organizations responsible for activities during a specific phase of the overall E/E/PE system or software safety lifecycle This independence is crucial for conducting functional safety assessments or validations effectively.