[SystemSafety] What do we know about software reliability?

[Olwen Morgan]

FWIW, I've always been sceptical about 61508. Do I detect a large dose 
of irony in the word "finessed"? I'd be more inclined to call it 
"fudged". In my view you cannot meaningfully speak of software 
reliability unless you have rigorous input-source and output-sink 
modelling (and many thanks, BTW, to Michael J, who kindly pointed out my 
omission of the output side in a previous posting).

Having had long and frustrating experience of random C shops, populated 
with what I call the "lumpenengineeriat", I have strong views in this 
matter. Things that one sees all the time are:

(1) Underassessment of system criticality,

(2) A "tick the boxes" mentality that ignores fitness-for-purpose of the 
practices upon which the box-ticking was putatively justified,

(3) Dire ignorance of and hostility towards soundly-based techniques,

(4) Haphazard use of CASE tools,

(5) Absence of intellectual discipline among engineers - s/w engineering 
does not require great intellectual puissance but it needs intellectual 
discipline by the train-load.

TBH, I've given up on expecting rapid progress in this field, if only 
because the standardisation itself has become, IMO, pretty 
dysfunctional. Everywhere there are tribal frictions where there ought 
to be constructive synthesis. You see this particularly in programming 
language standards, where it sometimes seems as if the language itself 
has engendered an in-group, inward-looking culture. How else could one 
be told that a technically sensible improvement was "not in the spirit" 
of a language? Call me a pessimist but I honestly believe we need to get 
specialists to look at this sort of thing from a sociolinguistic 
perspective.


Olwen



On 24/09/2020 12:35, Peter Bernard Ladkin wrote:
>
> On 2020-09-24 11:59 , Martyn Thomas wrote:
>> IEC 61508 ignore the probability that a hardware design is incorrect (we used to talk about
>> 'systematic errors' to distinguish them from random failures', but I haven't seen that expression
>> used recently).
> Yes, 61508 ignores probabilities attached to systematic failure, of either HW or SW. Deliberately.
> It is a controversial subject, as we see here in miniature.
>
> It is finessed by talking about objects (HW, SW or both) having a "systematic capability", which is
> a non-numerical quality saying how appropriate it is for that object to be used to implement a
> safety function with a given SIL. So for example an object with SC3 can be used to implement a SIL3
> safety function and an object with SC2 not.
>
> It goes along with a list of techniques and analysis types. Basically, you can claim a higher SC if
> you have used more of those techniques during development, and lower if fewer.
>
> The general idea is sort of right. If you have used SPARK thoroughly in your software development,
> used a validated SPARK-to-C compiler and a verified C compiler, and you have done it all right, then
> I think we can have more reliance on the machine code produced than if we farmed the specs out to
> some random C shop and took what they delivered without oversight or further analysis.
>
> However, I am sceptical about the way SC is handled in 61508, which is check-boxy: "have you used
> FM?" Yes/no. "Have you used semi-FM?" Yes/no. Not how or why or to do what. I am wary, but it is
> central to 61508.
>
> PBL
>
> Prof. Peter Bernard Ladkin, Bielefeld, Germany
> Styelfy Bleibgsnd
> Tel+msg +49 (0)521 880 7319  www.rvs-bi.de
>
>
>
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20200925/1afecf07/attachment.html>