[SystemSafety] Collected stopgap measures

[Paul Sherwood]

On 2018-11-16 23:19, Peter Bernard Ladkin wrote:
> 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.

I literally don't have time to read all of the emails on this list, and 
much of the content strikes me as middle-aged folks posturing about 
standards that the writers have contributed that I'm not going to read 
(because they're either paywalled, overlong, unfit for purpose).


> 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.

Good for you. I've already said that I think that document is a 
disgrace.

> 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.

I"m on linkedin - you can get a picture of the circles I move in from 
that.

I've repeatedly said that the topic I'm most interested in, in this 
context, is autonomous vehicles, but I've been involved in large-scale 
systems projects over several decades, in various industres.

But frankly I don't care whether you think I'm credible or not. I go to 
jail if I make promises I can't keep, and your waffle has been of 
approximately zero help to me so far.

> 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?

Do you think I'm restricted to UK? I'm not.

Do you think that all of the organisations that claim to be apply the 
standards actually use their experts when pressed to deliver as cheaply 
as possible? Not in my experience.

But to be clear, I'm ignoring that document.

> 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.

The hypervisor idiocy I mentioned most recently was argued to me  a few 
weeks ago by a safety-titled person from Germany, on behalf of a 
well-known international organisation which originated in Germany.

This is not about nationalities, and I find it quite bizarre that you've 
chosen to jump to this argument.

> 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?

Now I see them game - ask loads of questions (often variants on 
questions you've already asked multiple times) among lots of waffle, 
then blame others for not answering them all. I'm amazed you find the 
time.

> 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?

I won't be contributing to the ponzi scheme, and I don't think I'll be 
collaborating with you, specifically, under any circumstances.

> 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.

I really won't
> 
> PBL
> 
> Prof. Peter Bernard Ladkin, Bielefeld, Germany
> MoreInCommon
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319  www.rvs-bi.de
> 
> 
> 
> 
> 
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription:
> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety