As promised in previous posts, here is the complete reference list for the series “How to do a 13849–1 analysis”! If you have any additional resources you think readers would find helpful, please add them in the comments.
Book List
Here are some books that I think you may find helpful on this journey:
[0.2] Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. Included in the last post of the series is the complete reference list.
[18] M. Gentile and A. E. Summers, “Common Cause Failure: How Do You Manage Them?,” Process Saf. Prog., vol. 25, no. 4, pp. 331–338, 2006.
[19] Out of Control—Why control systems go wrong and how to prevent failure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.
Original content here is published under these license terms:
X
License Type:
Non-commercial, Attribution, Share Alike
License Summary:
You may copy this content, create derivative work from it, and re-publish it for non-commercial purposes, provided you include an overt attribution to the author(s) and the re-publication must itself be under the terms of this license or similar.
ISO 13849–1, Chapter 7 [1, 7] discusses the need for fault consideration and fault exclusion. Fault consideration is the process of examining the components and sub-systems used in the safety-related part of the control system (SRP/CS) and making a list of all the faults that could occur in each one. This a definitely non-trivial exercise!
Thinking back to some of the earlier articles in this series where I mentioned the different types of faults, you may recall that there are detectable and undetectable faults, and there are safe and dangerous faults, leading us to four kinds of fault:
Safe undetectable faults
Dangerous undetectable faults
Safe detectable faults
Dangerous detectable faults
For systems where no diagnostics are used, Category B and 1, faults need to be eliminated using inherently safe design techniques. Care needs to be taken when classifying components as “well-tried” versus using a fault exclusion, as components that might normally be considered “well-tried” might not meet those requirements in every application. [2, Annex A], Validation tools for mechanical systems, discusses the concepts of “Basic Safety Principles”, “Well-Tried Safety Principles”, and “Well-tried components”. [2, Annex A] also provides examples of faults and relevant fault exclusion criteria. There are similar Annexes that cover pneumatic systems [2, Annex B], hydraulic systems [2, Annex C], and electrical systems [2, Annex D].
For systems where diagnostics are part of the design, i.e., Category 2, 3, and 4, the fault lists are used to evaluate the diagnostic coverage (DC) of the test systems. Depending on the architecture, certain levels of DC are required to meet the relevant PL, see [1, Fig. 5]. The fault lists are starting point for the determination of DC, and are an input into the hardware and software designs. All of the dangerous detectable faults must be covered by the diagnostics, and the DC must be high enough to meet the PLr for the safety function.
The fault lists and fault exclusions are used in the Validation portion of this process as well. At the start of the Validation process flowchart [2, Fig. 1], you can see how the fault lists and the criteria used for fault exclusion are used as inputs to the validation plan.
Start of ISO 13849–2 Fig. 1
Faults that can be excluded do not need to validated, saving time and effort during the system verification and validation (V & V). How is this done?
Fault Consideration
The first step is to develop a list of potential faults that could occur, based on the components and subsystems included in SRP/CS. ISO 13849–2 [2] includes lists of typical faults for various technologies. For example, [2, Table A.4] is the fault list for mechanical components.
As you can see, there are many different types of faults that need to be considered. Keep in mind that I did not give you all of the different fault lists — this post would be a mile long if I did that! The point is that you need to develop a fault list for your system, and then consider the impact of each fault on the operation of the system. If you have components or subsystems that are not listed in the tables, then you need to develop your own fault lists for those items. Failure Modes and Effects Analysis (FMEA) is usually the best approach for developing fault lists for these components [23], [24].
When considering the faults to be included in the list there are a few things that should be considered [1, 7.2]:
if after the first fault occurs other faults develop due to the first fault, then you can group those faults together as a single fault
two or more single faults with a common cause can be considered as a single fault
multiple faults with different causes but occurring simultaneously is considered improbable and does not need to be considered
Examples
#1 — Voltage Regulator
A voltage regulator fails in a system power supply so that the 24 Vdc output rises to an unregulated 36 Vdc (the internal power supply bus voltage), and after some time has passed, two sensors fail. All three failures can be grouped and considered as a single fault because they originate in a single failure in the voltage regulator.
#2 — Lightning Strike
If a lightning strike occurs on the power line and the resulting surge voltage on the 400 V mains causes an interposing contactor and the motor drive it controls to fail to danger, then these failures may be grouped and considered as one. Again, a single event causes all of the subsequent failures.
#3 — Pneumatic System Lubrication
3a — A pneumatic lubricator runs out of lubricant and is not refilled, depriving downstream pneumatic components of lubrication.
3b — The spool on the system dump valve sticks open because it is not cycled often enough.
Neither of these failures has the same cause, so there is no need to consider them as occurring simultaneously because the probability of both happening concurrently is extremely small. One caution: These two faults MAY have a common cause — poor maintenance. If this is true and you decide to consider them to be two faults with a common cause, they could then be grouped as a single fault.
Fault Exclusion
Once you have your well-considered fault lists together, the next question is “Can any of the listed faults be excluded?” This is a tricky question! There are a few points to consider:
Does the system architecture allow for fault exclusion?
Is the fault technically improbable, even if it is possible?
Does experience show that the fault is unlikely to occur?*
Are there technical requirements related to the application and the hazard that might support fault exclusion?
* BECAREFUL with this one!
Whenever faults are excluded, a detailed justification for the exclusion needs to be included in the system design documentation. Simply deciding that the fault can be excluded is NOTENOUGH! Consider the risk a person will be exposed to in the event the fault occurs. If the severity is very high, i.e., severe permanent injury or death, you may not want to exclude the fault even if you think you could. Careful consideration of the resulting injury scenario is needed.
Basing a fault exclusion on personal experience is seldom considered adequate, which is why I added the asterisk (*) above. Look for good statistical data to support any decision to use a fault exclusion.
There is much more information available in IEC 61508–2 on the subject of fault exclusion, and there is good information in some of the books mentioned below [0.1], [0.2], and [0.3]. If you know of additional resources you would like to share, please post the information in the comments!
Definitions
3.1.3 fault
state of an item characterized by the inability to perform a required function, excluding the inability during preventive maintenance or other planned actions, or due to lack of external resources
Note 1 to entry: A fault is often the result of a failure of the item itself, but may exist without prior failure.
Note 2 to entry: In this part of ISO 13849, “fault” means random fault. [SOURCE: IEC 60050?191:1990, 05–01.]
Book List
Here are some books that I think you may find helpful on this journey:
[0.2] Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. Included in the last post of the series is the complete reference list.
[18] M. Gentile and A. E. Summers, “Common Cause Failure: How Do You Manage Them?,” Process Saf. Prog., vol. 25, no. 4, pp. 331–338, 2006.
[19] Out of Control—Why control systems go wrong and how to prevent failure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.
Original content here is published under these license terms:
X
License Type:
Non-commercial, Attribution, Share Alike
License Summary:
You may copy this content, create derivative work from it, and re-publish it for non-commercial purposes, provided you include an overt attribution to the author(s) and the re-publication must itself be under the terms of this license or similar.
Up to this point, I have been discussing the basic processes used for the design of safety-related parts of control systems. The underlying assumption is that these techniques apply to the design of hardware used for safety purposes. The remaining question focuses on the design and development of safety-related software that runs on that hardware. If you have not read the rest of this series and would like to catch up first, you can find it here.
In this discussion of safety-related software, keep in mind that I am talking about software that is only intended to reduce risk. Some platforms that are not well suited for safety software, primarily common off-the-shelf (COTS) operating systems like Windows, MacOS and Linux. Generally speaking, these operating systems are too complex and subject to unanticipated changes to be suitable for high-reliability applications. There is nothing wrong with using these systems for annunciation and monitoring functions, but the safety functions should run on more predictable platforms.
The methodology discussed in ISO 13849–1 is usable up to PLd. At the end of the Scope we find Note 4:
NOTE 4 For safety-related embedded software for components with PLr = e, see IEC 61508–3:1998, Clause 7.
As you can see, for very high-reliability systems, i.e., PLe/SIL3 or SIL4, it is necessary to move to IEC 61508. The methods discussed here are based on ISO 13849–1:2015, Chapter 4.6.
Goals
There are two goals for safety-related software development activities:
Avoid faults
Generate readable, understandable, testable and maintainable software
Avoiding Faults
Fig. 1 [1, Fig. 6] shows the “V-model” for software development. This approach to software design incorporates both validation and verification, and when correctly implemented will result in software that meets the design specifications.
If you aren’t sure what the difference is between verification and validation, I remember it is this way: Validation means “Are we building the right thing?”, and verification means “Did we build the thing right?” The whole process hinges on the Safety Requirement Specification (SRS), so failing to get that part of the process right in the beginning will negatively impact both hardware and software design. The SRS is the yardstick used to decide if you built the right thing. Without that, you are clueless about what you are building.
Figure 1 — Simplified V-model of software safety lifecycle
Coming in from the Safety Requirement Specification (also called the safety function specification), each step in the process is shown. The dashed lines illustrate the verification process at each step. Notice that the actual coding step is at the bottom of the V-model. Everything above the coding stage is either planning and design, or quality assurance activities.
There are other methods that can be used to result in verified and validated software, so if you have a QA process that produces solid results, you may not need to change it. I would recommend that you review all the stages in the V-model to ensure that your QA system has similar processes.
To make setting up safety systems simpler for designers and integrators, there are two approaches to software design that can be used.
Two Approaches to Software Design
There are two approaches to software design that should be considered:
The preconfigured building-block approach is typically used for configuring safety PLCs or programmable safety relays or modules. This type of software is referred to as “safety-related embedded software (SRESW)” in [1].
Pre-written function blocks are provided by the device manufacturer. Each function block has a particular role: emergency stop, safety gate input, zero-speed detection, and so on. When configuring a safety PLC or safety modules that use this approach, the designer selects the appropriate block and then configures the inputs, outputs, and any other functional characteristics that are needed. The designer has no access to the safety-related code, so apart from configuration errors, no other errors can be introduced. The function blocks are verified and validated (V & V) by the controls component manufacturer, usually with the support of an accredited certification body. The function blocks will normally have a PL associated with them, and a statement like “suitable for PLe” will be made in the function block description.
This approach eliminates the need to do a detailed V & V of the code by the designing entity (i.e., the machine builder). However, the machine builder is still required to do a V & V on the operation of the system as they have configured it. The machine V & V includes all the usual fault injection tests and functional tests to ensure that the system will behave in as intended in the presence of a demand on the safety function or a fault condition. The faults that should be tested are those in your Fault List. If you don’t have a fault list or don’t know what a Fault List is, see Part 8 in this series.
Using pre-configured building blocks achieves the first goal, fault avoidance, at least as far as the software coding is concerned. The configuration software will validate the function block configurations before compiling the software for upload to the safety controller so that most configuration errors will be caught at that stage.
This approach also facilitates the second goal, as long as the configuration software is usable and maintained by the software vendor. The configuration software usually includes the ability to annotate the configurations with relevant details to assist with the readability and understandability of the software.
Fully Customised Software
This approach is used where a fully customised hardware platform is being used, and the safety software is designed to run on that platform. [1] refers to this type of software as “Safety-related application software (SRASW).” A fully customised software application is used where a very specialised safety system is contemplated, and FPGAs or other customised hardware is being used. These systems are usually programmed using full-variability languages.
In this case, the full hardware and software V & V approach must be employed. In my opinion, ISO 13849–1 is probably not the best choice for this approach due to its simplification, and I would usually recommend using IEC 61508–3 as the basis for the design, verification, and validation of fully customised software.
Process requirements
Safety-Related Embedded Software (SRESW)
[1, 4.6.2] provides a laundry list of elements that must be incorporated into the V-model processes when developing SRESW, broken down by PLa through PLd, and then some additional requirements for PLc and PLd.
If you are designing SRESW for PLe, [1, 4.6.2] points you directly to IEC 61508–3, clause 7, which covers software suitable for SIL3 applications.
Safety-Related Application Software (SRASW)
[1, 4.6.3] provides a list of requirements that must be met through the v-model process for SRASW, and allows that PLa through PLe can be met by code written in LVL and that PLe applications can also be designed using FVL. In cases where software is developed using FVL, the software can be treated as the embedded software products (SRESW) are handled.
A similar architectural model to that used for single-channel hardware development is used, as shown in Fig. 2 [1, Fig 7].
Figure 2 — General architecture model of software
The complete V-model must be applied to safety-related application software, with all of the additional requirements from [1, 4.6.3] included in the process model.
Conclusions
There is a lot to safety-related software development, certainly much more than could be discussed in a blog post like this or even in a standard like ISO 13849–1. If you are contemplating developing safety related software and you are not familiar with the techniques needed to develop this kind of high-reliability software, I would suggest you get help from a qualified developer. Keep in mind that there can be significant liability attached to safety system failures, including the deaths of people using your product. If you are developing SRASW, I would also recommend following IEC 61508–3 as the basis for the development and related QA processes.
Definitions
3.1.36 application software
software specific to the application, implemented by the machine manufacturer, and generally containing logic sequences, limits and expressions that control the appropriate inputs, outputs, calculations and decisions necessary to meet the SRP/CS requirements 3.1.37 embedded software firmware system software software that is part of the system supplied by the control manufacturer and which is not accessible for modification by the user of the machinery Note 1 to entry: Embedded software is usually written in FVL.
Note 1 to entry: Embedded software is usually written in FVL.
3.1.34 limited variability language LVL
type of language that provides the capability of combining predefined, application-specific library functions to implement the safety requirements specifications
Note 1 to entry: Typical examples of LVL (ladder logic, function block diagram) are given in IEC 61131–3.
Note 2 to entry: A typical example of a system using LVL: PLC. [SOURCE: IEC 61511–1:2003, 3.2.80.1.2, modified.]
3.1.35 full variability language FVL
type of language that provides the capability of implementing a wide variety of functions and applications EXAMPLE C, C++, Assembler.
Note 1 to entry: A typical example of systems using FVL: embedded systems.
Note 2 to entry: In the field of machinery, FVL is found in embedded software and rarely in application software. [SOURCE: IEC 61511–1:2003, 3.2.80.1.3, modified.]
3.1.37 embedded software
firmware
system software
software that is part of the system supplied by the control manufacturer and which is not accessible for modification by the user of the machinery.
Note 1 to entry: Embedded software is usually written in FVL.
Field Programmable Gate Array FPGA
A field-programmable gate array (FPGA) is an integrated circuit designed to be configured by a customer or a designer after manufacturing – hence “field-programmable”. The FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC). [22]
Book List
Here are some books that I think you may find helpful on this journey:
[0.2] Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.
Note: This reference list starts in Part 1 of the series, so “missing” references may show in other parts of the series. Included in the last post of the series is the complete reference list.
[18] M. Gentile and A. E. Summers, “Common Cause Failure: How Do You Manage Them?,” Process Saf. Prog., vol. 25, no. 4, pp. 331–338, 2006.
[19] Out of Control—Why control systems go wrong and how to prevent failure, 2nd ed. Richmond, Surrey, UK: HSE Health and Safety Executive, 2003.
Original content here is published under these license terms:
X
License Type:
Non-commercial, Attribution, Share Alike
License Summary:
You may copy this content, create derivative work from it, and re-publish it for non-commercial purposes, provided you include an overt attribution to the author(s) and the re-publication must itself be under the terms of this license or similar.
As promised in previous posts, here is the complete reference list for the series “How to do a 13849–1 analysis”! If you have any additional resources you think readers would find helpful, please add them in the comments.
