【Haichuan Chemical Salary News】——The Application and Misuse of SIL
Thread Content
Original title: The Use and Misuse of SIL (published in London on January 14, 2009). Original author: Roger Short CEng, MIRSE, MIET, Atkins Rail, UK. The article is approximately 9,000 words long, and it takes about 25 minutes to read it. Preface: This article was originally published in 2009 in IRSE News (Issue 142, February) by Roger Short. It was reposted on June 22, 2019, by my friend Mr. Chen Yin on his WeChat public account “RAMS Engineer”. After reading this article, Dr. Li Xiaojin felt that although it was written many years ago, it was still very helpful for everyone to understand the concept of SIL accurately. With Roger Short’s consent, she decided to translate this article. I would like to thank Mr. Roger Short for granting his permission, as well as Mr. Chen Yin for his valuable suggestions and comments on the translation. Translator’s Note 1: The concept of SIL and its evaluation methods discussed in this article are primarily applicable to software. 2. In this paper, the author does not make a strict distinction between failure rate and failure probability, using them interchangeably in many places. This kind of mixing is acceptable from an engineering application perspective in security analysis, or under conditions of short time periods and very low failure rates (equivalent to using frequency to approximate probability). But I think it is still necessary to help readers distinguish between them. Taking the exponential distribution as an example: In the formula above, λ is the failure rate (a constant for the exponential distribution), with the standard unit being h^(-1); other common units include FPMH, FPMK, FIT, etc ； F(t) is the corresponding failure probability, that is, P(T≤t), and it has no units. It is easy to see that when λt approaches 0, F(t) and λt can be considered equivalent. Such assumptions are generally acceptable in the context of safety analysis, but we need to pay close attention to the unit of failure rate at this time. 3. For some key definitions, I have retained the original wording to help readers understand their meanings more accurately. The following is the main text of the article
Introduction The concept of Safety Integrity Level (SIL) plays a crucial role in the acceptance and verification of software and electronic systems in safety-related fields. However, people often focus only on the fixed failure probability threshold corresponding to each SIL level, without taking into full account all the factors that influence this value, thereby diminishing the intrinsic value of SIL. Misunderstandings of SIL can even lead to incorrect interpretations and applications of the entire concept of safety integrity. The history of SIL: The concept of using a hierarchical approach to measure the security of programmable electronic systems and their software first emerged during the development of international standards for such systems in the 1980s. This ultimately led to the establishment of the international basic standard for programmable electronic safety-related systems: IEC 61508, and it also contributed to the development of CENELEC standards for safety-related systems in the railway industry. To address the issues related to the use of computers in safety-critical control applications, manufacturers, research institutions, and universities around the world developed a large number of software engineering techniques in the 1970s and 1980s. On the other hand, even though many of these techniques have been adopted as standards and recommended for reducing the probability of errors in software, we still cannot predict how many errors remain in software that employs these techniques, because we cannot use methods similar to those used for hardware to calculate the probability of catastrophic failures in software (for hardware, we can calculate the failure probability of a system based on the failure rates of its electronic components).
Although there is still no technical means to accurately predict the probability of software errors to date, the pioneers who led the development of the IEC 61508 standard are convinced that expert judgment can be used to assess the effectiveness of existing technologies in ensuring software correctness. On this basis, 4 incremental groups were established based on effectiveness, and various techniques applicable to different stages of the software life cycle were assigned to each group. By selecting such a group and applying the technologies within it at various stages of the software life cycle, the software can meet the security integrity requirements corresponding to that group. The industry standard RIA23 for safety-related software in railway signaling systems, issued by the British Railway Industry Association in 1991, fully adopts the aforementioned SIL concept. In fact, apart from its earlier release date, RIA23 has benefited greatly from IEC 61508, as many suggestions from expert members from the UK were taken into account during the drafting of the RIA23 standard – experts who ultimately played a key role in developing IEC 61508. RIA23 was released before IEC 61508 because, as an international standard, the latter required going through a series of complex procedures before it could be published in order to reach a consensus among member countries.
In fact, Figure 1 shows the current approach we use to develop safety-related software with SIL requirements: selecting appropriate technologies from tables of various recommended techniques based on standards.
The number of combination patterns that can be obtained by selecting one technology from each table is extremely large, roughly reaching 3×(10^15). This concept of using certain techniques in system development to meet security and integrity requirements has been extended to cover the design, installation, and maintenance phases of systems, and it can prevent other types of \"systemic\" failures in electronic systems. EN 50129 provides 10 tables for these technologies, but unlike EN 50128, most of the technologies listed in these tables are not optional; they are generally required when developing safety-related systems. As a result, the number of available technology combinations is actually much smaller than that in EN 50128.
SIL and failure probability: As the concept of SIL was gradually developed, a quantitative probability value was assigned to each SIL level. Both IEC 61508 and EN 50129 contain this well-known table that shows the relationship between SIL and the failure rate under hazard conditions (as shown in Table 1). Table 1 Relationship between SIL and failure probability as specified in IEC 61508
If one reads IEC 61058, EN 50128, and EN 50129 carefully, it becomes clear that these standards do not actually state that by applying the appropriate technical measures as recommended for each SIL level throughout the software lifecycle, it is guaranteed that the corresponding level of probability of hazardous failures will be achieved. But many readers will misinterpret the standards in this way. During the review of safety cases for many large-scale railway projects, the author found that such misinterpretations are not rare. The relationship between this SIL and specific probability values is the main reason for the aforementioned misinterpretation of the SIL concept. The idea that certain combinations of technologies can achieve the hazard failure probability level corresponding to a SIL is itself a misinterpretation of the concept of \"probability\", which is commonly used in the fields of safety and reliability. Table 1 does not explain how the probability levels in the table were obtained, but it seems certain that these figures are based on expert judgment rather than empirical data. At that time, no one had the capability to determine whether the safety-related systems developed in accordance with these recommended measures achieved the desired failure rate levels in actual use; even today, the statistical data available to us remain very limited.
If it is desired to verify that the probability of a hazardous failure reaches 10^(-9) per hour, then approximately 10^10 hours (equivalent to about 1 million years) must pass without any hazardous failures occurring. At present, hardly any security-related systems can claim to have accumulated such a large amount of operational data. The Trackside Functional Module (TFM) of the SSI (Solid State Interlock) railway computer interlocking system has been in use since 1984; over the following 24 years, approximately 30,000 units of this type were deployed worldwide, accumulating a total operating time of around 3×(10^10) hours. There are likely few similar systems in the world that possess such extensive operational experience, and even by combining the data from all of these systems, only a small number of technology combinations corresponding to SIL4 can be confirmed.
Since there are many technical combinations that can meet the specified SIL level requirements, **this reduces the credibility of the failure probability range associated with that SIL, whereas SILs are originally defined based on quite narrow failure probability ranges. We can have thousands of ways to develop SIL4-level software that meets IEC 61508 requirements, but can all of them ensure that the final probability of hazardous failure is between 10^(-8) and 10^(-9) per hour?
The meaning of SIL: It is now very common to equate the SIL level with the failure probability; therefore, it is necessary to carefully consider how different standards describe the meaning of SIL. IEC 61058 defines SIL as a discrete level (with four possible levels in total), where Safety Integrity Level 4 represents the highest level of safety integrity, while Level 1 represents the lowest. Meanwhile, the standard defines safety integrity as the probability that a safety-related system will correctly perform the required safety functions under all specified conditions within a specified period of time (original text: … the probability of a safety-related system satisfactorily performing the required safety functions under all the stated conditions within a stated period of time).