IEC 61508, the the international standard for functional safety of systems involving E/E/PE subsystems (which nowadays means mostly every engineered system), is being revised, or “maintained” in the IEC jargon. It started, for the SW part, in November 2014 and for the general-systems and HW part in November 2017, after a request for comments from National Committees earlier in the year.

Some odd things are happening. There is a strongly-argued proposal to take any cybersecurity issues out of the document altogether. Or I should rather say strongly-advocated, because coherent technical arguments seem to be somewhat rare. Many of the assertions are phrased in terms of abstract “security”, and “safety”. Does “security” have to do with “safety”? Well, of course it does. And then again, of course it doesn’t, because “security” is not “safety” and vice versa. Such stuff. (See Footnote 1.)

For many such assertions, it is not clear what they concretely mean. One thing the logical positivists got right 85 years ago is that saying that what a statement means is given by what counts as evidence for or against its truth. Nowadays, such conditions are known as “truthmakers”.

So, let me take the following claim as an example

(++) Cybersecurity is out of scope of IEC 61508

What are its truthmakers? Let me first discuss another example:

(+) Wildlife behaviour is in the scope of IEC 61508

I’ll prove it for you, under certain reasonable assumptions, which constitute the truthmakers. And then we can discuss the assumptions.

You are building and designing a control system. As with many such systems, its function is distributed, and there are cables running between distributed parts. Say it can be identified as a hazard that some signals sent along a certain network connection are not received. (Hazard identification and analysis are required by IEC 61508 Part 1 subclauses 7.4.)

Say this system is to be installed in Menlo Park, California. The network connection operates between equipment in two different buildings. Then you have to worry about routing your cabling, because if you just run it along the usual channels on the outside of buildings, the Acorn Woodpeckers can get at it. (See Footnote 2.)

Severing the network connection is a possible cause of the hazard. It can happen, and it can happen through woodpeckers in this location. The hazard should be mitigated, and of course this is possible using “other risk reduction measures” (an IEC 61508 term meaning non-E/E/PE mitigation – Box 11 of the “Overall safety lifecycle” in Figure 2 of Part 1). Such as steel cable channels of suitable strength.

Suppose we agree that:
(*) if something can be a cause of a hazard, it is said to be “within scope” of any hazard analysis and assessment.
Hazard analysis and assessment, as well as risk analysis, is mandated in any safety-related standard by IEC Guide 51, and indeed by IEC 61508 itself in Part 1 subclause 7.4.

Suppose further that
(**) being “within scope” of part of a normative action of IEC 61508 counts as being “within the scope of IEC 61508”.

Then it follows that woodpecker action is “within the scope of IEC 61508”.
Suppose further that
(***) woodpecker action is wildlife behaviour

Then under these three suppositions (*), (**) and (***), I have just demonstrated that
(+) wildlife behaviour is in the scope of IEC 61508.

What about the assumptions? I imagine (***) is pretty uncontentious. Anybody who wants to claim the contrary to (+), namely
(-) wildlife behaviour is out of scope of IEC 61508
must therefore be prepared to forego either (*) or (**). But neither proposing NOT-(*) nor proposing NOT-(**) makes much sense at all.

Notice (+) is only a concern in specific cases. There is little point worrying about this in a similar installation at the South Pole. It is specific to a system installation at a particular site in Menlo Park.

So enough about woodpeckers. There is an exact parallel with “cybersecurity”. Replace “woodpecker action” with “cybersecurity vulnerability” in the above reasoning (but we don’t need the step through (***)). Then we have

(****) Cybersecurity vulnerability is in scope of IEC 61508

which is the contrary of (++). So why should this be at all contentious? Any technically-coherent (as distinct from political) reason for advocating (++) lies in giving up either (*) or (**).

A whiff of a coherent argument has been raised for giving up (*), but it is only a whiff. Namely, there is a new document presenting a “framework” (guidelines) for cybersecurity and functional safety for industrial automation and control systems (IACS). IEC TR 63069 Guiding Principle 1 says a safety engineer does not have to consider cybersecurity vulnerabilities at all. For some engineers, it suffices that IEC TR 63069 exists and says that; they don’t see any need to discuss the technical quality of the proposals/advice in the document (it is only an informational/advisory document, not normative).

But this Guiding Principle 1, and a lot of the rest of IEC TR 63069, is incoherent and is most certainly not best practice amongst those system engineers for whom cybersecurity is an issue (see my forthcoming paper for the Safety-critical Systems Symposium 2020, and Martyn Thomas’s 1pp comment in the same volume. A preliminary, somewhat sparse, version of the paper is already available: IEC TR 63069, Security Environments and Security Risk Analysis). (See Footnote 3.)

How to fix all this is not clear. It is notable that valid criticism of drafts of IEC TR 63069 was presented via the usual IEC channels during its development, and somehow didn’t make it through to be acknowledged and be responded to by the committee. And what can we do if (++) prevails in the IEC 61508 “maintenance”?

A colleague refers to the engineering-standardisation process as being “broken”. It seems to work well enough for products (e.g., the European 7-pin connector for electric-road-vehicle charging) but much less well for intellectual engineering processes. I have long advocated for peer review of standards documents at the final pre-publication stage by acknowledged senior scientists in the area. But of course that is prone to “capture” through well-resourced special interests as well, just as happened in medicine concerning the unhealthy effects of tobacco smoking, or (it is argued by some sides in litigation reaching the courts now) the more recent example of prescription and use of opioid medications.

Footnote 1. I like to characterise assertions lacking concrete truthmakers as “all syntax, no semantics”, ASNS for short. I used to work at a smallish research institution in Palo Alto. We had a computational logician on staff, who used to muse about “temporal logic” and “concurrency” and “reliability”, all these big general concepts, and try to figure out their interrelations. And write technical notes about them. People like me used to worry about the truthmakers here too. Another colleague took the basic vocabulary from some of these notes, and built a sentence generator in Lisp, which he called the “Babble Generator”. Its products uncannily resembled material that our logician colleague could have produced. To his credit, he took it all in good spirits. In fact, I suspect he was rather chuffed that somebody had gone to all that effort. But there is no evidence he used the BG to ease his own workload………

Footnote 2. I seem to recall SRI International, in Menlo Park, temporarily lost power from its power station at one point because of an Acorn Woodpecker intervention. When I worked there some three and a half decades ago, I used to watch the woodpeckers at work from my window. Researchers can sometimes suffer from a failing sense of purpose. Woodpeckers are a useful counterexample.

Footnote 3. The observations in the paper are not the only valid technical criticisms of IEC TR 63069. For example, 63069 contains a table of “multiply defined terms” in the IEC 61508 and IEC 62443 standards series. It contains 12 items. In fact, there are 63 such terms. And about half of them exhibit moderate to substantial differences in the definitions. How did the authors miss that? Further – how did the authors continue to miss it even after it was pointed out to them?