[SystemSafety] Collected stopgap measures

Peter Bernard Ladkin ladkin at causalis.com
Sun Nov 4 12:48:13 CET 2018


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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181104/8bec3093/attachment-0001.sig>


More information about the systemsafety mailing list