Re: [SystemSafety] EASA Notice of Proposed Amendment 2014-13

Date: Mon, 21 Jul 2014 13:39:00 +0200

IEC 61508 is cited as much as DO178 ...

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82

-----Original Message-----
Sent: Monday, July 21, 2014 1:32 PM
To: The System Safety List
Subject: [SystemSafety] EASA Notice of Proposed Amendment 2014-13

EASA has issued a Notice of Proposed Amendment concerning changes to ground-based systems used in civil aviation. This includes systems for air traffic control, for communication and navigation, and indeed for air traffic management in general and any support systems.

It is downloadable from

The official date is 24 June, 2014 and the consultation period is 3 months.

I think the word "changes" is disingenuous. It seems to be understood that the functions are provided already, and improving or updating the provision of a function is a "change", i.e., any new system. Provision of a new function is also a "change" - one may assume the function was "provided" implicitly beforehand.

It is "risk-based". We speak here of "safety risk" as the document prefers to say in one of its myriad buzzword-concatenations (p 171). I take it this is to be distinguished from, say, "business risk" and a good thing too.

Definitions are strewn throughout the 230pp document, and there seems to be no place at which they are collected together. At least the IEC and ISO get that right.

Readers will also have fun figuring out the subtle, if any, differences between safety case, safety support case, assurance case, safety assurance, safety argument, safety assessment, safety support assessment and so on. A hint at the level of terminological clarity comes through considering the definition of "safety support case" on p123, which is what most of us would call a reliability case, a case that a system behaves according to specification.

The overall requirement for Air Traffic Services (ATS) which concerns us is contained in ATS.OR.205(a)(2) and (b), especially (b)(4) and (b)(5). It is basically a SW.01 clause, but applied to any functional parts of systems which are being changed. An ATS provided must ensure that a safety assessment is carried out (clause (a)(1)) and "provide assurance, with sufficient confidence, via a complete, documented and valid argument that the safety criteria are valid, will be satisfied, and will remain satisfied" (clause (a)(2)). Clause (b) says that a hazard identification, risk analysis and risk assessment must be performed and it must be shown that the safety criteria are met. (All that's on pp38-9, but somehow I can't seem to copy-and-paste it).

In order to say what an "argument" is, it refers to Toulmin's 1958 classification, Fact, Warrent [sic], Backing, Rebuttal, Conclusion, as though nothing had happened since. But in fact it says, and illustrates, that an argument consists of evidence, claim, and inference, and assurance consists of a "hierarchy" of arguments. All that is sitting around pp124-126.

At this point I experience my usual frustration at the ignorance and arrogance behind such an endeavor. While Toulmin is a worthy source, no one working in the field (for there is such an academic field as the study of argumentation) accepts his classification as the be-all and end-all of what an argument is, although they accept his work as a founding document. Why don't engineers ask specialists, rather than just cite their own very limited reading? Further, the EASA NPA 2014-13 itself does not use Toulmin's classification, preferring to talk about evidence, inference and claim. But why, for example, do they cite Toulmin, and not GSN, especially as GSN has specifically been used in the field of aviation system assurance and Toulmin not?

Other interesting features are a requirement (or recommendation; I am not quite sure of the status) to use HAZOP guidewords to establish "completeness of argument" in hazard identification (p139), and an explicit adherence to the "Bow Tie Model" of accidents (p175).

The document is mostly about process - who does what. And is full of detailed examples.

These comments are the result of what I noted in a quick review (230pp in an hour or so), so they by no means represent any final opinion.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Tel+msg +49 (0)521 880 7319

The System Safety Mailing List

" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."

" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Jul 21 2014 - 13:39:12 CEST

This archive was generated by hypermail 2.3.0 : Sun Feb 17 2019 - 20:17:06 CET