EUROCONTROL AMHS Specification · PDF fileEUROCONTROL AMHS Specification Workshop ... »...

European Organisation for the Safety of Air Navigation

EUROCONTROL AMHS Specification Workshop

Speaker Jacky POUZET

Organisation EUROCONTROL

Date and venue 23rd June 2009, Brussels

2

EUROCONTROL AMHS Specification Introduction

♦ Today’s objectives

♦ Agenda

♦ Next Steps

3

EUROCONTROL AMHS Specification Why we are here

♦ To present the results of the Formal Consultation

4

EUROCONTROL AMHS Specification Agenda

♦ Welcome

♦ Update on Communication strategy – Nikos Fistas

♦ ATM Standardisation in the SES context

♦ EU perspective – Sven Halle

♦ EUROCONTROL perspective – Eivan Cerasi

♦ Overview of the Specification – Richard Papior

♦ Results of the Consultation

♦ Overall results – Bolek Gasztych

♦ Summary of Responses – Tony Kerr

♦ Questions & Answers

♦ Conclusion and next steps


EUROCONTROL AMHS Specification End


EUROCONTROL AMHS SpecificationWorkshop

Speaker Nikos Fistas



2

The big picture

SES

SESARATM Master Plan

COM -Infrastructure

Strategy

3

High-Level European ATM System 2020 architecture

4

Future Aeronautical Communications

CFMU

ATC, AOC, (APC)

ATSU

AIMAirline Ops

IP network (PENS – SWIM backbone)Applications: AMHS, OLDI/FMTP, Surveillance, AIM, Voice, …

VHF voice 25 & 8,33 kHz

Data link: CPDLC, FIS (ATN, ACARS)

New datalinks

New mobile network

Satellite Communications

Airports

ATSU4D

(COCR…)

ATC, APC, AOC

Surveil-lance

MIL

5

SESAR Service Levels - Communications

0806 07 09 10 11 12 1513 14 16 17 18 19 2220 21 23 24 25 26 27 28 Time (Calendar Years)

Implementation

Available for operationsRolling out Current Best Practices

R&D

Implementation

Available for operations

Preparing Trajectory based operations

R&D

Implementation


Implementing net-centric trajectory management

R&D

Implementation


Achieving advanced automation in a shared trajectory environment

R&D

Implementation


Extending operations with advanced separation modes


R&D

ImplementationFull 4D trajectory management

0

1

2

3

4

5

AT

M S

ervi

ce L

evel

s

AMHS, VDL2/ATN, 8.33 kHz above FL195

European IP backbone, VoIP (telephony)

G/G IP network, VoIP (radio),Link16, 8.33kHz below FL195

Air/ground transport layer, New Airport data-link (802.16)

New data-links (L Band, satcom)

A/G digital voice, A/A

6

SJU WBS

3 - Validation Infrastructure

13 - NIMS

10 - ATC

11 - AOC

12 - Airport 14 - SWIM

9 - Aircraft4 - En Route Operations

7 - Network Operations

5 - TMA Operations

6 - Airport Operations

8 - Information Management

15- Ground CNS

Industrial Support

A/1 - WP Management

D - ATM NetworkR&D Programme

16 - Transversal Areas

B - Target concept & Architecture

C - Master PlanMaintenance

E - LT & InnovativeResearch

SJUSJU

7

WP15Ground CNS

Spectrum 15.1 COM 15.2 NAV15.3 SUR 15.4

FCI – L band FCI - satellite

FCI – Airport surface Civil – Military interoperability

15.2.10 Terrestrial COM Infrastructure - SWIM

SESAR WP15

8

WP15.2.10:Terrestrial Com Infrastructure - SWIM

� Task 1 : PENS service (adaptation when needed), SWIM requirements.

� Task 2 : Security policy (incl. SWIM requirements)

� Task 3 : Follow technical validation (performances, multicast, VoIP, SWIM)

� Civil/Military coordination

� International coordination (via existing steering groups incl. civil/mil)

AFTN/CIDIN AMHS

AMHS/SWIM

PENSSWIM backbone

WP15.2.10Architecture (outputs)

(SESAR WP8-14)


EUROCONTROL AMHS SpecificationThe End

Single European Sky Regulations

EUROPEANCOMMISSION

Eurocontrol AMHS Stakeholder Consultation Workshop, 23.06.09

| 2Sven HalleEurocontrol AMHS Stakeholder Consultation Workshop, 23.06.09

� Single European SkyWhere did we start…I

SES started in 2004 with its 4 Regulations by laying down the foundations for

. Legal and institutional framework

» Single Sky Committee assists the Commission in adoptingthe enabling legislation through comitology with civ/militaryparticipation, EASA, ICAO and 3rd countries

» Industry Consultation Body enables all industrystakeholders and social partners to contribute to legislation

» Technical support from Eurocontrol in the rulemakingprocess through mandates


� Single European SkyWhere did we start…II. Separation of service provision from regulation

» Each Member State has established a National SupervisoryAuthority (NSA) to ensure effective regulation and foravoiding conflict of interests. NSAs are also exercising a safety oversight function

» Since 20 June 2007, air navigation service providers havebecome subject to certification by the NSAs (Regulation 2096/2005)

. Transparency of charges

» Regulation 1794/2006 on a common charging schemeensures full transparency in the establishement of airnavigation service charges


� Single European SkyWhere did we start…III. Harmonisation in licensing of controllers

» Adoption of Directive 2006/23/CE that will achieve a harmonised level of competence and an improved mobilityof workers (Important social dimension as there are i.e. 20.000 ATM controllers within the EU)

. Advances in the efficient use of airspace

» Common provisions for the flexible use (civil and military) of airspace in accordance with Regulation 2150/2005

» Harmonisation of airspace classification in the upperairspace in accordance with Regulation 730/2006


� Single European SkyWhere did we start…IV. Towards interoperable equipment

» An effective interoperability mechanism has beenestablished to adopt implementing rules (Regulations) and to develop Community specifications (Standards)

» So far 6 implementing rules & 4 Community specificationshave been adopted

» Indispensable framework for the efficient implementationof SESAR (Single European Sky ATM Research) and incorporated in the European ATM Masterplan


� Single European SkyInteroperability

. Objective and scope

» Interoperability means a set of functional, technical an operational properties required of the ATM systems in order to enable its safe, seamless and efficient operation

» Interoperability between the different systems , their constituents and associated procedures of the European ATM network

» Coordinated introduction of new agreed and validated concepts of operations or technology (SESAR)


� Single European SkyInteroperability

. Legislative Tools

. Conformity Assessment

Community Specifications

Essential Requirements

Implementing Rules

SES Interoperability Regulation (552/2004)

Mandatory Layer to implement the ERs. Developed under Commission Mandates

• European standards for systems, or constituents, together with the relevant provisions, drawn up by European Standardisation bodies in cooperation with EUROCAE

• Specifications drawn up by Eurocontrol on matters of operational coordination between Air NavigationServiceProviders

• Recognized as Means of Compliance with the ER / IR

Binding


�

.Environment» Aviation’s share of EU greenhouse gas emissions (currently 3%) is predicted

to increase.» Network improvements could save up to 4.8 mio tons of CO² per year.Fragmentation» Significant additional costs for airspace users (€2 bn per year could be saved

by reducing fragmentation).Economics» Cost efficiency efforts are not sufficient» Liberalization of aviation market vs. Harmonization of ATM» Current European route network is an amalgamation of national routes that

makes intra-European flights 15% less efficient than domestic flights, resulting in additional costs of €1.4 bn per year .Safety

» Cannot be compromised and must be enhanced with increased traffic levels .Capacity» Delay still accumulate to €1.3 bn per year and further increase of traffic (250%

increase within the next 20 years, growth rate of new EU States exceeds 10%) with enlargement and Open Skies

Single European Skyand what are challenges in the future:


� Single European Sky 2nd packageWhat are our goals…

� put the emphasis on the right governance using the Community method as driving force of aviation regulation

� ensure the highest safety standards by implementing a comprehensive Total System Approach

� focus on a more efficient and performing but also still human centered air transport network including the pan-European perspective

� establish a sustainable European air transport system reducing the effects of aviation on the climate change


� Single European Sky


� Single European Sky 2nd package is based on 4 pillars

� PERFORMANCE

� SAFETY

� CAPACITY

� TECHNOLOGY


� PERFORMANCE

» Introduction of a performance-driven approach and framework(including independent performance review) on safety,environment, capacity and cost-efficiency, with the appropriate elements (incentives) to drive the change process

» Economic and performance regulation with specific targets at Community level:

• Performance Target Setting for the Network

• Translate EU targets into national/local targets

• Adopt local targets and ensure coherence between local/EU targets

» Involvement of all stakeholders, more effective civil/military cooperation and social dialogue , support to the Eurocontrolreform


� PERFORMANCE

» Acceleration of the creation and integration of Air Navigation Services in Functional Blocks of Airspace (FABs) towards dates politically committed by States (2012 implementation) and elimination of national obstacles

» Enable Air Navigation Service Providers to perform their services in a more business-oriented and transparent manner

» Network Management Function, improving management/ coordination of network functions and optimising the use of the network (including airport and en-route slot coordination)

» Better flight-efficiency to be achieved through improvement of the network performance and more efficient use of resources


� SAFETY

» Effective use of the Community approach

» Extension of EASA competence to airports, air navigation services and air traffic management

» Implementation of the Total (gate-to-gate) System Approach

» Strengthen the oversight of National Supervisory Authorities


� CAPACITY

» Action Plan for airport capacity, efficiency and safety in Europe

» Establishment of an Observatory (Nov 2008) to exchange and monitor data/information on capacity (capacity assessment, capacity planning, co-modality, inter-modality)

» Implementation of an integrated Capacity Management with an increased predictability (airport capacity management determines ATM capacity) and evolution to time based operation

» Airports must be seen as an integral part of the ATM network• Entry and Exit points of the network• Effective use of capacity depends on all elements of transport chain• ‘Green’ operations require real-time flow of information (e.g. SWIM)

between all stakeholders


� TECHNOLOGY

» SESAR Joint Undertaking (JU) established in 2007 based on EU Treaty Article 171 with Council Regulation (EC) No 219/2007

» SESAR JU will drive technological improvements (converge fragmented R&D efforts) in line with the ATM-Masterplan

» JU membership negotiations with industry and stakeholders» Completion of Definition phase and endorsement of the ATM-

Masterplan by the Transport Council in 2008» Close cooperation between SESAR and CLEAN SKY» Global interoperability (SESAR / NextGen)

�Adoption of implementation elements through SES legal framework after validation of improvements/performance targets within the frame of the ATM Masterplan


� TECHNOLOGYSESAR concept

» Key to the SESAR concept is the business trajectory principle in which the users of the airspace and controllers define together, through a collaborative process, the optimal flight path.


� TECHNOLOGYSESAR concept

» Taking full advantage of existing and newly developed technologies (such as in GALILEO) SESAR’s target concept relies on a number of new key features:

- the Network Operation Plan , a dynamic rolling plan for continuous operations that ensures a common view of the network situation.

- Full Integration of Airport operations as part of ATM and the planning process.

- Trajectory management , reducing the constraints of airspace organisation to a minimum.

- New aircraft separation modes allowing increased safety, capacity and efficiency.

- System wide information management (SWIM) securely connecting all the ATM stakeholders which will share the same data.

- Humans as the central decision makers: controllers and pilots will be assisted by new automated functions to ease their workload and enable complex decision making processes.


� TECHNOLOGYSESAR Future ATM Concept

The driver: Performance Based Approach

ATM intranet

The foundation: Trajectory Based Operations

Collaborative Decision Making

Network ManagementAirports as Integrated

Partners

Source: SESAR JU


� TECHNOLOGY

2013 2020Date of Initial

Operating Capability

2017 20252009

2

3

4

1

5

0

AT

M

Ser

vice

Lev

el

Implementation

Available for Operations

Rolling out current Best Practices(CDA, Flexible sectorisation, Continuous Climb Departure, Initial Data link, Automatic Flight Conformance Monitoring,

Basic Departure Management (DMAN), Ground Based Safety Nets, Use of Runway Occupancy Time (ROT) Reduction Techniques)

Implementation

R&D


Preparing Trajectory based operationsInteractive rolling NOP, Manual UDPP

AMAN/DMAN integration

ATSAW in flight and on surface, ATSA-ITP

Improved Low Visibility Procedures

Implementation

R&D


Implementing net-centric trajectory managementSWIM enabled NOP using RBT/SBTFull set of Complexity Management ToolsASPA S&M2D-PTC on Predefined RoutesAutomated Surface Movement Planning and RoutingAdjustment of Separation Based on Ground Wake Vortex detection

Implementation

R&D


Achieving advanced automation in a shared trajector y environmentDynamic TMAs and Flexible Military structuresDynamic ATFM using RBTManagement Revision of RBT using DatalinkFull set of Advanced Controller tools using RBT/SBTASEP-ITP2D-PTC on User Preferred Trajectories3D-PTC on Predefined Routes

Implementation

R&D


Extending operations with advanced separation modesDynamic Mobile Area, 3D-PTC User preferred trajectoriesASEP C&P, SVS in low visibility conditionsCompatibility between Airborne and Ground Safety nets

Implementation

R&D


Accommodating full 4D trajectory managementbased on user preferred trajectoriesDynamic Sector shapesASEP WV spacing, ASAS Self separation4D-PTC

IP1


� Implementation Package 1IP1 main characteristics…

�Essential as the baseline for SESAR deployment

�It must be all about improving the current system making it coherent through implementation of best practices, better coordination and the preparation for trajectory / time based operations


� Process of IP1 refinement

”IP 3 - 2”

Developments

Eurocontrol work programme, existing developments, R&D results

Filtering of OIs from D5 =

• Existing IR, or linked to SES (IR & CS) regulation

Or

• Mature/complete or confidence in initial deploymentwithin the timeframe

• Justifiable with clear criteria (i.e. endorsed business case, anticipated network benefits)

• No critical R&D needed (~end of V3, EOCVM)

IP 1 Deployment

Improve thecurrent system

Prepare fortrajectory /time

based operationsmap

ping

EC, SESAR JU, Eurocontrol started as JWG the refinement process

shifting

defining


� Additional IP1 refinement

IP 1 Deployment

Improve thecurrent system

Prepare fortrajectory /time

based operations

Time classification

Geographical classification

Stakeholder/Airspace Usersegmentation

further parameters…


�

Information Management

Network Management

Trajectory Management, Separation, Automation

Airports

Airports & Aerodrome ATC

SESAR WP links

Aircraft Systems

Aircraft Operations FOC

TMA/En-Route Operations

SWIM

CNS Systems & Infrastructure

Airspace and Network Management

Aeronautical Information


� IP1 CNS Systems & Infrastructure

The IP1 baseline builds on existing/mature elements and consistsof the following items:

1. Deployment of AMHS for ground-ground data communications

2. Deployment of VHF (8.33kHz) above FL195 for voice communication and VDL2/ATN for initial data link

3. Implement MLAT systems and deploy ADS-B ground stations to supportsurveillance applications

4. Implementation of GNSS applications (APV/LPV)

5. Creation of a European IP backbone network and start implementationof VoIP (Voice over IP) for ground-ground voice communication


� IP1AMHS CS. Single Sky Committee (Apr.07) requested Eurocontrol to develop

a CS on AMHS (ATS Message Handling System) to ensure interoperability and seamless operations of AMHS in EATMN

. The CS will augment existing standards and will include:» The Basic ATS Message Handling Service, with its functional

components;» The Extended ATS Message Handling Service, including

Safety and Security standards, and Directory services;» The interoperability aspects of communication gateways

within the transition phase» The tests and verifications of compliance with the AMHS

requirements.

. Eurocontrol is expected to deliver the CS for SSC advisoryprocedure in 2009 as en element of Implementation Package 1

EUROPEANCOMMISSION

THANK YOU !

http://ec.europa.eu/transport/air/index_en.htm



Speaker Eivan CERASI



2

Interoperability RegulationEC Regulation 552/2004

Community Specifications(Voluntary Standards)


Implementing Rules

♦ Seamless operation

♦ Safety

♦ Civil-military coordination

♦ Support of new concepts of operation

♦ Environmental constraints

♦ Principles governing the logical architecture

♦ Principles governing the construction of systems

3

Interoperability Regulation

Such specifications may be:

• ENs drawn up by ESOs(CEN/CENELEC/ETSI) in cooperation with Eurocae on technical issues, or

• Specifications drawn up by EUROCONTROL on matters of operational coordination

Compliance with the ER and/or IR is presumed when meeting the CS

SES interoperability Regulation (552/2004)

Drafts developed by EUROCONTROL as EC Regulations

Community Specifications(CSs)

Voluntary Standards


(ERs)

Implementing Rules(IRs)

4


AMHS

Interoperability RegulationEUROCONTROL Examples and AMHS


VCS

IR

OLDI CSADEXP CS FMTP CS

EUROCONTROL Specifications

(some are not Community Specifications)

EUROCONTROL Specification on

AMHS to be recognised as EC


- Voluntary -

DLS

IR

COTR

IR

FMTP

IR

5


� Material of a voluntary nature, non binding

� Detailed technical/operational specifications

� Used as means of compliance with Essential

Requirements and Implementing Rules

� Can include references to ICAO SARPs, Technical

Manuals, EUROCAE docs

� Include traceability to regulatory requirements, in the

case of the AMHS Community Specification it will be

limited to the Essential Requirements

6

Specificity of AMHS

� No Implementing Rule on AMHS

� Therefore implementation of AMHS is not imposed by EC

Regulation

� AMHS is part of SESAR and ESSIP

� SESAR enabler CTE-C10 to be available for operations by 2011

� ESSIP Objective COM-05 (under revision)

� Value of EUROCONTROL Specifications

� “State-of-Art” AMHS specifications supported by a majority of

stakeholders after formal consultation procedure

� Value of the EUROCONTROL AMHS Specifications recognized as CS

� When used (as a whole) it provides a presumption of conformity

with Essential Requirements of the SES interoperability regulation

7

EUROCONTROL Notice of Proposed Rule-Making (ENPRM) Mechanisms used for SES regulatory mandates

Initiation Phase

Drafting Phase

Formal Consultation

Review of Comments

•Consultation•Stakeholders Workshop •Full impact assessment

•Initial impact assessment•Regulatory Approach

•Stakeholders Workshop•Amendment of Draft Rule

ENPRM Mechanisms

Mandate

SSC Opinion

EC Approval/Publication

8

Lessons Learned

� EUROCONTROL AMHS Specifications have been difficult to prepare in the absence of an Implementing Rule

� Further clarity should be given by the Commission on the way a Community Specification should be applied in this context (e.g. partial or full application of the provisions)




EUROCONTROL AMHS Specification

Speaker Richard PAPIOR



2

EUROCONTROL AMHS SpecificationIntroduction

♦ What is the specification based on ?

♦ How the document developed

♦ The final structure

♦ What is the specification for ?


EUROCONTROL AMHS SpecificationWhat is it based on ?

4

EUROCONTROL AMHS

Specification

EUROCONTROL AMHS SpecificationWhat is it based on ?

ISO/IEC & ITU-T MHS Standards

ISO/IEC

ISPs

Doc 9705 Sub-Volume

IIIDoc 9880 Part IIB

ATSMHS

Doc 9705 Sub-Volume

VII (DIR)

Doc 9705 Sub-Volume

VIII (SEC)

Annex 10 SARPs

SES Environment

ICAO EUR Region

ICAO Global

International Standards

EUR Doc 020 EUR AMHS Manual

EUR Doc 021ATS Messaging

Management Manual

(Future EUR Documentation)

SES Regulations

5

EUROCONTROL AMHS SpecificationMajor Technical Inputs (1)

ICAO SARPs:

� Annex 10 Volume II� Annex 10 Volume III Part 1

Detailed technical provisions:

� Doc 9705 Third Edition (2002) Sub-Volume III / Doc 9880 Part IIB (AMHS)� Doc 9705 Third Edition (2002) Sub-Volume VII / Doc 9880 Part IVA (Directory)� Doc 9705 Third Edition (2002) Sub-Volume VIII (Security)

Guidance material:

� Doc 9739 Draft Second Edition

6

EUROCONTROL AMHS SpecificationMajor Technical Inputs (2)

Regional manuals:

� ICAO EUR Doc 020 – EUR AMHS Manual� ICAO EUR Doc 021 – ATS Messaging Management Manual� ICAO EUR AFS Security Guidelines

Others:

� ECG User Requirements Document� SPACE project final report� Studies on Directory and Security deployment architecture� Supplier’s Technical Documents


EUROCONTROL AMHS Specification How was it developed ?

8

Draft

Specification

Specification Approach Document

Initial Plan

Planning

EUROCONTROL AMHS SpecificationDevelopment timeline

EC mandate May 2007

Scope Questionnaire

73% prefer Alternative 2

J F M A DDN J F

2007 2008

M J J A S O N M A

Scoping Workshop 12/12/07

1. Enhanced Basic AMHS (e.g. TCP/IP)

2. Extended AMHS, Directory & Security (3 annexes)

3. Extended AMHS plus interconnection between AMHS and internet messaging networks (e.g. SMTP)

9

COMT-43 Brussels8-9/10/08

ENPRM consultation

SOR Draft 1.0

Review Group

6&7/11/08

Draft 0.6

Drafting Group 29/2/08

Draft 0.3

Drafting stage Informal consultation

Review Group

09/09/08

Draft 0.5

Drafting Group

02/04/08

Draft 0.4

Final Report

EUROCONTROL AMHS SpecificationDevelopment timeline

J F M A M J J A S O N DDN J F M A M J J A S

2008 2009

Revised Structure

Review Version

ENPRM Workshop 23/06/09

Drafts

COMT-42 Brussels

11-12/06/08

ICAO AMHS Workshop,

Paris5-6/06/08


EUROCONTROL AMHS Specification What is in it ?

11

EUROCONTROL AMHS SpecificationDocument Structure

Specification is organised as a Main Body and Annex es. Chapters in Main Body provide contextual guidance a nd point to the self-contained Annexes

� Chapter 1 - introductory material describing the pur pose and scope of the Specification

� Chapter 2 - describes the Basic level of interoperability for AMHS

� Chapter 3 - describes the Extended ATSMHS

� Chapter 4 - describes the use of Directory systems and procedures

� Chapter 5 - outlines possible future Security mechanisms based on ICAO provisions

12


� Chapter 6 - additional requirements relating to impl ementation options, testing, and validation

� Chapter 7 - some of the transition and coexistence i ssues

� Chapter 8 - traceability between the means of compl iance in the AMHS CS and Single European Sky essential requireme nts

� Chapter 9 - procedures for maintaining and updating the Specification

� Chapter 10 - Reference documents

13


� Annex A (normative) - detailed requirements for the Air Traffic Services (ATS) Message Handling functionality at th e level of the Basic ATSMHS.

� Annex B (normative) - detailed requirements for the ATS Message Handling functionality at the Extended ATSMHS level of service, requiring support of Functional Groups (FG) for:

� the Basic ATSMHS (Basic FG),

� use of file transfer body parts for binary data exc hange (FTBP FG),

� use of interpersonal messaging heading extensions ( IHE FG)

� use of Directory (DIR FG)

� Support of AMHS Security (SEC FG) is foreseen in th e future

� Annex C (normative) - detailed requirements for Dire ctory systems to support the DIR FG

� Annex D (informative ) - indicative security provisions to support the SEC FG


EUROCONTROL AMHS SpecificationWhat is it for ?

15

EUROCONTROL AMHS Specification Transition to SESAR

Today’s infrastructure

SESAR / CNS infrastructure

Evolution

“Communication systems shall be designed, built, maintained and operated using the appropriate and validated procedures, in such a way as to achieve the required performances ... for a specific application, in particular in terms of communication processing time, integrity, availability and continuity of function”

New concepts of operationSESAR / SWIM enablers

AMHS CS

SES Regulations

Presumption of compliance


EUROCONTROL AMHS SpecificationThe End


EUROCONTROL AMHS SpecificationWorkshop

Speaker Bolek GASZTYCH



2

EUROCONTROL AMHS SpecificationFormal Consultation

� The draft EUROCONTROL AMHS Specification has

been subject to a Formal Consultation period of 3

months (22nd January to 22nd April)

� Consulted Organisations� National Civil and Military Authorities

� Air Navigation Service Providers

� International Organisations

� Airspace Users Organisations

� Military Airspace Users

� Industrial and Social Representatives

� EUROCONTROL Bodies

3

EUROCONTROL AMHS SpecificationFormal Consultation Outcome

� 35 Responses received from: � National Civil and Military Authorities

� Air Navigation Service Providers

� International Organisations

� Military Airspace Users

� Industrial and Social Representatives

� EUROCONTROL Bodies

� The majority of responses were in support of the

draft specification document

4

EUROCONTROL AMHS SpecificationWho responded ?

ANSP48.6%

Civil Authority31.4%

Military8.6%

Industry8.6%

Professional organisation

2.8%

ENPRM-09/001 Draft EUROCONTROL Specification on AMHS Responses received per Stakeholder Category

5

EUROCONTROL AMHS SpecificationThe responses were…

Not acceptable under any

circumstances11.4%

Not acceptable but would be

acceptable with amendments

20.0%

Acceptable but would be improved with amendments

14.3%

Acceptable without amendment

54.3%

68.6% Acceptable

ENPRM-09/001 Draft EUROCONTROL Specification on AMHS Responses received per Response Category

6

EUROCONTROL AMHS SpecificationGeneral Responses Overview

100.0%11.4%20.0%14.3%54.3%Percentage (%)

100%3547519

Total responses received by category

2.8%10001

Other (professional organisation)

8.6%31200Industry

8.6%31002Military

31.4%111118CAA

48.6%171448Service Providers (ANSPs)

%Total by Stakeholder category

Not acceptable under any circumstances

Not acceptable but would be acceptable with amendments

Acceptable but would be improved with amendments

Acceptable without amendment

7

EUROCONTROL AMHS SpecificationTotal number of comments

� In total, 98 comment sheets received

� Some with significant overlap

� Many comments are requests for clarification

8

EUROCONTROL AMHS SpecificationGeneral Responses by Category (1)

� 4 Responses with “Not acceptable under any circumstances” –

with 41 comment sheets

� All from the same Member State (ANSP, NSA, Military, Industry). Main

objection relates to inclusion of Extended ATSMHS on the grounds of

operational maturity, test specifications, ability to replace National

specifications, lack of Concept of Operations, definition of Constituents,

details of mapping to Essential Requirements.

� Comment sheet requests removal Annexes B, C and D.

Not Agreed. � Majority of responses in favour of adding value to Basic ATSMHS.

� The draft Specification is a candidate for adoption as a CS – this is a

voluntary means of compliance, not an IR.

9

EUROCONTROL AMHS SpecificationGeneral Responses by Category (2)

� 7 Responses with “Not acceptable, but would be acceptable with Amendments” – with 36 comment sheets

� Main amendment requests relate to removal of duplicated material, clarification of differences with ICAO documents, removal of advisory and background material, removal of informative security Annex.

� Mostly Agreed

� …but informative security Annex should remain, with clarified status, for alignment with ICAO technical manual.

� Some concern over support for existing and planned deployments

� Will be clarified

� …that there is no impact on existing deployments. Annex A could be used, together with additional materials, to justify EC Declaration.

10

EUROCONTROL AMHS SpecificationProposed Specification Updates

� Search and remove material duplicated in other standards

� Replace AFTN/AMHS Gateway PRL Tables with cross-references

to Doc 9880 Part IIB (reduction of ~30 pages)

� Update document references

� ICAO EUR Doc 020 now refers to Doc 9880 instead of Doc 9705

� Remove reference to Extended ATSMHS test cases

� Additional text on:

� Use (or not) of Directory to determine recipient capabilities

� Support for Directory Names in O/R addresses


EUROCONTROL AMHS SpecificationEnd


AMHS EUROCONTROL Specification

Results of ENPRM Consultation - Consolidated Comment s

Speaker Tony Kerr


Date and venue 23 June 2009, Brussels

2

Summary of Responses

Objective: To present consolidation of major themes occurring in ENPRM 09/001 responses

� Major Issues (Non-technical)

� Regulatory (SES)

� Technical Issues

� Other Issues

All received comments, and more detail on proposed responses, are listed in SOR document

Consolidated comment topics are given in Black head ings

EUROCONTROL Response and proposed Actions appear in Brown text

3


Major Issues (Non-technical)� Maturity of ATSMHS Extended Service

� Size of Specification vs. Value Added

� Definition of transitional steps

� Inclusion of AMHS Security requirements

4

Maturity of ATSMHS Extended Service

“The scope covers elements of the ATSMHS Extended Service that have not been fully defined and are not mature. Inclusion of the ATSMHS Extended Service at this moment is not feasible and should be removedfrom the EUROCONTROL Specification.”

No change proposed. Security is already advisory only. Standards for the Extended ATSMHS are technically mature and validated, published by ICAO in 2002, based on long-established standards extensively validated in other domains.

AMHS is part of SESAR Implementation Package 1 (IP1). It must support new concepts of operation and is part of the transition to SWIM.

The Basic level of service adds little if any value to the existing AFTN and does not readily support new concepts of operation (e.g. binary content).

The draft EUROCONTROL Specification:

� Offers a voluntary means of compliance with SES Regulations,

� Provides a means to kick-start the migration effort from the Basic to the Extended level of service by defining some initial requirements that can be built upon using the results of ongoing implementation projects.

Document maintenance procedures ensure that less mature elements can be further elaborated as experience is gained and application performance requirements become clearer.

5

SESAR System Enabler(extract from e-ATM Master Plan)

Migration to AMHS (ATS Message Handling System) from AFTN is carried out to improve regional, global and civil/military global interoperability.The ATS Message Handling System (AMHS) is a proven messaging application based on the X.400 worldwide standards for messaging and on the Internet Protocol (IP) for transmission and routing. In the EUR ICAO Region it was decided to implement the AMHS on top of a TCP/IP network infrastructure. The deployment of AMHS is an ongoing work, which was started with the implementation of the "Basic Service" since 2006. An important development will be the introduction o f the "Extended Service" which is described in the ICAO documentation.The realisation needs technical and theoretical support especially regarding operational procedures and resulting adaptations of the AMHS COTS software.

Related Operational Improvement Steps

IndustrialisationDeployment

6

Size of Specification vs. Value Added

What benefit does the Specification add over the existing documentation to a EUR State implementing an AMHS system? It increases the overheads of maintaining the documentation.Advisory and background material should be removed, since this is a specification, not a guidance or training document.

The draft EUROCONTROL Specification adds value in a number of areas:

� Basic ATSMHS - requirements are specified for safety and performance, management and conformity assessment for the various elements of the AMHS.

� Extended ATSMHS - additional requirements are specified for the detailed profile, directory architecture and functionality and conformity assessment, as well as guidance on deployment scenarios, etc.

It clearly distinguishes requirements, recommendations and explanatory material.

Just including a list of cross-references would make the document unreadable.

Some of the conformity assessment material can be replaced with cross-references, significantly reducing the size of Annexes A and B.

Any unnecessary duplication of requirements will be removed.

7

Size of Specification vs. Value Added

0

10

20

30

40

50

60

70

Mainbody

Annex A Annex B Annex C Annex D Appendix1

Appendix2

Conformity assessment

Requirements & Notes

Explanatory

Document control

Total 226 pages,

176 plus Appendices

Can reduce by ~30 pages by replacing GWY PICS with x-ref

► 146 pages plus Appendices

► 30 pages requirements / notes

Num

ber

of p

ages

Introduction

Basic AMHS

Extended AMHS

Use of Directory

AMHS Security Requirements

Additional AMHS Requirements

Transition / Coexistence issues

Traceability to RegulatoryProvisions

Document updatre procedures

List of references

Document control

Document control14%

Explanatory34%

Requirements & Notes13%

Conformity assessment

39%

Main Body analysis

8

Definition of transitional steps

“Step-wise approach to compliance should be defined. Ensure that Annexes can be incrementally put into operation.”ICAO manual allows indefinite support of Basic service “as long as required”.

“Initial” AMHS interoperability target should include only Basic service, possibly with DIR, definitely excluding SEC. A series of interim targets should be defined, providing a more stepwise transition and a more stable, less ambitious target.

One response - AMHS Basic service level implemented only as an interim solution on the transition path to SESAR information management (SWIM) services.

ICAO Doc 9880: “It is intended that eventually the Extended level of service will be supported by all ATSMHS users, so that the BasicATSMHS will not be required anymore.”

In the context of SESAR the value of the Basic level of service may be questioned, especially the lack of support for binary data transfer.

When recognised as a CS, the specification will be a voluntary means of compliance to the SES essential requirements. It is a tool to aid conformity assessment.

Detailed planning of transition steps is out of scope.

9

Inclusion of AMHS Security provisions (1/5)

“Security requirements are not yet mature, or are only mentioned in draft ICAO documents and should not be included in the CS.”

Regulation (EC) No 2096/2005 (Common Requirements): An ANSP must "ensure the security of operational data it receives or produces or otherwise employs…”

A system-wide approach to information security must be taken, depending upon the results of an end-to-end threat analysis. Security must obviously be a consideration for the AFS, including for AMHS – measures could be taken at application level and/or messaging level and/or network level.

Secure messaging is one possible element of an overall information security policy, and is a key element of the Extended ATSMHS in ICAO Doc 9880 Part IIB.

Technically validated security mechanisms for the ATN, including the recommended cryptographic algorithms, PKI and digital signature scheme, are defined in ICAO Doc 9705 Sub-Volume VIII (2002).

No application threat analysis so far justifies use of AMHS security mechanisms.

Clarification: Distinguish between (a) messaging protocols that can carry security elements and (b) security mechanisms.

10

“SEC”

SEC functional group of the Extended ATSMHS

SEC functional group in the referenced MHS standardised profiles

Secure messaging using the message token

Recommended in Annex B for MTA, UA and MS components implementing the Extended ATSMHS

cryptographic algorithms, PKI

Informative in Annex D

What is meant by “Security Support”?

Transparent relay of security-related elements of service for forward compatibility

System Enabler for secure messaging in the future

ICAO Doc 9880 Pt IIB

ICAO Doc 9705 SV8

11


Impact assessmentThe justification and impact of AMHS security requirements must be assessed before any inclusion in the CS. AMHS Security requirements must remain “Optional” and not “Recommended” as currently worded, until there is a European agreement to implement AMHS Security, based on an appropriate impact study and cost analysis.

Security performance requirements are an integral part of the SESAR Validation & Engineering Process.

Cost-benefit analysis would be considered as part of the impact analysis of an implementing rule, and/or as part of an ANSP’s system procurement.

The CS will not mandate usage of security mechanisms.

It is generally much more difficult to “bolt on” security at a later stage than to integrate it into the system design.

Recommendations are not requirements; i.e. they are already “Optional”.

12


Product support

“The proposed AMHS security requirements are not currently supported by AMHS systems deployed or being implemented.”

For the Basic level of service, there are only basic security requirements for access control (Annex A, §A.2.1.8.5).

For the Extended level of service, security-related provisions in Annex B (transparent relay) are not required for implementation, but are recommended for forward compatibility. There are no requirements for the security mechanism; cryptographic Security functionality is restricted to an informative annex

Digital signing of message content is commonplace in some other domains, and does not represent a great technological leap forward.

PKI products and services are widely available.

13


Uniform implementationAre ANSPs who implemented AMHS systems before the release of the CS required to implement the SEC function? If they do not, then how they can be interconnected with those who have implemented? If done by bilateral agreements, the non-SEC capable AMHS systems could be vulnerable points of the AMHS community.

There are no requirements to implement the SEC functional group of AMHS.

Conformance to the Extended level of service can be achieved without the SEC functional group of the Extended ATSMHS (§3.3.6).

There should be no problem interconnecting a SEC and a non-SEC system:

� If a SEC system sends a secure message to a non-SEC system, it is processed like a regular non-SEC message – the (‘non-critical’) message token is ignored. Confirmation could be requested at application level.

� SEC systems are required to be able to accept unsigned messages (without a message token) from non-SEC systems. The security status would be flagged to the user and treated at application level.

14


Status of advisory materialThe sections on security are “not as advanced as other elements of the Extended ATSMHS” and should be removed, perhaps to another document, to separate specifications from advisory material pertaining to immature requirements.Use of "shall" in Annex D could mislead, as not in line with conventions (§1.7.3).

In response to previous consultation, AMHS security features (message origin authentication, content integrity assurance and supporting mechanisms) are included with “informative” status only, as a guideline for future deployments.

Conclusion on AMHS Security Provisions :

� No change to the current scope is proposed.

� To be clarified that “shall’ statements in Annex D only apply to systems claiming SEC conformance. If not, the whole Annex D is not applicable to the system.

� Threat analysis should be conducted per user application – but out of scope of AMHS specification.

15


Regulatory (SES)� Status of the Specification vs. System Specificatio n

� AMHS Constituents

� Testing and Conformity Assessment

� Timescales not Defined

� Granularity of SES traceability

16

Status of the Specification

Is the CS usable as a System Specification?Can it replace a National Specification?Is it sufficient for obtaining EC Declaration of Conformity or Suitability for Use (of Constituents)?

A CS specifies a means of compliance to SES essential requirements and/or implementing rules for interoperability (Article 4 of Regulation 552/2004).

Systems / procedures or constituents that meet the relevant CS requirements have presumption of compliance with the essential requirements and/or the implementing rules for interoperability.

There is no interoperability implementing rule to refine the essential requirements in the area of ground-ground message handling systems.

There is no requirement in the SES Regulations that a CS should be able to replace a national specification.

CS compliance can be a key requirement in a system procurement, but is generally not sufficient to specify the functionality not related to interoperability.

The EC Declaration of Conformity will refer to Community Specification(s) followed. (ANSPs may identify Constituents as part of an ATM System).

Paragraph 1.4.5 (“not intended to be a complete system specification sufficient for procurement purposes”) will be clarified.

17

AMHS Constituents

AMHS belongs to “communications systems and procedures for ground-to-ground […] communications” (EATMN Systems in Reg (EC) No 552/2004 Annex I)

CS should give ANSPs and manufacturers detailed requirements to “design, build, maintain and operate” the systems and their constituents for implementing “Basic ATSMHS” or “Extended ATSMHS”.

Constituents should be specified e.g. ATS Message Server, User Agent, AFTN/AMHS Gateway, Access Unit, and if necessary sub-constituents, which are absolutely needed for Basic ATSMHS, or to provide additionally the Extended ATSMHS.

It is a function of an IR to determine the constituents (Reg 552/2004 Article 3(3)(c)). ANSPs can also request an EC Declaration of conformity or suitability for use for IOP constituents not covered by IR/CS . The Technical File accompanying the EC Declaration of verification will contain the list of constituents.

The draft EUROCONTROL Specification does distinguish between the main candidateconstituents of the AMHS; e.g:

ATS Message Server

A.2.2 (Basic)

B.2.2 (Extended)

ATS Message User Agent

A.2.3 (Basic)

B.2.3 (Extended)

18

Testing and Conformity Assessment

“No test specification is currently available to ensure the correct implementation of the Extended ATSMHS”

SES implementing rules describe specific conformity assessment procedures. A CS, as a voluntary standard, cannot prescribe the execution of specific tests or the use of a specific test tool.

The specific test cases for the Basic ATSMHS in ICAO EUR Doc 020 are not prescribed for SES compliance. They offer a means of assessing the conformity to the Basic level of service, but other tests are possible.

It is feasible to define test cases for the Extended ATSMHS.

EC Declaration of conformity or suitability for use will describe procedures followed. Records of tests and examinations performed constitute part of the Technical File accompanying the ANSP’s EC declaration of verification.

The Specification requires (§A.3.2) that “tests shall be conducted within a common framework consistent with the procedures in the ICAO EUR AMHS Manual”.

Reference to “Extended ATSMHS Conformance Tests” doc will be removed.

19

Timescales not Defined

Dates are not specified for compliance with the EUROCONTROL Specification and possible transition measures.

Reasonable schedule required for applicability dates for step-wise compliance, taking into account areas where further enabling work is required.

Implementation timescales are outside the scope of a EUROCONTROLSpecification, which is limited to technical interoperability measures, and is a voluntary means of compliance.

Regulation (EC) No 552/2004, Article 3 (3e):Implementing rules for interoperability shall in particular:(e) specify the conditions of implementation including, where appropriate, the date by which all relevant stakeholders are required to comply with them.

20

Granularity of SES Traceability

Appendix 1 of the draft Specification does not give adequate traceability to the essential requirements (ERs) of Reg 552/2004. Separate matrices for Basic ATSMHS and Extended ATSMHS could be created, such that

• ER “keywords” extracted - e.g. from ER 1 (seamless operation) keywords are: designed, built, maintained, operated, information sharing);

• Evidence provided to every ER and extracted keywords at the constituent level and system level, and if necessary, procedure level;

• referenced documents contain chapter and paragraph details.

No change proposed. The ERs in Regulation 552/2004 are extremely generic and high level -it is difficult to trace meaningfully at a greater level of granularity. Normally, a CS would trace requirements to an associated IR.

There are no known precedents for splitting ERs based on keywords as suggested. E.g. ER4.1: “Communication systems shall be designed built, maintained and operated using the appropriate and validated procedures, in such as way as to achieve the required performance … for a specific application, in particular in terms of communication processing time, integrity, availability and continuity of function.” => risk of combinatorial explosion!

AMHS is an infrastructure component - required performance for a specific application can only be evaluated in the context of that application.

21

Granularity of conformity requirements (continued)

Differentiation between “Basic ATSMHS” and the “Extended ATSMHS” is possible due to the format of the requirement tags.

Example requirement tag: [AMHS-AMU-Axx]

Component level:“AMU” = ATS Message User Agent

Basic vs. Extended:“A” = Annex A (Basic service)“B” = Annex B (Extended service)

Then Appendix 1 allows association with each ER at the Service and Component levels.

22


Technical Issues

� Support for ATSMHS subsets

� AMHS user architecture

� Network protocols

� Interface Requirements

23

Support for ATSMHS subsets

“It is nowhere specified how the Directory can be used to determine the ATSMHS functional subsets which may be implemented by different systems.”

“It should be clarified at what stage of implementation an ANSP can claim Extended AMHS capability, i.e. which of the listed Extended features and functions are needed.”

Various approaches are possible, e.g:

a) Recipient capabilities “known” in advance by bilateral agreement. Direct “host” (application) AMHS users would send only to agreed pre-configured addresses, with compatible capability level.

b) The existing ICAO Directory schema can be used to determine user capabilities :

IHE supported – if the ‘atn-ipm-heading-extensions’ attribute is TRUE

FTBP supported – if the ‘exclusively-acceptable-eits’ attribute includes the file transfer value ‘{joint-iso-itu-t(2) mhs(6) ipms(1) eit(12) file-transfer(0)}’

SEC supported – technically, a sending UA does not need to know this; a non-SEC recipient ignores the message security features (they are marked ‘non-critical’). Operationally, this could be achieved at application level, requiring a signed reply in response to a signed message.

The draft Specification simplifies the subsetting problem by reducing the options to “Configuration IX” - {Basic + IHE + DIR + FTBP}.

Therefore, any conformant system recipient with ‘atn-ipm-heading-extensions’ set to TRUE will support IHE and FTBP.

24

AMHS user architecture

The “AMHS Functional Architecture” could imply that all national end systems will be ATS Message User Agents. A number of States have "no plans" to deploy UAs.

The usage of ATS Message User Agent is not limited to human users and can also be included in computer applications interacting with the ATSMHS.

The architecture which is deployed by some States includes the use of an “AMHS terminal server" providing centralised UA/MS functionality, including AMHS P3 protocol and P2 message formats.

The Specification will be clarified to illustrate, amongst other possibilities:

a) Deployments which do not include distinct ATS Message User Agents;

b) Terminal Server approach;

c) UAs may be connected using other networks instead of or additionally to the national network;

d) Direct “host” users i.e. “computer applications running on ATN end systems and interacting with the ATSMHS by means of APIs.”

2525

AFTN/AMHS Gateway

DSA DSA

ATS Message Server

ATS Message Server

UA


UA

AFTN terminal

National Network

National Network

European AMHS over TCP/IP

ATN Directory Service

AFTN terminal

AFTN/AMHS Gateway

Direct AMHS users can sign messages and check signatures from peer direct AMHS usersAFTN/AMHS Gateway can check signatures from direct AMHS users


DUA

DUA

DUA

DUA

DUA

DUA

CA CA

Public Key Infrastructure

“Initial” Interoperability Target ???

Clarify to allow for, amongst other possibilities:

a) Deployments which do not include distinct ATS Message User Agents;

b) Terminal Server approach;

c) UAs may be connected using other networks instead of or additionally to the national network;

d) No security function in initial UA deployment steps.

Figure 3 of draft EUROCONTROL Specification on AMHS

26

Network protocols

The Specification (§2.3.1) explains why network security is not addressed. It is essential that a baseline of Security protocols be specified in the CS as important impacts on system interoperability capabilities are anticipated. Reference should be made to appropriate PENS Security requirements.

Regulation (EC) 633/2007 (FMTP) lays down requirements for the use of IP version 6, but IPv6 is not promoted in this EUROCONTROL Specification.

Optional / mandatory network security requirements must be described somewhere, in the context of an overall security strategy, but are out of scope for the EUROCONTROL Specification on AMHS.

ICAO Doc 9880 Part IIB allows an ATS Message Server to use the transport service provided by the ATN/OSI and/or the ATN/IPS, and refers to Doc 9896 for the transport service provided by the Internet Protocol Suite. Doc 9896 specifies use of IPv6 by IPS hosts, RFC 2126 for TCP/IPv6 interface, or RFC 1006 for TCP/IPv4 interface combined with IPv4/IPv6 protocol translation device(s).

References to specific IPS protocol versions should be removed, as this is not within the scope of an AMHS specification. The specification should refer to the Transport Service Interface and remain neutral on IPv4 / IPv6.A reference to ICAO Doc 9896 can be added.

27

Interface Requirements

Use of the specific term “API” as a generic term to describe various aspects related to system interfaces can lead to confusion and misunderstanding.

The use of APIs is not a precondition to interoperability and does not necessarily support interoperability of AMHS component implementations.

The preferred means to ensure interoperability are the implementation of well standardised system interfaces and the execution of conformance and interoperability tests. Those standardised interfaces are available for message submission, transfer, and delivery as well as for systems management purposes.

Agreed in general. Well-defined interfaces are essential for the construction of modular systems (SES essential requirement #7).

The term “interoperability” should be used as defined in the SES framework Regulation 549/2004, not just technical interworking between components

The text will be clarified. Some of the statements in §A.2.1.2 can be removed. Others are important but the implication could be more clearly described. (E.g. in [AMHS-GEN-02] the reference to Doc 9880 §3.2.2.2.3is only relevant to an AMHS Message Server).

28


Other Issues� Differences with respect to ICAO documents

� Non-testable requirements

� Lack of Concepts of Operation for DIR and SEC

� Message server topology

� Addressing Scheme

� Use of Directory Names

� System Management Requirements

� Message Splitting Requirements

� Profile Requirements Lists

� Minor Technical Errors, Editorial Corrections and U pdates

29

Differences with respect to ICAO documents

“It is not clear if there are any specific differences between the detailed specifications in the draft EUROCONTROL Specification and the ICAO source documents. Any such differences should be clearly indicated in the EUROCONTROL Specification.”

Agreed. It was indeed the intention to identify any divergences from other standards and documents. In some cases, however, the draft Specification elaborates on general requirements in the ICAO documents, rather than diverging from them.

Action: The draft Specification will be reviewed for any divergence from ICAO requirements that have not been highlighted.

30

Non-testable requirements

Some requirements (notably safety and performance related) are difficult to verify, and are subject to interpretation when assessing compliance.

Many of these requirements are in testing category “Evaluate” (Appendix 1, §A1.3) noting that "The results [of the tests or demonstrations] are evaluated by the test scrutinisers to assess the degree to which the requirement has been met".

This is far too subjective for mandatory (“shall”) requirements. Such “Evaluate” requirements should be consistently worded as (non mandatory) recommendations, using "should" statements.

Since not all requirements can be tested definitively by executing test cases between implementations, testing categories “Demonstrate,” “Evaluate” and “Audit” are defined.

Requirements in “Evaluate” test category can be “shall” statements. It is the responsibility of the approval authorities to ensure that such evaluation has been performed.

31

Lack of Concepts of Operation for DIR and SEC

“The Extended Service specification is not mature enough for implementation, as parts of the detailed specification are not finalised and the concept of operations is not agreed.”

A Directory concept of operation would describe, inter alia: How information about a recipient's capability to support the IHE can be retrieved from the Directory; How to build the Directory Information Tree (DIT); The "common agreed [Directory] schema“; Support of different versions of information based on the AIRAC cycle (cf. current AMC procedures).

A Security concept of operation would describe, inter alia: How Public Keys are distributed among ANSPs; Who will be the suppliers and coordinators of the certificates; Procedures for handling tokensNo immediate impact on the Specification, which defines basic interoperability requirements. Further levels of specification, implementation agreements and operational procedures can follow, and would typically offer means of compliance to an interoperability IR.

Some parts of the Extended level of service, notably Directory and Security (PKI) services have potentially wide-ranging application not restricted to AMHS, and these services need extensive coordination and testing before being put into operation.

The required Directory schema is defined in Doc 9880 part IV. A Security CONOPS is available in ICAO ACP guidance material. A Security Policy would need to be agreed to address certificate handling issues. The responsibility for Member States to ensure that ANSPs implement an appropriate security policy would be defined in an IR.

32

Message server topology

“The implementation of the fully-meshed topology is not currently known, until there is total European implementation of PENS.”

Agreed that a fully meshed system is not necessarily optimal. This was a SPACE Recommendation. MTA topology can be independent of networklayer topology.

Action:

Delete paragraph 2.5.6: “It is envisaged … migrate to a fully meshed topology.” Reference could instead be made to ICAO EUR Doc 020 (EUR AMHS Manual) §3.3.4 “Recommended European AMHS topology” (new inedition 4).

33

Addressing Scheme

“The Common AMHS Addressing Scheme (CAAS) is recommended – but for ANSPs whose domestic network has a star topology, the XF addressing scheme is considered to be sufficient.”

“Paragraph 2.9.3 on XF addressing in received messages is ambiguous.”

Adoption of a single addressing scheme would aid seamless operation (SES essential requirement #1).

The recommended addressing scheme is consistent with ICAO Doc 9880: “an AMHS management domain should implement CAAS at the earliest opportunity.”

The XF addressing scheme is neither recommended nor prohibited. For interoperability, all components of Basic and Extended systems must support all address formats allowed in Doc 9880 Part IIB.

An AFTN/AMHS Gateway needs to be able to handle both schemes in received AMHS messages, in order to correctly convert to an AFTN message.

An AFTN/AMHS Gateway receiving an AFTN message must generate the correct O/R Addresses within the corresponding AMHS message. This requires that it can determine which address scheme to use (e.g. by accessing the Directory).

Paragraph 2.9.3 on XF addressing in received messages will be clarified.

34

Use of Directory Names

“In the Extended ATSMHS an O/R name is required to comprise both the MHS form (MF)-address (O/R address) and the directory name (distinguished name form) of the AMHS user, though it is not necessary to use both elements in all instances of communication.”

This implies the requirement for a global directory. It means that DIR is not optional (as stated in §3.3.4), but is required for any Extended ATSMHS.

ICAO Doc 9880 requires that a directory name is included as part of an O/R Name. Implies inclusion in message envelope and IPM heading. In practice, a UA, MTA, or Gateway receiving a message has no use for the received directory names, as it never needs to look anything up in the directory. Theoretically, support for IPM Use of Directory requires a UA to be able to display the directory component in a received O/R Name (ISP 12062-1 A.2.3).

For maximum interoperability, Extended AMHS systems should be allowed to omit the directory name from all O/R Names.

35

System Management Requirements

Recommendation [AMHS-MGT-A25]: “Communication between the management interface and the system should be through the use of an SNMPv3 compatible interface, enabling interoperability between manager and agent components” is considered misleading. SNMP is a recognised standard for high level monitoring of heterogeneous systems by maintenance staff. It is not a recommended solution for configuring and operationally managing a complex system such as an AMHS System.

Offering interoperability between an AMHS server and "management interface" is not a useful requirement, as the AMHS Server System will be delivered with proprietary Management Client Software.

SNMP MIBs have been developed for monitoring X.400 systems (e.g. RFC2249) and can be utilised by COTS monitoring products.

Agreed that proprietary management client is typically provided to configure and operationally manage proprietary software, and better to use than a generic SNMP manager.

The recommendation will be modified.

36

Message Splitting Requirements

The draft Specification (§A.2.5) refers to message splitting in conformance with regional procedures. The splitting procedure for long messages described in ICAO Annex 10, Vol. II, Attm. B should be referenced and is not considered as a regional procedure.

As noted in the draft Specification ([AMHS-GWY-A05] Note 1), the procedure slightly amends that in ICAO Doc 9880 to reflect European requirements.

Action: Analyse different message splitting procedures and modify the draft EUROCONTROL Specification if necessary. Any differences from ICAO standards or recommended practices will be highlighted.

37

Profile Requirements Lists

Table A-1 shows FTBP, IHE, SEC and DIR as Optional for an AFTN/AMHS Gateway supporting the Basic ATSMHS. These should be deleted.

Tables A-2 and A-3 should be taken out and replaced by a reference, as they appear redundant (with similar tables in ICAO Doc 9880).

FTBP, IHE, SEC and DIR functional groups are specified as Optional in ICAO Doc 9880 (Table 3-6) for ATS Message Server and ATS Message User Agent claiming Basic ATSMHS conformance. For an AFTN/AMHS Gateway, FTBP is not relevant, SEC could be applicable in the AMHS-to-AFTN direction but is not currently specified. IHE and DIR could optionally be supported.

Tables A-2 and A-3 add value by grouping conformity assessment materials in one place and providing a PICS for the AFTN/AMHS Gateway to complement the PICS in the ICAO EUR AMHS Manual. Given the size of these tables and the fact that Doc 9880 is the principal reference, it is agreed that the tables should be removed and replaced with cross-references to Doc 9880, with a requirement for suppliers to indicate the required and optional features that are supported by their products.

38

Minor Technical Errors, Editorial Corrections and U pdates

The draft EUROCONTROL Specification contains a few identified errors and inconsistencies which need to be corrected.

The Specification should be updated to refer to the most recent version of the referenced documents. Notably ICAO EUR Doc 020 (EUR AMHS Manual) has recently been updated and now refers to the detailed AMHS provisions in Doc 9880 instead of Doc 9705.

Various minor editorial and technical comments and suggestions for updates were received, and will be actioned – details in SOR Annex B.

Updates received from DCMAC regarding interoperability with Military Message Handling Systems will be integrated.

All references will be updated as necessary before the EUROCONTROL Specification is finalised as part of the final report to the European Commission on the AMHS mandate. [AMHS-BAS-A02] will be removed.

Thereafter, document maintenance procedures will apply.

39

Conclusion

The draft EUROCONTROL Specification will be updated and clarified in the areas indicated before delivery as part of the final report of the AMHS mandate.

� No change to the overall scope.

� Clarification of Interoperability Target diagram and description.

� Significant reduction in size.

� Additional guidance on use of directory, level of security support, use of Directory Name.

� Update to align with latest reference document editions, fix editorial and minor technical bugs.

Some issues might be addressed by an implementing rule (formal definition of constituents, deployment sequence, etc).

The SOR document will be updated after the workshop and will also be part of the final report.

Thank you for all comments received!



Speaker Jacky POUZET



2

EUROCONTROL AMHS Specification The Next Steps

♦ Finalise the EUROCONTROL Specification

♦ Deliver final report to the Commission:

♦ EUROCONTROL AMHS Specification

♦ Outcome of the consultation

♦ Evaluation of the comments (SoR)

♦ Proposals of Eurocontrol to support stakeholders implementation efforts

♦ Review by the Commission – Single Sky Committee decision

♦ “ AMHS Community Specification”

3

EUROCONTROL AMHS Specification The Next Steps - Timescale

Formal Consultation, 22 January – 22 April 2009

Formal Consultation Workshop, 23 June 2009

Produce Final Report and deliver to European Commission by September 2009



Date post:	01-Mar-2018
Category:	Documents
Upload:	trinhmien
View:	242 times
Download:	3 times