[SystemSafety] [System Safety] FOSDEM talk by Paul Sherwood

[Prof. Dr. Peter Bernard Ladkin]

On 2025-02-11 13:45 , Paul Sherwood wrote:
>
> On 2025-02-11 12:08, Prof. Dr. Peter Bernard Ladkin wrote:
>> On 2025-02-11 11:43 , Paul Sherwood wrote:
>>>
>>> Agreed, but as I said in the talk, the key point is that "we are not in Kansas anymore". The 
>>> "old ways" served for microcontrollers, but some of them do not scale to the multicore 
>>> microprocessor world we are now in.
>>
>> Edition 3 of IEC 61508, which is now out for voting, explicitly addresses the issues of 
>> multicore. Indeed, that has been a major topic of discussion for the 7+ years the HW part has 
>> been in development.
>
> Excellent. 

Unavoidable.

But now that you know that Edition 3 says stuff about multicore, you can take steps to (a) read it 
and (b) comment. It's not trivial, I understand (from Martyn Thomas, who tried commenting through 
the BSI on Edition 2) but it is doable. If you have stuff to say about multicore, you might really 
want to ensure that it goes through the BSI to the IEC and that we on the Maintenance Teams address 
your comments (which we *must* do if they reach the IEC.

> And ideally the standard would be properly public, so folks discuss flaws and improvements (the 
> open source way... )

That is something John Knight and I and Martyn and others have been banging on about for nearly two 
decades now.

In Germany, various universities are designated by the DKE to be repositories for IEC standards, and 
nominally have multiple copies. You are supposed to be able, whoever you are, to go into the library 
and reference them. It doesn't work. The Uni-of-Applied-Sciences Bielefeld (formerly known as FH 
Bielefeld) has its main campus some 1/2km (now) from the Uni main building. Back ~decade ago, my 
students tried to access IEC 61508 through the repository. They had nominally any number of copies 
and none were accessible in the library to consult.

In other words, people try to do things and they don't work.

I don't know what the situation is in GB.

Having worked on it for a decade plus, I would say that the chances of changing the business model 
of the IEC are approximately zero.

>>> My understanding (I may be wrong) is that the accepted approach to "what is sufficient" is 
>>> something along the lines of "we put suitably qualified+experienced people on the job and they 
>>> tell us when they are finished".
>>
>> Um, no. Nowhere near accurate. IEC 61508-1 has requirements for hazard and risk analysis (and has 
>> had ever since 1997). HRA is established in ISO/IEC Guide 51 as a requirement for any 
>> international standard which concerns safety-related systems or components. The Guide 51 
>> considerations obviously also apply to ISO 26262.
>
> Hmmm.... Sorry but I'm failing to grasp the relevance of your comment. I was replying to 
> "sufficient for acceptable safety" which is about the whole of the work, not just risk/hazard 
> analysis. 

That was a counterexample to your characterisation to show that it was misleadingly trite. Of course 
there is a lot more. The 50-60 documentation requirements for software in IEC 61508-3 are part of 
that "lot more".

> My understanding (that sufficient is when the experts say so) is based on feedback from actual 
> practitioners.

My rubbishing of your contention is based on the opinions of people whose companies have been 
required to use IEC 61508 since it came into existence.

>> Littlewood and Strigini showed clearly in 1993 that you can't use statistical evaluation to 
>> establish positively the safety requirements of safety functions with SIL2 - SIL4 reliability 
>> requirement. (You can use statistical evaluation in hindsight to assess whether your system did 
>> achieve was it was intended to achieve, but you usually need years - or decades - of operational 
>> experience.)
>
> We're all standing on the shoulders of giants - but lots of things which were shown clearly in the 
> 90s have since been improved upon.

How would you "improve upon" a piece of established mathematics?

>
> I am talking about open source, which in many cases has much better provenance (and evidence of 
> its provenance) than most proprietary software.

IEC 61508-3 requires that software for safety functions be developed according to its strictures. If 
you have software of unknown pedigree/provenance/whatever you want to call it, you can't use it in a 
safety function unless it comes with all the 50-60 pieces of documentation. We can argue about the 
details (as I have done for decades), but if it doesn't have it then you can't use it. Period.

What I find disturbing is not that there are people with different ideas about how you qualify 
software for safety-critical use (that is how I got into the debate in the first instance), but that 
that people with an interest do not necessarily inform themselves about the current state of the 
standardisation before they propose what they think might be alternatives. I realise that that might 
not be trivial (in particular, discussing a detailed standard is itself not trivial, even when you 
have gained access) but that is surely the way forward. I am all for discussion of alternatives 
outside the confines of IEC committees. Indeed, when I started on this list it was full of 
discussion of IEC 61508, including people on the committees, but at that time IEC 61508 was brand 
new (published 1997) and people were keen to get the best thing out they could, and to revise it as 
necessary for the 2nd Edition.

But there has to be a common basis for discussion. There is a standard. It is a Basic Safety 
Publication for the IEC. That means that anything that doesn't have domain-specific safety 
regulation is governed by IEC 61508, and that all other safety-related standards must be consistent 
with it. You can't just wipe it away with a wave of the hand. You need to engage. Engagement and the 
establishment of a common basis for discussion is what I would like to see happen.

PBL

Prof. Dr. Peter Bernard Ladkin
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany
Tel: +49 (0)521 3 29 31 00