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

From: Peter Bernard Ladkin < >
Date: Sat, 23 Apr 2016 12:24:24 +0200


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 www.rvs.uni-bielefeld.de



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Sat Apr 23 2016 - 12:24:52 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:08 CEST