[SystemSafety] Collected stopgap measures

Sun Nov 4 22:27:20 CET 2018

in the front piece to DO-178C/278A there’s a hand drawn sketch of a lecture theatre with the 178C delegates voting, about half the hands are up. The title of the sketch is ‘consensus’, irony intended.

Having had a chance to use the output of that standardisation effort I can tell you that parts of it are good and parts of it are not very good. The OO supplement is, well, unhelpful. I hear the FM supplementary standard is quite good, but I haven’t had a need to crack it open. 

Regards, 

> On 4 Nov 2018, at 10:48 pm, Peter Bernard Ladkin <ladkin at causalis.com> wrote:
> 
> On 2018-11-03 20:00 , Paul Sherwood wrote:
>> On 2018-11-03 18:52, Martyn Thomas wrote:
>>> Unfortunately, IES 61508 isn't fit for purpose in a world with far
>>> more software than hardware and a large and growing cybersecurity
>>> threat. It was a decent standard for the 1980s, when almost nothing
>>> else existed.
>> 
>> It's not just me seeing that, then.
> 
> I think lots of people have criticisms of IEC 61508, but many of them are technically more precise
> than yours have been. For example, https://rvs-bi.de/publications/WhitePapers/RVS61508Problems.pdf
> and https://rvs-bi.de/publications/WhitePapers/rvsIEC61508CaseStudy.pdf and
> https://rvs-bi.de/publications/WhitePapers/LadkinPiUessay20130614.pdf and
> https://rvs-bi.de/publications/WhitePapers/ReqSpecConsCompl-RVS-WP7.pdf and
> https://rvs-bi.de/publications/WhitePapers/LadkinFallerExample20150101.pdf and
> https://rvs-bi.de/publications/Papers/LadLitt20150301.pdf and
> https://rvs-bi.de/publications/Papers/LadIETpubV.pdf and
> https://rvs-bi.de/publications/Papers/LadkinLittlewood-Practical-FinalV2.pdf and
> https://rvs-bi.de/publications/RVS-Bk-17-01.html
> 
> (Nancy doesn't like IEC 61508 either, but she generally restricted herself to one-sentence
> disparagement. She called IEC 61508 "dangerous" at one point, as you did, but resisted encouragement
> to say what she meant, as you have.)
> 
> I think IEC 61508 is likely much better on (current) digital HW components than it is on SW or
> systems engineering. People who work primarily in SW do not necessarily meet people from companies
> who manufacture environment-resistant reliable sensors for industrial process plants. Or trackside
> electronic milestones for railways. Or axle counters. That is the kind of kit for which IEC 61508
> and derivatives has worked relatively well. Remember, before IEC 61508 there was nothing. There was
> no requirement that you had to perform a risk analysis for this kit. That you had to demonstrate
> that random HW failures in your environmentally-robust thermometer met so-and-so reliability
> criteria. See below for an anecdote concerning Bill Black.
> 
> Saying about Parts 1 and 3 "I don't like it; it doesn't work" is not new nor helpful nor
> particularly insightful. I would encourage critics to be precise about what they don't like/think
> doesn't work. I would also encourage them to suggest practical ways of getting better results.
> 
> Martyn chose first to try to work within the system, in the late 2000's. Edition 2 of IEC 61508 was
> being prepared, and CDs were sent out for commentary. In theory, every electrotechnologist (member
> of the acknowledged national electrotechnical professional organisation) has an opportunity to
> comment. IN practice, the responsible national organisations do not always make it easy. Most
> engineers, for example, never find out when comments have been soliticed and the IEC has a
> three-month deadline.
> 
> There is a form. There are administrative details; it asks for your comment, and what subclause your
> comment addresses (or it can be general) and it asks for a proposed action. The final column is for
> the committee response ("Accepted"; "Accepted in principle"; "Rejected") which is filled out, along
> with reasons, by the committee that addresses it (the National Committee if it is rejected at this
> stage; the IEC Maintenance Team if it is passed along). The comments go to the NC, which decides
> which to reject and which to pass on to the MT. All very straightforward.
> 
> Martyn filled out the form. His pertinent comments on Part 3 were rejected by the UK NC as being
> "out of scope". They weren't. A number of then-members of the UK NC were on this list. There was
> zero discussion of any of this. You are not supposed to air committee deliberations in public (that
> is justified to protect IP) but you are allowed to consult with expert advisors, and the York
> mailing list (as it then was) could reasonably have been considered a forum for consulting with
> expert advisors - except for the fact that it was publicly archived. But I am sure that could have
> been dealt with. In any case, that was a lot of work on Martyn's part for what turned out to be
> nothing.
> 
> During the 2000's I produced a number of what I thought to be stinging technical criticisms of
> various parts of IEC 61508, along with (and this is important) some suggestions as to how to
> rectify. The Chair of the French NC is on this list, and he forwarded a note of mine to the
> then-Chair of the German NC, who then invited me to present to the German NC at their October 2009
> meeting. I did so. I was then invited to join the Safe Software working group, and I first presented
> there on 19th January 2010. I just looked it up - there it is in the document archives, the first
> document of 2010: "914.0.3_2010-0001 Vorschläge Ladkin zu IEC 61508-3". Eight+ years later we have
> IEC PT 61508-3-2.
> 
> You can wring your hands over the time frame, but that indicates progress. Back in 2010, most
> members of DKE AK 914.0.3 were against introducing any FM-based assurance into critical SW
> development (including one stalwart who was convinced, and probably still is, that Hoare-logic
> cannot possibly work, despite plentiful, decisive contrary evidence from, say, the iFACTS project).
> By October 2016, there was consensus in that working group on a formulation for a New Work Item
> Proposal on FM to be sent to the IEC. It was resolved to send that to the IEC at the German NC
> meeting in November 2017. It went in in March 2018, and now the IEC PT 61508-3-2 is meeting.
> 
> That is what it takes if you choose to work for change within the system itself. And you might fail.
> In September 2009, Rolf Spiker of Exida sent me an email inquiring on behalf of a client in Canada
> whether Part 7 Annex D, the statistical evaluation of SW as "proven in use" was a reliable guide to
> evaluating SW as "proven in use". (2009 is unfortunately a missing year in my mail archives, so I no
> longer have the original.) I thought "not really", and asked Bev, who confirmed that view
> definitively. Since then, Bev and I have been working on a replacement for that 4.5pp. At first,
> through the same channel as above, then through a separate working group formed by the DKE at my
> suggestion in late 2015; now through the IEC MT. That has gone a lot less well, for reasons which
> support Martyn's contention that "the standardisation process is broken" in spades.
> 
> Indeed, I have lots of bad experiences in standardisation which support Martyn's contention that it
> is broken, many of which I have shared with Martyn. For example, companies send in negotiators who
> may barely be expert, and two negotiating tactics which one may encounter are verbal bullying and
> disparagement, and filibustering.
> 
> The difficult question is what can effectively replace the current system? Any system you have is
> going to have a large political component to its decision procedures. John Knight, I and Martyn have
> made a number of suggestions for improvement. For mine, you might want to check out
> https://rvs-bi.de/publications/WhitePapers/RVSsfssPrinciples.pdf . For John's, a 2014 SSS Keynote at
> https://scsc.uk/r126/1:1 .
> 
> I think, for example, that having separate procedures for product standards and methodological
> standards would be a good idea. I have had near-first-hand experience of effective standardisation;
> the European plug/socket for electric-car charging. Basically, in such cases there needs to be just
> one universal design; how you get there is secondary, as long as the final design works. So you have
> companies and nations having their discussions/battles in committee until one emerges, by
> "consensus". Done.
> 
> This oesn't work with methodology, even with so-called experts. Consider this group. You have one
> faction saying "FM, pooh". You have another faction saying you must use them. You have one faction
> saying use of C should be anathema for critical-systems programming; another faction saying it is OK
> if it satisfies certain coding standards (MISRA C); another faction saying it that it does not
> matter if source is C or any other (procedural?) language. How do you get consensus out of that?
> Suppose the criterion were not consensus but, say, supermajority vote. Then all the big companies
> could stuff committees to mutually support qualification of each other's toolsets and the lone
> non-affiliated voices saying that the toolsets aren't as reliable as claimed would be shut out as
> the minority.
> 
> Consider again statistical evaluation of critical SW, a la Part 7 Annex D. We had some discussion on
> this list a couple of years ago, which went weird. Somebody told Bev Littlewood, the 8th winner of
> the most prestigious award for software engineering for his work on the statistical evaluation of
> software, that he had been wasting his professional life doing something conceptually impossible. At
> least four of the world's most expert people on statistical evaluation of software are on this list;
> other members (such as the above) say this is conceptually misplaced. You wouldn't get a Part 7
> Annex D from this group in those circumstances, not even a poor one, so you certainly wouldn't get
> people working for its replacement by something better.
> 
> Independent peer-review of first-edition methodological standards could dampen committee-capture by
> big-company bully players, because proposals favoring their company business models are unlikely to
> make it past independent peer review on their dubious merits. But that process could also be
> compromised by lobbying techniques and the real possibility of corruption (big companies have lots
> of money, and I imagine not every poorly-paid academic could resist an offer to be set up
> comfortably for the rest of hisher life).
> 
>>>   Which is why
>>> 61508 is illogical, unscientific, and irredeemable. 
> 
> I don't agree entirely with Martyn's assessment of IEC 61508. :-)
> 
> First, I would say that IEC 61508 is recognised to be much better on digital HW components than it
> is on anything else (such as SW, and systems engineering). I and others used to have arguments on
> the precursor of this list with a UK member of the 61508 committee, Bill Black. I finally met him at
> an IET meeting. He uttered a couple of sentences that I think explained it all. I have incomplete
> recall, so this is a rephrase. He suggested that there had been no basis on which to evaluate
> digital HW components for safety-related operation; now there was and, despite all the things wrong
> with IEC 61508, the world was a lot better for having a standard rather than none. I was a SW guy;
> he was a digital-HW-component guy. He was happier; I was not.
> 
> I would say that in its current incarnation, there is lots wrong with IEC 61508. It exists already,
> so the established procedures only allow incremental change. I think that change could be effected
> if enough people engage - the challenge is to get them to engage. Martyn obviously disagrees with
> that assessment and his experience with commenting on Edition 2 bears it out.
> 
>> Public good
>>> standards should be written by independent experts, throwing down the
>>> gauntlet to industry to decide whether or not to follow the standard.
> 
> The weakness I see is determining who is an independent expert. That is a political process. I do
> see a lot of good in putting good stuff out there and inviting people to jump on board. But you
> don't necessarily have to be outside the system to do that.
> 
>> ... The kinds of documents I'm hoping for
>> will be on gitlab/github, with evidence of history, active reviews and CI/CD.
> Great. Put our electrotechnical standards development process under commercial control of a FAANG
> company. The opinions of Dr. Pangloss come to mind.
> 
> 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