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

[Paul Sherwood]

On 2025-02-11 18:03, Prof. Dr. Peter Bernard Ladkin wrote:
>>> 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.

I'm much more interested in safety than in compliance, so I won't be 
spending any of my limited remaining time contributing to the IEC/ISO 
walled garden.

<snip>
> 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.

Your pessimism seems entirely justified, but I shall keep calling them 
out.

>>>> 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".

Pity it went over my head, then.

>> 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.

That's a different population, I think - you're talking about owners (or 
employees?) of companies in industries where IEC 61508 is mandatory. I'm 
talking about (mainly) automotive safety practitioners and assessors.

>>> 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?

We've had this conversation before, I'm sure we'll continue to disagree.

>> 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.

As I already said, this is understood.

> 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.

Believe it or not, Peter, I wholeheartedly agree with you on this.

I'm engaging, and I'm encouraging others to engage. Perhaps we could 
tone down the sarcasm a bit, and folks with thinner skins might be more 
willing to get involved?

br
Paul