[SystemSafety] Collected stopgap measures

[Peter Bernard Ladkin]

On 2018-11-16 11:27 , Martyn Thomas wrote:
> I think this discussion is missing the point.
> .....
> 
> I interpreted Paul's emails as a request for help because he would like to be able to argue for
> better software engineering but finds himself frustrated by a software industry that mostly does not
> use rigorous engineering and gets away with it.

Help on what?

> In response he received a measure of abuse and quotations from international standards that are
> known to be flawed, rather than a reasoned discussion of the issues that he had raised.

I don't agree with that characterisation of that part of the debate in which I have intervened.
Furthermore, I have asked questions in order to try to gain a better understanding of what is at
issue, and those questions have so far not been answered. It is hard to engage in a constructive
debate when pertinent questions remain unanswered.

IEC 61508-3 is a standard for SW development for safety-related software. I meet on a regular basis
hundreds of engineers involved in engineering software, most of them German, all of them without
exception claiming their organisations develop safety-related SW according to 61508-3 (or other
applicable standard. Not all industry sectors use 61508). That goes not just for DKE work but for
trade fairs, international conferences and so on.

Paul has claimed to be encountering SW engineers developing safety-related SW who do not adhere to
the requirements of IEC 61508-3. Now, I'd like to know what circles he is moving in, for they are
certainly not mine. Are large parts of the UK SW industry (not involved in defence, aerospace,
medical devices, robots, road vehicles, rail, which have their own documents) simply ignoring IEC
61508-3? Would it follow, for example, that we should write British SW suppliers out of our supply
chains? What is the nature of the phenomenon being alluded to here? I don't know, and I would like
to understand it better.

And what is specifically wrong with IEC 61508-3 requirements? If one is worried that safety-related
SW is developed without a requirements specification, then IEC 61508-3 says there has to be a safety
requirements specification. Is that wrong? Generally, if one is concerned that safety-related SW is
being developed without phenomenon X, and one thinks that X might be needed, and 61508-3 requires
that there be an X, isn't that worth noting? Are there papers on it?

It is correct to observe that lots of successful software is developed without a (formal or
semi-formal) requirements specification, but I also take the liberty to find it banal. Much of this
successful software is exercised to a far greater extent than any safety-critical SW. Mike Ellims
pointed out a decade ago that the SW in a box used in top-selling car models will be exercised
general at least 3 x 10^8 operating hours in a single model year. Most avionics SW does not get that
kind of exposure over its lifetime, let alone in one year. Software in kit in large industrial
plants has even less. The mechanisms that are understood to drive the dependability of generic
software such as Windows, Mac OS and Linux are largely not present in most safety-related SW
applications that I encounter. This phenomenon has been discussed in this forum many times over the
last two decades. It is not new. And it does not follow that development of safety-related SW should
follow the path of widely-exercised software.

> I would like the discussion to focus on what we might be able to do to radically improve software
> engineering standards across industry, 

I am concerned largely with safety-related software. If one is concerned with all software, then I
think that is a task for which different incentives are in play. For most safety-related SW, there
is already an applicable standard of whatever quality, as well as motivation to follow it (namely,
getting dunned by some regulator). The task here is thus to improve or replace whatever
standardisation is already in place.

One thing that could happen, and that is manifestly not happening, is that when a request for
maintenance of an applicable standard goes out to the participating and observing countries,
engineers in those countries respond with their critiques of the current standard and suggestions on
how it needs to be changed. For according to IEC rules (and CEN/CENELEC rules, and those of other
standardisation bodies) only those comments so received will be addressed during maintenance. Who
here did that when the request went out for IEC 61508 maintenance in 2017? Who here will do that
(please) when the CD comes out for comment in, say, March 2020?

We are around 300 people here. If everyone makes a comment, that is more than the total number of
comments we received on all of IEC 61508 in 2017. Note that every comment is accompanied by a
proposal for change - you can't say what is wrong without saying how you think it should be fixed.

Another thing that could happen is that people write potential replacements (and get them adequately
peer-reviewed). That is happening also, as you know. Some of that is within the IEC, some of that
outside it.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
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: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181117/b55a9ded/attachment.sig>