Can Designers Really Ignore Part 1 of IEC 61508?

The IEC 61508 standard comes in 7 parts. There is a part 0 which is a technical report and hasn’t been updated since 2005. Parts 1, 2 and 3 contain normative requirements (i.e. things you must do to claim conformance), part 4 is normative but only contains definitions and parts 5,6 and 7 are informative in that they give assistance in how to apply parts 1, 2 and 3. A nice overview of the various parts of IEC 61508 is given in figure 1 of part 1.

Figure 1 - an overview of the parts of IEC 61508

Other interesting views of the standard are given in figures 2 and 3.

Figure 2 - overall safety lifecycle according to IEC 61508

The box 10 above is further elaborated in figures 3 and 4 of IEC 61508-1 and mostly relates to what is contained in parts 1 and 2. This begs the question as to whether only box 10 above is  relevant to people developing hardware or software elements; including integrated circuits.

The activities in boxes 1 through 16 are summarized in table 1 of IEC 61508-1 and further expanded on in its sub-clauses 7.2 (concept) to 7.17 (decommissioning or disposal).

Figure 3 top 1.5 rows of IEC 61508-1 table 1

For software, design part 3 contains the main software requirements and for a hardware element, sub-system or system part 2 contains the requirements. Part 2 is the most important part for an integrated circuit manufacturer (an upcoming blog will discuss the topic of whether Verilog and VHDL used to design digital circuits are hardware or software).

The question then is how relevant is part 1 of IEC 61508 for an IC manufacturer such as Analog Devices?

Indeed, how important is it for machine builders and the like noting that IEC 62061:2005 states “Subsystem(s) incorporating complex components shall comply with IEC 61508-2 and IEC 61508-3 for the required SIL” with no mention of part 1?

When reading standards, it is always good to start with the scope.

Figure 4 Excerpt from the scope of IEC 61508-2

The scope of part 2 offers some guidance...

• Item a) says you must at least read and understand part 1
• Item d) shows how part 2 follows part 1 to implement the items from the design requirements specification extracted from the system safety requirements specification from part 1 and this is re-enforced by the V-model for an ASIC development given in IEC 61508-2:2010 figure 3; where the E/E/PE system safety requirements specification is drawn to the left of the V model along with the E/E/PE system architecture stage.

Figure 5 - V model for an ASIC from IEC 61508-2

Taking all the above on board I generated the following table of relevance of the clauses and main sub-clauses of IEC 61508 part 1 for an integrated circuit development.

When preparing this table, I used the SEooC definition from ISO 26262-1:2018.

Figure 6 - Definition of an SEooC from ISO 26262

Using the SEooC definition separates two uses cases

Case 1 – A customer comes to ADI looking for an IC developed in compliance to IEC 61508 for use in their system or sub-system and hands a safety requirements specification to the ADI team.

Case 2 – ADI wants to design an IC for use in safety systems but doesn’t have a lead customer and therefore must assume an environment and generate the IC safety requirements for ourselves.

I equate case 2 to an SEooC.

Figure 7 - Relevance of clauses and sub-clauses of part 1 to an IC development

Some of the clauses from part 1 and some from clauses 4, 5, 6 and 8 are easy to identify as part 2 refers to them directly and gives little or no other guidance on the topic.

Figure 8 - Example of a direct reference to part 1 in IEC 61508 part 2

Others such as 7.7, 7.8, 7.12, 7.13 are clearly not applicable to an IC development. Still others are replaced by their own clauses in part 2 such as sub-clause 7.8 on “overall safety validation planning”.

What remains then from part 1 are clauses such as 7.2 (concept), 7.3 (overall scope definition), 7.4 (hazard and risk analysis), 7.5 (overall safety requirements) and 7.6 (overall safety requirements allocation) which I believe are necessary for the IC developer to comply with if doing an SEooC.

For instance, if doing an open market/SEooC integrated circuit unless you implement the requirements from the 7.2 (concept) phase how do we know what the end use environment of our IC will be in order to generate the ASIC safety design requirements. The assumptions made during phases 7.2 to 7.6 above would then need to be documented in the safety manual and the person designing the IC into their system would have to make sure the ADI assumptions match the actual system safety requirements specification or implement some sort of compensating measures.

The above view is supported by IEC 61508-2:2010 7.2.2.1 which states that the specification of the E/E/PE system design requirements shall be derived from the E/E/PE system safety requirements, specified in 7.10 of IEC 61508-1. Which IEC 61508-1 in turn says is “7.10 E/E/PE system safety requirements specification

While the discussion in this blog has centered on an IC development, I believe most of the ideas expressed would apply to hardware items such as temperature transmitters and analog input output cards for a PLC.

Note – this discussion is based on IEC 61508:2010.