[SystemSafety] Collected stopgap measures

[Paul Sherwood]

I see you already wrote in another email that I've "resisted 
encouragement" to clarify, but that's not the case. I wanted to consider 
your mail properly, and I found that hard to do, in the face of the 
other traffic.

On 2018-11-03 12:00, Peter Bernard Ladkin wrote:
>> The key escape clause in your words is "in effect".  It's not clear to 
>> me that the applicable laws
>> require compliance with IEC 61508 at all.
> 
> There is no "escape clause". I am reporting what I have been told.

Perhaps you've been misinformed, then. Or perhaps I have. I'm attempting 
to get to the truth of it, though, since as I've said 61508 seems unfit 
for the kind of software I have to deal with.

> Laws are one thing. Reducing risks ALARP is the legal principle, from
> 1949. Getting prosecuted by
> HSE is another thing.

Quite. In addition to being beaten up here, I'm talking with legal folks 
to understand the implications.

> HSE said on the predecessor to this list that
> their criterion for prosecution
> is whether or not the organisation complied with IEC 61508 in
> developing whatever system.

Just because someone said it on the internet doesn't make it true. Who 
precisely said it? Is the text of the statement still available 
anywhere?

> Obviously, you can be prosecuted and declared not guilty. Equally,
> your system can cause damage and
> you not necessarily prosecuted.

I'm sure I'm not alone in preferring to avoid **both** of those outcomes 
if possible.

>> the UK position boils down to
>> demonstrating that risks have been reduced SFAIRP.
> 
> That is established UK law from 1949.

Yes, and still applicable today, I'm told.

>> From my limited exposure to the IEC documents, they seem to be of 
>> little use to me as a duty-holder
>> attempting to wrestle with connected software-intensive systems at 
>> scale.
> 
> Right. There is little attempt to prescribe how you go about building
> a safety-related system (that
> is a common complaint, in fact, from new entrants). But the standard
> does tell you what you have to
> document and what you have to assure. Even if it does so in a way
> which you might consider obscure
> and convoluted. And even if there are gaps (which there are).

"Now that you've forked over your 3K, here's the punchline: we're not 
going to tell you what to do, but here are some clues about what 
documentation you should create"

I do find it odd that you're defending 61508, while accepting that it's 
got problems. Wouldn't it be better to fix the problems?

If the documents were fantastic, we could just use them, rather than 
complaining about them.

>> In fact I'd go so far as
>> to say that the standards seem to be dangerously misleading.
> 
> You suggest that IEC 61508 is leading people to do things which can
> result in harm? How so?

To be clear I wasn't singling out 61508 in that specific statement. As I 
see it, the current standards ecosystem leads to various dangerous 
misunderstandings, for example:

- extrapolate what works for microcontrollers to multicore 
microprocessors
- choose pre-certified software for its magical safety powers
- achieve ASIL D by combining two ASIL B parts
- claim safety by delivering component reliability

To be fair, I expect that the standards don't expressly say that any of 
the above is ok. Some of your comments (and documents you've written) 
show that you understand the pitfalls (and  better than I do, no doubt).

But that doesn't alter the fact that people are settling on suboptimal 
designs, misdirected by (perhaps misunderstanding) the standards - for 
example "pre-certified" OS kernel or 'safety-critical hypervisor".

>>> A risk analysis must be performed (hazard identification, hazard
>>> analysis - basically the
>>> assignation of a severity to each hazard, and some estimate of
>>> likelihood, then risk assessment, the
>> 
>> OK, so we're already off down a track that doesn't work out very well 
>> in practice - humans are awful
>> at estimating likelihoods, for example.
> "Humans" have been performing this kind of risk analysis in civil
> aerospace for 80 years or more, as
> part of the Approved Means of Compliance (as it is called in
> EASA-Speak) and it seems to work out
> very well indeed.
> 
> They also do it in rail electronic kit. Works well there, too,
> although I don't think as well as in
> civil aerospace.

I think I already mentioned Greer's law - presumably there's a safety 
equivalent.

> If you don't like those ways of estimating risk, how would you go
> about estimating risk?

So far, I'm led to understand that from a legal perspective, if we have 
identified a real risk, we should mitigate against it, irrespective of 
any guesstimate of its likelihood.

>> Yes. As I understand it all of the above fails to consider, for 
>> example:
>> 
>> - specification risks
> 
> What is a "specification risk" How can a specification possibly have
> any risk associated with it (I
> am using the term "risk" here as in IEC 61508-4 subclause 3.1.6 or
> electropedia.org item 351-57-03)

Risks arising as a result of folks specifying the wrong thing. I'm using 
risk in the normal commercial/english sense. I do wish that folks 
wouldn't redefine common words to suit their own purposes.

>> - component interaction risks
> 
> Dealt with. If component interaction engenders a hazard, then hazard
> identification will spot it if
> you do the hazard identification right.

Oh, absolutely. If everyone does everything right, everything will be 
all right.

Meanwhile, back in the real world I inhabit, multiple vendors lob 
'pre-certified' components into the pot, with NDAs on their special 
sauce, including special safety sauce.

One hazard I encounter surprisingly often is "vendor tells lies about 
what their thing does".

... and here I ran out of both time and inclination to write more.

br
Paul