IEC 61508: It’s not failure it’s unfinished success

While searching for a quote for the title of the final part of the blog series, we came across many inspirational quotes from philosophers and thought leaders, regarding ultimately one of the key areas for any guidance literature on safety. What has gone wrong before and what have we learned from it? In the first part of our blog (IEC 61508 The mother of all safety standards), we gave a brief overview of IEC 61508, in the second part we focused on how IEC 61508 has influenced both standards in the automotive and medical domains: If you are looking for inspiration turn to IEC 61508. In this last part of the series we look at techniques used in other functional safety sources and compare them with IEC 61508.

The challenge of commonality

An area that still tends to be overlooked to a certain extent is that surrounding common-cause failures. IEC 61508 has a good approach to this topic in Annex D of part 6. The failure of individual channels in electrical/electronic and programmable electronic systems is assessed both for systematic and random failures. There is then a portion of the failure rate that can be assigned to a common failure in both channels as indicated in Figure 1:

Figure 1: Common failure between channels

The approach in IEC 61508 is to quantitatively grade the common cause relation between the two channels using the beta-factors model (measure of coupling between the two channels). This is applied through a series of questions giving a weighted score – typical examples are indicated in Table 1:

Table 1: Common cause assessment of electronics or sensors

In total there are 37 questions of this type and the factors X_LS etc. are then use in formulas to arrive at the quality figure for common cause failures. The grading in IEC 61508 takes very much a system’s view of the subject, and the considerations around different personnel are important here.

In the automotive domain ISO 26262 tends to handle the topic of common cause failures within the subject of dependent failures (common cause being a subset of dependent failures). This is carried out at a more technically detailed level around the area of software architecture, semiconductor considerations and in part 9 also at systems level. There is no attempt to quantify the failures, and this activity is very much left to the expertise of the team carrying out the analysis.

In the medical device sector this topic is not really handled at all, IEC 60601 makes references to common cause failures, but there is no specific strategy defined. This is an area where medical device teams working on more safety critical devices could benefit from the strategy defined in IEC 61508.

Decomposition

The topics of decomposition and segregation are perhaps not so well handled in IEC 61508 as they are in ISO 26262. ISO 26262 providing clear decomposition guidelines and highlighting the importance of freedom from interference between the decomposed components of the architecture Figure 2 illustrates the decomposition options for automotive safety integrity (ASIL) level D (the most critical level).

Figure 2: ISO 26262 ASIL D Decomposition Options

The confirmation of the freedom from interference is key in this activity e.g. that there are no software deadlocks in one decomposed block caused by the other decomposed block.

This topic is to a certain extent handled in the medical device sector in IEC 62304, when looking at the topic of segregation, again however with minimal definition. This is an area where ISO 26262 certainly gains the greatest credit.

Software methods & techniques

With this topic IEC 61508 really comes into its own. Supporting the software processes defined in part 3 is the informative guidance in part 7, which delves into the software techniques and measures for achieving software safety integrity. Topics such as requirements management, coding standards, dynamic objects and limited use of interrupts amongst others are covered well in part 7. It is true that many of the topics in part 7 of IEC 61508 are present in ISO 26262, but not to the same level of detail as defined in IEC 61508, which also provides a good list of external references for additional reading.

As IEC 62304 in the medical device world is a more of a lifecycle model than a software standard, little is covered there, part 7 of IEC 61508 makes good reading for software developers in the medical device sector.

A topic that is really popular at the moment is artificial intelligence (AI), and this is also covered to a certain extend in part 7 of IEC 61508, look out for our blogs on AI at the start of 2021.

In summary IEC 61508 still has a big role to play in supporting development activities in multiple industries, even ones that have their own dedicated standard. Back to the topic of state of the art as covered by our blog earlier this year: Are you brave enough to use State of the Art?

As we mentioned in the opening sentences knowing what has previously not worked, is key to moving toward success, no system is ever 100% safe, but utilising information from multiple sources is a good way of reducing the likelihood of failure. IEC 61508 is very much a key source of information in this quest.

By Alastair Walker, Consultant