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

[Prof. Dr. Peter Bernard Ladkin]

On 2025-02-12 16:37 , Paul Sherwood wrote:
> On 2025-02-12 14:31, Prof. Dr. Peter Bernard Ladkin wrote:
>>
>> If, as you say, you are mainly interested in automotive, then IEC 61508 itself isn't of much 
>> interest to you.
>
> Hmmm, I guess you didn't actually consider any of the content in my presentation, then.

Correct. I am looking for good argument, and good argument is mostly to be found in writing. And in 
talks which mirror existing writing.

I am familiar with most of the arguments which suggest open-source software somehow enhances safety. 
I am having a discussion in parallel with a colleague who likes to put many failures, including 
dangerous failures, down to "poor programming".

Source software is only one of the components of a software-based system. There are requirements, 
hazard and risk analysis, and then compilation into object code and running that object on a 
processor. A NASA investigation into critical-mission failures from, oh, thirty years ago now, 
found, I remember, 200 of them, of which 198 were a mismatch between requirements coverage and the 
conditions actually encountered by the kit.

If source code quality has in the meantime become a major source of safety-critical failures, I'd 
like first to see evidence of that, and, second, I'd like to get some idea of why this might be 
happening. If you are restricting to road-automotive, I'd like to know why road-automotive has a 
particular problem with the quality of source code which other branches don't appear to have.

A colleague runs the software division at a major automotive-electronics supplier. Ten years ago, he 
said in public, and illustrated with examples, that most, by far, of the problems they have with 
their kit is well below the level of source code - more in the interface between object code 
semantics and processor behaviour.

I have another colleague who works at a company which supplies software-based devices for industrial 
process plants. He says they have had no software-related failures of a particular device in nearly 
two decades of being on the market. (His problem is mainly that the IEC 61508 standard, to which 
clients require conformance, has no provision for "grandfathering" software based on operational 
experience - but this ultrareliable kit was developed to 61508 Edition 1 and Edition 2 has different 
requirements which you cannot reverse-engineer into existing kit.)

Neither of those colleagues seem to need to be concerned with source-code quality. Most of the 
issues the 61508 Maintenance Teams have discussed in a decade of work towards Edition 3 have nothing 
at all to do with quality of source code.

> Agreed, except that I do *differentiate* "safety" from "compliance [to standards]" based on 
> experience.

You could recount the incidents which led you to that conclusion. Then we can discuss your reasoning.

>
> <snip>
>> I don't think it is appropriate to "call them out" (in the usual meaning of those words) unless 
>> you have a concrete, practical idea of what can replace it. The fundamental point is that if the 
>> IEC didn't charge money for its publications, there would be no IEC. And if there weren't an IEC, 
>> we'd all be in a right technical mess. An alternative would be for governments to fund 
>> standardisation. But it is not something governments like to (be seen to) spend money on. It is 
>> politically easier to try to encourage industry to do so.
>
> It's entirely feasible for a group of experts to develop standards on a voluntary basis 
> **without** an organisation like IEC locking up their results.

I've heard that before. My first experience was with the Internet standards, as well as with the 
colleagues who wrote them. Indeed, it worked fine for the first, say, twenty years of a new 
technology. I would speculate that is because they are all product standards, which are well known 
to be the model for which most IEC standards and ISO standards are successful. You want a plug for 
charging electric vehicles. People who buy electric vehicles want to travel all over Europe, the way 
they did with their petrol cars. You need a product standard (thank you Mennekes and Mercedes-Benz). 
That's the way we got most of the early Internet protocols. Things have changed as the branch has 
matured.

I have been involved peripherally, a number of times, in trying to devise a voluntary safety 
standard for software-based systems. I reject your assertion that this is "entirely feasible". I 
think it is highly unlikely to work for safety of software-based systems, for any number of reasons. 
One of which is that the safety standards that exist are very inclusive. If you wanted to write 
another one, there are myriad colleagues who would point out to you what you are leaving out.

>> There are no industries in which "IEC 61508 is mandatory". "Mandatory" is tied to regulations. 
>> Regulations are laws. Laws are not tied to industries, but to countries/jurisdictions. There are 
>> countries whose regulations mandate use of specific technical standards. And others, such as the 
>> US and UK, where they do not.
>
> I was responding to your phrase "have been required to use IEC 61508 since it came into 
> existence". If the usage is not mandatory, on what basis have they been "required to use" it?

1. Because that is what their companies require. 2. Their companies require it because the 
companies' clients require it. 3. The companies' clients require it for a variety of reasons. One is 
indemnity: for example HSE said clearly in the 1990's that they consider use of 61508 as exhibiting 
due diligence, and lack of its use as neglecting the due diligence requirement. And since HSE has 
prosecution authority, that was pretty compelling for companies selling into UK markets. Another is 
interesting: military suppliers. Each country has their own military standards, and it is a fair bet 
that if you want to sell your own kit, built to your country's regulations, into another market, you 
can't do so because you can't demonstrate compliance with other regulations in a language your 
company does not understand. But clients like your kit. So clients say: OK, we see the problem - 
demonstrate conformance to IEC 61508 instead.

>> I am unaware of engaging in any sarcasm. If you mean toning down critique then, as you will have 
>> noticed, I'm very much a spade-caller.
>
> I meant your tone, not the critique. It's entirely possible to spade-call without treating folks 
> as if they are idiots.

You are welcome to comment about the way I write. I am equally self-welcome to ignore your comment.

PBL

Prof. i.R. Dr. Peter Bernard Ladkin, Bielefeld, Germany
www.rvs-bi.de