Some of the most important semi-conductor information in IEC 61508:2010 is in in part 2 Annex E. This annex was added in the 2010 version of the standard and will be revised for revision 3 due out in the 2021/22 time frame.
Figure 1 - title of the Annex
The Annex is normative in that it contains requirements (as opposed to being informative if it only contained guidance on how to interpret or apply the body of the standard).
Annex E is specifically called out from IEC 61508-2:2010 clause 184.108.40.206 where it states in point b) that “the special requirements for ICs with on-chip redundancy (see Annex E), where relevant, unless justification can be given that the same level of independence between different channels is achieved by applying a different set of measures”. The fact that an alternate set of techniques is possible makes the normative nature of Annex E somewhat in doubt! However, even if using alternate techniques the individual pieces of advice from Annex E are good.
Some important limitations on the Annex:
One view regarding item 4) is that the authors intended “duplication” to mean any form of on-chip redundancy and another interpretation is that consensus was reached on the assumption that “duplication” means what the dictionary states which implies identical redundancy. Personally, I am not sure it matters because as I said earlier clause 220.127.116.11 allows a set of alternative techniques and a claim for diversity would be one of those techniques and of course the diversity can be bolstered by the techniques from annex E.
Clause E.1 lists 17 requirements and it states all 17 “requirements a) to q) shall be fulfilled. The requirements include:
If the combined on-chip channels are looking to achieve SIL 3 (2XSIL2) there are an addition two requirements given in clause E.2:
Clause E.3 explains how to calculate βIC which is then used to calculate the reliability metrics instead of using β. Clause E.3 allows a claim for on-chip redundancy with in my view a very generous maximum allowed βIC of 0.25. Typically βvalues used elsewhere in the standard are in the 1 to 10% range.
The process to arrive at a value for βIC starts with an assumed βIC of 33% and the number is increased and decreased depending on techniques and measures given in table E.1 and E.2. A calculated βIC of <25% is needed to make a claim for on-chip redundancy. An interesting paper on the topic is “Design and implementation of on-chip Safety Controller in terms of standard IEC 61508” with table 1 showing example calculations for βIC. When doing the calculations using diversity is worth 6%, testing for EMC with an additional safety margin is worth 5%, a temperature sensor between the two channels with a quick shutdown time is worth 9%.
Two ICs from Analog Devices to illustrate the issues are the AD7902/3 and the ADSP-CM417F. The AD7902/03 have two 16-bit 1MSPS SAR based ADC in a single package. Annex E does not apply as there are two separate die in the package. Therefore using this single package with two die should have no particular difficulties to overcome in making claims for redundancy.
Figure 2 - Example of a redundant IC where Annex E does not apply
Another interesting chip is the ADSP-CM417F which is a dual core uC with on-chip ADCs available to each of the uC. I will devote a future blog to these parts but for now it should suffice to say that with an on-chip ARM Cortex M0 and an on-chip ARM Cortex M4 it is not duplication but rather divergent redundancy.
Figure 3 - The ADSP-CM417F implements divergent on-chip uC cores
A number of comments has been received by the IEC TC65/SC 65A/MT 61508-1/2 committee regarding Annex E and it will probably change for revision 3 of IEC 61508. Possible future changes include:
This week’s video is at https://www.youtube.com/watch?v=m3GyELnJCmY. A redundant safety switch prevented a disaster. Even if 3 or the 4 redundant safety mechanisms deployed the safety engineer could still claim a success since the 4th one held!! For further information see https://en.wikipedia.org/wiki/1961_Goldsboro_B-52_crash
For next time, the discussion will be on the functional safety requirements for software.