[SystemSafety] IEC 61508 Committee Draft of Edition 3 published

[Peter Bernard Ladkin]

At the weekend, I received notification that the Committee Draft of Edition 3 of IEC 61508 (the 
functional safety standard for digital parts of safety-related systems) has been released by the 
IEC. That means it is being circulated through/in/by the National Committees for comment. The 
comment period extends into January 2023.

There is a fair amount of change/new stuff. There is a fair amount of stuff that is going to make 
some people very unhappy.

If this concerns you, do get in touch with your National Committee (that is IEC speak for your 
national electrotechnical standards organisation) to see how you may be able to comment.

I had a lot to do with a slightly more detailed formulation in Part 1 of how human factors are to be 
addressed (largely, explicit reference to the substantial existing literature; there was supposed to 
be a separate IEC standard on HF and E/E/PE functional safety, but that fell through). I also had a 
lot to do with the reformulation of Part 7 Annex D, on the statistical evaluation of (existing) 
software through its operational history. I am pretty happy with those two contributions.

Both point further. We may resurrect the HF+functional safety project with the IEC. I say "we" - I 
chair the German mirror committee and we are thinking about it. But it won't happen until key people 
have more time.

Bertrand Ricque and Michael Kindermann (both on this list) are both thinking about an IEC project to 
write a standards document with more detail on the statistical evaluation of safety-critical 
software. There seems pretty much universal agreement that Part 7 Annex D is not enough. However, 
there is a lot of disagreement about what more can/should be said. I proposed and chaired a German 
mirror committee in 2016, but it fell apart. More recent disagreement can be read in the issues of 
the SCSC eJournal.

There are going to be a lot of people unhappy with the way cybersecurity is treated. (Hint: it is 
essentially completely left out.) I reduced my involvement in the 61508 Maintenance Teams from 
December 2019 because of my unhappiness with the way in which that issue was handled.

In Germany, some of us have been trying to fix the awful IEC 63069 on cybersecurity and safety. Many 
of you will not be aware that it is a Technical Report (i.e. informative not normative) but a 
proposal has been circulated by the IEC to turn it into a Technical Specification (i.e. normative), 
and there is not that much different. The comment period on that ends next week.

The reason cybersecurity is such a mess is, at a high level, quite straightforward. It is a 
universal threat with which engineers who are not computer scientists are only superficially 
familiar. Every large company is manoeuvring its way around responsibility and liability issues. In 
other words, politics, largely formulated by people who are not subject-matter experts.

Others on this list may well point out that the reason a lot of software-based systems continue to 
be vulnerable is that the companies selling this vulnerable SW (largely, SW-based pieces of HW) do 
not seem to be willing to put in the effort to reduce its vulnerability. (Look at the CVE list on 
ICS-CERT; the words have changed since the 1990's but if you perform the translation it is still the 
case that 90% of the vulnerabilities essentially concern a lack of strong data typing on inputs.) I 
think Rod Chapman can attest to the fact that putting in the effort demonstrably reaps the 
sought-after reward, as well as that, using modern tools, the effort is manageable.

But I have heard a (the?) senior safety engineer for a very, very large company saying out loud to a 
group of engineers including myself and Bertrand Ricque that you can't effectively do (have done) 
anything about Triton. Of course we can (and could have). It is a misled mindset that needs to be 
changed.

PBL

Prof. i.R. Dr. Peter Bernard Ladkin, Bielefeld, Germany
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de




-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20221004/670347b5/attachment.sig>