Initial Activities in Enterprise Architecture application to ...

EUROPEAN AIR TRAFFIC MANAGEMENT

Initial Activities in Enterprise Architecture application to ATM -

Evaluation Report (D9)

Document Identifier: OATA-MCS-12-09 Edition: 1.1 Edition Date: 27-05-2009

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

E U R O C O NTROL

Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

OATA-MCS-12-09, Edition: 1.1 Page: ii of 58

DOCUMENT CHARACTERISTICS TITLE


EATM Infocentre Reference:

Document Identifier: OATA-MCS-12-09 Edition: 1.1

Contractual Ref: Contractual ID:

TRS 08-11642-C D9

Version Date: 27-05-2009

Abstract This document provides a summary description of the material produced throughout the study which has ensued from the Eurocontrol TRS entitled “Initial Activities in Enterprise Architecture application to ATM”, plus the analyses performed, the conclusions drawn, the lessons which have been learnt and recommendations made for the subsequent work to be done in the SESAR Development Programme. The document takes the form of an Evaluation Report (D9).

Keywords EAEA OATA MCS SESAR

Contact Person(s) Tel Unit Prepared by: John R F Guy +44 1489 616526 NATS

Issued by: Michael Heap +44 1489 444424 NATS

STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via

In progress General Public Intranet Internal Draft EATM Stakeholders Extranet Working Draft Restricted Audience Configuration Manager Proposed Issue

Released Issue x Printed & electronic copies of the document can be obtained from the EATM Infocentre or from the OATA PSO

ELECTRONIC SOURCE Path: File Name: Host System: Software Application Size: Windows XP: Microsoft Word 10.0

Publications

EUROCONTROL Headquarters 96 Rue de la Fusée, B-1130 BRUSSELS Tel: +32 (0)2 729 47 15 Fax: +32 (0)2 729 51 49 E-mail: [email protected]

OATA Project Support Office (PSO)

EUROCONTROL Headquarters 96 Rue de la Fusée, B-1130 BRUSSELS Tel: +32 (0)2 729 50 40 E-mail: [email protected]


OATA-MCS-12-09, Edition: 1.1 Page: iii of 58

DOCUMENT APPROVAL The following table identifies all management authorities who have successively approved the present issue of this document.

AUTHORITY NAME AND SIGNATURE DATE

Work Package Manager

Project Manager P. Monaco

DOCUMENT CONTROL Copyright notice © 2009 European Organisation for the Safety of Air Navigation (EUROCONTROL). All rights reserved. "Member States of the Organisation are entitled to use and reproduce this document for internal and non-commercial purpose under their vested tasks. Any disclosure to third parties shall be subject to prior written permission of EUROCONTROL".

DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document.

Edition Number Edition Date Reason for change Pages

affected

0.1 16-03-2009 Working draft document All

0.2 20-03-2009 New table of content & text for Section 7

0.3 27-03-2009 Updated content (Sections 6 and 8) All

0.4 08-04-2009 Updated content (Executive Summary & Section 7)

0.5 24-04-2009 Updated for Eurocontrol comments All

1.0 08-05-2009 Final version

1.1 27-05-2009 Updated after final Eurocontrol comments and discussion (26-05-09)


OATA-MCS-12-09, Edition: 1.1 Page: iv of 58

TABLE OF CONTENTS

DOCUMENT CHARACTERISTICS ........................................................................................................ II

DOCUMENT APPROVAL...................................................................................................................... III

DOCUMENT CONTROL........................................................................................................................ III

DOCUMENT CHANGE RECORD ......................................................................................................... III

TABLE OF CONTENTS......................................................................................................................... IV

LIST OF FIGURES..................................................................................................................................V

LIST OF TABLES ...................................................................................................................................V

1 EXECUTIVE SUMMARY................................................................................................................. 6

2 INTRODUCTION ............................................................................................................................. 8 2.1 CONTEXT................................................................................................................................... 8 2.2 SCOPE OF THE STUDY................................................................................................................ 8 2.3 STRUCTURE OF THIS REPORT..................................................................................................... 9

3 DEFINITIONS AND ACRONYMS................................................................................................. 10

4 BACKGROUND TO EA AND SOA IN THE ATM DOMAIN ......................................................... 12 4.1 SESAR PROJECT DEFINITION PHASE....................................................................................... 12 4.2 SOA TASK FORCE ................................................................................................................... 14

5 DEVELOPMENT APPROACH & OVERVIEW OF EAEA DELIVERABLES ............................... 15 5.1 GENERAL OVERVIEW ............................................................................................................... 15 5.2 HIGH LEVEL BREAKDOWN OF ACTIVITY ..................................................................................... 16

5.2.1 Operational Goals.......................................................................................................... 16 5.2.2 Operational Services, Processes & Organisation ......................................................... 17 5.2.3 Information..................................................................................................................... 20 5.2.4 Information and Application Services & Systems.......................................................... 20

6 ENTERPRISE ARCHITECTURE FRAMEWORK CONSIDERATIONS....................................... 22 6.1 INTRODUCTION ........................................................................................................................ 22 6.2 DEVELOPMENT OF THE EAEA FRAMEWORK PROPOSAL............................................................. 23

6.2.1 Summary of Status ........................................................................................................ 23 6.2.2 Overview of Initial Proposal ........................................................................................... 23 6.2.3 Overview of Updated Proposal...................................................................................... 24

6.3 RATIONALE AND USE OF SOME SELECTED SUB-VIEWS............................................................... 26 6.3.1 Capability (Strategic) View ............................................................................................ 26 6.3.2 Operational View ........................................................................................................... 27 6.3.3 Service-Oriented View................................................................................................... 32 6.3.4 System View.................................................................................................................. 38


OATA-MCS-12-09, Edition: 1.1 Page: v of 58

7 LESSONS LEARNT & HIGH LEVEL CONCLUSIONS................................................................ 41 7.1 DIRECTION OF STUDY AS SET BY THE TRS ................................................................................ 41 7.2 STRATEGIC BUSINESS ASPECTS ............................................................................................... 41 7.3 THE APPROACH AND METHOD .................................................................................................. 41 7.4 FRAMEWORKS ......................................................................................................................... 42 7.5 INFORMATION AND INFORMATION SERVICES .............................................................................. 42 7.6 OPERATIONAL AND APPLICATION SERVICES .............................................................................. 44 7.7 SYSTEMS................................................................................................................................. 44 7.8 GENERAL CONCLUSIONS.......................................................................................................... 44

8 STUDY RECOMMENDATIONS.................................................................................................... 45 8.1 DIRECTION OF STUDY AS SET BY TRS....................................................................................... 45 8.2 STRATEGIC BUSINESS ASPECTS ............................................................................................... 45 8.3 THE APPROACH AND METHOD .................................................................................................. 45 8.4 FRAMEWORKS ......................................................................................................................... 47 8.5 INFORMATION AND INFORMATION SERVICES .............................................................................. 47 8.6 OPERATIONAL AND APPLICATION SERVICES .............................................................................. 47 8.7 SYSTEMS................................................................................................................................. 48 8.8 GENERAL RECOMMENDATIONS ................................................................................................. 48

9 PROPOSED WAY AHEAD........................................................................................................... 49

10 REFERENCES .......................................................................................................................... 51

11 ANNEXES ................................................................................................................................. 52 11.1 ANNEX 1 – LIST OF OPERATIONAL (BUSINESS) GOALS ................................................. 52 11.2 ANNEX 2 – CROSS REFERENCES BETWEEN OPERATIONAL (BUSINESS) GOALS AND OPERATIONAL IMPROVEMENTS (OI) IN LINE-OF-CHANGE (LOC) 10 ........................................ 57

LIST OF FIGURES

Fig. 1: Overview of Initial EAEA Framework Proposal ............................................................8 Fig. 2: Principal Relationships between Deliverables D1 to D8 ............................................15 Fig. 3: SWIMPOOL Diagram – Airport Centric View .............................................................18 Fig. 4: ATC Hierarchical & C2 Relations ...............................................................................19 Fig. 5: Overview of Updated EAEA Framework Proposal .....................................................25 Fig. 6: NCV-1 – Capability Vision ..........................................................................................27 Fig. 7: NOV-4 – Organisational Relationship Chart...............................................................28 Fig. 8: NOV-5 - Operational Activity Model Example ............................................................29 Fig. 9: NOV-5 – Operational Activity Model...........................................................................30 Fig 10: NOV-6c – Operational Event-Trace Description .......................................................31 Fig. 11: NOV-7 – Information Model (Example) .....................................................................32 Fig. 12: NSOV-1 – Service Taxonomy - Operational Services...............................................33 Fig. 13: NSOV-1 – Service Taxonomy – Application Services...............................................34 Fig. 14: NSOV-1 – Service Taxonomy – Information Services ..............................................35 Fig. 15: NSV-1 – System Interface Description......................................................................39 Fig. 16: NSV-12 – Service Provision ......................................................................................40

LIST OF TABLES

Table 1: NSOV-2 – Service Definition - Operational Services ...............................................36 Table 2: NSOV-2 – Service Definition - Application Service ..................................................36 Table 3: NSOV-2 – Service Definition - Information Service..................................................37 Table 4: NSOV-3 – Service to Operational Activities Mapping - Operational Services..........38


OATA-MCS-12-09, Edition: 1.1 Page: 6 of 58

1 EXECUTIVE SUMMARY This evaluation report presents the findings of the Eurocontrol TRS study entitled “Initial activities in Enterprise Architecture application to ATM”. The stimulus for this study came from the output of the SESAR Project Definition (PD) Phase, where it was identified that Enterprise Architecture (EA) and Service Oriented Approach (SOA) techniques should be applied to the development of the future European ATM System (EATMS) which would underpin the creation of an ATM Performance Partnership (ATMPP) between the “Users of the Network” (namely the Airspace Users, Airport Operators and Air Navigation Service Providers (ANSPs)). In order to fit with the envisaged timescale for the start of the SESAR Development Phase, the scope of this study was limited to activities at an Airport, concentrating on the arrival, surface movement, aircraft turnround and departure aspects. The findings cover both the approach taken and the actual output of the study.

The TRS had specified a number of deliverables which, when created, were thought to capture and describe a European ATM EA (EAEA), plus a draft EA framework proposal to accompany it. The development of these deliverables was undertaken by a consortium led by NATS and included representatives of the major ATM Stakeholder groups who provided expert knowledge in all the key subject areas. Eurocontrol were also closely involved in the study as a contributor.

As this type of activity had not taken place in the context of European ATM previously, there was no definitive process to follow. Consequently, a series of workshops and working sessions were held to develop the material required. To expedite the study in the short time available, a “middle-out” approach was taken. Having identified an initial set of Operational (Business) Goals based primarily upon material developed during the SESAR PD phase, a pictorial view of the operational environment being studied was developed which identified the Actors involved and the Operational Processes that take place. After several iterations, this formed the basis upon which Operational and Information Services were defined and developed. Subsequently, a Conceptual Information Model and thence, a more detailed Information Model were developed. Finally, some Systems aspects and associated Application Services were considered.

Using the material described above, consideration was given as to how an EA framework should be chosen, scoped and used to support the definition, development and management of the future EAEA.

The principal findings of the study were as follows.

1) The approach taken has demonstrated that taking a service-based approach can readily be used to describe, define and develop the inter-relationships needed to create a future EATMS which would underpin the creation of an ATMPP between the “Users of the Network”.

2) The approach taken to develop operational processes, operational services and information services has shown that this can be successfully applied to analyse both the SESAR future vision and today’s legacy situation. Thus, by adopting such an approach, consideration of activities related to IP1 and IP2 can be made seamless.

3) The trade-off between creating the wide range of specified deliverables within the timescale set for the study, and having to take the “middle-out” approach to do this, meant that creating a full EA solution could not be achieved. Although an initial set of operational (business) goals was developed, further work at the business level and taking a more “top-down” approach to the development of performance capabilities and operational services is required before an “ATM Enterprise” can be defined. However, building upon the work done to date, it is considered that this is readily achievable.



4) Undertaking detailed development work of systems solutions before a high degree of maturity of the business relationships and operational processes and services is achieved should not be attempted.

5) The development of a Conceptual Information Model, and thence a more detailed Information Model (or Data Model to be used as a reference for the design of systems solutions), is crucial to this type of activity. Further, it, and the associated information requirements, needs to be developed at a very early stage in the architecture process. Having these aspects in place will allow some parallel working to be undertaken at the business, operational and systems levels provided a strong governance régime is also applied across the levels and it acts from a “top-down” perspective.

6) An EA framework must be considered as a support tool to be used to maintain coherence across the variety of aspects which make up the “ATM Enterprise”. The choice of the framework to be used is not critical, relative to determining the nature of the “ATM Enterprise”. Thus, once it is determined, a suitable framework should be selected which is best suited to support the maintenance and management of the “Enterprise”. One of the “standard” frameworks should be used (as opposed to creating a bespoke EAEA framework) in order to minimise support costs since commercially available software tools are based upon them. To date, and for illustrative purposes only, the work has been aligned with the NATO Architecture Framework (NAF).

In conclusion, the study has provided valuable insight into how EA techniques can be used to develop an EAEA and that taking a service-based approach will enable an “ATM Enterprise” to be created which will fulfil the vision developed in the SESAR PD phase. The work undertaken has produced an extremely valuable set of recommendations for the future SESAR Enterprise Architecture work. It is highly recommended that these form the basis of, and starting point for, all future work in this subject area. These recommendations will enable a structured approach to be taken to developing an EAEA in the SESAR development programme.



2 INTRODUCTION

2.1 Context The results delivered from the SESAR Project Definition (PD) phase recommended that an Enterprise Architecture (EA) approach, together with taking a Service-Oriented Approach (SOA), be used as the basis to manage the development of the Future European ATM System (EATMS). Consequently, the need for a European ATM Enterprise Architecture (EAEA) was identified. It was recognised by many of the ATM stakeholders participating in the SESAR PD phase that a first set of EA & SOA activities needed to be undertaken urgently in order to facilitate and steer the subsequent programme of work to be undertaken during the SESAR Development Phase. The aim of this study was to go some way to addressing this need.

2.2 Scope of the Study The basis of the study was specified in a Task Requirement Sheet (TRS), the details of which can be found in Ref.1. Its objective was to develop some initial versions of some of the main artefacts and views of an EAEA, but with a scope restricted to an Airport context. The study was also aimed at gaining knowledge and experience on how taking an EA approach can be used in the SESAR Development Phase in order to validate which approach shall be taken in the future.

Eurocontrol has proposed an initial description of an EAEA framework [Ref.2], tailored to covering SESAR’s requirements and based upon existing EA frameworks. The initial EAEA framework proposed by Eurocontrol is based on the NATO Architecture Framework (NAF) [Ref.3] and UK Ministry of Defence Architecture Framework (MoDAF) [Ref.4], but is customised to adapt aspects of them to meet the needs of ATM. This initial EAEA framework has been applied to the extent considered relevant to the scope of this study, it being further refined based upon the experience gained in applying it to the practical application of considering activities performed at and around an Airport. The EAEA framework proposed by Eurocontrol comprises the following high-level views:

Strategic View

Operational View

Service-Oriented View

Technical View / Physical Architecture

e.g. Performance TargetsBusiness Strategies

e.g. Organisational StructureProcess Model

Conceptual Information Model

e.g. Implementation StandardsImplemented Systems

ATM Infrastructure

Problem OpportunityGoal

InformationProcess

OperationalService

Organisation / Human Actor

InformationSystem Service

Network

Hardware

Software

e.g. Logical ArchitectureAICM, FOIPS

System ViewInterface

Information

Systeme.g. Technical Architecture

AIXM, ICOG ICDs

Pro

gram

me

Vie

wTi

min

gP

roje

cts

/ A

ctiv

ities

e.g.

Gan

ttC

hart

Fig. 1: Overview of Initial EAEA Framework Proposal



The TRS specified the need to produce 8 deliverables which contain the detailed output from the study, namely :

• Deliverable D1 (Operational (Business) Goals) [Ref.12],

• Deliverable D2 (Operational Services) [Ref.13],

• Deliverable D3 (Operational Processes) [Ref.14],

• Deliverable D4 (Organisation Chart) [Ref.15],

• Deliverable D5 (Concept Information Model) [Ref.16],

• Deliverable D6 (Services) [Ref.17],

• Deliverable D7 (Systems) [Ref.18],

• Deliverable D8 (Information Model) [Ref.19].

The material created in order to produce these deliverables has also been used to evaluate the detailed proposals made in the EAEA framework of Ref.2. This material has also been used to evaluate the approach which has been followed as a consequence of having to produce these deliverables as defined by the TRS.

2.3 Structure of this Report This report, defined by the TRS (Ref. 1) as Deliverable D9, has been structured as follows.

Section 4 provides a summary of the background information considered relevant to setting the scene and context of the work which has been done, plus the foundations upon which the recommendations made concerning the way ahead have been built. It identifies some key recommendations made in the SESAR PD phase deliverables with respect to the current ATM situation [see Refs 6 to 11] and summarises the proposals made by the so-called SOA Task Force [see Ref. 5].

Section 5 provides an overview of the approach taken to create the core material needed to produce the D1 to D8 deliverables, again this primarily being defined by the activities described in the TRS. Thence, section 6 contains the high level summary of the conclusions drawn from the activities to create this core material and the results of the analytical work performed using the material.

A specific section is included which contains the results of the evaluation work performed concerning the usefulness and relevance of the EAEA framework proposal and the views contained within it; this is section 6.

Section 7 contains an overview of the lessons learned and high level conclusions.

Section 8 contains the Study Recommendations drawn from all aspects of the TRS activity.

Finally Section 9 outlines a view of the way ahead and how future activities, namely SESAR Joint Undertaking (SJU) WP-B (see Ref. 20), could benefit from the findings of this Report.



3 DEFINITIONS AND ACRONYMS

ACRONYMS DEFINITIONS AICM Aeronautical Information Conceptual Model

AIXM Aeronautical Information Exchange Model

ANSP Air Navigation Service Provider

AOC Airline Operations Centre

ATC Air Traffic Control

ATM Air Traffic Management

ATMPP ATM Performance Partnership

BAA British Airports Authority

CDM Collaborative Decision Making

CIM Concept Information Model

C2 Command and Control

DCB Demand Capacity Balancing

DFS Deutsche Flugsicherung

DoW Description of Work

EA Enterprise Architecture

EADS European Aeronautic Defence and Space Company

EAEA European ATM Enterprise Architecture

EATMS European ATM System

ENAV Ente Nazionale Assistenza al Volo

ETA Estimated Time of Arrival

FOIPS Flight Object Interoperability Proposed Standard

IATA International Air Transport Association

ICAO International Civil Aviation Organisation

ICDs Interface Control Documents

ICOG Interoperability Consultation Group

IP Implementation Package

IT Information Technology

KPA Key Performance Area

KPI Key Performance Indicator

LDM Logical Data Model

LFV formerly Luftfartsverket (Sweden)

LIM Logical Information Model

LOC Line-of-Change

MOD Ministry of Defence (United Kingdom)

MoDAF MOD Architecture Framework

NAF NATO Architecture Framework



NATO North Atlantic Treaty Organisation

NATS formerly National Air Traffic Services Ltd. (United Kingdom)

NOP Network Operations Plan

OBG Operational (Business) Goal

OI Operational Improvement

PD Project Definition

R&D Research & Development

RBT Reference Business Trajectory

SBT Shared Business Trajectory

SESAR Single European Sky ATM Research

SESAR PD SESAR Project Definition

SICTA Sistemi Innovativi per il Controllo del Traffico Aereo

SJU SESAR Joint Undertaking

SOA Service-Oriented Approach

SOV Service-Oriented View

SWIM System Wide Information Management

TOBT Target Off Block Time

TRS Task Requirement Sheet

WP Work Package

XMI XML Metadata Interchange

4D Four-Dimensional



4 BACKGROUND TO EA AND SOA IN THE ATM DOMAIN

4.1 SESAR Project Definition Phase The deliverables from the SESAR PD phase made a number of recommendations, relative to today’s situation [Ref.6], upon which the vision of defining and managing a future EATMS should be based. These covered the 4 main subject areas of the business aspects related to air transport, the role of and approach to performing ATM in the future, the nature of the future institutional aspects and the approach to designing and managing the technical aspects of the future “System”. A selection of the key recommendations was made upon which to base the strategic business considerations and direction needed throughout this study. Those selected are listed below.

For Air Transport :

• Stakeholders in the Air Transport Industry must grow their businesses to strengthen the links between them.

• The business plans of the “Users of the Network” (i.e., the Airspace Users, Airport Operators and Air Navigation Service Providers) must be more closely aligned through a set of service relationships.

• Stakeholder’s business planning must share a common set of values, goals, incentives & risk sharing mechanisms.

• The ATM Industry must be empowered to manage to the above values & goals by being able to make its own investment decisions & how to finance them.

For ATM :

• There is a need for a consistent & explicit framework which links the economic, commercial & operational priorities of stakeholders.

• A comprehensive ATM performance framework is needed as the basis upon which to make management decisions.

• The lack of flexibility to easily change systems must be addressed to enable variable levels of operational ATM System capacity to be provided in real-time.

• The concept of a “Network Plan” must be comprehensively developed & implemented

• An explicit set of relationships to specify services, requirements & obligations between stakeholders must be created such that they become integrated “partners” in the future ATM System.

• A more liberalised approach to service provision & a more proactive approach to investing in new infrastructure based upon applying the principles of asset management must be considered.

• Interoperability to be developed & specified at service & functional levels through development of single functional architecture of the future ATM System.

For the Institutional aspects :

• A simpler, coherent & consistent framework of legislation & regulation matched to the ATM Industry’s future business model is a key goal.

• Design the institutional framework & business framework together, such that both work collectively for the benefit of the air transport industry as a whole.

• The Future ATM System is likely to closely integrate air & ground systems; this will need simpler decision making mechanism & process(es) to be used to



manage investment decisions – these must be designed concurrently with future ATM System.

• Realising the expectation of a single functional architecture based upon the exchange of services between stakeholders means there must be a move away from developing prescriptive, technically-oriented standards towards one taking a performance-based approach.

For the “System” aspects :

• The Design of the Future ATM System must be based upon having a :

o functional architecture defining the information flows needed between principal entities within it;

o clear distinction between ATM services, the supporting (technical) services and the physical assets which make up the technical infrastructure.

• Applied R&D must be focused upon the applications needed to achieve the overall System performance targets, rather than on the technological solutions to deliver them.

• The development of future products must be coupled with the in-service support/asset management régimes to achieve a more comprehensive, coherent decision making process.

From the recommendations made in Ref.6, the vision of a performance-driven future EATMS based upon a collaborative ATM Performance Partnership (ATMPP) between the “Users of the Network” was proposed [Ref.7]. This forms the foundation of the strategic business and organisational aspects which were considered throughout the study (Note : The ATMPP between the “Users of the Network” will be termed the “ATM Enterprise” for convenience in this document).

Based upon the key recommendations outlined above, the system architecture work performed in the SESAR PD phase recommended that EA and SOA techniques be used to develop, define, design and manage the future EATMS. This proposal was based upon the following principal shortcomings of the current situation.

• The current EATMS has a fragmented design which is difficult and expensive to change.

• The diversity of the technologies in use throughout the systems in operational service today is so large that taking a “bottom-up” approach to making changes to individual systems to try and create a “Single” EATMS for the future will never work in a way which will meet today’s expectations of the stakeholders for a future, performance-driven approach.

• The “piecemeal” approach which has been taken up to now to maintaining legacy systems and/or replacing them “one-by-one” in the context of a System-design philosophy which is based upon the “point-to-point” exchange of information is fundamentally mismatched with the way in which modern information technology (IT) systems are designed, how they function and the way in which they need to be procured and maintained.

• The way in which the definition, design and evolution of a EATMS has been approached to date has neither led to an effective harmonisation of air navigation service providers’ (ANSP) systems, applications, or interfaces, nor to the creation of a true EATMS which includes the relevant systems all of the Stakeholders which need to be part of it (specifically those of the airspace users and airport operators).

None of the above will be capable of enabling the proposals being developed as the Future ATM Target Concept [Ref.8] to be implemented, since it relies on being able to share



information between all stakeholders (i.e., through the use of System-wide Information Management (SWIM) techniques) and provide a high degree of connectivity to maximise the benefits of using Collaborative Decision Making (CDM) techniques.

4.2 SOA Task Force From the above points, it was clear that a fundamentally different approach needs to be taken to the design and development of the future EATMS. If stakeholders want to derive the benefits of using modern IT solutions (which are not necessarily bespoke to the ATM industry) to implement the future SESAR concept of operations and meet the future performance needs (but starting from today’s diverse legacy systems baseline), making changes to the design of, and/or replacing, systems must be done in a harmonised way and at a common level throughout the EATMS’s architecture. Taking a service-oriented approach and using an Enterprise Architecture framework will enable this harmonisation to be achieved.

As a result of making these recommendations, a small multi-stakeholder task force was set-up to develop them and propose some “next steps”. Their report is included as Ref.5, with a summary of some key findings being as follows.

• European ATM has to be seen as a single enterprise, captured in the EAEA.

• The EAEA provides a business-driven framework that allows a meaningful way to partition and manage ATM complexity, reconciling different partners’ business visions for ATM and creating a bridge between their business needs and their requirements for IT solutions.

• Using a combination of EAEA and SOA will enable improvements in business agility and efficiency to be realised through a streamlining and alignment of the supporting IT infrastructure to the business.

• Adopting EAEA and SOA approach is not a silver bullet that will immediately solve all the issues surrounding the evolution of ATM systems.

• Moving to using an EAEA and SOA techniques implies a paradigm shift in the way the business is viewed and managed and in the way the supporting IT infrastructure is specified and developed. This will require a big cultural change, especially to management and system engineering processes.

• In an EAEA/SOA and SWIM-based environment, partners give access to their systems and information to other partners within the enterprise. This means that security issues, such as authentication and access control, have to be managed at the enterprise level.

It was concluded that the adoption of an EAEA and taking a service-based approach represents a long-term strategy for change that will challenge partners to re-engineer their organisation, processes and IT to optimise their ATM related activities as federations of relatively independent services. However, European ATM is not the first to attempt making such a transition and the experience of other industries must be embraced to identify best practice and learn lessons. Consequently, a key recommendation to take an incremental approach, starting with a tightly scoped initial project, to test the findings of the task force laid the basis of the study which is the subject of this report.



5 DEVELOPMENT APPROACH & OVERVIEW OF EAEA DELIVERABLES

5.1 General Overview This section describes the process for the development of the content of the 8 deliverables D1 to D8 (Refs 12 to 19 respectively) which contain the working level details of the material produced throughout the study. Fig.2 shows the principal relationships between these 8 deliverables.

ConceptualInformation

Model

Airspace Users

AirportOperator

ANSP

ATM Performance Partnership

Business relationships

Process & service

relationships

Systems & service

relationships

Operational (Business) Services

Operational (Business)

Goals

Information Services

Operational Processes

Organisational (Unit)

Structure

Application Services

Information Model

Systems

[D1]

[D2]

[D4]

[D3]

[D5]

[D6]

[D7][D8]

ConceptualInformation

Model

Airspace Users

AirportOperator

ANSP


Airspace Users

Airspace Users

AirportOperatorAirport

Operator

ANSPANSP


Business relationships

Process & service

relationships

Systems & service

relationships

Operational (Business) Services

Operational (Business)

Goals

Information Services

Operational Processes

Organisational (Unit)

Structure

Application Services

Information Model

Systems

[D1]

[D2]

[D4]

[D3]

[D5]

[D6]

[D7][D8]

Fig. 2: Principal Relationships between Deliverables D1 to D8

The basic material which formed the core of the content for the 8 deliverables was developed through using a series of 3 workshops, each of 4 days in duration, and 4 working sessions, each 3 days long, held at Eurocontrol HQ between the beginning of November 2008 and the end of February 2009.

The partners participating in these workshops and working sessions were drawn from the following companies and organisations :

• Airline Group • BAA • DFS • ENAV • Indra • LFV (supported by Saab / Combitech) • NATS • SICTA • Eurocontrol • SESAR Joint Undertaking’s (SJU) Industrial Support Function (EADS).

The basic material was created using the :



• expert knowledge of the participants;

• material produced throughout the SESAR project definition phase;

• draft material which had already been produced by Eurocontrol prior to the start of the study and which was briefed during the training workshop;

• material already available from work which had already been done by some partners on this topic.

It was acknowledged from the beginning that developing an Enterprise Architecture is an iterative process and that there are many dependencies between the different artefacts within it. Further, ideally a “top-down” approach should be taken which firstly establishes the vision for the enterprise and its strategic business drivers, so establishing the foundations upon which consideration of the other aspects shown in Fig.1 should be based. However, given the scope constraints and the aggressive timescale imposed upon the study, and since the material available from the training workshop was most mature with respect to developing the operational services and operational processes, working on these was chosen as the starting point for the study in order to expedite progress overall. Consequently, consideration of the various layers (indicated as views in Fig.1) has taken a “middle-out” approach to developing the study’s deliverables. Taking such an approach, when coupled with the pre-defined scope of the deliverables, has inherently directed the way in which the work has been done and imposed limitations upon the methods which could have been used. Taking a more “top-down” approach and allowing more flexibility regarding the set of deliverables (but aligning them with one of the standard EA frameworks) would have led to a more succinct set of deliverables which would have concentrated upon outlining the meta-model [e.g., see Ref.3] for the ATMPP and future EATMS (albeit constrained as being only airport-centric), rather than being pre-occupied with the EA views themselves.

5.2 High Level Breakdown of Activity This section summarises the principal aspects of the content of a set of 8 deliverables [see Refs.12 to 19] produced as part of the study. These 8 deliverables contain details of the material produced from the workshops and working sessions outlined above, plus the ensuing analyses and updates which have been performed.

5.2.1 Operational Goals The D1 document deals with one of the 3 aspects (these being Goal, Problem and Opportunity) which were considered by Eurocontrol to make up a Strategic View. The subject of D1 is Operational (Business) Goals. Without specific guidance being provided at the beginning of the study, these Goals have been derived with respect to the notion of an ATM Performance Partnership (ATMPP) between the “Users of the Network” (i.e., the Airspace Users, Airport Operators and Air Navigation Service Providers) as described in the material produced from the SESAR project definition phase [see Ref.7].

A list of operational (business) goals has been produced and is included as Annex 1. These shall be considered to be an initial set since time, scope and need limitations imposed upon the study did not require an in-depth goal modelling activity to be performed. When undertaking such activities in the future a more comprehensive, rigorous and iterative process of goal development, modelling and analysis must be performed to establish a solid operational/business foundation at the top-level of the Enterprise Architecture (EA) model which will be used to guide the development of the Future EATMS.

In order to ensure the development of other aspects of the Enterprise Architecture model and subsequent ATM System are guided and driven in a “top-down” manner by the operational



(business) goals, links are needed to these other aspects. In this study, in the operational view, an initial set of Operational Services was specified as being required (this being the subject of the D2 deliverable). In order to link the operational (business) goals to these operational services, the notion of capabilities was introduced. Although not specifically required by the study, an outline of how to address this topic by taking an example is described in Ref.12. This was included because when developing the future EA model referenced above consideration of capabilities (and functions) is essential to ensure the operational services are developed and defined to meet the goals.

The D1 document also includes the result of an initial attempt at linking the operational (business) goals to the operational improvements (OIs) in the line-of-change 10 contained in the material produced from the SESAR project definition phase [see Ref.9 and Annex 2]. From the analysis performed, it is concluded that all the OIs can be linked to at least one goal and the majority can be linked to two or more. However, as they are understood and/or specified today, most of the OIs appear to be solutions without any specific connections as to how they will meet the performance targets associated with the goals and/or how they are compatible with taking a service-based approach.

It shall be clearly understood that the supplementary information contained in Ref.12 concerning the approach used to link the operational (business) goals to the operational services through the use of capabilities is a result of the “middle-out” approach taken from the beginning of the study to produce the other deliverables as they were specified in the TRS.

5.2.2 Operational Services, Processes & Organisation The activity to identify the Operational Processes, as detailed in D3, and Services, as in D2, for this airport-centric study was addressed by developing a diagram, referred to as a “SWIMPOOL”, of what happens in and around an airport with respect to the conduct of ATM. This diagram, shown as Fig.3, became the reference point for the overall activity. It took into account the Actors / Stakeholders / Organisations that are involved (represented by the “lanes” of the “SWIMPOOL”) in a time period from roughly the top of descent of an aircraft on approach (or leaving the stack as appropriate) to an airport, through the aircraft turnround process, to a point on the climb out from an airport.



Fig. 3: SWIMPOOL Diagram – Airport Centric View



The development of the SWIMPOOL diagram provided a very powerful way of visualising what needs to be done; that is, the operational processes and sub-processes that are required, and how they fit together sequentially for each Actor / Stakeholder. The level of detail that needs to be generated should match the objective of the activity. This representation also lends itself to identification of the relationships between the processes carried out by the different actors, allowing process handoffs to be considered and identified. The handoffs can then be categorised as implicit or explicit and expert judgement can be made whether they are carried out manually, or by making use of automation.

In summary, Operational Services are the container used to deliver capabilities through the Process. Once the capabilities have been defined and mapped to the objectives or goals, they provide a linking vehicle to the performance framework that exists throughout the architecture.

The SWIMPOOL provides a high level view of the Actors involved in the problem space being analysed. The Organisation Chart (the subject of D4) developed as part of this activity, supports the Actors in the SWIMPOOL and provides greater levels of detail, including other Actors which are part of the Organisations identified for the Airport Centric View, and the roles that each Actor can or will carry out.

An example diagram (see Fig.4) extracted from Ref.15 illustrates ANSP ATC roles.

Fig. 4: ATC Hierarchical & C2 Relations

Organisational relationships are also identified and these have been developed from the roles and tasks which are associated to the individual Actors. The relationships identified and detailed fall into the following categories :-

• Command & Control (C2)

• Hierarchical

• Functional



• Reporting

• Collaborational

5.2.3 Information The “ATM Enterprise”, which embodies the Operational Processes and Services, requires access to information to deliver its performance and objectives. It is crucial that all Actors / Stakeholders, as well as the various processes and services employed, have the same view and understanding of the information that exists. This view was developed and enhanced by identifying, at the highest level initially, the types of information that are required for the “ATM Enterprise” to function. The types of information are usually referred to as “Concepts”.

The view of the information (or Concepts) was captured in a Conceptual Information Model (CIM) which supports all Actors / Stakeholders so that they could develop a common understanding of the terms as they apply across the “ATM Enterprise” and, especially importantly, within their respective business areas. Forming the D5 deliverable, the CIM is a prerequisite for the development of consistent and interoperable processes and services, and ultimately information systems. It focuses on the key concepts needed for the interoperation between Actors / Stakeholders. With the Operational Processes and Services that were identified, expert judgement was applied to identify the information objects that needed to be exchanged at lower levels of the “ATM Enterprise”, thus providing a more detailed (Logical) Information Model (the deliverable D8) containing more concepts and subject areas. Again, the level of detail developed was commensurate with the objectives to be met.

The Logical Information Model provides :

• A more detailed conceptual view of the information required to support the problem space (in this case the Airport Centric View).

• The information areas against which a Logical Data Model (LDM) (which was not specified as a deliverable, but which will be needed to determine system design solutions) will be built to :

- split work into manageable areas

- control data against information concepts so as to prevent unnecessary fragmentation and achieve the correct level of detail in the LDM.

• A link between the CIM and the LDM as an enabler, so as not to have to wait for the LDM to be created.

• The opportunity to draw out / identify the Information Services which are confirmed against the LDM later.

• Help to support a strong Governance régime by providing understanding of information needs.

5.2.4 Information and Application Services & Systems After the Operational Processes and Operational Services were identified and the relevant Conceptual and Logical Information Models were developed, the capability to process and share the information to meet the objectives of the “ATM Enterprise” (in this case the Airport Centric View) was put in place. This was done initially by identifying the Services that will be required to accomplish this.

The Services were categorised (see deliverable D6) as :

- Information Services which deliver information to and from the Operational Services used by the Actors within the “ATM Enterprise”; or



- Application Services where information will be processed in some way, or is the automated part of an Operational Service.

After this level of detail was reached and agreed, expert judgement was made to allocate the range of services to systems (the subject of the D7 deliverable) for the future, or consider where they may be undertaken currently in legacy systems.

This was achieved and provided an early view by mapping capabilities to legacy applications and where necessary using a bottom-up approach to validate Services without compromising the overall governance of the top-down perspective of the architecture.



6 ENTERPRISE ARCHITECTURE FRAMEWORK CONSIDERATIONS

6.1 Introduction This section provides details of how EA Frameworks have been considered throughout the study.

In order to meet the goal of managing the scale, scope and inevitable complexity within and across the various subject areas needed to make up an EAEA, a structured approach is needed. Consisting of a series of views which cover the principal subject areas of importance, an EA framework provides a support environment which helps to achieve the above goal. Several Enterprise Architecture Frameworks are in use today, e.g.:

• Department of Defence Architecture Framework (DoDAF) used by all major U.S. Government Department of Defence Organisations.

• UK Ministry of Defence Architectural Framework (MoDAF) developed by the UK Ministry of Defence.

• NATO Architecture framework (NAF) developed by NATO to support achieving a federation of members’ defence systems.

• The Open Group Architecture Framework (TOGAF), a standard generic, industry-neutral, architecture Framework.

• The ZACHMAN Framework developed by John A. ZACHMAN, another generic, industry-neutral, framework and one of the first to be developed.

There is, however, a strong link between DoDAF, MoDAF and NAF, with the latest updates to each of them generally incorporating the most recent additional features of the others.

At the heart of an architecture framework is a reference model, termed a meta-model. This specifies the architectural elements and the permissible relationships between them which can be used to describe the architecture of the subject enterprise. The meta-model is a key enabler to achieving coherence across the important subject areas which make up the architecture. This is done by defining which kinds of elements (to be defined only once) can be used and re-used throughout the views which make up the EA framework.

Throughout something as wide-ranging and complex as the EAEA is envisaged to be, the need is to maintain coherence and consistency within and across stakeholder organisations in the relevant subject areas is essential. Whether it be for the :

• Management team, who are primarily concerned with defining the business strategy, goals, objectives and performance targets,

• Operational experts, who will define the operational activities needed to meet the goals and targets, or

• Systems/Technical experts, who will determine the systems solutions needed to underpin the operational activities, meet the goals and the targets,

all must have the confidence that the individual aspects for which they are responsible fit together with those of the others at all times. Whilst specific specialist groups will be responsible for the content of the views most applicable to their area of responsibility, all will be reliant upon using the information contained in all of the views (as applicable) to discharge their roles and responsibilities.



6.2 Development of the EAEA Framework Proposal

6.2.1 Summary of Status Prior to undertaking this study, Eurocontrol (after collaboration with the SJU’s Chief Architect and its Industrial Support Function), made an initial EAEA framework proposal [Ref.2] tailored to meet SESAR's requirements. This was based upon a combination of NAF and MoDAF, since these had been explicitly updated to incorporate taking a service-oriented approach1; a key recommendation coming from the SESAR PD phase deliverables. The outline structure of this initial proposal is that shown in Fig.1.

This initial EAEA framework proposal, plus the material created throughout this study, provided a basis for refining it, leading to the production of an updated EAEA framework proposal [Ref.21]. Subject to confirmation of the suitability of the proposed approach, Ref.21 will be used in the SESAR development programme.

6.2.2 Overview of Initial Proposal The decision to use predominantly views from NAF as the basis for this first framework proposal was, in principle and to a first order, sound, not only because it takes a service-based approach, but also since one of NATO’s main challenges is to create an overall architecture for its “enterprise”. This "enterprise" brings together, when needed, the defence systems of its member Nations; in particular to achieve the interoperability of their systems. This, in principle at least, is well aligned with the SESAR vision to do the same across today’s ATM Systems which are owned by different organisations throughout Europe.

It must be remembered, however, that NAF is not itself an architecture. It provides the rules, guidance and product descriptions for developing, presenting and communicating architectural structures in a military defence environment. It is the common denominator for understanding, comparing and integrating these architectures. Consequently, the terms, phrases and views within it are defined in the context of how they are understood throughout the defence industry with respect to NATO’s role, goals and objectives. Thus, using the same vocabulary does not necessarily mean these terms, etc. will be understood and have the same meaning and relevance throughout the ATM industry.

As the study progressed, a first assessment was made of the initial EAEA framework proposal resulting in the following observations and conclusions.

• A number of specific views and some of the architectural elements of the underlying meta-model contained in the initial proposal were significantly different from their near equivalent views in either MODAF or NAF. Consequently, the use of the MODAF and/or NAF nomenclature to refer to them was confusing and should not be used.

• References to “Activities” and “Processes” in the initial proposal were unclear since in MODAF and NAF they appear to be interchangeable. There is potential for confusion unless clarity and consistency of defining and expressing activities and/or processes is achieved since they are critical to identify the services needed to link them. The activities and/or processes are the basis for what the enterprise does and it is extremely important to get their usage clear, unambiguous and as complete and correct as possible.

• By deciding that the Service-Oriented View defines only the System Services, with the Operational Services being defined in the Operational View, and creating views which were more systems-oriented caused concerns regarding their compatibility with taking a service-oriented approach and what shall be understood by a service throughout the meta-model.

1 DoDAF is evolving along the same lines.



• The operational nodes are, in MODAF & NAF, logical collections of activities (which could be organisation, systems, human, etc.). Therefore, there should not be preconceived notions of whether a system or a human should perform certain activities.

• The initial EAEA framework proposal gave the impression that there would be a need to develop and maintain a bespoke architecture framework. The need to do this should be minimised since, for the EA frameworks which already exist, there is a great deal of supporting resources and infrastructure available at, nominally, very little cost. The aim should be to exploit this support to take best advantage of it.

• The Technical View does not contain the physical architecture. It contains standards which are used in the other views. The physical architecture, if wanted, is covered in the system view.

• The use of the “All View”, which is in both MODAF & NAF, is missing. This needs to be added as the “All View” is essential when working with the other architectural views since it provides the overall scope and purpose of the enterprise as a whole.

In addition to the points made above, a number of other considerations were identified as follows.

• Greater emphasis needs to be placed upon firstly creating the scope, definition, aim and mission of the enterprise for the future EAEA, rather than attempting to analyse which framework and thence, which views should be used to define and describe it.

• Developing common architectural descriptions which are meaningful both within different companies, organisations, etc. and across them, and which will exist in a distributed enterprise environment will require a common standard for their description. This standard (i.e., the selected architecture description framework) requires a language comprising common language elements, syntax and semantics. The reference model must provide a notation traceable to a formal definition for the modelling elements and the relationships used to describe a specific architecture.

• Both MoDAF and NAF provide a service description that is independent of the categorisation or underlying implementation of the service. This is a crucial point in the development of service-oriented architectures and is probably a concept that is most difficult to grasp. Nevertheless it is one of the powerful means to achieve a future EATMS which is composed of the various systems of the different stakeholder organisations. Thus, it is essential to keep the architecture framework indifferent to any kind of implementation specific categorisation of services. The initial EAEA framework proposal did not adhere to this fact.

6.2.3 Overview of Updated Proposal Using the material developed throughout this study and consideration of the observations, conclusions and points identified above with respect to the initial framework proposal, an update of the proposal has been made by Eurocontrol [Ref.21]. The change has been to align the proposal with a standard framework in order to be able to benefit from the “commercial-off-the-shelf” support (e.g., in terms of future tools development, documentation and training) available. Given the limited analysis performed in this study, the experience gained to date and for demonstration purposes at this stage, NAF will be the standard framework used to exemplify the roles of an architecture framework and meta-model in the remainder of this section of the report. However, this does not imply that NAF is the best candidate to use to support the development of the EAEA in the future, nor does it imply that all parts of the framework must be used.

Before an appropriate meta-model is defined for the EAEA and a suitable architecture framework chosen for use throughout the SESAR development programme, there is still a



need to identify what are the goals of the EAEA, and therefore, which parts of the selected framework will be needed to support achieving these goals.

Fig.5 shows an overview of the updated EAEA Framework Proposal. The main difference between it and the initial proposal are :

• The “All View” has been introduced.

• Greater emphasis has now been placed on capabilities by renaming the Strategic View.

• The “Service-Oriented View” previously only addressed services provided by the IT system. Now it addresses all services (including Operational Services previously included in the Operational View) with the kind of service being clearly indicated.

• The “System View” now addresses the more general notion of Resources, not just the IT systems, and now includes the notion of "functions”.

• The “Technical (Standards) View” now addresses guidelines and standards to support implementation, rather than the implementation itself.

All

Vie

wA

ll V

iew

Pro

gram

me

(Pro

ject

/ A

cqui

sitio

n) V

iew

Pro

gram

me

(Pro

ject

/ A

cqui

sitio

n) V

iew

Capability (Strategic) View

Operational View


Systems View

Technical (Standards)View

Capability (Strategic) View

Operational View


Systems View

Technical (Standards)View

Ove

rvie

wD

efin

ition

s

Capability Problem / OpportunityGoal

Service

Resource /System Data

InformationProcess Information Exchange

Organisation / Human Actor

The high-level requirements for Enterprise change over time.

The operational concept – operational roles, processes, scenarios; information flows.

The services to support the operations, their interfaces, behaviour and policy.

The solution specification – the resources providing the services.

Sets

the

scop

e an

d co

ntex

t, pr

ovid

es a

sum

mar

y of

find

ings

.

Technical Standard

ImplementationGuideline

To support implementation – policy, standards, guidance, constraints.

Mile

ston

es /

Tim

ing

Pro

ject

s /

Act

iviti

es

Plan

ning

of p

rogr

amm

es, p

roje

cts,

acq

uisi

tions

to p

rovi

de th

e re

quire

d ca

pabi

litie

s.

Inter-connection

Function

Fig. 5: Overview of Updated EAEA Framework Proposal

In detail, the refined EAEA framework proposal is decomposed into the following main views.

• All View is an overarching view that sets the scope and context of the architecture and contains a common definition of the terms used to describe the architecture. (Note: This view was not addressed by the EA Demonstration Study).

• Capability (Strategic) View describes the enterprise vision and in particular the goals or targets that guide the architecture’s development to ensure that all parts of the enterprise collaborate efficiently to reach the same overall goals.



• Operational View describes the operational processes and activities, organisations and actors and information exchanges required to accomplish ATM operations.

• Service-Oriented View describes the services relevant to the enterprise to manage the information and support the operational processes as defined by the Operational View.

• System View describes the systems and the resources supporting the operational needs, plus their interconnections.

• Technical View provides the technical implementation guidelines upon which engineering specifications are based and common building blocks are established. It includes a collection of the technical standards, implementation conventions, standards options, rules and criteria organised into profiles that govern systems and system elements for a given architecture. (Note: This view was not addressed by the EA Demonstration Study).

• The Programme View describes all relationships between the Capability requirements and the different Programmes and Projects being implemented (Note: This view was not addressed by the EA Demonstration Study).

6.3 Rationale and Use of Some Selected Sub-views The main views of NAF, and hence the updated framework proposal, each consists of a number of sub-views. These are used to address specific aspects concerned with the subject area of each of the main views. NAF [Ref.3] contains 39 sub-views. However, without a clearly defined meta-model of the EAEA against which to assess which of these sub-views are needed to describe and manage it, plus the limited scope of this study, it was only possible to select a limited number to demonstrate their typical content and how they might be used. The material developed during the study and contained in Refs.12 to 19 is the basis of that shown in the example sub-views.

Again, it is stressed here that the content of this whole sub-section is included in this report for illustrative purposes only.

6.3.1 Capability (Strategic) View From Ref.3, the sub-view “NCV-1 – Capability Vision” can be used to capture and describe the principal aspects of the enterprise. NCV-1 has three parts, the:

• Enterprise Vision;

• Enterprise Goals, together with the desired outcomes and measurable benefits associated with them;

• Strategy in terms of capabilities.

The TRS required that “operational (business) goals” [see Ref.12] be developed. These, plus a capability example contained in Ref.12 and the SESAR performance framework material contained in Ref.7, have been used to develop the sub-view shown in Fig.6. It shows an example of how a hierarchy of goals could start to be developed which links the SESAR key performance areas and targets of Ref.7 with the type of capabilities needed which relate to specific aspects of the EAEA.

By linking the ensuing hierarchy of goals to identify and plan the capabilities needed to meet the performance targets, traceability and consistency can be achieved throughout the development and evolution of the EAEA.

The scope of the study did not allow for the detailed identification and/or development of capabilities. However, in order to underpin the content within NCV-1, it is considered that the “NCV-2 – Capability Taxonomy” sub-view will be needed to compliment it since it will



contain a structured list of capabilities and sub-capabilities that will be required in a certain timeframe. Each capability is, where necessary, sub-divided into sub-capabilities and/or functions, in order to provide clarity and the appropriate level of granularity commensurate with meeting the needs of the capability management process. All terms used in NCV-2 should only be expressed in non-implementation specific based terms.

Fig. 6: NCV-1 – Capability Vision

(Example related to Partial Set of Goals)

6.3.2 Operational View In NAF, the operational view is a description of the tasks and activities, operational elements and information exchanges required. The detailed material produced throughout the study on operational processes, operational services, information services and organisation/actors was used to create the following illustrative examples of some of the sub-views related to the operational aspects.

“NOV-4 – Organisational Relationship Chart” describes the principal actors and/or operational nodes which make up the structure of the EAEA and the organisational relationships between them. These are important because they can, for example, illustrate fundamental human roles as well as the organisational relationships.

Fig.7 shows, using the material contained in Ref.15, a typical example derived for the airport-centric scope of this study which relates to an airport operator.



Fig. 7: NOV-4 – Organisational Relationship Chart

(Example for Airport Operator)

“NOV-5 – Operational Activity Model” describes the operations that are normally conducted in the course of achieving an operational objective. It describes operational activities, or tasks, and the input/output (I/O) flows between activities; these generally relating to information exchanges.

From the operational process and information services produced throughout the study, Fig.8 shows a typical NOV-5-type sub-view of the hierarchical decomposition of the processes (boxers in yellow) and sub-processes (boxes in white) involved. Similarly, Fig.9 shows the processes (boxes in yellow) with the I/O flows of the information elements (boxes in white) between them.

These figures have been created using the material contained in Ref.14 and the SWIMPOOL diagram of Fig.3.



Fig. 8: NOV-5 - Operational Activity Model Example

(Example of hierarchical decomposition of processes and sub-processes)



Approach / Departure Controller

Airport Air Traffic Control

Flight Crew

Aircraft Approach Taxi Aircraft to Instructions

Aircraft Departure

Manage Aircraft Airborne Separation and Sequencing

Provide Landing Clearance

Manage Surface Separation and Sequencing

Provide Surface Movement Guidance

Departure Clearance

ATC Clearance

ATC Clearance

ATC Instruction

ATC Clearance

Safety: Separation

Flight

Business trajectory

Business trajectory

Business trajectory

Performance:Efficiency: Sequencing: Airborne Sequencing Plan

ATC Clearance

Fig. 9: NOV-5 – Operational Activity Model

(Example of Input/Output flows between Processes)

In order to assess not only the static, but also the dynamic characteristics of the EAEA, “NOV-6 – Operational Activity Sequence & Timing Description” in NAF could be used. In particular, “NOV-6c – Operational Event-Trace Description” can be used to describe the sequence of processes and provide a time-ordered examination of the information exchanges between participating actors in particular scenarios.

Fig.10 gives an example of the decomposition of the Aircraft Approach process into sub-processes (boxes in white), activities (boxes in blue) and the sequence between them (black lines with arrow). In green, the event that triggers the starting of the process and in pink the end event of the process.

The Actor responsible for the process is the Flight Crew.



Fig 10: NOV-6c – Operational Event-Trace Description

(Example of “Aircraft Approach” Process)

Throughout the study it was apparent that the need to develop and define an Information Model is crucial to ensuring coherence and consistency is achieving throughout all aspects which will make up the EAEA. The purpose of an information model is to analyse the information aspects of the operational domain and to guide the design of information systems. By contrast, a data model (as described in the System View) is used to design the data presentation, handling and storage functionality of an information system.

In NAF, “NOV-7 – Information Model” is the sub-view. Fig.10, created using the material contained in Ref.19, shows the main information elements and their relationships developed in the study.



class Concept Model Iteration 1

News

Flight

Clearance

Airspace

Performance

Demand

Facility

Capacity

«ATM Business Concept»Gov ernance

Business_Trajectory

Condi tion

Time

Traffic_flow

«ATM Business Concept»Activ ity

Organisation

Resource

Surface

Person

+affects

+is_affected

+affects

+is_limited

+may_affect

+may_affect

+is_limited

+may_affect

+control_monitor

+affects

+air_traffic_time_continuum

+ATM_enterprise_monitors

+is_limited

+taking_place_in_space

+wherein_flight_exist_and_move_in_air

+identification

+describes_the_flight+authorizes

+authorize_to_move

+hold_facil ities

+affects

+initiate_activities

+creates_demand

+holds_demand

+holds_facili ties

+by_which_business_objectives_may_be_achived

+maybe_affected

+measure_the_effective_use

+holds_facili ties

+may_afffect

+human_resources

+manage_people

+by_which_business_objectives_may_be_achived

+an_entity_to_perform_work

+controls_monitor_business_trajectories

+individual_fl ight_information

+measure_the_effective_use

+holds_resources

+wherein_fl ight_exist_and_move_on_ground

+taking_place_on_ground

+control_monitor

Fig. 11: NOV-7 – Information Model (Example)

6.3.3 Service-Oriented View Taking a service-oriented approach to the development and structuring of the EAEA was a key recommendation in the deliverables produced throughout the SESAR PD phase. Using the understanding of services in its broadest sense, the notion is that the way in which actors throughout the future EATMS interact at all levels is through the provision and receipt of services.

The detailed material produced throughout the study on operational, information and application services was used to create the following illustrative examples of some of the sub-views related to taking a service-based approach and which are considered to be useful to support the development of the meta-model of the EAEA.

These sub-views have been developed using the material contained in Refs.13, 14, 17 and 19.



From NAF, “NSOV-1 – Service Taxonomy” is used to organise knowledge according to the service perspective and to facilitate the harmonisation of services across multiple domains. Fig.12 shows, as an example, a sub-view of the structure of the categories of operational services (boxes in white) and the services themselves (boxes in green) produced during the study. It has been developed using the material contained in Ref.13 and by adding hierarchic relationships between services.

Aircraft APP Management Service

Aircraft DEP Management Service

Aircraft Landing Service

Aircraft Parking Service

Clearance Provision Service

Facility Allocation Service

Flight Sector handover Service

Pre-departure Check service

Safety Net Service

Separation Assurance Service

Sequencing Service

Surface Route Service

Trajectory Management Service

Weather Monitoring Service

APP Clearance Provision Service

DEP Clearance Provision Service

Landing Clearance Provision Service

Taxi Clearance Provision Service

Air Safety net Service

Surface Safety Net Service

Air Separation Assurance Service

Surface Separation Assurance Service

Air Sequencing Service

Surface Sequencing Service

Surface Route Planning Service

Surface Route Selection Service

ATM Operational Service

Airspace user Services

ATC ServicesAirport Services

Fig. 12: NSOV-1 – Service Taxonomy

(Example of Operational Services)



Surface Sequencing Service

Sequencing Service

Airborne Sequencing Service

Airport Facility Service

Air Traffic Control Services

Airport Operations Services

Capacity Service

Network Operations Services

Monitor Capacity Service

DCB Scenario Building Service

Departure Slot Service

Surface Conflict Detection Service

Flight Operations Services

Flight Management Service

Flight Briefing Service

Surveillance Services

Surface Surveillance Service

Air Surveillance Service

Surface Movement Service

Facility Status Service

Safety Nets Service

Medium Term Conflict Service Detection Service

Conflict Detection Service

ATM Application Services

Clearance Communication Service

Business Trajectory Management


(Example of Application Services) Fig.13 shows, as an example, a sub-view of the structure of the categories of application services (boxes in white) and the services themselves (boxes in pink) produced during the study. It has been developed using the material contained in Ref.17 and by grouping the application services into the categories shown.




(Example of Information Services)

Fig.14 shows, as an example, a sub-view of the structure of the categories of information services (boxes in white) and the services themselves (boxes in yellow) produced during the study. It has been developed using the material contained in Ref.17 and by grouping the information services into the categories shown.

From NAF, the sub-view “NSOV-2 – Service Definitions” is used to delineate and define the services needed to support the operational activities.

A definition of a service is broken apart into distinct segments: • service outcome : defining the intended “real world” effects provided by the

service; • service properties : identifying specific properties of a service that may differ from

one instance or implementation of a service to another. This includes quality of service properties such as performance, security, availability, reliability, maintainability, latency, confidentiality, and integrity;

• service interfaces : specifying the interfaces through which the service consumer may exchange information with this service;

• service policies : specifying the policies regarding security, commercial conditions, applicable laws, etc., under which the service is provided.

NSOV-2 can be presented in tabular form, with the level of details between different types of services not necessarily the same. Table 1 shows, using the material created in Ref.13, an example of how the service definitions may appear for some operational services.

Actor Operational Service Input Output Description

Airport Departure Clearance Request Clearance The functionality that provides for the



ATC Provision Service submission of a clearance, given by the ATC authority to the flight crew.

Flight Crew

Approach Clearance Provision Service Request Clearance

The functionality that provides for the submission of a clearance, given by the ATC authority to the flight crew.

APP ATC

Safety Net Service :: Air Safety Net Service No input Alert

Table 1: NSOV-2 – Service Definition (Example related to Some Operational Services)

Table 2 shows an example of how the service definitions may appear for an application service. It has been developed using the material contained in Refs.17 and 19, with more details about the service description and the service’s operations and associated parameters coming from the SESAR Logical Architecture [Ref.8].

Service Type Description

Application Service

Responsible for determining and maintaining the taxi plan for departing or arriving aircraft taking into account all available information concerning the flight progress and the availability of airport resources, and assessing the potential interactions with other mobiles in order to provide a taxi plan free of any conflict if possible or minimising the number of conflicts and the deviation from the Reference Business Trajectory.

Operation

Planning of the taxi-in plan for a specific Flight as conflict free as possible including the runway crossing points as well as associated time constraints before aircraft landing.

Operation Parameters Optimise taxi-in plan

Input: Flight

Output: Taxi Plan

Planning of the taxi-out plan including the runway crossing points as well as associated time constraints before aircraft takes off.

Operation Parameters Optimise taxi-out plan

Input: Flight

Output: Taxi Plan

Provides a taxi plan different from the one rejected by the controller

Operation Parameters

Surface Movement Service

Provide alternative taxi plan Input: Taxi Plan

Output: Sets of Taxi Plan

Table 2: NSOV-2 – Service Definition (Example related to an Application Service)

Table 3 shows an example of how the service definitions may appear for an information service. Similarly, it has also been developed using the material contained in Refs.17 and 19,



with more details about the service description and the service’s operations and associated parameters coming from the SESAR Logical Architecture [Ref.8].

Service Type Description Information

Service Provides access to flight information.

Operation

Returns the runway associated to the flight

Operation Parameters Find runway

Input: Flight (flight_id)

Output: Runway

Assign a runway to the flight

Operation Parameters Assign runway

Input: Flight (flight_id), Runway

Output: Report

Find Flight aircraft status (e.g., ready, transponding)

Operation Parameters Find Flight Status


Output: Flight_Status

Update the status of the flight Update flight status Input: Flight (flight_id), Flight_Status

Output: Report

Returns the Taxi Route of the flight

Operation Parameters Find Taxi Route


Output: sets of Taxi Plan

Set the taxi route of the flight

Operation Parameters

Flight Service

Set Taxi Route Input: Flight (flight_id), Taxi Route

Output: Report

Table 3: NSOV-2 – Service Definition (Example related to an Information Service)

The sub-view “NSOV-3 – Services to Operational Activities Mapping” provides traceability by illustrating (generally through the use of a matrix) which services support which operational activities. Table 4 shows an example of such a mapping using the material produced throughout the study. In NAF a process is considered to use a service (denoted by “supports”), whereas a process can also describe how a service is realised (denoted by “is described by”).



Table 4: NSOV-3 – Service to Operational Activities Mapping (Example of Operational

Services)

Although not explicitly explored in the study, NSOV-3, together with a number of other sub-views in NAF, can be used to form a line of reasoning which interrelates and maintains traceability across capabilities, operational activities, services and systems.

6.3.4 System View Due to the time and scope constraints placed upon the study, only very limited consideration could be given to the systems aspects. Using predominantly the material contained in Ref.18, some example views are described below.

In NAF, “NSV-1 – System Interface Description” is used to illustrate which systems collaborate in which way to support the information exchange needs between the actors as defined in the Operational View. The system’s interfaces effectively specify the system’s behaviours without specifying its implementation details.

Fig.15 gives an example of a how a high-level System Interface Description sub-view may appear with the interactions being between systems and services highlighted.

Operational Services/ Processes

Airc

raft

App

roac

h

Taxi

Airc

raft

to

Inst

ruct

ions

Airc

raft

Dep

artu

re

Man

age

Airc

raft

Airb

orne

Se

para

tion

and

Sequ

enci

ng

Man

age

Surf

ace

Sepa

ratio

n

Prov

ide

Surf

ace

Mov

emen

t G

uida

nce

Prov

ide

Land

ing

Cle

aran

ce

Dep

artu

re

Cle

aran

ce

Aircraft APP Management Service supportsAircraft DEP Management Service supports

Aircraft Landing Service supportsAircraft Parking Service supports

Clearance Provision Service supports supports supports supportsis

described by

is described

byFacility Allocation Service supports

Flight Sector handover ServicePre-departure Check service supports

Safety Net Service supports supports

Separation Assurance Service supports supportsis

described by

Sequencing Service supports

Surface Route Planning Serviceis

described by

supports

Trajectory Management Serviceis

described by

is described

bysupports

Weather Monitoring Service supports



Fig. 15: NSV-1 – System Interface Description

(Example of System and Service Interactions)

In NAF, the main purpose of “NSV-12 – Service Provision” is to illustrate which systems contribute to the provision of which services”.

Fig.16 shows, as an example, which services are provided by which systems (information services being shown in yellow and application services in pink). When a service is located in green rectangle this denotes that the service is provided by the systems in the respective stakeholder entities. The main dependencies between the services are depicted with a dotted blue arrow.



Fig. 16: NSV-12 – Service Provision

(Example mapping of Services to Systems)



7 LESSONS LEARNT & HIGH LEVEL CONCLUSIONS The following information has been developed from the material contained in the TRS D1 to D8 deliverables (Refs 12 to 19). An attempt has been made to group the material to identify major themes and extract the messages to be taken forward.

7.1 Direction of Study as set by the TRS • The activities outlined in the TRS started at too low a level and did not articulate

the ‘business’ problem to be addressed, nor did they provide a clear view of how the problem, opportunities and goals should be linked together.

• The breadth of the subject areas requested in the TRS (as evident by the set of specified deliverables) and the emphasis placed upon the systems engineering solution aspects, coupled with the inherent level of detail which proved to be needed to achieve participants understanding and meet their expectations in the limited time available, meant that only limited attention could be paid to addressing the strategic / business aspects of the Enterprise.

7.2 Strategic Business Aspects • The initial analysis performed on the goals has concluded that a number of them

can be considered as sub-goals. Consequently, if further analysis is done on them, it is concluded that the set can be reduced in number and a hierarchy of principal goals and sub-goals (which could be considered as objectives) would be the likely outcome.

• From the analysis performed, it is concluded that all the OIs can be linked to at least one goal and the majority can be linked to two or more. However, as they are understood and/or specified today, most of the OIs appear to be solutions without any specific connections as to how they will meet the performance targets associated with the goals and/or how they are compatible with taking a service-based approach.

7.3 The Approach and Method • The SWIMPOOL process diagram helps understanding of the overall operations

and the respective roles and activities of the various Actors. However, the interrelationships between the SWIMPOOL lanes should have been developed earlier in the study to improve the usefulness for the activities which followed.

• An essential lesson learnt was that of the importance of EA in providing governance, and in particular the importance of Governance itself, including guidance and agreement of the definition of terms and methodology to the problem space being considered.

• There was confusion about the meaning and scope of design and architecture activities that became apparent during the production of D2 and D3 (Operational Services and Operational Processes). The activities are different and an understanding of the difference is crucial to understanding what should be produced (i.e., the principal concern of design) and why it is being produced (i.e., the principal concern of architecture).

• The use of a middle-out approach to developing the architecture taken for this Study is not a strategic approach to the production of an Enterprise Architecture. That is, by definition, it is not top-down. It is a pragmatic approach used to deliver quick results, with the resultant impact on the material developed, which can be used as a starting point and for the assessment of the problem space. The output



should be validated against the strategic layers of the EA if it is to be used to generate subsequent life-cycle deliverables. It is important that, ultimately, all parts of the Enterprise are linked and aligned to the strategic vision and that the justifying arguments are made from a top-down perspective.

• The use of the approach adopted for the discovery of Operational Processes enabled a relatively fast way to ascertain the processes used within the current ATM Airport Centric view, and provided a suitable basis for the discovery of a number of required deliverables (artefacts is the current paradigm). However, it is a middle-out approach and should be used in conjunction with other techniques to create a reference model, not instead of using one.

• Operational process identification and levelling are part of an iterative task and further iterations of the Study’s output material would be required to increase confidence that the correct processes had been identified.

• During the Study activity (i.e. exploring an EA methodology), time and resource limitations (i.e., schedule of work) meant it was not always possible to provide stable inputs to subsequent tasks within the overall activity. More detailed activity planning will need to be carried out for future activities, taking note of the task dependencies.

• The list of systems has been elaborated based on those from the SESAR PD phase, however there was no recognised methodology to aid the identification of systems/sub-systems from the set of services which were identified.

7.4 Frameworks • Concentrating on the architecture framework views and how to populate them is

not the approach to adopt to develop an EA. The content and selection of the views are a result of creating the reference model, not its design. The views have the purpose of communicating the content to different Stakeholder groups. Their design must be derived from the ATM Stakeholder needs and problem space being addressed. The underlying architecture remains invariant to which views are selected.

• As the Study progressed, and the strategic objectives were revisited, it became apparent that the NAF notion of capabilities would offer potential when describing the architecture from a high level viewpoint and be particularly useful in illustrating the evolution of capabilities towards the proposed target architecture, plus helping to link business goals to operational services.

• The development of the Organisation Chart Views requires close co-operation with the development of the Operational Processes and Operational Services in order to achieve a consistent set of Architecture Artefacts to support the operational domain.

7.5 Information and Information Services • Information requirements are normally captured in the operational view

documentation (e.g., the NOV-3 sub-view in NAF v3). The absence of such an artefact made it difficult to identify the key business information for the Airport Centric View.

• Both the EAEA proposed framework and the defence frameworks on which it is based (MoDAF and NAF) are almost devoid of meaningful guidance on the use of a CIM, particularly with reference to the level at which the CIM should be produced relative to the Architecture layers. It is not clear from the material



whether it is a strategic view for the business or a reference view for Information Architects, or indeed both.

• There was no common understanding of the scope, content or method for developing a CIM and as a result, the process was not as efficient as it could or should have been. The material produced is a first attempt, with further iterations required to develop the CIM. However, it must be noted that there is no correct answer, only material that is fit for purpose and provides all Stakeholders with a common understanding of the information appropriate to the overall Enterprise.

• The identification and articulation of the information concepts being addressed within the problem space for the CIM significantly aids the understanding of all areas of the architecture activity, regardless of the level being addressed or the work being undertaken.

• Identification of Information Services builds a greater understanding of the Operational Processes identified within a particular area (in this case the Airport Centric view), and generates important feedback for further elaboration of the Operational Processes.

• Identification of Information Services requires a sound operational understanding of the Users’ needs. That is, the identification of the Information Services relies on the business process models identified at a higher level, coupled with analysis performed by operational experts.

• The classification of an Information Service is not straightforward (e.g. how much logic is acceptable in an Information Service and how and where should business rules be included) and requires the use of expert judgement. Agreement on the rules for classification, clear definitions, EA principles, Architecture experience and Operational experience all help to increase the consistency and coherence of services as they are identified.

• The simplicity of a LIM will almost always disguise the amount of thought that must be applied to produce it to the correct level of detail and in a form that can be agreed amongst the Stakeholders. Conversely however, there is always the temptation to iterate to provide a level of detail and correctness that is not required. The LIM is considered to be part of “architecture” and should provide a level of detail commensurate with the problem being addressed.

• The LIM is simply a schematic representation of the information (including loose relationships) that is perceived to be required in the problem space being analysed. It is important to understand that information and data are not the same thing and that an Information Model is required regardless of the approach taken to data design at the lowest level.

• Information Models must be capable of standing alone and being agreed and approved by all Stakeholders, irrespective of work undertaken on the functional area of architecture (i.e., Operational Services, Processes, Capabilities, etc.). Whilst one will inform the other, the LIM must not be derived from the functional work, lest changes in the business will necessitate changes in data structures and will require constant change to the IT support and infrastructure. Information elements rarely change when they have been modelled correctly.

• The LIM is a mandatory deliverable for any future programme of work that involves Information Technology to leverage Operational Improvements. It can also be considered as an enabler for quick wins by providing the mechanism for identifying common information.



• The Study found that, as a result of producing the LIM, the Information Services required for the problem space could be identified quickly once the information concepts and their relationships were articulated.

7.6 Operational and Application Services • During the Study there was a level of uncertainty as to the use of Operational

Services regarding whether the service is delivering the process or is being delivered by the process. Both were considered appropriate for this activity, however the approach for future activities should be agreed.

• The relationships between the various Organisations and their respective Actors allows for the confirmation of the Operational Services needed to support the operational functionality of both the current and future organisational structures.

• There was confusion about the difference and relationship between Operational Services and Application Services. This is reflected, to some extent, in the Study output, particularly where the appropriate expert judgement was not available to be applied.

• The production of the Application Services was hampered by the lack of a clear statement of intent as to what they were expected to achieve. The approach taken was to describe the functionality that needed to be provided with the support of automation.

• Even with a complete and well documented set of Information and Application Services available, there is still an activity to link the service and system view. This activity requires detailed domain knowledge to be provided by ATC operational experts.

7.7 Systems • The production of the system view implies making use of a set of well defined and

agreed services. Due to the time constraints of the Study, it was not possible to provide this set and as a result, the systems material was not as complete as other Study deliverables.

7.8 General Conclusions • As a result of this Study a better understanding has been reached of how

performance objectives can be linked to services through the use of capabilities. However, identifying and using processes to measure performance has not been explored in detail. To this effect, activity modelling (i.e., creating a functional description) is a far better tool to use to represent what is required as part of a reference model. The SWIMPOOL diagram, as a view, is only a means to an end and should not be considered as the end in itself.



8 STUDY RECOMMENDATIONS The following information has been developed from the material contained in the TRS D1 to D8 deliverables (Refs 12 to 19). An attempt has been made to group the material to identify major themes and extract the messages to be taken forward.

8.1 Direction of Study as set by TRS • Whilst the subject areas specified by the TRS were clearly relevant, in any future

study, a better balance between specifying the needs of the Enterprise and then identifying solutions must be achieved.

• EA Governance, including guidance and agreement of the definition of terms and methodology to the problem space being considered, is crucial to any future activities in this area,

• Since most of the Operational Improvements (OIs) in the line-of-change 10 (see Ref.9) appear to be solutions without any specific connections as to how they will meet the performance targets associated with the goals and/or how they are compatible with taking a service-based approach, they must be reconsidered based upon the goal and performance-driven approach outlined in this Study.

8.2 Strategic Business Aspects • When undertaking the development of operational (business) goals in the future,

a comprehensive, rigorous and iterative process of goal development, modelling and analysis must be performed to establish a solid operational/business foundation at the top-level of the EA which will be used to guide the development of the Future EATMS.

• Some activities can be performed in parallel and performing iterations between layers is essential. By taking a service-based approach in combination with the use of a reference model will allow selected functions, or groups of capabilities, to progress without compromising neither the overall shape of the whole EA, nor the governance mechanism which must accompany it. However, it is important that achieving consolidation, agreement and “sign-off”, especially of the content of the reference model, is critical to achieving effective governance. This approach should be used in the future.

• In order to link the operational (business) goals to the operational services (and other aspects of the EA model as applicable), the notion of capabilities (and functions) is essential to ensure the operational services will be developed and defined to meet the goals.

8.3 The Approach and Method • The Study activities were carried out by individuals with a wide range of domain

knowledge (e.g., ATC operations, system engineering, research and development) but a limited knowledge of, and exposure to, business and Enterprise Architecture activities. In future, each activity should be carried out by a small group of experts which must include having business domain knowledge, plus Enterprise Architecture knowledge and experience.

• The establishment of, and agreement upon, a Meta-model is seen as necessary from the outset to be used as a driver for guiding and unifying the EA activities.

• The overall EA process should be to develop a pragmatic approach to the way in which material will be developed or identified, which addresses the problem and



the objectives to be met. This must take account of the business drivers in the problem space.

• The middle-out approach adopted in this Study as a mechanism for service identification and exploration is considered to be directly compatible with taking an EA approach. However a functional model (including capabilities) must be produced to enable a common understanding of the problem space to be developed. This is needed to support Stakeholder understanding and decision making as part of the overall process to develop and agree an EAEA.

• With any EA activity, it is necessary at the outset to identify the objectives of using this approach. Subsequently, the EA framework and its views/sub-views should be used to capture the material developed by the Stakeholders and experts involved, and to provide support and governance to help meet the stated objectives.

• The architecture activity should use the EA framework to bridge the gap between the vision and goals of the overall Enterprise to the capabilities, functions and systems that have to be implemented and deployed.

• To develop the overall ATM Enterprise, individual Stakeholder ‘enterprises’ will have to be linked in such a way as to provide consistency throughout all layers of the Enterprise.

• In order to ensure that system solutions are implemented which provide the information services to deliver the required operational services of the ATM stakeholders, a top-down approach should be taken to developing the EA. This does not preclude carrying out activities in parallel at various layers of the EA provided an iterative approach is taken and an appropriate governance régime is put in-place.

• More detailed activity planning needs to be carried out for future EA activities, especially taking note of task dependencies.

• The issue of making use of existing material (e.g., the proposals made in the results of the OATA and FOIPS studies) remains open. For any problem being addressed, an architecture should be developed that meets the objectives stated by the ATM Stakeholders. Thence, in order to meet these objectives in the most efficient manner, a balance has to be found between developing new material which is independent of the existing material and re-using selected parts of this material to populate the architecture.

• A major objective of the Study was to understand the impact of the introduction of services upon the architecture. It could be shown within the scope of the Airport Centric View, that services can indeed be identified and used for developing and describing the architecture, providing a common understanding for all Stakeholders to help meet performance and efficiency objectives. As a result, a Service–based approach should be used in the future.

• During the Study, an agreement on a service taxonomy and classification was not achieved. However, it is felt that this is important and should be done before further detailed EA activities are initiated.

• When undertaking the development of operational (business) goals in the future, a comprehensive, rigorous and iterative process of goal development, modelling and analysis must be performed to establish a solid operational/business foundation at the top-level of the Enterprise Architecture (EA) model which will be used to guide the development of the Future EATMS.



• A reference model of the activities that need to be performed within the overall enterprise by the participating Stakeholders and Actors is required to identify and confirm what is expected of each, and to ensure consistency and completeness.

8.4 Frameworks • NAF provides limited guidance on how to develop an EA as it is a framework, and

should not be treated as a methodology or implementation method. The method to be adopted to develop the EA should be agreed in advance of trying to apply the architecture framework.

• In the development of the EA, it is important to describe the “top-layers” of the architecture (i.e., the strategic and business layers) correctly, as they will drive the “design” and they are the layers where Stakeholder expectations and the architecture environment are captured. The top-layers will remain fairly static over time, whereas the lower-level (i.e., design) layers are more likely to change to continue to provide optimal solutions.

• The capability aspects of the chosen architecture framework should be used to illustrate the evolution of the capabilities of the Enterprise over time and link business goals with operational services.

• The EA system view is dependent upon the service view. The production of the system view and the mapping of services to systems should only start when there is an agreed initial version of the service view.

• Future EAEA development activities should include a process for the production of the reference model for the Enterprise, identifying the necessary “core material” in accordance with this meta-model. This material will then be represented using a set of views.

8.5 Information and Information Services • A CIM is required for future EA activities and would form a significant part of the

“collective memory” for the ATM Industry, enabling the necessary agreements between Stakeholders to achieve inter-operability, guide architects and inform the solution developers of the likely information requirements of future EAEA activities.

• The purpose of the CIM should be identified and the requirements developed making use of the contents of regional and global ICAO and IATA documents, as appropriate.

• The CIM should be documented in a formalised, standardised notation language showing the agreed and defined information concepts and their relationships.

• Information modelling is included within the architecture frameworks used for this Study and must be an integral part of any future EA activity.

• There is a need to clarify the level of detail required of any CIM that is required for the problem space under analysis and ensure that it is consistent for use on a wider scale throughout the entire EAEA.

• The LIM must be considered as a mandatory deliverable for any future EA programme of work and should be used to produce an Information Service model with a mapping between Information Elements and Information Services.

8.6 Operational and Application Services • Before further EA activities are undertaken, a clear statement regarding the intent

and scope of any Application Services is required. A significant factor regarding



the identification of Application Services should be making best use of standardised interfaces and re-use of existing functionality.

• When services are being identified and developed, the aim should be to provide a coherent level of abstraction and detail so that any subsequent allocation to systems is made easier.

8.7 Systems • As the EA system view is dependent upon the service view, an agreed set of

services should be identified prior to development of the system view.

8.8 General Recommendations • A clear understanding is required as part of the overall strategy statements

(whether through the expression of the vision or the goals) that any EA approach taken will not articulate the way in which the desired capabilities are designed, built and implemented. Expert knowledge and judgement must still be applied.



9 PROPOSED WAY AHEAD

Due to a number of practical limitations, the activities undertaken in response to this TRS took an approach which was not top-down and the problem space only represented part of the ATM Enterprise, i.e., the Airport Centric View. Nevertheless, the study has identified many very useful lessons to be learnt and made numerous recommendations which can be taken forward in the SESAR development programme. These can be applied directly to create an ATM Enterprise based upon taking a service-based approach.

Based upon the lessons to be learnt and the recommendations identified, the following summarises the principal activities which must be considered as part of the proposed way ahead to be followed within the SESAR development programme.

• Identify the starting point for developing an EA in the ATM environment, taking into account the SESAR ATM Target Concept and the agreed Work Package structure of the development programme.

• Identify the steps in the overall process to develop an EA and link these to the principal elements of the SESAR Future ATM Target Concept.

• Identify a strategy for developing the overall EA, recognising that the problem space is large and that several Stakeholders (especially those from the “Users of the Network”) will be involved. This large problem has to be broken down into a number of smaller problems which are then addressed using a common approach (including use of language, terminology, definitions, etc.).

• Choose an Architecture Framework to be used to support the future activities.

• Identify the required outputs from the EA activities (e.g., an Information Model, a Service Catalogue).

• Develop guidelines for the development of a reference architecture meta-model at the start of any future activity.

• With the general acceptance of the introduction of EA and taking a service-based approach in future SESAR activities, the conventional “Operational Improvement – OI” approach must be challenged and critically scrutinised with respect to its relevance within this new paradigm.

• An initial output from this TRS is that the concept of capability should be applied to the development of the EAEA for the future European ATM System, with a move away from the current preoccupation with OIs.

The way forward should set in place a Governance structure and process for both the SESAR ATM Target Concept and the ATM Enterprise it will enable. Although activities can be performed in parallel, the SESAR vision cannot be achieved without a top-down view of the entire problem space. This should be rigorously developed, applied and managed throughout the EA Governance structure to ensure that, ultimately, all parts of the Enterprise are linked and aligned to the strategic vision, and that the justifying arguments and rationale are made from a top-down perspective.

Clear consideration must be given to the development of a Conceptual Information Model to ensure consistency of understanding is achieved across the Enterprise, facilitate System Wide Information Management and ensure a service-based approach is taken.

Allied to this, it is important to work out how the SESAR Concept of Operations will be presented and how it will lend itself to the discovery of Operational Processes, and subsequently, Operational Services. From the work undertaken in this study, it is evident that the CIM and the Operational Processes are key parts of developing the EAEA. When these



artefacts are identified and described, it will then be possible to make use of the most appropriate EA Framework to support the governance structure and further illustrate the various ”layers” of the Enterprise that are deemed necessary. This will be done primarily using expert judgement.



10 REFERENCES

1. Eurocontrol Task Requirement Sheet No. : 08-111642-T, entitled “Initial Activities in Enterprise Architecture application to ATM”, dated 18/08/2008.

2. OATA MCS – EAEA Framework proposal : Doc. Ref. OATA-MCS-22-01, Edition 1.1, dated 30/10/2008.

3. NATO Architecture Framework (NAF), v3, Annex 1 to AC/322-D(2007)0048.

4. (UK) Ministry of Defence Architecture Framework (MoDAF), v1.2.003, dated 30 April 2008.

5. Report of SESAR SOA Task Force, v4.0, dated 21 January 2008.

6. SESAR Definition Phase - Milestone Deliverable D1 - Air Transport framework : The current Situation – Edition 03-00 - Reference DLM-0602-001-03-00.

7. SESAR Definition Phase - Milestone Deliverable D2 - The performance Targets – Edition 02-00 – Reference DLM-0607-001-02-00.

8. SESAR Definition Phase - Milestone Deliverable D3 - The ATM Target Concept – Edition 02-00 – Reference DLM-0612-001-02-00.

9. SESAR Definition Phase - Milestone Deliverable D4 - The ATM Deployment Sequence – Edition 02-00 – Reference DLM-0706-001-02-00.

10. SESAR Definition Phase - Milestone Deliverable D5 – The ATM Master Plan – Edition 2.0 – Reference DLM-0710-001-02-00.

11. SESAR Definition Phase - Milestone Deliverable D6 - The Work Programme for 2008-2013 – Reference DLM-0710-002-02-00-D6.

12. OATA – MCS - 12 – 01 (Deliverable D1-Operational (Business) Goals) v1.0.

13. OATA – MCS - 12 – 02 (Deliverable D2-Operational Services) v1.0.

14. OATA – MCS - 12 – 03 (Deliverable D3-Operational Processes) v1.0.

15. OATA – MCS - 12 – 04 (Deliverable D4-Organisation Chart) v1.0.

16. OATA – MCS - 12 – 05 (Deliverable D5-Concept Information Model) v3.0.

17. OATA – MCS - 12 – 06 (Deliverable D6-Services) v1.1.

18. OATA – MCS - 12 – 07 (Deliverable D7-Systems) v1.1.

19. OATA – MCS - 12 – 08 (Deliverable D8-Information Model) v2.0.

20. SESAR Joint Undertaking (SJU), Work Package B (WP-B), Description of Work (DoW) v4.0.

21. OATA MCS – EAEA Framework proposal : Doc. Ref. OATA-MCS-22-01, Edition 1.3, dated 16/04/2009.



11 ANNEXES

11.1 ANNEX 1 – LIST OF OPERATIONAL (BUSINESS) GOALS The following Table shows the Operational (Business) Goals (OBGs) developed during the study.

OBG Code

Operational (Business) Goal (OBG)

Explanatory Notes

OBG-1 To enable a 3-fold increase in the capacity of the Future EATMS and at least to handle a doubling of air traffic demand by 2020.

The Future EATMS must be capable of handling 3 times the air traffic demand for ATM services in order to meet the more detailed performance targets [see Ref.7]. The activities performed at Airports and the associated infrastructure must be capable of supporting the achievement of this goal. These must be capable of being implemented and deployed when needed.

OBG-2 To improve the safety performance of the Future EATMS by a factor of 3 by 2020 and ultimately by a factor of 10 when handing the 3-fold increase in air traffic demand.

When being capable of providing the capacity to handle up to 3 times the demand for ATM services, the Future EATMS must be capable of meeting the safety performance targets stated concurrently and proportionally to the increase in air traffic demand. Safety performance of the activities performed at Airports and the associated infrastructure must be capable of supporting the achievement of this goal; these being integral and appropriate to the operational context.

OBG-3 To enable a 10% reduction in the effects flights have on the environment.

When being capable of providing the capacity to handle up to 3 times the demand for ATM services and meeting the safety performance targets, the Future EATMS must be capable of enabling a 10% reduction in the effects flights have on the environment [see Ref.7 for more details] concurrently. The activities performed at Airports and the associated infrastructure must be capable of supporting the achievement of this goal; these being integral and appropriate to the operational context.

OBG-4 To provide ATM services from the Future EATMS at a cost to the airspace users which is at least 50% less relative to the charges made in 2005.

It is envisaged that the Future EATMS will provide a variety of ATM services to meet the specific needs of the wide variety of airspace users. Having scoped what constitutes ATM in the future, the actors within the Users of the Network, plus the activities and infrastructure needed, the services will be provided at a cost to the airspace users which is equivalent to 50% less relative to the charges made in 2005.

OBG-4a For the “Users of the Network” (i.e., the airspace users, airport operators and air navigation service providers) to deliver ATM Services which meet the performance targets (see Annex 1) by working collectively through the formation of the ATM Performance Partnership (ATMPP).

For the “Users of the Network” (i.e., the airspace users, airport operators and air navigation service providers) to deliver ATM Services which meet the performance targets [see Ref.7] by working collectively through the formation of the ATM Performance Partnership (ATMPP). In particular, this relates to the key performance area (KPA) of



OBG Code


Explanatory Notes

Participation.

OBG-5 To use the ATM Performance Framework of 11 Key Performance Areas (KPAs) as the basis of setting and achieving commonly agreed ATM Key Performance Indicator (KPI) targets for the “Users of the Network” within the ATM Performance Partnership.

For the “Users of the Network” to deliver ATM Services which meet the performance targets [see Ref.7] by having a common understanding of and working collectively to meet a common set of performance indicators and targets which are based upon and derived from the ICAO Performance Framework.

OBG-6 To make collaborative decisions within the partnership to meet commonly agreed performance targets and goals.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to meet a common set of performance targets and goals defined for the ATMPP.

OBG-7 To measure performance from an “en-route-to-en-route” basis, i.e., incorporating the airport turn-around process.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to meet a common set of performance targets and goals defined for the ATMPP. By measuring performance from this perspective, the activities and capabilities of operations performed by the Users of the Network at Airports are fully integrated into the performance of the Future EATMS.

OBG-8 To achieve whole ATM Network optimisation of performance which incorporates optimised regional performance and optimised local performance in a 3-tiered ATM structure.

Although achieving optimal performance across the European ATM Network is essential to support the network nature of air transport, it is acknowledged that different airspace users have different needs. Further, geographical variations and constraints also determine the different activities and capabilities needed to meet these differing needs. It is considered that, in order to meet differing needs under different operational circumstances, the aim will be to optimise performance at local, sub-regional (e.g., across a functional airspace block) and network levels. However, optimisation at one level must be done with respect to the next highest level. In addition, this goal relates to achieving the principles established for the Participation KPA [see Ref.7].

OBG-9 To use common time reference as basis to perform operations.

Through the sharing of information, having a common view of situations and making decisions collaboratively, the Users of the



OBG Code


Explanatory Notes

Network will agree to use, as a means, a common time reference to plan, implement and perform their activities.

OBG-10 To achieve best overall outcome for a flight, using its trajectory (SBT/RBT) as the basis, to meet performance targets.

This goal builds directly upon one of the main features of SESAR’s proposed concept of operations whereby the Users of the Network scope their capabilities and perform their activities to work collaboratively to meet a common set of performance indicators and targets which achieve the best outcome for each flight as required by the relevant airspace user.

OBG-11 To minimise the need for tactical intervention to change the reference business trajectories of flights.

This goal builds directly upon one of the main features of SESAR’s proposed concept of operations whereby the Users of the Network scope their capabilities and perform their activities to work collaboratively to meet a common set of performance indicators and targets which achieve the best outcome for each flight as required by the relevant airspace user.

OBG-12 To meet ATM performance targets, make maximum use collectively of available information, maximising the sharing of information throughout the partnership, but respecting commercial and competitive considerations.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to meet a common set of performance targets and goals defined for the ATMPP.

OBG-13 To achieve “economies of scale” by identifying activities which are consistent & generic across partners’ operations, but acknowledge and accommodate variations where appropriate.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to meet a common set of performance targets and goals defined for the ATMPP. Where appropriate and workable, partners will also use common processes and find common solutions which will avoid duplication, provide shared benefits and thus, lead to reduced costs. This is considered to be key to meeting the cost effectiveness performance target [see Ref.7].

OBG-14 To make optimal use of resources to meet performance targets, continuously balancing demand with capacity.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to make optimal use of the resources available to ensure the available



OBG Code


Explanatory Notes

capacity of the ATM System meets the demand presented. This is one of the main principles upon which demand capacity balancing within the SESAR Concept of Operations is based.

OBG-15 To apply asset management principles as the basis of making new infrastructure investment decisions to derive optimal benefits from legacy and new systems.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to meet a common set of performance targets and goals defined for the ATMPP. Where appropriate and workable, partners will also use common processes and find common solutions which will avoid duplication, obtain maximum benefits from the assets used and coordinate major investments. This is considered to be key to meeting the cost effectiveness performance target [see Ref.7].

OBG-16 To achieve interoperability at service & functional level to deliver performance targets throughout future ATM System.

Through the sharing of information and having a common view of situations, the Users of the Network will make decisions collaboratively to plan, implement and perform their activities and capabilities to meet a common set of performance targets and goals defined for the ATMPP. Where appropriate and workable, partners will also use common processes and find common solutions to meet this goal. This goal relates to achieving the principles established for the Interoperability KPA [see Ref.7].

OBG-17 To reduce runway occupancy time to maximise capacity appropriately under all meteorological conditions.

This can be considered as a sub-goal of the higher-level business goal concerned with meeting the capacity performance target.

OBG-18 To safely reduce separation distances to maximise capacity appropriately under all meteorological conditions.

This can be considered as a sub-goal of the higher-level business goals concerned with meeting capacity and safety performance targets.

OBG-19 To optimise turn-round times. This can be considered as a sub-goal of the higher-level business goals concerned with meeting the capacity and cost effectiveness performance targets, plus making optimal use of resources.

OBG-20 To improve allocation and use of resources.

This can be considered as a sub-goal of the higher-level business goals concerned with meeting the capacity and cost effectiveness performance targets, through making optimal use of resources.

OBG-21 To optimise take-off sequence to make most efficient use of resources.

This can be considered as a sub-goal of the higher-level business goals concerned with meeting the capacity, safety and cost effectiveness performance targets, through making optimal use of resources.

OBG-22 To optimise arrival sequence to make most efficient use of resources.

This can be considered as a sub-goal of the higher-level business goals concerned with



OBG Code


Explanatory Notes

meeting the capacity, safety and cost effectiveness performance targets, through making optimal use of resources.



11.2 ANNEX 2 – CROSS REFERENCES BETWEEN OPERATIONAL (BUSINESS) GOALS AND OPERATIONAL IMPROVEMENTS (OI) IN LINE-OF-CHANGE (LOC) 10

The following table cross references the Operational (Business) Goals (OBGs) and the Operational Improvements (OIs) associated with the SESAR Line-of-Change (LOC) 10. Also included is the Implementation Package (IP) to which each is associated [see Ref.10].

OI CODE LOC 10 OI STEPS IP CROSS-REFERENCE WITH

RESPECT TO OPERATIONAL (BUSINESS) GOALS (OBGs)

AO-0101 Reduced Risk of Runway Incursions through Improved Procedures and Best Practices on the Ground

1 Solutions mainly in support of OBG-2

AO-0102 Automated Alerting of Controller in Case of Runway Incursion or Intrusion into Restricted Areas

1 Solution mainly in support of OBG-2

AO-0103 Improved Runway-Taxiway Lay-out, Signage and Markings to Prevent Runway Incursions


AO-0104 Airport Safety Nets including Taxiway and Apron


AO-0201 Enhanced Ground Controller Situational Awareness in all Weather Conditions

1 OBG-1, OBG-2

AO-0202 Detection of FOD (Foreign Object Debris) on the Airport Surface

1 OBG-2

AUO-0605 Automated Alerting of Runway Incursion to Pilots (and Controller)

2 Solution mainly in support of OBG-2

AO-0203 Guidance Assistance to Airport Vehicle Driver

1 Solution mainly in support of OBG-1 & OBG-2

AO-0204 Airport Vehicle Driver's Traffic Situational Awareness


AO-0205 Automated Assistance to Controller for Surface Movement Planning and Routing


AO-0206 Enhanced Guidance Assistance to Airport Vehicle Driver Combined with Routing


AO-0207 Surface Management Integrated With Departure and Arrival Management

2 OBG-10, OBG-21, OBG-22

AUO-0602 Guidance Assistance to Aircraft on the Airport Surface


AUO-0603 Enhanced Guidance Assistance to Aircraft on the Airport Surface Combined with Routing


AUO-0604 Enhanced Trajectory Management through Flight Deck Automation Systems

1 Solution in support of OBG-10

AO-0501 Improved Operations in Adverse Conditions through Airport Collaborative Decision Making

1 OBG-1, OBG-6, OBG-10

AO-0601 Improved Turn-Around Process through Collaborative Decision Making

1 OBG-19

AO-0602 Collaborative Pre-departure Sequencing 1 OBG-10, OBG-21 AO-0603 Improved De-icing Operation through

Collaborative Decision Making 1 OBG-6, OBG-10

DCB-0304 Airport CDM extended to Regional Airports

1 OBG-6, OBG-8

AO-0402 Interlaced Take-Off and Landing 1 OBG-1, OBG-10, OBG-21, OBG-22 AO-0403 Optimised Dependent Parallel Operations 1 OBG-1, OBG-2, OBG-20



OI CODE LOC 10 OI STEPS IP CROSS-REFERENCE WITH RESPECT TO OPERATIONAL (BUSINESS) GOALS (OBGs)

AUO-0701 Use of Runway Occupancy Time (ROT) Reduction Techniques

1 OBG-1, OBG-9, OBG-17

AUO-0702 Brake to Vacate (BTV) Procedure 1 Solution mainly in support of OBG-10 & OBG-17

AUO-0703 Automated Brake to Vacate (BTV) using Datalink


AO-0301 Crosswind Reduced Separations for Departures and Arrivals

1 OBG-10, OBG-18

AO-0302 Time Based Separation for Arrivals 1 OBG-10, OBG-18 AO-0303 Fixed Reduced Separations based on

Wake Vortex Prediction 1 OBG-10, OBG-18

AO-0304 Dynamic Adjustment of Separations based on Real-Time Detection of Wake Vortex

2 OBG-10, OBG-18

AO-0305 Additional Rapid Exit Taxiways (RET) and Entries

1 Solution in support of OBG-1, OBG-15 & OBG-17

AO-0502 Improved Operations in Low Visibility Conditions through Enhanced ATC Procedures

1 Solutions in support of OBG-10

AO-0503 Reduced ILS Sensitive and Critical Areas 1 Solutions in support of OBG-15 & OBG-20

AO-0504 Improved Low Visibility Runway Operations Using MLS

1 Solution in support of OBG-1 & OBG-18

AO-0505 Improved Low Visibility Runway Operations Using GNSS / GBAS


AUO-0403 Enhanced Vision for the Pilot in Low Visibility Conditions


AUO-0404 Synthetic Vision for the Pilot in Low Visibility Conditions


AUO-0501 Visual Contact Approaches When Appropriate Visual Conditions Prevail


AUO-0502 Enhanced Visual Separation on Approach (ATSA-VSA)


AO-0701 Effective Collaboration between ATM Stakeholders Supported by Environmental Management Systems

1 OBG-3, OBG-10

AO-0702 Improved Relations to Neighbours 1 OBG-3 AO-0703 Noise Management to Limit Exposure to

Noise on the Ground 1 OBG-3, OBG-10, OBG-20

AO-0704 Optimised Design and Procedures for Airport manoeuvring Areas to Reduce Gaseous Emissions and Noise Disturbance

1 Solutions in support of OBG-3, OBG-10, OBG-15 & OBG-20

AO-0705 Reduced Water Pollution 1 Solution in support of OBG-3 & OBG-10

AO-0706 (Local) Monitoring of Environmental Performance

1 OBG-3, OBG-13

AUO-0801 Environmental Restrictions Accommodated in the Earliest Phase of Flight Planning

1 OBG-3, OBG-10

AUO-0802 Ground Movement Techniques to Reduce Gaseous Emissions and Noise Disturbance

1 Solutions in support of OBG-3 & OBG-10

AUO-0803 Reduced Noise Footprint on Departure 1 OBG-3, OBG-10

Initial Activities in Enterprise Architecture application to ...

Technology

Transcript of Initial Activities in Enterprise Architecture application to ...