[SystemSafety] Collected stopgap measures

Sat Nov 17 17:26:10 CET 2018

Peter (and others on the list) please accept my apologies for this 
email.

I started writing out of annoyance, then decided to bin it before 
completion, and hit send by accident.

On 2018-11-17 08:22, Paul Sherwood wrote:
> 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
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription:
> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety