[SystemSafety] Separating critical software modules from non-critical software modules

[Peter Bernard Ladkin]

On 25 Jul 2013, at 22:22, René Senden <rene.senden at gmail.com> wrote:

> Dear Myriam,
>  
> In your example, are we talking about sw-modules (safety-critical/non-safety-critical) which are part of the same sw-component?
> For example do these modules correspond to (or are they part of) CSCs within the same CSCI… ?
> Also, in both cases (critical vs non-critical), are we talking about newly developed modules, reuse with(out) modifications, or perhaps all of the “above”?

I find this thread both fascinating and valuable. Let me say why.

Myriam introduced the term (SW) "module" and asked some questions about how they were to be treated (architecturally; also for assessment) in a mixed digital architecture which could be divided (at least in one way, let us assume) into components with the properties of safety-related and non-safety-related.

First, what did not happen. As far as I know, no one asked "what's a module?" 

It should be evident that until you know what a thing is, any assertions you make about its properties will be tendentious. But lots of people have written about modules and their properties and what you have to do. How do we have any idea they are talking about remotely similar things, let alone the same thing? And thereby the assertions made about what properties modules may or may not have correct (or not)?

Then, what did happen. Peter Bishop linked his contribution to specific HW-based objects. Brief, clear discussion. Because people know what is being talked about and can toss one around in their hands.

Each higher-level software construction tool (let us call it "programming language" for short) has its own definition of "module" or equivalent and its own conception of what kinds of properties modules are supposed to have, which are explained in the usual texts. But hardly any of them have mechanisms in place which *guarantee* that these things called modules reliably have the properties the texts attribute to them.  It is usually the case that "modules" are supposed to work like "this", but in fact you can do that and that with them and if you do they don't, they do something different, maybe unpredictable and unwanted. 

Like, you can sit in your car and drive it along and when you turn the steering wheel clockwise you go right, and anticlockwise and you go left. Nice property of a steering wheel to have. Except when it's Sunday 13th and it has just rained, but less than 2mm in the last hour, and the asphalt granularity is so-and-so and the traffic light is just changing from green to yellow. Then no matter what you want or do the car will often or always rapidly accelerate and turn sharply right. So be warned to avoid these situations. 

Les Hatton's Safer C is full of such examples. I know it's an oldish book but some things unfortunately don't change much. 

That is why some people such as myself advocate that, to build SW for safety-critical use, you must specify what properties the SW (in whatever architectural composition you favor) is to have, and assess the SW to *ensure* that it has those properties on which your design is presaged.

PBL

Prof. Peter Bernard Ladkin, University of Bielefeld and Causalis Limited
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130726/190c6988/attachment-0001.html>