Functional safety, Part 3 of 7. IEC 61508: Systematic randomness or random systematicity?

A whole hub is dedicated to security on Habré, and perhaps no one really thinks about what is embedded in the concept of security, and so everything is clear: information security. However, there is another side to safety, the safety associated with risks to human health and life, as well as the environment. Since information technologies themselves do not pose a danger, they usually speak of a functional component, that is, of security associated with the proper functioning of a computer system. If information security has become critical with the advent of the Internet, then functional security has been considered before the advent of digital control, because accidents have always occurred.



This article continues the series of publications on functional safety.



The description of a rather complicated terminological casuistry took an entire article , and now it’s time to understand the structure of IEC 61508 requirements.

')

It is not recommended to read to those who are not interested in standardization.

How to understand the structure of IEC 61508 requirements?

So, let's take another look at the structure and interconnections between all seven parts of IEC 61508 (this is a repetition of the picture from part 2 of the publication). What is important for us now is that the requirements are directly contained in the first three parts, while the remaining four parts are for reference only.





Figure 1. Overall framework of the IEC 61508 series (IEC 61508, Figure 1)



Let's think, on the basis of what can we analyze the requirements in order to put them "on the shelves"? Need a classification (taxonomy), and where to get it? First you can look at the content of the standard.



Indeed, parts of IEC 61508-1,2,3 have a typical content, since in all three parts:



- Section 5 sets out documentation requirements;

- Section 6 provides requirements for the management of functional safety;

- Section 7 describes the structure of the life cycle;

- Section 8 sets out the requirements for functional safety assessment.



However, just a simple look at the content of the standards is not enough to systematize their requirements. It is necessary to remember that functional safety, and with it the level of safety completeness, which we need to achieve, depends on the presence or absence of two types of failures:



1) random hardware failures for which the likelihood of occurrence can be determined;

2) systematic failures caused by design errors.



To denote the ability to resist the first and second, special terms are introduced: Random Capability & Systematic Capability (resistance to random and systematic failures). With regard to Random Capability, it is clear that the system must be protected from accidental failures (for example, by methods of redundancy, resistance to interference and other extreme influences, etc.). Systematic Capability depends on both the implementation of development processes and the mechanisms for protection against failures, and includes:



- functional safety management;

- implementation of the functional safety life cycle (Functional Safety Life Cycle);

- protection against systematic system design and hardware failures (Systematic Failures Avoidance);

- protection against systematic software design failures (Software Failures Avoidance).



In addition, it is necessary to carry out a functional safety assessment (Functional Safety Assessment) by determining the conformity of products (hardware, software, and documentation) and product development processes to the above requirements.



Such a structure of functional safety requirements is shown in the figure below, and it is this structure that is proposed to be used when analyzing the requirements of individual parts of IEC 61508. Further, the article gives a brief analysis of the content of each of the parts of IEC 61508 presented in the Mind Map form.





Figure 2. Structure of IEC 61508 requirements

IEC 61508-1, General Requirements

The first part, IEC 61508-1 , sets the tone for the entire standard. Some difficulty to understand is that this part largely describes the level of the object of control and management, which is not very familiar to IT specialists. Here the approach is even wider than the level of the automated process control system, and much wider than the level of the controller and software. What to do with it? Select only those requirements that relate directly to the system being developed or evaluated.





Figure 3. Contents of IEC 61508-1



Hereinafter, Mind Map sections and applications are labeled below with labels that indicate which group of requirements a particular section or application corresponds to. In addition, the Important branch was created on the Mind Map, emphasizing the important tables and figures that are “lost” in the standard text without it.



Documentation requirements (section 5) are assigned to the Functional Safety Management group. IEC 61508-1 also contains Appendix A related to documentation, but in my opinion it is not particularly useful. The recommended documentation structure (based on certification experience) will be discussed in subsequent publications. The structure of documents largely determines the structure of the life cycle, and we have it, as for all security-related applications - V-shaped.

IEC 61508-2, System Requirements

The second part, IEC 61508-2 , as the name implies, refers to the control system. As defined in the introductory publication on functional safety, we consider three types of control system architectures: embedded systems (Embedded Systems), Industrial Control Systems based PLC systems and the Internet of things Device Layer. It is important to note that, in addition to the system requirements, IEC 61508-2 also defines the requirements for the hardware (hardware) component of the systems. Sections 5, 6 and 8 contain only references to IEC 61508-1.





Figure 4. Contents of IEC 61508-2



As part of IEC 61508-2, we will find a number of important applications that are normative, i.e. mandatory character:



- Appendix A proposes an approach to the implementation of self-diagnosis, as well as protection against systematic failures;

- in Appendix C, protection measures against systematic failures are supplemented by requirements for their implementation at various stages of the system life cycle;

- Appendix C shows how to calculate the diagnostic coverage in order to ensure a particular safety integrity level (SIL);

- Appendix D contains the requirements for the content of the operating manual, which is called the Safety Manual with regard to safety requirements;

- Appendix E describes approaches to the on-chip backup when implementing control functions using integrated circuits;

- Annex F is formally informative, i.e. however optional, but nevertheless, de facto, it should be considered if custom integrated circuits (ASIC) or programmable logic integrated circuits (FPGA & CPLD) are used in the systems.

IEC 61508-3, Software Requirements

The third part, IEC 61508-3 , defines the requirements for software, which can be both a component of the system and a separate object of assessment and certification.





Figure 5. Contents of IEC 61508-3



Sections 5, 6 and 8 traditionally refer to IEC 61508 1, but there are some minor additions that take into account the features of the software.



Of the applications, A and B are important, containing requirements for protection against software failures. Appendix D contains the requirements for the Safety Manual regarding the features of the software.

IEC 61508-4, Terms and Definitions

IEC 61508-4 contains a structured list of terms used, which is discussed in detail in Part 2 of the publication.





Figure 6. Contents of IEC 61508-4

IEC 61508-5, Recommendations for the application of methods for determining safety integrity levels

IEC 61508-5 provides fairly abstract examples of how to determine the safety integrity level (SIL). I would consider this part simply as an illustrative material for study, especially since when we receive the initial data for the development of a system or software, the level of safety integrity (SIL), as a rule, is already set there.







Figure 7. Contents of IEC 61508-5

IEC 61508-6, Guidelines for the application of IEC 61508-2 and IEC 61508-3

IEC 61508-6 loudly states that it contains guidance on the application of parts 2 and 3 of IEC 61508, i.e. system requirements, hardware and software. In fact, Appendix A contains a rather trivial description of the stages of project implementation (at the level of “develop requirements”, “plan your work”, etc.). What is of interest is detailed examples of the calculation of reliability and safety indicators (Annexes B, C, D), as well as an example of how to implement safety integrity methods for software (Appendix E). The latter illustrates the application of applications A and B of IEC 61508-3.





Figure 8. Contents of IEC 61508-6

IEC 61508-7, Methods and tools

IEC 61508-7 contains a list of methods to protect against accidental hardware failures and against systematic design errors (both system and hardware, and software). It seems that the authors of the standard have tried to publish everything they have ever heard about these methods. Therefore, there are many theoretical things that can hardly be effectively applied in practice. Nevertheless, the application of basic approaches in terms of diagnosing, testing, organizing project management, etc. is mandatory regulatory requirements. Thus, IEC 61508-7 should be studied on the basis of IEC 61508-2 and IEC 61508-3, where a pragmatic approach to the implementation of protection against failures and errors is described.





Figure 9. Contents of IEC 61508-7

findings

Consideration of IEC 61508 based on the classification and structuring of requirements allowed to break this serious document in seven parts and 700 pages.



The classification criteria of the requirements make it possible to distinguish aspects of functional safety that must be considered to complete the picture in the planned series of articles, namely:

- Functional Safety Management and Functional Safety Assessment;

- implementation of the functional safety life cycle (Functional Safety Life Cycle), including testing;

- estimating the probability of random failures and providing protection against such failures (Random Capability) through the prism of the theory of reliability and safety;

- methods of protection against systematic failures of system design and hardware (Systematic Failures Avoidance) and against systematic failures of software design (Software Failures Avoidance).



PS To explain the main aspects of functional safety, the following cycle of articles is developed:

- Introduction to the subject of functional safety ;

- Standard IEC 61508: terminology ;

- IEC 61508 Standard: requirements structure ;

- The relationship between information and functional safety of the process control system ;

- Management processes and functional safety assessment ;

- The life cycle of information and functional security ;

- The theory of reliability and functional safety: basic terms and indicators ;

- Methods to ensure functional safety .



Here you can watch video lectures on the topic of publication.