Re: [SystemSafety] Does "reliable" mean "safe" and or "secure" or neither?

Date: Mon, 25 Apr 2016 07:57:33 +0000

I never thought that the title of the thread limited the discussion to software. My understanding was that it was at system level…

I would add that software can’t have ant property because it just doesn’t exist. Hardware is “configured” in a way specified by what we call software, but it is still hardware.

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82

From: systemsafety [mailto:systemsafety-bounces_at_xxxxxx Sent: Saturday, April 23, 2016 4:32 PM
To: Littlewood, Bev
Cc: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Does "reliable" mean "safe" and or "secure" or neither?

Tsk Tsk Bev....the thread on this subject last year ended in no accepted conclusions by either set of parties; just some shouted louder (and got personal) and I among others gave up I'm going to do now.

Best regards

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654<> [Image supprimée par l'expéditeur.]

77 Barnards Green Road
WR14 3LR
Company No. 07642673
VAT No:116495996<>

Where “As previously established” = “If I say it often enough it will be true”


As previously does not have a reliability.


On Thursday 2016-04-21 05:00 , I wrote:
> On 2016-04-20 23:18 , Les Chambers wrote:
>>> But here's the thing, any standards body that goes down this path will soon encroach upon the territory of
>>> established religion whose moral codes often diverge even though their collective central core is probably the same.
> That is utter nonsense.

Les deprecated this as somehow lacking intellectual rigor. So here's a more rigorous derivation.

Suppose you have a computer-based system S with function F on which you want to rely. You've done your best to write software So1 for S so that it executes F, but sometimes it doesn't. You run So1 in environment E1, and mostly it executes F (75%) but sometimes it doesn't (25%). You run So1 in environment E2, and mostly it executes F (60%) but sometimes it doesn't (40%).

Someone else has done their best to write software So2 for S so that it executes F, but sometimes it doesn't. You run So2 in environment E1, and mostly it executes F (70%) but sometimes it doesn't (30%). You run it in environment E2, and mostly it executes F (65%) but sometimes it doesn't (35%).

You can talk about the reliability of So1 in E2 and in E2, and about the reliability of So2 in E1 and in E2. Reliability is a function of software and its environment: reliability(So1,E) = 75%.

Now suppose you have a new environment E3 and you want to know whether to choose So1 to run in it or So2. How do you choose? How So1 and So2 run in E1 and E2 might not be a reliable guide to how either is going to run in E3, although you'd imagine that there would be some kind of correlation. You want somehow a measure of So1 against So2 which is going to guide your choice.

And then you've heard that someone else has written So3 to perform F, and has some reliability stats in some other environments, but not E1, E2 or E3. So now you want a guide to choosing from So1, So2 and So3. And so on for So4 from yet another vendor, and ........

What's that measure going to be? Let's call it XXXXXX. If you had software So7 and So8, and So7 ran more reliably in every environment you tried than did So8, you might want to conclude that So7 had more of XXXXXX than So8. You can't say that So1 has more XXXXXX than So2 per se, if you just look at their reliabilities in E and E1, because one is not dominant over the other.

And doesn't XXXXXX seem like a silly name? It's hard to pronounce, for one thing. So you might want to call it, I dunno, ... how about "integrity"?

You know that whatever integrity is, it's not the same as reliability. You also have a pretty good hunch that it might be correlated with the care taken in developing the software. But you have no exact measure.

So what you might do is say: I can't be exact, so I'll stick with five discrete categories of "integrity" for software: no-measure, low, medium, high and exceptionally high. You might even want to call these "levels" (except for the first). And give them numbers, say no-number, 1, 2, 3 and 4. And develop software for IL 1 by whatever means people think is appropriate for the cases where you need the kind of performance hopefully associated with IL 1-designated applications. Mutatis mutandis for IL 2, 3, 4.

Well, actually, I've left a bit out. The developers already did that. So1 and So2 were both developed using means thought appropriate for IL 2. So3 was developed using means thought appropriate for IL 4.

So, which software do you procure for executing F in E2? Mutatis mutandis, I'd probably choose the one with IL 4. Of course, that doesn't mean So3 will actually perform more reliably in E3 than the others. I don't know that for sure and won't find out until I try (all three, and document carefully their performance over a long period of time).

None of this is subjective, although some of it is vague and some is uncertain (irredeemable uncertain, according to some people). There is also a difference in what software is intended to do, what it is needed to do, and what it actually does. (Ingo Rolle has some insight into how this affects claims about the software, and has written it up. The final version is due to go up on my blog soon.) Still, it does a job right now which people need doing, but probably can't do perfectly.

Then someone comes along, quotes a couple of common-language dictionary definitions of "integrity", and says something about established religion and moral codes. Utter nonsense you might say, and I did.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Je suis Charlie
Tel+msg +49 (0)521 880 7319<tel:%2B49%20%280%29521%20880%207319>>

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654<tel:%2B44%280%297412%20074654><> [Image supprimée par l'expéditeur.]

77 Barnards Green Road
WR14 3LR
Company No. 07642673
VAT No:116495996<>

The System Safety Mailing List

Bev Littlewood
Professor of Software Engineering
Centre for Software Reliability
City University London EC1V 0HB

Phone: +44 (0)20 7040 8420<tel:%2B44%20%280%2920%207040%208420> Fax: +44 (0)20 7040 8585<tel:%2B44%C2%A0%280%2920%207040%208585>

Email: b.littlewood_at_xxxxxx

" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."

" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Apr 25 2016 - 10:01:39 CEST

This archive was generated by hypermail 2.3.0 : Sat Feb 16 2019 - 18:17:07 CET