[SystemSafety] What do we know about software reliability?
Peter Bernard Ladkin
ladkin at causalis.com
Thu Sep 24 13:35:51 CEST 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20200924/e757bdac/attachment.sig>
More information about the systemsafety
mailing list