EUROCONTROL EXPERIMENTAL CENTRE · 2019. 2. 18. · ATM Araffic Management ir T DFD DFlow Diagram (or Design) ata EEC EUROCONTROL Experimental Centre FMEA Failure Modes and Effects

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL EXPERIMENTAL CENTRE

TOWARDS AN APPROACH TO BUILDING SAFETY INTO DESIGN

EEC Note No. 12/05

Project SAFBUILD

Issued: June 2005

The information contained in this document is the property of the EUROCONTROL Agency and no part should be reproduced in any form without the Agency’s permission.

The views expressed herein do not necessarily reflect the official views or policy of the Agency.

REPORT DOCUMENTATION PAGE

Reference: EEC Note No. 12/05

Security Classification: Unclassified

Originator: EEC – SAS (Safety Analysis and Scientific)

Originator (Corporate Author) Name/Location: EUROCONTROL Experimental Centre Centre de Bois des Bordes B.P.15 F - 91222 Brétigny-sur-Orge Cedex FRANCE Telephone: +33 (0)1 69 88 75 00

Sponsor: EATM

Sponsor (Contract Authority) Name/Location: EUROCONTROL Agency 96, Rue de la Fusée B-1130 Brussels Telephone: +32 2 729 90 11 WEB Site: www.eurocontrol.int

TITLE: TOWARDS AN APPROACH TO BUILDING SAFETY INTO DESIGN

Authors Fabrice Drogoul (EEC) Alfred Roelen (NLR) Steve Kinnersly (AEA)

Date 06/2005

Pages xii + 45

Figures 2

Tables 6

Annexes 6

References 28

EEC Contact Fabrice Drogoul

Project SAFBUILD

Task No. Sponsor 120000-SRD-3-E1-0000

Period 2003-2004

Distribution Statement: (a) Controlled by: Head of SRT (b) Special Limitations (if any): None (c) Copy to NTIS: YES / NO

Descriptors (keywords): Design, best practices, safety, ATM, nuclear, rail, aviation

Abstract:

The purpose of this document is a step towards developing efficient processes to input safety into design for future ATM concepts. A review of safety practices from other industries including rail and road transport has been performed, and best practices as well as gaps are presented. This will help the Eurocontrol Experimental Centre develop a suitable safety assessment approach.

Towards an Approach to Building Safety into Design EUROCONTROL

Project SAFBUILD - EEC Note No. 12/05 v

FOREWORD The SAFBUILD programme of activities is aimed at enhancing safety in systems at the concept and design stages of development. Literally, it is concerned with ‘building safety into design’. Previous work has considered firstly what techniques others use to assess safety in systems at all stages of their life cycle. This extensive review yielded a small number of techniques and tools which can be used to assure safety in ATM, including some techniques that can be applied at very early stages of design. Such techniques have since been adapted and tried with success at the EUROCONTROL Experimental Centre, where future concepts for Air Traffic Management ATM) are explored. Secondly, the need to consider safety at all in the early design stags needed to be confirmed. Therefore a second main report evaluated the claim that ’50 – 60%’ of accidents have their roots in the design stages. This claim was indeed found to be true, across a range of industries. This reinforced the need to consider safety at these early stages in the system development life cycle.

This current report considers how different industries consider the broader question posed by SAFBUILD – how to ‘get safety into design’, again by reviewing a range of industries. The review shows a common reliance on a three-tiered approach – Context, Principles, and Tools. Since the latter has already been documented, most of the report focuses on the former two aspects. The aim of this review is therefore to present how other industries ‘do’ safety in design, and to see what ATM can learn from them. However, since there are differences between the nature of ATM and other industries, it is not a simple matter to ‘copy and paste’ – the adaptation must be intelligent, and also there are safety aspects that are possibly unique to ATM, for which perhaps other industries are not concerned. These aspects are discussed at the end of the review.

This review feeds forward into the ongoing development of safety assurance activities in the EEC’s activities, known as SAND (Safety Assurance for New Designs). The next report in the SAFBUILD ‘series’ will document the SAND process and its application to EEC concept design work.

Fabrice Drogoul Safety Research, EEC

EUROCONTROL Towards an Approach to Building Safety into Design

vi Project SAFBUILD - EEC Note No. 12/05

Page intentionally left blank


Project SAFBUILD - EEC Note No. 12/05 vii

TABLE OF CONTENTS

LIST OF ANNEXES......................................................................................................... VIII

LIST OF FIGURES .......................................................................................................... VIII

LIST OF TABLES............................................................................................................ VIII

ABBREVIATIONS AND ACRONYMS............................................................................... IX

REFERENCES .................................................................................................................. XI

1. INTRODUCTION...........................................................................................................1 1.1. SAFBUILD SUMMARY................................................................................................... 1 1.2. PURPOSE...................................................................................................................... 2

2. APPROACH USED.......................................................................................................2

3. DEFINITIONS................................................................................................................3

4. SCOPE AND CONTENT OF THE REVIEW..................................................................6

5. WHY ATM IS DIFFERENT?..........................................................................................8 5.1. CONTEXT ...................................................................................................................... 8

5.1.1. Open or Closed System ....................................................................................8 5.1.2. ATM an Integrated System................................................................................8

5.2. PRINCIPLES .................................................................................................................. 9 5.2.1. Difference in Design ..........................................................................................9 5.2.2. Certification and Regulations...........................................................................10 5.2.3. Change Impact ................................................................................................10 5.2.4. Safety Culture..................................................................................................10 5.2.5. Systemic View and Models..............................................................................11 5.2.6. Knowledge Management.................................................................................11

6. WHAT WE HAVE IN ATM AND MORE SPECIFICALLY IN EUROCONTROL..........12 6.1. SAM.............................................................................................................................. 12 6.2. EEC SAFETY ............................................................................................................... 13

7. FINDINGS OF THE REVIEW ......................................................................................14

8. WHAT ATM CONCEPT DEVELOPMENT NEEDS IN TERMS OF SAFETY..............23

9. WHY DO WE STILL HAVE GAPS?............................................................................24

10. CONCLUSIONS..........................................................................................................25


viii Project SAFBUILD - EEC Note No. 12/05

LIST OF ANNEXES ANNEX A - Railway Signalling (End User, Operator)...................................................................... 28 ANNEX B - Railway Signalling (System Supplier)........................................................................... 32 ANNEX C - Air Traffic Management (System Supplier)................................................................... 36 ANNEX D - Aircraft Systems (Regulatory Requirements) ............................................................... 38 ANNEX E - Process Industries (Chemical, Nuclear Power, Food) (Best Practice Guidelines) ....... 42 ANNEX F - Automobile Systems (Best Practice Guidelines) .......................................................... 44

LIST OF FIGURES Figure 1: Variations on development cycles .................................................................................... 3 Figure 2: Standard IEEE V model.................................................................................................... 4

LIST OF TABLES Table 1: Industries, Viewpoints and Sources ............................................................................... 6 Table 2: List of annexes and contents........................................................................................ 14 Table 3: Synthesis of context findings........................................................................................ 15 Table A-1: Factors to consider in the design of operator-system interfaces.................................. 30 Table B-1: Techniques for software validation............................................................................... 34


Project SAFBUILD - EEC Note No. 12/05 ix

ABBREVIATIONS AND ACRONYMS

Abbreviation De-Code AD Airworthiness Directive

ATM Air Traffic Management DFD Data Flow Diagram (or Design) EEC EUROCONTROL Experimental Centre

FMEA Failure Modes and Effects Analysis FTA Fault Tree Analysis

HAZOP Hazards and operability study HMI Human Machine Interface HOL Higher Order Logic IEC International Electrotechnical Commission IEE Institution of Electrical Engineers ISO International Standards Organisation JAR Joint Airworthiness Requirement

MISRA Motor Industry Software Reliability Association NLR Nationaal Lucht-en-Ruimtevaartlaboratorium

SEMSPLC Software Engineering Methods for Safe Programmable Logic Controllers SIL Safety Integrity Level STD State Transition Diagram STT State Transition Table VDM Vienna Development Method

Z A formal specification language notation and design technique


x Project SAFBUILD - EEC Note No. 12/05



Project SAFBUILD - EEC Note No. 12/05 xi

REFERENCES

[1] Albers, M. (in press). “Design for complex situations: Analysis and creation of dynamic Web information”. Mahwah, NJ: Lawrence Erlbaum Associates.

[2] Bishop (1990) “Dependability of critical computer systems” - Part 3: Techniques Directory; Guidelines produced by the European Workshop on Industrial Computer Systems Technical Committee 7 (EWICS TC7). London Elsevier Applied Science 1990(249 pages), P.G. Bishop (editor), Elsevier.

[3] Brown, J.S., Duguid, P (1991): “Organizational Learning and Communities of Practice: a unified View of Working”, Learning and Innovation.Organization Science, vol.2, no 1, 1991. pp 40-56.

[4] Cardosi, K. and Murphy, E. (Eds.), (1995). “Human Factors in the Design and Evaluation of Air Traffic Control Systems”. Federal Aviation Administration, Office of Aviation Research, DOT/FAA/RD-95/3. The associated checklist is available at http://research.faa.gov/volpe.asp.

[5] Damski A., and R. Westrum. (2003). “Requisite Imagination: The Fine Art of Anticipating What Might Go Wrong.” Pp. 187–220 in Handbook of Cognitive Task Design, E. Hollnagel, ed. Mahwah, N.J.: Lawrence Erlbaum Associates.

[6] Dorbes, A., Geissel, M. and Jackson A., (2001). “Integrating multiple viewpoints in the coherent design of advanced controller working positions”, Proceedings of the 20th Digital Avionics Systems Conference (DASC), Daytona, October 2001.

[7] Drogoul (2004), “Review of root causes of accidents due to design”, EEC Note No. 14/04.

[8] Drogoul F. ,Grau J.Y., Amalberti R.(2003), Dialogues with the customer – The designer interface with operations personnel. 21th International Workshop New Technologies and Work 2003 (NeTWork), design for Safety. Berlin 29 - 31 may.

[9] EATMP Human Resources Team (2000). Human Factors Integration in Future ATM Systems – Design Concepts and Philosophies. HRS/HSP-003-REP-01. Edition 1.0. Released Issue. Brussels: EUROCONTROL.

[10] Figarol, D. and Chatty, S. (2001) design lifecycle in ATM.

[11] Grau J.Y.,. Drogoul F., Guichard L Guibert S. & Gawinowski G. (2003). Safety assessment for validating new concepts in air traffic control. 12th. International Symposium on Aviation Psychology, 14-17 April 2003, Dayton, Ohio.

[12] Hale Andrew, Kirwan Barry (2003). Safety in the design process- opening Pandora’s Box. Network 2003. Berlin.

[13] Health and Safety Executive (1995), Out of Control, Why control systems go wrong and how to prevent failure, London, UK.

[14] Health and Safety Executive (2003), Mutual misconceptions between designers and operators of hazardous installations, J S Busby, University of Bath.

http://research.faa.gov/volpe.asp


xii Project SAFBUILD - EEC Note No. 12/05

[15] Jackson, A. (1998) HF Integration within Concept Development, Design, and Pre-Operational Evaluation: A Pragmatic Approach. Third Eurocontrol Human Factors Workshop, Luxembourg, 1998.

[16] Kennedy, R., Jones, H., Shorrock, S. and Kirwan, B. (2000). “A HAZOP analysis of a future ATM system”. In P.T. McCabe, M.A. Hanson and S.A. Robertson, Contemporary Ergonomics 2000. London: Taylor and Francis.

[17] Leveson, N.G. (2000) Intent Specifications: An Approach to Building Human-Centered Specifications. IEEE Transactions on Software Engineering.

[18] Leveson, N.G. (2004) A New Accident Model for Engineering Safer Systems. Safety Science. Vol. 42, No 4.

[19] McMahon Chris (2004), Process models – Cinderella among design modelsDepartment of Mechanical Engineering, Complexity workshop, University of Bath, UK.

[20] MEFISTO http://giove.cnuce.cnr.it/mefisto.html.

[21] Nadine Sarter, David D. Woods, and Charles E. Billings.(1997) Automation Surprises. in G. Salvendy (Ed.) Handbook of Human Factors/Ergonomics, 2nd Edition, Wiley, New York.

[22] Nik Mottershead and Elliott Hey (2004), Enabling Users To Create A Clear Visual Hierarchy For A Safety-Related User Interface.. HCI.

[23] Norman, D.A. (1986). Cognitive Engineering in Norman, D.A. & Draper, S., (eds.). User Centered System Design, Lawrence Erlbaum Associates, N.J.

[24] PMI Standards Committee (1996). A Guide to the Project management Body of Knowledge. Project Management Institute, Newtown Square, P.A.

[25] Roberts, K. H. and Gargano, G. (1990) “Managing a high reliability organization: A case for independence”, in Von Glinow, M.A. and Mohrman, S. (1990) (Eds) Managing Complexity in High Technology Organizations. New York: Oxford University Press. Pp. 146-159.

[26] Sagan, S.D., (1993). “The Limits of Safety: Organizations, Accidents and Nuclear Weapons.” Princeton University Press, Princeton, New Jersey.

[27] Shorrock S. (2003) “Individual and Group Approaches to Human Error Identification”, Eurocontrol, EEC Note 2003-8 (I and II).

[28] Shorrock, S.T. and Kirwan, B. (2002) “Development and Application of a Human Error Identification Tool for Air Traffic Control”. Applied Ergonomics, 33, 319 – 336.

http://giove.cnuce.cnr.it/mefisto.html


Project SAFBUILD - EEC Note No. 12/05 1

1. INTRODUCTION

Safety in aviation, due to high risk nature of the domain, has a large economical and social impact. Learning after the event via accidents not only constitutes unnecessary loss of life but also seriously damages confidence in air travel from the flying public.

A previous Eurocontrol study [7] has shown that root cause of more than half of aviation accidents can be traced to design deficiencies. One of the main trends for Safety improvement therefore is about putting safety into design. The importance of design in modern industry is becoming ever more clearly realized worldwide. But little attention has been given to the fact that design is often not an ordered, progressive or even explicit process [12].

The Eurocontrol SAFBUILD project concept is simply stated - get safety into the design process itself, and have the designers ‘own’ a large part of the safety of their design. This report moves one step towards this objective.

A review on gathering data on experience from other industries was conducted with a particular focus on how they successfully addressed safety in design. The objective of Eurocontrol was to gain insight and best practices out of these successful experiences on what exist in other industries. The study came across different processes that managed to integrate safety into design. Then, taking into account differences between ATM design and those industries, the main questions are:

• What should be adapted for ATM? • What are the gaps?

1.1. SAFBUILD SUMMARY

The SAFBUILD program aims to build safety into design in EEC projects through defining and researching applicable means for building safety in the design process of ATM systems. It encompasses a large number of varied activities such as tools, techniques and methods to support the inclusion of safety into development processes with an ultimate aim to derive an integrated approach adapted to ATM R&D.

SAFBUILD aims to support designers in their safety role, to develop a process and supporting tools for integrating safety into the design throughout the design life cycle, leading to a safer and more resilient ATM system.

The principal drivers for SAFBUILD were:

• A claim that 60% of the root causes of accidents arise in design stages. • A ‘model’ of the integration of safety information based on established practices in the

nuclear and motor industries based on the existence of ‘safety information databases’ and the systematic application of relevant data at an identifiable ‘design stage’.

The basis for these drivers, however, comes from other industries. While ATM has similarities with respect to other industries, it also has significant differences. Thus, SAFBUILD includes investigation of these differences, their significance for ATM and the development of an appropriate model for building safety into design for ATM. In order to achieve this, SAFBUILD also includes consideration of the context in which EEC projects are carried out and the use that is made of the outputs from projects.


2 Project SAFBUILD - EEC Note No. 12/05

1.2. PURPOSE

The purpose of this study is to determine how EEC should build safety into design by reviewing other industries, in particular to identify what design practices and safety considerations are most beneficial to assuring a ‘safe design’.

The review covered representative sources from a range of industries with mature safety cultures, specifically ATM, aircraft, railway signalling, process industries (chemical, nuclear power, food) and automobile systems. Sources were chosen to cover a range of viewpoints including end user/operator, system supplier, regulator and best practice guidelines.

The European Safety and Reliability Data Association (ESReDA) was used In this context, as well as failure event databases of raw data drawn from specific collection campaigns, which analysed the performance of component reliability against a variety of factors. Component reliability databases provide average failure rates, failure on demand probabilities and repair times for components at different population size under various operating conditions.

The SAFBUILD project considered that an important step to integrating safety into design was to provide visibility on best design practices and processes leading to mistakes. Moreover, scanning practices from other industries and demonstrating how to tailor those practices to ATM (Air Traffic Management) was considered as a necessary step to widen the scope to foster innovation while benefiting from a return of experience leading to best practices.

The report therefore contains a core section with detailed annexes related to practices in the industries:

The core section:

• introduces the approach, the scope and the findings from other industries; • discusses the discrepancy between ATM and the other domains under scrutiny; • states how safety is accounted for in ATM and in Eurocontrol; • presents and discuss the best practice findings from the review and their potential

adaptation for ATM. The annexes provide the details of the overview of best design practices from the industries reviewed in the analysis.

2. APPROACH USED

The approach used for this study was to select and review representative sources from a range of industries with mature safety cultures and to cover a range of viewpoints. Then, particular best approaches were consolidated into more general findings that could be potentially applied as generic principles.



3. DEFINITIONS

The following definitions are used in this study.

Safety is freedom from unacceptable risk of harm1.

Design can be used as either a verb (‘to design …’) or a noun (‘a design …’).

As a verb, design is the process by which detailed specifications sufficient for unambiguous production of an entity (e.g. software item; hardware; visual display; subsystem; system) are developed to satisfy the concepts, requirements, assumptions and constraints for that entity. Design does not include the production of the entity (e.g. software coding; production of hardware; etc.).

As a noun, design is the product of design activity.

Building safety into design is defined as the process of designing attributes and features into a design that enables its implementation to achieve the required level of safety.

Context of a design refers to the environment in which a design solution must operate. This embraces the scope of the design, the characteristics of the users, the physical environment, the software environment, the operational context.

Design Lifecycle

Figure 1: Variations on development cycles

There is a very substantial literature proposing models to describe the processes involved in system development. The most common (‘Waterfall’, ‘V’, ‘Spiral’) development cycles are depicted in Figure 1. The classical 'V' model steps are detailed in Figure 2.

More recently, a number of researchers have begun to explicitly recognise that projects are developed in the context of other, similar activities, such as feasibility tests and precursor projects. The MEFISTO Project [20], for example, proposes a two stage ‘vV’ model to include prototyping for design clarification. Even more creatively, Figarol and Chatty [10] have combined the spiral and the V to capture the sequence of an open, iterative process for design, followed by a more structured one for product development.

1 ESARR4 (EUROCONTROL SAFETY REGULATORY REQUIREMENT - ESARR4 - Risk Assessment and mitigation in ATM.



1 11

2 10

9 3

4 8

5 7

6

Figure 2: Standard IEEE V model

Note that in general it is more correct to speak about a development life cycle than a design life cycle. The latter actually refers to the life of a particular design instance. Actually, it would even be better to define a project/product/system life cycle which would unambiguously include operations and decommissioning. In terms of the scope of activities undertaken at the EEC, only the first four phases of this lifecycle are addressed in a way that is likely to have an impact on subsequent ATM system developments2.

In addition to the phases of the cycle there are also potential improvements to be made in the management of the cycle itself. There are a number of issues in development which have potentially important impacts for the safety and quality of the final product system, e.g. legacy problems in reuse, unnecessary complexity through inheritance, operation of systems outside of design intention. These may be improved or mitigated in a number of ways, e.g. better traceability, recording of design rationale, etc., through better management of the lifecycle itself. This issue can be addressed by including another ‘target phase’ in the scope ‘management of process/lifecyle’3.

Therefore, the first four phases of the lifecycle (in figure 2) together with the 'target phase' in its management constitute the effective scope of EEC projects and define where safety information can be applied (Target).

2 The cycle described is the cycle of ATM development. There is an additional issue of identifying more clearly how the work done in an R&D centre like the EEC impacts/participates in the overall cycle of ATM system development. Our work is defined as pre-operational. However, our assumption is that specifications and prototype designs developed at the EEC, often for testing and feasibility purposes, will at a minimum serve as ‘role models’ for subsequent development. In other cases, they are likely to be used even more directly as contributing directly to the ‘requirements’ for new systems.

3 This element would need to reflect prevailing validation strategy requirements + safety requirements (through safety assessment for the new design).



However, the scope of relevant safety information may be larger, in that experience gained from all phases in the real world may generate information, or even requirements, which could be relevant for system design, e.g. certain system architectures may be easier to maintain thus reducing certain types of risk. Thus ‘lessons learnt’ from all phases are potentially relevant to R&D project activities (Source).



Table 1: Industries, viewpoints and sources

4. SCOPE AND CONTENT OF THE REVIEW

The review has considered practices and safety considerations in the following industries:

• Railway signalling. • Air traffic management systems. • Aircraft systems. • Process industries (chemical, nuclear power, food etc.). • Automobile systems.

These industries were chosen because:

• Each has a well-developed safety culture. • Achieving a high level of safety is important for their public acceptability and business

success. • They span a large range of domains, from close to the air traffic management domain in

which the EEC works to very different types of domains.

Sources were chosen to cover the following viewpoints:

• End user or operator requirements on design. • System supplier design practices. • Best practice guidance within industry. • Regulatory requirements.

The sources chosen are given in Table 1. They are believed to be representative of the many other potential sources that exist within and outside the above industries.

Industry Viewpoint Source

Railway signalling End user, operator Railway Group Standards,

oard, UK Rail Safety and Standards B

Railway signalling System supplier Internal company procedures (confidential)

Air traffic ent System supplier ny procedures

managemInternal compa(confidential)

Aircraft systems Regulatory requirements ularly para 1309 . JAR 25, partic

Process industries Best practice guidance

6 (chemical, nuclear power, food)

SEMSPLC Guidelines IEE Technical Guidelines 8 : 199

Automobile systems Best practice guidance Development Guidelines for Vehicle

Based Software, 1994. (The ‘MISRA’guidelines)



The review addressed the following:

• Design activities and attributes with potentially generic value. • Aspects related to safety, whether explicit or implicit. • Processes, tools, techniques and methods that might be relevant to EEC design

activities.

It did not address:

• Phases other than design e.g. requirements specification. • Design activities and attributes specific to the industry with little potential generic value. • Aspects not related to safety. • Processes, tools, techniques and methods that are specific to the industry concerned

(e.g. for the design of circuit boards with industry-specific application).

In the case of system suppliers, commercial confidentiality has required that findings be only given at a general level rather than giving specific detail and those companies be kept anonymous.

For aircraft systems, manufacturers must comply with strict regulatory requirements regarding how safety is to be incorporated and demonstrated in design. These are rather more detailed and specific than what is usually available in other industries. However, it must be noted that EASA regulations are becoming less binding than previous JAA regulations from a legal perspective. The regulatory requirements have therefore been reviewed for this study rather than specific industry applications of the requirements (which are commercially confidential).



5. WHY ATM IS DIFFERENT?

5.1. CONTEXT

Every domain may initially appear to be unique or at least specific enough to raise scepticism when talking about transfer to another industry.

Strictly speaking, context is not a means by which Safety is built into design. But the review has shown that adaptation to the context is the main difference in the process used towards improving safety.

Context is a source of requirements and of constraints on the design [1]. Some of these constraints and requirements will surely relate directly to safety. Perhaps others will be more indirect deriving from the needs and constraints of operations. The critical part of this for building safety into design is essentially the correct identification of this context, its boundaries, and of these requirements and constraints.

5.1.1. Open or Closed System

Nuclear power plants are ‘closed’ systems, because they have defined boundaries and compartmented elements. In aviation, the Airbus philosophy for example is based on the definition of a flight envelope. The safe state of the machine is defined and margins are set to safe limits.

In ATM the system is ‘open’ in many respects. Multiple aircraft are moving through three-dimensional space in time across national boundaries, according to a mixture of pre-planned trajectories and variable routing structures. In addition, disturbances such as weather and passenger-induced delays impact the system and so induce less predictable behaviour of the elements of the system.

5.1.2. ATM an Integrated System

The notion of ‘envelope’ in ATM is different: everything feeds in the controller. We are in a position of a human centred situation whereas in other industries the edge of the envelope can be easily designed, the cognitive nature of the central element and treatment of information make this envelope difficult to set. All elements of the overall aviation system interact and all are linked to the human.

ATC and nuclear are therefore very different, ATC is one of the only activities where safety (separation of aircraft) is the principal product of the work. In nuclear like in chemical or else the product is energy or so and Safety is built in the tools [11].

Aviation should be seen as an integrated system. When something impacts on Safety the end effect is unknown. This is not the case in nuclear where impact can be isolated or at least localised.

In Nuclear Power Plants, dependence between the different safety ‘barriers’ is very limited. Operator actions are heavily proceduralised and checked rigorously, and there are many hardware and software-based back-ups that require no operator response. In ATM, principal barriers are temporal and spatial – ensuring that aircraft and other objects are not in the same place at the same time. Additional safety nets are also added but the possible dependencies between these barriers is rarely addressed.



It is difficult in ATM to measure the edge of the ‘safe’ envelope. Therefore, it makes sense to consider the activity of air traffic controller as an expert domain. Front line operators should be seen as the ones to know more about the work and the process. Consequently, the line of conduct should be to minimise additional constraints on front line operators as far as possible since the entire scope of the impacts cannot be predicted. It is important to recognise that front line operators guarantee the necessary flexibility of the design. It is for this reason that, for example at the EEC, controllers are heavily involved in the concept design process.

5.2. PRINCIPLES

5.2.1. Difference in Design

The differences in nature are reflected in the design process itself. In ATM we have to talk about design processes partly due to ATM non-modularity. It is a more organic and innovative process.

In the Nuclear domain, because design is not significantly changing at this point in time, it is heavily guided by standards which due to design ‘stability’ can be made very detailed. In ATM, where the whole system is undergoing major changes, the standards define much higher level constraints.

There also exists an inherent paradox with the implementation of Safety in design. On one hand, putting high priority to Safety is likely to require detailed analysis that will result in subsequent cost together with potentially many constraints and limitations for the selection of possibilities and options in a project. On the other hand, a wide range of possibilities may be necessary to create new means to mitigate major hazards identified for a new design. Safety emphasis for a design under development can potentially jeopardise innovation and creativity. The core issue there is: how to find a balance between safety principles and innovative options with no historical background nor comparison basis? In summary, the following conflicting characteristics apply to design in the ATM domain and may imply adaptation when learning from other domains:

• The fact that design appears to be a ‘community’ activity. Ideas enter the community from operations, industry or research centres and circulate over a number of years being tested or refined before achieving implicit acceptance or being rejected as unworkable.

• With this distributed approach it is very difficult to identify ‘designers’ or the optimal point of impact for safety information

• In general the ‘design’ processes in the nuclear and car industries are reasonably ‘focused’ on a particular installation, sub-system or model. Impact and scope are ‘relatively’ simple to assess. Although this can be the case in ATM, more generally ATM systems integration issues and the impact of changes may be very far-reaching.

• Safety literature frequently cites the fact that one of the special characteristics of the ATM system is that ‘safety’ is a ‘product’ unlike many other systems where it is a ‘quality’ of the output. This emphasis on safety may be one of the main reasons for the ‘diffusion’ of the design process since in fact almost the whole ATM community has to assure itself of the validity of a solution before it can really be put into practice.



5.2.2. Certification and Regulations

No certification exists in Air traffic control unlike the Aircraft industry because ATC is highly contextual and also because provision of the ATC service and its regulation used to be embedded into a single entity controlled by States.

The ATC domain raises another problem related to standards and regulations. The evolution of standards is often missing since the rationale for the standards is hardly documented. For example, a text in a Label should have a ratio of 8 to 1 (this is the standard for monochrome and it has never been revisited for colours displays). Moreover, standards and regulations for ATM are written in a "polished" bureaucratic format. For instance, Eurocontrol Safety Assessment Methodology (SAM) guidelines4 are embedded in Eurocontrol agency documentation writing procedures.

For early concept design however, such guidelines should ideally not be written in a prescriptive style approach and should not put too many constraints on the creative process. Rather, designers should be encouraged to use this creativity to look for ways to add safety value to future ATM concepts.

5.2.3. Change Impact

Nuclear Power Plants (NPP) incident and accident typologies are well-known, and there has been little change in their operation and technology in recent times. Therefore the whole NPP system can be assessed robustly via a mature safety assessment process.

ATM is going through a period of major change. More and more controllers become specialized on a limited environment. (licensed on a small number of sectors). They become more and more specialized and rely on expertise on the behaviour and knowledge restricted to a specific area. The standardization is therefore more difficult.

Car design is like ATM, in that it is also in a period of major change, but there is not a mature Hazard Assessment process – rather the car industry is in a test assessment culture. Car makers for example run cars for several months non-stop prior to public release. They also test and adapt technological innovation in extreme and severe conditions. They can test for a high representative proportion of the total life of the system (a new car design) while in ATM the equivalent Real Time Simulation (RTS) is not at the same scale of testing (3 weeks only). Moreover, ATM is a transport service for which the flying public is reluctant to accept the associated risks. Cars are products and there is less awareness by the public of the actual risks incurred from using cars (the public is instead more focused on the human being behind the steering wheel as the principal safety issue).

5.2.4. Safety Culture

Safety culture has been the focus of a large effort in the nuclear power industry since Chernobyl. There is still much that is not understood about what makes a good safety culture, although it is always relatively easy to spot a bad safety culture. ATM has a strong culture, because the nature of the job is high pressure and high responsibility, and so the controllers, and the managers themselves (usually ex-controllers) are strong people. This strength can have positive and negative consequences, e.g. there is a tendency towards conservatism in the industry, against change. Nevertheless, the positive aspects clearly outweigh the negative ones at this point in time.

4 http://www.eurocontrol.int/safety/GuidanceMaterials_SafetyAssessmentMethodology.htm



Safety culture approaches can help to understand why ATM is safe, and can help to ensure that as ATM and controllers and managers themselves change (and they will given the rate of change in ATM), the key strengths are maintained and not inadvertently discarded.

5.2.5. Systemic View and Models

Effective control of safety requires that we can model the basic technical and human processes of the system, locate accident scenarios in them, understand the causes of them, define control measures and strategies and design effective management systems to ensure those controls are put in place, maintained and improved. The ATM domain lags a decade behind the nuclear and process industries in making such explicit models of safety and risk control, including explicit and auditable safety management systems. Because they consist of many actors, working for different organisations, such transport system models have to be integrated across organisations and actors, which makes them doubly difficult to create. For the moment risk assessment and management are based on inadequate system models for being carrying out effectively. They are too limited or not validated or too specific or too high level. However, without them, it is impossible to optimise design choices based on safety considerations, or to prioritise risk prevention or assess the effect of change (in hardware, software or organisation) on safety performance.

5.2.6. Knowledge Management

ATC and nuclear are again rather different; ATC is one of the only activities where safety is one of the products of the work, together with traffic flow efficiency5. In the nuclear domain as in the chemical industry or other industries, the product is energy or an industrial product and Safety is built in the tools to design, manufacture and control the end product.

One of the major problems in maintaining knowledge and reusing information is that all information is context dependent. If any information is going to be reused, the context where it originated should be available to support the proper re-interpretation and instantiation.

The question for design projects is, therefore, one of determining what design practices and safety considerations are most beneficial to assuring a ‘safe design’. Knowledge management is not only about safety, it is also about requirements capture. It is a learning approach.

Unfortunately, previous experience, e.g. Human factors Integration in Future Air Traffic Management systems (HIFA)6, Validation Data Repository (VDR)7, FAA Human Factors (HF) Guidelines suggest that the ‘database’ approach as such is too passive to impact effectively on current ATM R&D working practices. A database is of value only if it has an operational link and instantiation. The link with real data and past experience has to be built. The use of database has to be incorporated in a defined and coherent process.

5 Refer to ICAO Doc 4444 ATM/501 "Procedures for Air Navigation Services Air Traffic Management" Air traffic control service. A service provided for the purpose of: a) preventing collisions:

1) between aircraft, and 2) on the manoeuvring area between aircraft and obstructions; and

b) expediting and maintaining an orderly flow of air traffic. 6 http://www.eurocontrol.int/eatmp/hifa/hifa/HIFAhelp_hifa.html7 https://www.eurocontrol.int/eatmp/vdr/jsp/PUBLIC.jsp

http://www.eurocontrol.int/eatmp/hifa/hifa/HIFAhelp_hifa.html

https://www.eurocontrol.int/eatmp/vdr/jsp/PUBLIC.jsp



6. WHAT WE HAVE IN ATM AND MORE SPECIFICALLY IN EUROCONTROL

Safety assessment has evolved towards a more explicit and structured "safety" in ATM with regulations being enforced.

Eurocontrol has produced Eurocontrol Safety Regulatory Requirements (ESSARs). Moreover, Eurocontrol also provides guidelines and proposes methods to meet those standards and requirements. Those methods are currently being used on a regular basis on a majority of large scale ATM projects and constitute standard practice for the projects sponsored by the European Commission.

6.1. SAM

Eurocontrol has provided a Safety Assessment Methodology (SAM)8 to help ANSPs fulfil the ESSARs. SAM improves the ability to identify and prevent hazards in current and future ATM operations. So far for example several methodological developments have focused on dealing with ‘human error’ and human factors in safety, as the role of the controller is so central to ATM safety.

The SAM methodology describes a generic process for the safety assessment of Air Navigation Systems.

This process consists of three major steps:

• Functional Hazard Assessment (FHA); • Preliminary System Safety Assessment (PSSA); • System Safety Assessment (SSA).

This process is aligned to the engineering lifecycle of a project. Figure 3 shows the relationships between these major steps and the overall System Life Cycle.

The methodology describes the underlying principles of the safety assessment process and leaves the details of applying these principles (or supplementing them if necessary) to be defined for each specific project.

8 http://www.eurocontrol.int/safety/GuidanceMaterials_SafetyAssessmentMethodology.htm

http://www.eurocontrol.int/safety/GuidanceMaterials_SafetyAssessmentMethodology.htm



STEPS Lifecycle applicability

Figure 3 - Relationships between the safety assessment process and the overall system life cycle

6.2. EEC SAFETY

The focus of the Eurocontrol Experimental Centre projects is mainly on early design and conceptual phases. Therefore usually only FHA steps of the SAM methodology apply to the internal projects.

The EEC has therefore developed a Safety Policy, and a safety assessment approach that has been tailored to fit this early stage of the ATM system design process.

In term of Safety Assessment EEC has developed a toolbox of methods that are applicable in the range of R&D projects.

Safety R&D at the EEC is helping Eurocontrol to develop new and better methods of safety assessment and assurance for current and future systems. Some of these methods are adaptations form other industries where such assessment practice is relatively much more mature. Such new/adapted methods are being applied and tested at the EEC to enhance the level of safety built into new designs and concepts. The resulting methodological adaptations and advancements are as follows:

• A generalised hazard assessment approach – HAZOP. • Human error identification – TRACER-Lite. • Ways to model new concepts and systems for safety assessment – SADT. • Ways to model human involvements – Hierarchical task Analysis. • Ways to model human dependency in assessments – THERP Dependence Analysis. • Quantification of human error probabilities – CORE-DATA database and formal expert

judgement procedures. • Hazard identification for related systems – Cross-Boundary HAZOP. • Safety assurance for live trials – Live Trial HAZOP. • Safety insights in simulations – SAFSIM. • Hazard and safety requirements tracking systems – HARTS.



7. FINDINGS OF THE REVIEW

The framework of the review encompasses the variations in the range, scope and objectives of projects and the shifts and changes that can occur in design processes and philosophy due to external pressures and events.

The following details are available in the annexes:

Table 2: List of annexes and contents

Industry Perspective Reference

Railway Signalling End User, Operator Details Appendix A

Railway Signalling System Supplier Details Appendix B

Air Traffic Management System Supplier Details Appendix C

Aircraft Systems Regulatory Requirements Details Appendix D

Process Industries (Chemical, Nuclear Power, Food)

Best Practice Guidelines Details Appendix E

Automobile Systems Best Practice Guidelines Details Appendix F

The following general observations are made about the above findings:

1. There is much in common in the way that safety is built into design in the different industries.

2. The different viewpoints (end user/operator, system supplier, regulatory requirements and best practice guidelines) also give a consistent picture.

3. Where there are differences, these are either due to the specific nature of the industries or viewpoints, or they reflect differences in emphasis rather than substance.

4. Safety enters the design process via external requirements and is expressed in terms of attributes that the system must possess.

5. Building safety into design involves adopting design practices that produce the required attributes for safety and do not produce unsafe attributes.

6. Safety in design must be verified as part of the design process.

7. Safety is implicit rather than explicit in the design processes of the two system suppliers; this is because their systems are inherently safety-related and safety attributes are expressed via technical requirements.

The findings can be put into three categories:

1. Context: These elements give the context in which design is carried out and affect design safety, but they are not part of the design process itself. They play an essential role in the definition of the scope and the boundaries of the intended operations that are anticipated using the design.

2. Principles: These address aspects of safe design process or attributes of a safe design. In the airborne domain, they are used to substantiate to a certification authority that a design has the potential to meet its safety targets.

3. Tools, methods and techniques: These are used as appropriate to carry out specific design activities. In the airborne domain, they contribute to providing evidence of safety assurance.



The next 3 tables summarise the findings for the different industries and viewpoints under the above three categories. Findings in each category are divided into Primary findings and Secondary findings. Primary findings are widely applicable, generic findings synthesised from across the industries and viewpoints. Secondary findings supplement Primary findings. They are more detailed than Primary findings and may therefore not apply to all situations.

The aim for Eurocontrol is to enlarge those findings to be effectively useful for designers.

A necessary part of this section is also to determine what design practices and safety considerations are most beneficial to assuring a ‘safe design’ and how relevant they are to the ATM domain. The review will be analyzed point by point in terms of applicability, best practices and gaps.

Under each table a summary of gaps and existing practices in EEC are presented where applicable.

Table 3: Synthesis of context findings

Primary Secondary Context Design safety attributes should be determined by external requirements (safety requirements)

Safety requirements to be determined within a risk-based framework

Safety requirements may include safety integrity levels

Safety requirements should define the contribution to safety from the different ways in which the design can operate or be used

Safety requirements should consider design constraints Design constraints may include system architecture, hardware and software as well as constraints arising from the context.

Requirements may need to be modified due to findings from the design process itself (e.g. from the results of prototyping)

Persons working on safety-related design should have suitable training, experience and qualifications

Where persons do not have suitable training, experience and qualifications, they should be adequately supervised and their work reviewed and checked by appropriately qualified persons

External requirements: In general, the means for building safety into design are based on the existence of safety requirements that have been generated by the end user and are appropriate for the intended application. No specific provisions were found for research and development projects where application-specific requirements are not likely to exist. However, both of the system suppliers (ATM and railway signalling) develop new systems for international markets. Design of new systems is understood to take into account the likely high-level requirements from the market (e.g. from regulation) and to aim at producing designs that can readily be tailored to the specific safety requirements of individual applications. In addition to "safety", such an approach is also driven by economical considerations for distribution of fixed costs over several customers, both for development and maintenance of a design. Thus, design principles include producing an application-independent design prior to an application-dependent design (ATM system supplier) and the use of prototyping to help develop requirements as well as the design (railway signalling system supplier).



The need for safety requirements has been identified in EEC projects but the specific R&D environment suffers from the lack of a standardised requirement capture process.

Constraints: Future ATM systems or sub-systems do not end in a vacuum but have to be integrated into existing operating environments. Consequently, it is essential to capture and document the same level of understanding of existing systems as new ones. The existing requirements must be turned into constraints and safety should be driven by design constraint as part of the design team. This is essential in order to ensure feasibility of a smooth transition to new operating methods with a new design.

Training: Design activities do not necessarily understand safety. Designers do not necessarily have a clear view of Safety (similarly safety practitioners may have only a limited understanding of Design). Training is therefore required for dissemination to enable integrated safety work in projects.

Gaps: • Requirements are not fully captured. • Design works need to be more embedded. • Training is also a gap. More safety assessment training is needed. • ‘Design’ stages are not always identifiable.

Best practices:

• ESARR 5 already ensures the proper checks and levels of qualification for controllers. • There is a recognisable design and development lifecycle. • An integrated risk picture will be produced for 2004 and 2012 ATM concept development

showing where safety is critical.

Table 4: Synthesis of principles findings

Principles

There should be two levels of design, high-level architecture and detailed design

The high-level and detailed design levels may be further subdivided in order to facilitate safe design

The design should incorporate a clear strategy to deal with failures and errors

The design should use, as appropriate, specific attributes such as fault tolerance, failure recovery and revealing failures to operators

The design should ensure that : − the operations based on the design degrade

gracefully through a defined hierarchy of states or modes in the event of faults or disruption;

− the state or mode is made apparent to the operator.

The design should ensure easy, error-free recovery from failures

The design should address the system response to errors, including human error.

The design should consider the balance between features to enhance safety and the resulting increase in complexity (which can make it more difficult to assure safety)

The design should aim to minimise complexity while having the desired safety attributes



Principles

The design should be modular Modules should be defined so as to simplify interfaces, minimise complexity and facilitate integration and testing

Modules should have high cohesion and low coupling

The design should consider segregation or partitioning as a means to enhance safety

Safety-related and non-safety-related modules, subsystems and hardware components should be segregated

Modules, subsystems and hardware components with different safety integrity levels should be segregated

The design should be fully documented Specifications should be documented at all levels of design, including functional specification, architecture specification, software specification

Modules should be specified in sufficient detail that the person responsible for their realisation (e.g. coder for software modules) does not have to make any assumptions

The safety of the design should be demonstrated Demonstration should be by means of analysis for a new or modified design, evidence of ‘proven in use’ may be used for an existing design

The inclusion of safety at the design stage of projects, processes and products is now accepted as a necessity. There have been improvements in the preceding years but there are still areas of improvement that require attention.

Requirements: Generally, building safety into design is based on the existence of safety requirements that have been generated by the end user and are appropriate for the intended application. However, system suppliers make provision for flexibility in requirements by means such as application-independent designs and development of requirements during the design process via, for example, prototyping. Safety requirements are expressed in terms of attributes that the system must possess. Building safety into design involves adopting design practices that produce the required attributes for safety and do not produce unsafe attributes.

It is important to ‘cascade’ safety through requirements' determination (this means ‘joined-up’ safety thinking so the resultant whole product has safety as a property). An interesting perspective is the possibility of testing captured requirements and testing if they are safety related. The philosophy of an approach like Nancy Leveson’s one is to put safety into the requirements' capture process and verify if those are actually implemented in the end product [17], [18]. This is unlikely to be usable at the EEC stage of concept design, but could be useful for projects in later design stages wherein a formal requirements capture process is applied.

When talking about Safety it happens that the concept itself can be unsafe. Many Safety concepts come from the nuclear industry and do not transfer easily to ATC. Therefore, safety concept seems to be a real issue to consider. Clearly, safety requirements have to be traded-off with other objectives sought by a concept.



Strategy: The following paragraphs consider and evaluate some of the safety-in-design strategies available to ATM from other industries.

Target level of Safety (TLS) The TLS (target level of safety) is in some way a means of capturing hazards and impact while giving a landmark and reference for designers. Design does not seek "perfection" but rather the appropriate balance between the goal and the constraints (cost, timing…) to reach this goal. Therefore, it is important to find the relationship between the major elements (including safety), and understand the impacts and the needs. It is usually very difficult for a designer to have an idea of the Safety impact of a design decision or design option because safety does not often provide a global impact description – however assessment of a system design against a TLS does give a global impact statement. TLS is therefore a useful concept for design safety, though there can be difficulties in assessing a design against a quantitative criterion at an early design stage.

Modularity: The modular approach to Safety is not a full ATM solution. Although ATM can be described in modular terms, in reality it is far from modular due to the open and human centred nature of ATM. The danger of a modular approach is that safety may appear to be okay in each module, but the interactions and inter-dependencies are not fully addressed, and the impacts of these can be significant. The approach that needs to be developed is to consider a notion of performance envelope and ensure that the system remains in the boundaries of the envelope [8]. The freedom that would be left would be related to productivity and human flexibility. This in turns substantiates the validity of a human-centred automation approach in which the operator is able to maintain his/her skills. Designing an efficient and safe human/automation partnership however remains a significant challenge [26].

Segregation: The segregation principle in ATM mainly relates to separation standards. SAM tries to do technical segregation. ATM has also tried to have safety nets that are independent but the recent Ueberlingen mid-air collision accident has raised questions on the degree of independence of those safety nets.

Demonstration: In ATM it is too early to require a systematic safety case for research in the R&D environment. The developing ESARR (European Safety Regulations) are rightly requiring more formal and explicit analyses for system designs that are to be implemented. ESARR4 calls for risk arguments to be based on an overall risk target level (TLS) of safety for ATM of 1.55 E-8 accidents per flight hour. Now that this TLS has been set, all safety arguments for future ATM must relate to it, and therefore must themselves end in a quantification of risks to show that they are safe enough. This is a good step towards demonstration.

Another step forward for new concepts could be Hazard log: This technique to record all identified hazards, and to be able to trace all hazards with document follow up is not difficult to implement and is heavily used in other domains with success. This approach creates a ‘safety memory’ for concept designs. This is important because of frequent re-use or partial re-use of former concept studies in ATM.



•

Table 4: Synthesis of tools, methods and techniques Findings

Documentation: Designers should be able to retrieve readily available information for different parts of a new design that are safety-relevant in order to assist them in the decision making process. The idea of a database can be borrowed from other industries. The real issue is that some designers do not completely realize that they are making crucial decisions relevant to safety as part of the design activity, and that these decisions impact upon the end product.

Gap: • Modularity is not an option for ATM. • No or limited certification for ATM at present. • Lack of regulations applicable at the early concept stage. • Safety Strategy is independent to Concept development and projects strategy. • Link between the past experience and design is lacking.

Best practices:

• The outputs of any ATM project should be more than statements but should contain analysis, contradictory debate and recommendations.

• ESARRs seek for arguments and documentability. • The integration of safety in design at Eurocontrol is ujnder development. • Commitment to safety is needed. • Economic pressure and the regulation process tend to promote the idea of a harmonised

Air Traffic Controller (ATCO) licence for ECAC States9 as well as a high-level logical design of an integrated ATM "system of systems" across all ECAC States, towards which the present individual national systems shall evolve10. Standardisation process is likely to emerge in the ATC w• orld...

• A culture in which both the need and the value of the integration of safety information is recognised and supported by the organisational and cultural practices is needed. Safety culture maturity is under scrutiny.

Tools, methods and techniques 1

Appropriate tools and techniques should be used for

ds for l airborne

ools and techniques include: safety analysis during design Note: Example "Guidelines and methoconducting safety assessment process on civisystems and equipment", SAE ARP4761 (Aerospace Recommended Practice)

T− HAZOP − ‘What if?’ analysis − ‘What causes?’ analysis − Failure Modes and Effects analysis (FMEA) − Fault Tree Analysis − Formal specification and proof − Common Cause Assessment − External Events Analysis − Human Error Assessment and reduction

Technique Appropriate tools, methods and techniques should be used for design specifications

Well written natural language (e.g. English) for simpler systems

Mathematical, for example: − Z − HOL − VDM

9 Refer to "http://www.eurocontrol.int/humanfactors/public/standard_page/Licensing.html" 10 Refer to OATA (Overall ATM/CNS Target Architecture) "http://www.eurocontrol.int/eatmp/oca/architecture/oata_overview.htm"

http://www.eurocontrol.int/humanfactors/public/standard_page/Licensing.html

http://www.eurocontrol.int/eatmp/oca/architecture/oata_overview.htm



Tools, methods and techniques 1

techniques for functional processes, for

low diagrams

Proceduralexample: − Data f− System threads

chniques for manipulation of − Object oriented tedata

− State transition diagrams − Timing diagrams, for time sequencing Appropriate tools, methods and techniques should be used for hardware design

Hierarchical block diagrams

State transition diagrams and tables

Appropriate tools, methods and techniques should be ontrol flow analysis used for software validation

C

Example: "Software considerations in airborne systems Modular analysis and equipment certification", EUROCAE ED12-B/RTCA DO178-B Information flow analysis Equivalence analysis Semantic analysis Impact analysis Completeness analysis Fault Coverage analysis Failure behaviour of hardware Formal proofs

Notes: tools, techniques and methods given here are specifically referred to in documentation. The documents 1. The

also refer to other sources for alternatives.

Process:

esign must be verified as part of the design process, this involves an appropriate

provide good processes to enhance safety assessment in projects but it

Safety in dcombination of analysis and testing which should be defined and planned during the development of the design. It would even be better to also account for the risks associated with the adequacy (or not) of testing, that is to inter-relate risk evaluation with verification and validation processes. Otherwise there exists the risk that people who do not use terminology in the same way will allocate resources for dealing with issues in the design process which are actually located elsewhere. ESARRs, SMS, and Safety policies are defining a framework and a process for rational, documented and efficient safety technique application.

Appropriate techniques: SAM and the EEC toolbox is already identified that some methods are missing. For example the nature of recent accidents in ATM has shown the importance of capturing the full range of human responses in hazard-related scenarios. ESARRs already require fault and event tree analysis or equivalent approaches as in the nuclear power and other industries.



Representativeness: In terms of tools and techniques the strength of ATM is the use of Real Time Simulations. Many domains do not have such extensive simulation capabilities. Real-time simulations help to justify changes and new systems, though measures during these simulations are not always robustly controlled with respect to safety.

Human Reliability Assessment (HRA): HRA is relatively unknown in ATM, only a few recent qualitative studies of human errors using techniques such as TRACER or HAZOP are available [28], [16], [27].

Databases: Actually, there are few elements that are universally known to have the potential to create major sources of hazards in an end product [13]. On the other hand, such elements are very likely to embed latent failures. Consequently, designers would benefit from a database which would warn them of those elements or factors that require special attention to have a potentially safe design. Turning a “potentially safe design” into a “really safe design” would in theory only actually require small adjustments of low level requirements and safety management of the design process. On the contrary, missing important elements to ensure the potential for safety is likely to require major re-design effort thus leading to inefficiency (cost, resources, development schedule, and deployment problems).

The use of reliability database (for components but also human element) is missing in ATM. The primary source of hazards today lies in people's misconceptions about systems and their intended usage. This includes the misconceptions of designers about operators (controllers), operators' intentions and the operating environment; and it includes the misconceptions of operators about the design, its rationale and boundaries of safe operation.

These misconceptions are, moreover, related. A designer can have a misconception, for instance, about an operator's usage of the design and an operator a misconception about the intended operations sought by a design [14]. It is therefore important that in the future both designers and operators can scan through historical misconceptions both of other designers and of other operators when reasoning about the risks that a new system may embed [22].

Where no databases and no appropriate techniques exist, there can be recourse to expert judgement, using formal procedures and validated experts. However, because expertise is known to suffer from biases, and since by definition experts on the failure behaviour of future systems have limited expertise, expert judgement protocols must include means for detecting biases and incoherent judgement, and hence rejecting the results should the expertise fail according to certain quality criteria.

Top down safety: With the SAM and toolbox increased usage there is a danger here that ATM risk assessments ‘compartmentalise’ too much, i.e., given the vagueness of the boundaries, that some of the risks become ‘someone else’s problem’. Many safety assessment techniques may be considered ‘bottom-up’ safety, dealing with the important details of projects, but there is therefore a need for a complementary ‘top down’ approach, one that can consider how various future ATM tools and concepts will work together to achieve the overall target level of safety. This therefore means there is a need for more ‘integrative’ assessment of the whole system including sub-system or modular interactions, as is being developed in Eurocontrol at the moment via the Integrated Risk Picture.



Gaps: • It is difficult to specify the boundaries of a design. • Be careful when only using expert judgement.

Best practices:

• The necessary and relevant ‘safety’ information has been captured and exists in the appropriate form for integration.

• ATM has improved in reporting accidents and incidents with ESARRs application and incident database development.

• Development of an Integrated Risk Picture is ongoing in Safety R&D.



• d the idea to develop a safety reference database for

• or learning from incidents is needed.

8. WHAT ATM CONCEPT DEVELOPMENT NEEDS IN TERMS OF SAFETY

Some specific design principles, practices, tools techniques and methods for building safety into design have been identified from a contrast of ATM with other industries and listed. However, the choice of which to use depends on the system and its safety requirements and principles. A design is safe only within a certain range of operating and environmental conditions and when used in certain ways; establishing and defining these is part of building safety into design.

It is important to realize that inadequate definition and description of requirements can only result in 'poor design' or use of system elements outside their design envelopes. Therefore, it is important that R&D for ATM moves from investment decisions based on "habits" and "assumptions" towards a documented decision-making process that substantiates where, why and how to target development improvements.

If we recap the main points of the review and discussion about the applicability of the insight from other domain into the 3 main group previously defined, safety needs for ATM are:

In terms of context:

• ATM needs a culture of requirements capture and documentation. • Working in conjunction with projects to ensure appropriate organisational practices to

support the delivery effectively. • Match safety process to design context.

In terms of Principles:

• It needs to be a coherent process integrating tools and methods to identify safety requirements in ATM.

• The EEC activities are about conceptualization, early design and development. Safety needs to be integrated in design activities. Safety experts should work with designers so they can understand safety, and safety requirements should be embedded within design constraints.

• Need for a more embedded work, a more integrated approach. • It appears difficult to have formalized concept design process but ATM needs structure. • Because of the ‘organic’ nature of design a Safety Management System is needed to

guide the principles of safety. • Commitment to apply those principles is required to achieve the above, especially since

there is not regulation at this level currently.

In terms of Methods:

• We need to further develop some methods (e.g. HRA, etc.). • We need to standardize the usage of method and tools to be able to enhance feedback

and enable comparison. The success of reliability • database in NPPs suggest that it should be used in ATM.

• We run simulations where we could investigate and learn more about safety for projects or new ATM organizations. The nuclear industry raisedesigners. Technique f



9. WHY DO WE STILL HAVE GAPS?

We have seen that for instance we cannot stick too closely to the nuclear ‘template’, ATM and nuclear are two different domains, and so adaptation of principles, methods and practices are needed. The remaining question is why this adaptation is not yet done?

Similar experience from attempts to introduce human factors knowledge into the design and development process has suggested that these are difficult issues. It is not sufficient to simply collect good data, or even good practice and ‘point-it’ at the R&D process. There is little take-up unless the information is visible, useful or otherwise facilitates the activities already going on in the R&D. Additionally, one of the basic processes of design is that of resolving apparent conflict between requirements by understanding their priorities. In some kinds of design, like HMI for graphical interfaces (and we would suggest safety), priorities can often be highly context dependent. Under such conditions, general guidelines alone are of little use to end users. There is generally a need for expert support to selectively instantiate the guidelines to a particular context of operations. Consequently, it is not enough to set up a ‘pipeline’ of information flow between project targets and data sources. There are at least two additional requirements:

1. The ‘pipeline’ must transform and filter the data into a format which is directly accessible to the recipient project and it activities. This requires expertise.

2. The ‘pipeline’ must be ‘intelligent’ in the sense that the process must be adaptable over time. It must be capable of learning what type of information is useful and effective if delivered to the projects, where this information can be obtained, and what form of delivery is most effective.

Another characteristic is desirable:

3. The data collection process should not be passive. As the process learns what type of information is useful, it should be possible ‘to go looking’, to seek new information sources which can provide the relevant data.

However, this critical perspective does not invalidate the arguments for the value of the integration of safety related information into whatever design processes are currently present in ATM R&D; it simply suggests that the implementation strategies employed in other industries will probably not be directly applicable to ATM. Their intent must be re-interpreted and adapted to meet our different context. In particular, it will probably be necessary to re-examine our definitions of ‘design’ and perhaps of ‘safety’ itself.



10. CONCLUSIONS

A range of industries have been reviewed and safety is recognised as being of primary importance.

This study has examined the way in which safety is built into design for representative cases from a range of industries and viewpoints. The different industries and viewpoints are broadly consistent at the generic level (i.e. excluding industry-specific detail). Even if different by nature, it has been highlighted that all industries rely on the same fundamental basic principles for safety. The main differences lie in the adaptation to the context.

Integration of safety in design can be achieved based on established practices in other industries based on the existence of ‘safety information databases’ and the systematic application of relevant data at an identifiable ‘design stage’. While some best design principles are well founded on practices in other industries, those require re-examination in the context of ATM R&D and EEC practices in particular.



ANNEXES






ANNEX A - RAILWAY SIGNALLING (END USER, OPERATOR)

Company or Organisation Rail Safety and Standards Board Ltd. The responsibilities of this organisation include developing, maintaining and issuing safety standards and associated guidance for all systems and equipment to be procured and operated on the UK railway network. Source Documentation Railway Group standards and guidance notes, particularly GK/GN0806 ‘Guidance Note : Signalling and Operational Telecommunications Systems : Safety Requirements’ Issue 1, April 2002. Source Type Mandatory standards and associated guidance. Detailed Findings The sources take the viewpoint of the end user/operator and therefore address what should be included in the system design and the design process for them to be acceptable to the end user/operator.

The development of the system requirements should include consideration of:

1. The proposed system architecture, the principal hardware and software components that define the system, and the interfaces between them.

2. Hardware and software tools which are required in order to support the safe design and testing of the system

3. Constraints on the choice of technology The permitted modes of operation associated with the use of the system should be defined as part of the system requirements. For system design purposes it may also be appropriate to define system modes. For all modes, there should be clarity regarding the contribution made by the system to achievement of safety and that contributed by the users and procedures. As far as is reasonably practicable one or more of the following strategies should be incorporated into the design of the system to cater for the various failures (in descending order of preference):

1. full fault tolerance 2. limited fault tolerance 3. self-protection of failures 4. self-revelation of failures

In some designs, functionality may be retained by automatic reconfiguration of the system. Where protection is to be provided by ensuring that, in the event of a failure, the system automatically enters a known safe state, one or more of the following design philosophies should be adopted:

1. The use of components that are of fail-safe design, incorporate into a fail-safe application design.

2. The use of duplicated or triplicated subsystems. 3. The use of two or more diverse sets of software and data within a single channel system. 4. Self-checking within a single-channel system with rapid detection and shutdown in the

event of failure.



The degraded modes of the system should be arranged in a hierarchy so that modes in which safety is ensured principally by the system are use in preference to those that depend principally upon human action. So far as is reasonably practicable, the degradation of the system from normal modes through its degraded modes should be designed so as to be ‘graceful’, retaining essential functionality as much as possible. The system should be designed so that when it moves into a degraded mode the change in mode of operation is recognisable by (or indicated to) users.

The design of the system should facilitate easy, error-free recovery from failure conditions back to normal operation. It may be appropriate to incorporate self-checks so as to avoid operator or maintainer errors when undertaking the recovery process, where such errors could lead to impairment of safety.

The following safety-related factor should be considered when planning the overall system architecture and design:

1. The risks associated with the use of complex systems and architectures. 2. Segregation of safety-related subsystems from non-safety-related subsystems. 3. Physical design of sub-systems and layout of components in such a way as to minimise the

risk of safety-related hardware failure. When planning the system architecture and selecting hardware and software, maintainability should be considered.

When the system interfaces with other systems or infrastructure, interface requirements should be developed that adequately control:

1. The transfer of risk across the interface. 2. The risks associated with failure of the interface. 3. The risks created by an inappropriate interface.

Interfaces should be specified and designed so as to safe and reliable operation under all reasonably foreseeable circumstances.

Interfaces between the system and operators shall be designed so as to minimise the risk of operator error giving rise to an unsafe situation. (‘Operators’ includes all people who interface with the system, including maintainers.) (See Table A-1 for a list of factors to consider in the design).

Conformance of the system design shall be demonstrated by either or both of the following approaches :

1. Safety analysis and risk assessment, in the case of novel designs and novel elements of the design.

2. Application of proven designs.



Table A-1: Factors to consider in the design of operator-system interfaces

Allocating Functions Between the System and People

Requirements of legislation or Standards

Safety criticality of the activity and the potential for catastrophic consequences if it is performed incorrectly

The (generally) superior ability of people to make decisions and respond flexibly in circumstances where the information leading to the decision is complex, incomplete or imprecise

The workload on users, under both normal and exceptional circumstances. This includes not only the workload associated with use of the system itself, but also the total workload on users (e.g. where an operator may be controlling several systems)

The difficulties that users may have in acting correctly in circumstances that occur very rarely, including: the vigilance required to monitor the actions performed by the system in case it malfunctions; the risk of non-recognition of a malfunction because of its rarity; the likelihood of a user making an error under system failure or emergency conditions (when the system is not providing the safety protection that it normally does) and the user is having to perform actions in place of the functions normally carried out by the system; the stress placed on users in these circumstances.

Personnel issues such as job design and job satisfaction (etc.)

The reliability and repetitiveness with which the activity needs to be performed

The technological feasibility of automating the functions

Public perception of the acceptability of activities being automated or performed by people

Relative economics of people-based and system-based solutions

Where a Function Is To Be Performed By Users Security of access, so that only authorised personnel can perform the function

How the user will be aware of the need for the function to be performed (what cues are provided by the system)

The cues and information provided to the user to promote a correct action or response

How the system will respond in the event of user error, for instance by: prevention of an unsafe action; warning of an unsafe action; self-correction by the system (doing what the user intended instead of what was actually commanded); provision of context-sensitive help facilities.

The ergonomic design of the interface so that its operation by the user is as intuitive as possible, making it ‘natural’ to perform the correct actions

Operational Modes In Which The System Needs To Provide Information To Users System startup/initialisation/commencement of use

Normal operation

Response to abnormal/failure/emergency conditions

Operation and supervision under degraded modes of operation and total failure conditions

Safe restoration to normal operation after a failure or operation in a degraded mode

System shutdown

Other Factors Consistency with respect to other interfaces that the operator might use

Clarity about system boundaries and area of control

Visibility and legibility of interface control devices and indications (choice of text, symbols, colour etc.)

The environmental conditions under which the interface will be used (lighting conditions, background noise etc.)

Provision of a defined and logical hierarchy for the presentation of audible/visual warnings and alarms, optimised for human responses to such warnings and for the importance/urgency of the actions to be taken

Time duration for which audible/visual information is presented

Risks associated with the provision of configurable displays






ANNEX B - RAILWAY SIGNALLING (SYSTEM SUPPLIER)

Company or Organisation A major developer, designer and supplier of railway signalling systems Source Documentation Confidential. Source Type In-house procedures. Detailed Findings These are generic findings. Specific details cannot be given because of commercial confidentiality. Safety is not explicitly noted in most of the in-house procedures, it is implicit because of the safety-related nature of railway signalling systems.

Engineers working on safety critical or safety related design shall have appropriate training, experience and qualifications. Where this is not possible, they shall be adequately supervised by appropriately qualified persons and that the work is thoroughly reviewed and checked.

The design engineer shall determine the precise nature of the hardware requirements from the requirements specification.

The overall sequence of the software design and coding process shall be:

• Requirements specification. • Design the system functionality to satisfy the requirements. • Partition the functions into software and hardware. • Specify the software. • Decompose the software functions into ever more detailed design. • Convert the design into code.

A Functional Specification shall be written which defines what functions are required to fulfil the requirements. This shall form the basis for system testing and any user guides to be supplied. The implementation is not considered at this stage.

Using the Functional Specification as the basis, an Architecture Specification shall show how the system functions will be implemented. It will define the hardware/software architecture, data structures, functional components and interfaces of the product. Dependent on the complexity and nature of the design process, these may be specifications in their own right.

A Software Specification shall be derived and shall include, where appropriate, information on:

• Content of individual data structures. • Objects or modules. • Inter-component or inter-class interfaces (messages). • Data dictionary (defining the format of data structures and message fields).

Each software element shall be decomposed in order to provide further detailed information.

All interfaces between modules or classes shall be defined.



alysis

alysis

Brief s m B-1.

A notation or methodology shall be used for design decomposition which is appropriate to the project, for example:

• Well written English. • Mathematical, such as Z, HOL or VDM. • Procedural (e.g. Data Fow Design (DFD)), where the emphasis is on the functional

processes required. • Object oriented, where the emphasis is on the manipulation and transformation of data.

Use shall be made of CASE tools or other packages for ease of understanding where this is practicable.

Each individual module or class shall be specified. This specification shall include descriptions of the module or class, inputs to each function or member, outputs from each function or member, data structures used and transformations made, error conditions and actions to be taken.

The use of prototyping (rapid or otherwise) is permissible, either as a means of evaluating aspects of a design, or as a means of developing the requirements and the design in their own right. The following activities shall be used as a minimum:

• Stating clearly the aims and objectives for the prototype, particularly the aspects of the final product performance that are to be evaluated, before prototyping commences.

• Reviews to establish whether aims and objectives are being met. • Version control for the documentation and the prototype. • Involving the Users. • Planning and carrying out testing of the product. • Ensuring the transfer of the results of the prototype into the Requirements Specification.

The Module/Class specifications, together with the design documentation, shall be used as a basis for module or class testing. Test specifications are prepared at each level of the design, which can then be used after building and integrating the code to test at the corresponding level.

Hierarchical block diagrams shall be used for hardware design. Block diagrams comprise :

• Functional Blocks - these depict a specific function appropriate to the level of the diagram. Interfaces• - these depict the flow of data, power, control bussing etc.

If necessary, State Transition Diagrams or Tables (STD/Ts) may be produced to support the Functional Block Diagram(s).

Prototyping may be used and the results of testing the prototype used to further the hardware design.

A Test Specification shall be produced. This shall include both functional and non-functional aspects of the system.

Software Validation shall be carried out. This shall include, as appropriate :

• Equivalence analysis • Control flow analysis • Modular analysis • Information flow an• Semantic analysis • Impact analysis • Completeness an

u maries are given in Table



Table B-1: Techniques for software validation

Technique Summary

Equivalence Analysis Traces all requirements listed in the software requirements documentation to the software implementation. The requirements document is examined to ensure that all requirements are mutually consistent, unambiguous, complete and quantifiable

Control Flow Analysis At system level, a call tree or overall structure diagram shall be created which details how the software modules interact with each other and a graphic representation shall be created. For each module, control flow shall be examined to ensure it is well-structured according to good software engineering principles, e.g. that it conforms with Hecht or Dijkstra rules of program structure.

Modular Analysis Dynamic testing of a section of software to ensure that all paths through the code are executed in accordance with the detailed design documentation. For each test, predictions are produced to indicate the function that should be performed and the outputs to be generated. Test cases are derived from the design documentation to execute the paths through the code identified during structural analysis. The tests shall provide a rigorous level of coverage for the functionality included in the module.

Information Flow Analysis Analysis of how specific data values are passed through the software. The code is examined to ascertain how information in one section of the software is passed to subsequent sections with the intention of showing that data integrity is maintained.

Semantic Analysis Examination of the functionality of the software to ensure its operation is consistent with its requirements. It involves using the results of all validation analyses to assess the performance of the software. Semantic analysis also includes examination of the source code to ensure it is consistent with the design documentation and to ascertain its effect on system functionality.

Impact Analysis Determines that a change in functionality of a software module has no direct or indirect adverse effect on the functionality of the other sections of code. This is achieved by examining data use and information flows within the software, and by ensuring that the changes have the intended impact and that no undesired side-effects are experienced.

Completeness Analysis Ensures that all functions in the finished implementation can be traced to an entry in the requirements documentation. Each function in the software is identified and then the functionality is traced through the design documentation to the requirements document.






AIR TRAFFIC MANAGEMENT (SYSTEM SUPPLIER)

ompany or Organisation major developer, designer and supplier of systems in the air traffic management sector

ource Documentation Confidential.

ource Type -house procedures.

Detailed Findings hese are generic findings. Specific details cannot be given because of commercial confidentiality.

e procedures, it is implicit because of the safety-lated nature of the systems. esign shall consist of a high level design (architecture) and detailed design.

pplication independent design is developed first, then an application dependent design.

ystem Threads are used to develop the design. Threads define the system response to a stimulus. A thread gives the behaviour of the system from the time a particular event is received by the system to

e time that the system’s response is generated. An external thread is initiated by an input that omes from outside the system boundary or an output leaving the system boundary. An internal read is initiated by some event within the system.

Threads are used to group functio ms to enhance understandability, evelopment, maintenance, and operations. This decomposition aims to:

Separate: − Critical from other functions. − Functions dealing with different types of external (outside the subsystem) inputs. − Functions producing different types of external (outside the subsystem) outputs. − Minimize: − The number of interfaces within the subsystem. − The complexity of software functions and interfaces.

Maximize: − Reliability, availability and maintainability characteristics. − Usability. − Ease of integration and testing.

• Identify: − Candidates for common or shared services.

In evaluating competing technical solutions, both development and operational costs should be evaluated to choose the most cost-effective solution. Factors to take into account in determining the overall architecture include: techniques for availability management; principal execution states and state transitions; design scalability; catastrophic failure recovery; re-entrant code; protection for shared resources; human error mitigation.

ANNEX C -

CA S

SIn

TSafety is not explicitly noted in most of the in-housreD

A

S

thcth

ns into System Configuration Ited

•

•



Each thread should be expanded into separate data flow diagrams, with inputs, outputs, and well as nominal paths.

Interfaces to retained data repositories or queues should be shown. Adaptable or pre-set data sage should be indicated. If system safety categories are assigned to software functions, then the

ram should be recorded.

functions fully described. The diagrams should address error conditions as

ucategory for each thread diag



Source Documentation AR 25 ‘Large Aeroplanes’. (Note: JAR 25 is based on the US Federal Aviation Regulations Part

25 and is essentially the same for the material relevant here.)

Source Type Regulatory requirements.

Detailed Findings The following relate to generic requirements for building safety into design. Requirements for specific aircraft systems are not considered here.

A risk-based framework is to be used for determining the safety attributes of systems. As a general principle, an inverse relationship should exist between the probability of a failure condition and its effect on the aircraft. The severity of failure conditions is split into four classes: Catastrophic, Hazardous, Major, and Minor. The probability of failure conditions is split into four classes: Probable, Remote, Extremely remote, and Extremely improbable. The terms Probable, Remote, Extremely remote, and Extremely improbable are expressed in terms of acceptable numerical probability ranges for each flight hour, as follows:

• Extremely improbable less than 10-9 per aircraft flight hour • Extremely remote 10-9 - 10-7 per aircraft flight hour • Remote 10-7 - 10-5 per aircraft flight hour • Probable more than 10-5 per aircraft flight hour

The fail-safe design concept is to be used. This considers the effects of failures and combinations of failures in defining a safe design. According to the fail safe concept, the failure of any single element, component or connection in any system or subsystem should be assumed during any flight and should not be catastrophic. Subsequent failures during the same flight, whether detected or latent, and combinations thereof, should also be assumed, unless their joint probability with the first failure is shown to be extremely improbable. The occurrence of any failure condition which would prevent the continued safe flight and landing of the aeroplane must be extremely improbable. The occurrence of any other failure condition which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating conditions must be improbable.

Warning information must be provided to alert the crew to unsafe system operating conditions, and to enable them to take appropriate corrective action.

Systems, controls, and associated monitoring and warning means must be designed to minimise crew errors which could create additional hazards.

Safety analysis of the design must consider possible modes of failure, the probability of multiple failures, undetected failures, warning cues, corrective actions, the capability of detecting faults and effects on the aeroplane and occupants. Advisory material (Joint AMJ 25.1309 ‘System Design and Analysis’ and its US equivalent Advisory Circular AC 25.1309) provides guidelines for performing system safety assessments. It proposes a Functional Hazard Assessment for identification and classification of significant failure conditions.

ANNEX D - AIRCRAFT SYSTEMS (REGULATORY REQUIREMENTS)

Company or Organisation Joint Aviation Authorities.

J



, Failure Modes Effects Analysis and Reliability Block Diagrams is recommended to systematically postulate the

ty of the aircraft resulting from any possible failure or combination of

considered to be part of the design from the point of view of certification.

gn, including in respect of safety The regulator establishes the Type Certification Basis. This is the applicable rules

ments to which the manufacturer must show (and the regulator must o be granted a Type Certificate. Derivatives of older aircraft usually are

ply to new regulations if major changes to the design were made. In many

final approval of the particular design under

reviewed and any revisions or additions that are

the flight test program. Flight test nd a certification flight-test program.

e n flight tests a ually in close co-operation but without direct involvement of the certifying authority in order to obtain a first overview of the

airworthiness standards, the required inspections have been satisfactory completed, and the

he conditions and limitations under which the

Type Inspection Report has to be issued which

For complex systems, the use of analytical tools such as Fault Tree Analysis

effects of failures on the safefailures and events.

Operating procedures areThe operating procedures define the safe operating regime for the aeroplane.

The Aircraft Type Certification process validates the desirequirements. and any additional requirefind) compliance in order tonly required to comcases, the regulations from the time of the first certification apply. The regulator creates a Type Certification Board, a management level group charged with confirming that all applicable regulations have been complied with prior to evaluation. The regulator identifies significant certification items which will require special attention during the certification program. These items are described in “Issue Papers”. The manufacturer then submits data on how it is intended to demonstrate compliance with the applicable regulation in the form of a Certification Plan. After approval of the Certification Plan the actual certification process will start. Detailed design submittals begin, including drawings, reports, analyses, test plans and test reports. This can include ground and simulator tests. Examples of ground test are full-scale structural loading tests. These data are found necessary must be incorporated before final acceptance by the authorities.

An important aspect of the aircraft certification process isprograms are divided into an evaluation flight test program aTh evaluatio re executed by the manufacturer, us

handling and performance characteristics of the aircraft. The certification flight tests are executed with the participation of representatives of the authority and partially flown by the authority’s test pilots. Both quantitative as well as qualitative assessments are being used. The role of the certification test pilot at this stage is significant, especially when it comes to an assessment of the aircraft handling qualities.

A Compliance Check List is composed which provides information concerning the substantiation information which has been provided to show compliance with applicable regulation. When the regulator determines that the manufacturer has demonstrated compliance with all applicable

required documentation is approved, the Type Certificate is issued. A Type Certificate Data Sheet is issued as part of the Type Certificate. It describes taircraft meets the applicable airworthiness requirements.

Within 90 days after issuing the Type Certificate, a includes the final documentation of the ground inspection and flight test phase of the certification program.

In addition to the Type Certification, a number of provisions must cater for the airworthiness of each individual aircraft. Before the manufacturer can produce aircraft intended for sale it must obtain a Production Certificate. For each individual aircraft coming off the production line a Certificate of Airworthiness has to be issued.



nsafe condition exists in a product (aircraft or system) and that the unsafe

rating limitations for

After the Type Certification is completed and aircraft of the type are introduced into service, the authorities continue to monitor safety of the design through a service difficulty reporting and analysis system. If at any time during the service life of an aircraft, the airworthiness authorities determine that an ucondition is likely to exist or develop in other products of the same type design, they may issue an Airworthiness Directive (AD). The purpose of an Airworthiness Directive is to correct or prevent an unsafe condition. An AD gives a description of required corrective action or opea particular aircraft or system. Compliance to Airworthiness Directives is compulsory.






PROCESS INDUSTRIES (CHEMICAL, NUCLEAR POWER, FOOD) (BEST PRACTICE GUIDELINES)

ompany or Organisation chemical process, oil and gas, food, nuclear power generation

nd software industries on behalf of the Institution of Electrical Engineers.

ource Documentation Guidelines : Safety-Related Application Software for Programmable Logic Controllers.

E Technical Guidelines 8:1996. ISBN 0 85296 887 6.

ource Type Best Practice guidelines.

etailed Findings esign is to be carried out within a risk-based, safety management framework consistent with IEC

61508.

The safety attributes to be achieved by the software design are expressed in terms of software afety requirements. The software safety requirements are derived from a broader set of system afety requirements. The software safety requirements are each associated with, and derived from, pecific safety functions.

he software is assigned a Safety Integrity Level (SIL) that is determined by the SIL for the safety nction to which it contributes and by the role of the software within the overall safety function.

Design is divided into 2 phases: Software Design Phase and Software Detailed Design Phase. The objective of the Software Design Phase is to propose a software solution to the requirements

etailed in the Software requirements Specification by providing a software architecture consisting of programs and modules. The objective of the Software Detailed Design Phase is to expand on the software architecture to a point where code may be generated from it.

Software Design Phase

ANNEX E -

CProduced by representatives of thea

SSEMSPLC IE

S

DD

sss

Tfu

d

During the Software design phase:

• Data flow diagrams can be used to describe the software architecture at a program level • Inter-program control flow model and program interface definitions should be produced. • Timing properties and the nature of inter-program communications should be defined,

timing diagrams may be used. • State transition diagram or similar can be used to describe program functionality. • Software fault tolerance, avoidance and detection techniques (e.g. redundancy, recovery

blocks, self-checking etc.) need to be considered against an increase in complexity. • Lowest level modules are those that are unable to be further partitioned without

complicating the design. Consider the size of the smallest modules with respect to testability.

• Aim for high cohesion (i.e. each module does one task), low coupling (i.e. modules are independent).

It is recommended that the software is a partitioned into a set of logical functions and categorised on the basis of safety:

• Safety-related functions should be partitioned from non safety-related functions. • There should be further partitioning between safety functions of different safety integrity

levels. • Use structure charts to detail the hierarchical relationship between modules.



independence an be demonstrated.

oftware operation and maintenance procedures should be identified during the software design of the software and any data that the software uses in maintained

sign Verification and Safety Report details what actions were taken to verify that the ve been met in the design and the results and conclusions of the safety

en undertaken.

The safety integrity level will be dictated by the most severe categorisation, unless adequate between partitioned elements c

Sphase to ensure that the SILthroughout its operational life (note: operation and maintenance must be linked to the features which are assumed during the design of the software in order to ensure that an adequate level of safety integrity is achieved).

Safety analysis examines the effect of failure of the software modules identified and assigns the appropriate SIL to each module.

A Software Desoftware requirements haanalysis that has be

Software Detailed Design Phase During the Software Detailed Design Phase:

• A Software Detailed Design Specification should be produced for each module. • Each Software Detailed Design Specification contains enough detail to ensure that the

coder does not need to make any assumptions about the functionality that a module has to perform.

• Procedures to test that the specified functionality has been achieved are produced in the form of a set of Software Detailed Design Test Specifications. The tests specified should be performed on the software modules in isolation.

• Safety analysis examines the effect of failure of each individual software module. A Software Detailed Design Verification and the Safety Report details what actions were taken to verify that the software requirements have been met in the design and the results and conclusions of the safety analysis that has been undertaken.

General tools and techniques

Fault tolerance, avoidance and detection should be used as appropriate (e.g. redundancy,

Tools r

Additi a

•

• at the Software Design Specification does not compromise the software

includes timing information

recovery blocks, self-checking).

fo safety analysis of a software design include:

• Fault trees • HAZOP

Failure behaviour of the hardwa• re (processor, comms etc.)

on l safety analysis tools for SIL 3 and SIL 4 include:

• Formal specification of the design using a mathematical language such as Z, VMD-SL, etc. Formal proof that the software design meets the Software Requirements Specification Formal refi• nement of the Software Requirements Specification to the Software Design Specification using proven translations Formal proof thsafety requirements

• Notation that



ANNEX F - AUTOMOBILE SYSTEMS (BEST PRACTICE GUIDELINES)

Company or Organisation Produced by representatives of the motor industry acting as the Motor Industry Software Reliability Association (MISRA) consortium.

Source Documentation Development Guidelines for Vehicle Based Software, 1994. ISBN 0 9524157 0 7. Source Type Best Practice guidelines. Detailed Findings Design is to be carried out within a risk-based, safety management framework.

Safety analysis should be carried out as part of the requirements analysis phase and should become more detailed as the design progresses. It is highly iterative and should be considered as a continuous process during requirements analysis and design. Tools and techniques include :

• PASSPORT Cross modelling (Ref: PASSPORT, Framework for Prospective System Safety Analysis, EC DRIVE II Projects, V2057/8, 1994).

• ‘What if?’ analysis. • ‘What causes?’ analysis. • Failure Mode and Effect Analysis (FMEA). • Fault Tree Analysis (FTA).

System design should consider both random and systematic faults.

System design should take into account human (user) behaviour, including unsafe behaviour.

The safety attributes to be achieved by the software design are expressed in terms of software safety requirements. The software safety requirements are derived from a broader set of vehicle safety requirements. Safety integrity requirements should include process measure to avoid, and design attribute measures to control, systematic and random failures. Such requirements include:

• Logical and physical partitioning. • Diversity. • Redundancy. • Condition monitoring. • Self-test.

Safety verification is specifically concerned with safety requirements and should proceed concurrently with the normal design and implementation process. It’s purpose is to ensure that each phase maintains the safety attributes of the previous phase without introducing errors. Verification techniques include reviews, static analysis, black-box testing and white-box testing.

Safety validation should be carried out specifically to confirm the all safety requirements have been met. Validation mainly involves system testing but may also include animation techniques.

It is recommended that a suitably qualified and independent assessor and/or auditor performs product assessment in order to act as an advocate for the level of confidence in the safety.

Design is divided into 2 phases : Architectural design phase and detailed design phase.



Architectural Design

The architectural design phase involves partitioning the system into subsystems and assigning

y are defined : Uncontrollable (IL 4); Difficult to control (IL 3);

determines the Integrity Level of the system. The software is

to have a lower a lower Integrity Level than the system of ction from software failures is provided (e.g. by use of hardware).

les cannot be demonstrated, the highest IL for any of ust be used for all.

Detai

functionality to the various elements (hardware, software). It addresses both functional and implementation aspects of the design. The architecture should address both logical and physical partitioning.

A system is assigned an Integrity Level (IL) according the degree of controllability following a failure. 5 categories of controllabilitDebilitating (IL 2); Distracting (IL 1); Nuisance only (IL 0). The failure mode with the highest associated controllability categoryassigned an Integrity Level (IL) that is determined by the IL for the system to which it contributes and by the role of the software within the overall system.

An architecture may allow softwarewhich it is part if appropriate proteIf segregation between components or moduthe non-segregated components or modules m

led Design

iled design phase produces a software design that meets the requirements of the software The detaas derived from the system architecture. This includes the appropriate Integrity Level.

Design te

• matic code generation.

consideration of:

ic – the advantages and disadvantages with respect to integer pplication.

esign of control systems. and adaptive control – the control system should be optimised to be as

s possible within the defined constraints. ork services should be used,

where possible an internationally recognised protocol standards appropriate for the

lysis techniques supported by CASE tools as appropriate for the Integrity Level.

chniques depend on the Integrity Level. Minimum requirements are:

IL 4 – Formal specification of complete system. Auto• IL 3 – Formal specification for those functions at this level. • IL 2 – Structured method supported by CASE tool. • IL 1 – Structured method. • IL 0 – ISO 9001.

Detailed design should include

• Real-time implications – an iterative design strategy is likely to be needed as many aspects of real-time behaviour will be poorly defined at the outset.

• Floating point arithmetarithmetic need to be assessed for the specific a

• Modelling – use of modelling tools to aid the d• Optimisation

efficient a• Communications and multiplexing – A layered model of netw

Integrity Level should be used. • On-board diagnostics – diagnostics should be included as part of the overall system

requirements and design strategy, not added as an afterthought. • System security – there should be protection against unauthorised access to software. • Fault management – a control system should degrade gracefully in accordance with its

integrity and availability requirements, safe states should be defined with reference to the system hazard analysis.

• Verification and validation – the design should support verification and validation through modularisation and ease of testing.

• Tools and techniques – structured ana

Documents

EUROCONTROL EXPERIMENTAL CENTRE · 2019. 2. 18. · ATM Araffic Management ir T DFD DFlow Diagram (or Design) ata EEC EUROCONTROL Experimental Centre FMEA Failure Modes and Effects