d38 cns/atm ground system requirements definition

MA-AFAS IN STRICT CONFIDENCE CONTRACT NO. 2000-00228 REPORT NO. 560/79699 ISSUE 2

i

D38 – CNS/ATM GROUND SYSTEM REQUIREMENTS DEFINITION CONTRACT N° : GRD1-2000-0228 PROJECT N° : GRD1-1999-10516 ACRONYM : MA-AFAS TITLE : THE MORE AUTONOMOUS - AIRCRAFT IN THE FUTURE AIR TRAFFIC MANAGEMENT SYSTEM AUTHOR: Alenia Marconi Systems (AMS) PROJECT CO-ORDINATOR : BAE SYSTEMS (AVIONICS) PRINCIPAL CONTRACTORS :

NLR (Netherlands) QINETIQ (UK) EUROCONTROL EXPERIMENTAL CENTRE (France) Airtel ATN Ltd. (Ireland) ETG (Germany)

ASSISTANT CONTRACTORS: Indra Sistemas (Spain) SCAA (Sweden) Galileo Avionica (Italy) SAAB Transpondertech (Sweden) DLR (Germany) Frequentis (Austria) NATS (UK) SOFREAVIA (France) Skysoft (Portugal) Thales ATM (France) Stasys Limited (UK) ENAV(Italy) AMS (Italy)

Report Number : 560/79699 Project Reference number : - MA-AFAS-WP3-D38-RE-AMS-ISSUE 2 Date of issue of this report : May 2003 Issue No. 2 PROJECT START DATE : 1/3/2000 DURATION : 36 months

Project funded by the European Community under the ‘Competitive and Sustainable Growth’ Programme (1998-2002)

COPYRIGHT NOTICE This document is proprietary to the MA-AFAS consortium members listed on the front page of this document. The document is supplied on the express understanding that it is to be treated as confidential and may not be used or disclosed to others in whole or in part for any purpose except as expressly authorized under the terms of CEC Contract number GRD1-2000-0228

MA-AFAS IN STRICT CONFIDENCE CONTRACT NO. 2000-00228 REPORT NO. ISSUE 2

ii

All enquiries related to this publication should be referred to:

αβχδ AVIONIC SYSTEMS

Airport Works, Rochester, Kent. ME1 2XX England

Tel. 01634 844400 Fax. 01634 816721

Airborne Systems Requirement Specification

for

More Autonomous – Aircraft in the Future

Air Traffic Management System

Data Deliverable D38 Document No. 560/79699

Issue 2

Contains 122 pages total

Comprising:

8 pages front matter

120 pages text and figures


iii

CONTRIBUTION BY

Company Name AMS (UK) A. Hogbin DLR B. Czerlitzki BAE SYSTEMS M. Pywell LFV A. L. Linge EEC D. Cloarec NATS D. Harriman

LIST OF EFFECTIVE PAGES AND CHANGE HISTORY

Section(s) Date Issue Reason for change and/or Change Note Number.

ALL 25/07/2001 Draft 1 Document Creation ALL 21/09/2001 Draft 2 Comments received by the partners ALL 31/10/2001 Draft 3 Further comments after Linkoping meeting, 25/09/2001 ALL 14/11/2001 Issue 1 Chapter 19 Chapter 22

13/09/2002 Issue 2 AOC platform modified New chapter 22 added “AOC Fleet simulator Requirements”

Chapter 2 4/10/2002 Issue 2 MEDUP platform modified Add figure option 3B

Chapter 5 4/10/2002 Issue 2 Removed Nup Platform Chapter 8 4/10/2002 Issue 2 IHTP Platform Modified Chapter 21 4/10/2002 Issue 2 Removed CPDLC Messages Version Originating Company Author Contract Task 1.0 AleniaMarconi Systems Carlo Iori

Vania Di Francesco Assistant WP 3.2

2.0 AleniaMarconi Systems Carlo Iori Vanja Gregorini

Assistant WP 3.2

2.1 AleniaMarconi Systems Carlo Iori Vanja Gregorini

Assistant WP 3.2


iv

DISTRIBUTION LIST This Document is distributed as below.

Additional copies held by unnamed recipients will not be updated. Paper Copies Name Address

MASTER Library BAE SYSTEMS, Rochester MA-AFAS Library Avionic Systems

Electronic Copies

Name Address

European Commission EC, Brussels MA-AFAS Consortium Members [email protected]

MA-AFAS Web Site


v

Table of Contents

1 INTRODUCTION ...........................................................................................................................11

1.1 PURPOSE AND SCOPE ..............................................................................................................................11 1.2 SYSTEM OVERVIEW ................................................................................................................................12 1.3 DOCUMENT OVERVIEW...........................................................................................................................13 1.4 REFERENCED DOCUMENT .......................................................................................................................14

2 MEDUP PLATFORM DESCRIPTION.....................................................................................................16

2.1 SYSTEM ARCHITECTURE .........................................................................................................................16 2.2 FUNCTIONS .............................................................................................................................................16 2.3 OVERALL MEDUP DATA FLOW ..............................................................................................................19

3 MEDUP IMPLEMENTATION OF MA-AFAS RELATED FUNCTIONS............................................20

3.1 ADS-B, AUTOMATIC DEPENDANT SURVEILLANCE BROADCAST ............................................................21 3.2 TIS-B, TRAFFIC INFORMATION SERVICE BROADCAST ............................................................................22 3.3 FIS-B, FLIGHT INFORMATION SERVICE...................................................................................................23 3.4 MEDUP GROUND STATION ATN SWITCH..............................................................................................25

4 MEDUP DATA DICTIONARY..................................................................................................................27

5 ESCAPE PLATFORM DESCRIPTION....................................................................................................30

5.1 ESCAPE ARCHITECTURE .......................................................................................................................30 5.2 FUNCTIONS .............................................................................................................................................31

6 ESCAPE IMPLEMENTATION OF MA-AFAS RELATED FUNCTIONS...........................................34

6.1 AIRSPACE DATA SERVER .........................................................................................................................35 6.2 AIRCRAFT SERVER ..................................................................................................................................36 6.3 TRAJECTORY PREDICTOR ........................................................................................................................36 6.4 INDEPENDENT AIR SURVEILLANCE .........................................................................................................37 6.5 TRACK DEVIATION MONITORING............................................................................................................38 6.6 FLIGHT MANAGER ..................................................................................................................................38 6.7 IUC INTERFACES.....................................................................................................................................39 6.8 ASAS DELEGATIONS ..............................................................................................................................39 6.9 ADS-B/TIS-B SUPPORT..........................................................................................................................40 6.10 DATALINK SERVICES...............................................................................................................................40 6.11 ATN STACK AND INFRASTRUCTURE........................................................................................................40

7 ESCAPE DATA DICTIONARY.................................................................................................................41

8 IN HOUSE TEST PLATFORM, PLATFORM DESCRIPTION ............................................................43

8.1 SYSTEM ARCHITECTURE .........................................................................................................................43 9 IHTP IMPLEMENTATION OF MA-AFAS RELATED FUNCTIONS.................................................46

9.1 ATC DATA LINK CONTROL ....................................................................................................................47 9.2 AOC DATA LINK CONTROL....................................................................................................................47 9.3 DELEGATED MANOEUVRES.....................................................................................................................49 9.4 CLEARANCE DELIVERY...........................................................................................................................49


vi

9.5 CPDLC...................................................................................................................................................50 9.6 TRAFFIC BROADCASTS............................................................................................................................50 9.7 FLIGHT INFORMATION SERVICES ............................................................................................................51 9.8 AIRLINE OPERATIONS CENTRE................................................................................................................51

10 DATA DICTIONARY .................................................................................................................................53

11 PRECISION APPROACH PLATFORM DESCRIPTION......................................................................55

11.1 INTRODUCTION .......................................................................................................................................55 11.2 SBAS......................................................................................................................................................55 11.3 GBAS .....................................................................................................................................................59 11.4 FUNCTIONS .............................................................................................................................................62

12 DLR SMGCS PLATFORM ON BRAUNSCHWEIG AIRPORT............................................................63

12.1 SYSTEM DESCRIPTION .............................................................................................................................63 12.2 SYSTEM ARCHITECTURE..........................................................................................................................64

13 SMGCS IMPLEMENTATION OF MA-AFAS RELATED FUNCTIONS ............................................65

13.1 REQUIREMENTS.......................................................................................................................................66 14 DATA DICTIONARY .................................................................................................................................68

15 AOC GROUND PLATFORM DESCRIPTION........................................................................................72

15.1 SYSTEM ARCHITECTURE .........................................................................................................................72 15.2 FUNCTIONS .............................................................................................................................................73 15.3 AOC GROUND PLATFORM CONTEXT......................................................................................................74

16 AOC GROUND PLATFORM IMPLEMENTATION OF MA-AFAS RELATED FUNCTIONS .......75

16.1 COMMUNICATIONS..................................................................................................................................75 16.2 AOC FLIGHT PLAN .................................................................................................................................78 16.3 AOC MAINTENANCE ..............................................................................................................................83 16.4 COLLABORATIVE DECISION MAKING......................................................................................................84 16.5 AOC ASSET MANAGEMENT....................................................................................................................87 16.6 AOC OPERATOR HMI.............................................................................................................................90

17 AOC GROUND PLATFORM DATA DICTIONARY .............................................................................93

18 AOC FLEET SIMULATOR REQUIREMENTS....................................................................................111

18.1 SYSTEM OVERVIEW........................................................................................................................111 18.2 FUNCTIONAL REQUIREMENTS.....................................................................................................112 18.3 NON-FUNCTIONAL REQUIREMENTS...........................................................................................117

19 AOC TRACEABILITY OF THE GROUND REQUIREMENTS.........................................................118


7

List of Figure Figure 1. MA-AFAS Validation Platform..............................................................................................11 Figure 2. - MEDUP system block diagram ............................................................................................16 Figure 3. MEDUP Data Flow.................................................................................................................19 Figure 4. MA_AFAS system block diagram In Rome Environment .....................................................20 Figure 5. ADS-B Context Diagram ........................................................................................................21 Figure 6. TIS-B Context Diagram ..........................................................................................................23 Figure 7. MA-AFAS point to point communications in the MEDUP environment...............................25 Figure 8. ESCAPE Architecture.............................................................................................................30 Figure 9 . ESCAPE Modules..................................................................................................................34 Figure 10. Airspace Server Component context diagram.......................................................................35 Figure 11 . Aircraft server component context diagram.........................................................................36 Figure 12 . Trajectory Predictor component context diagram................................................................36 Figure 13. Independent Air Surveillance context diagram.....................................................................37 Figure 14. Track Deviation Monitoring context diagram.......................................................................38 Figure 15. Flight Manager server context diagram ................................................................................38 Figure 16. IUC component context diagram ..........................................................................................39 Figure 17. IHTP system block diagram..................................................................................................43 Figure 18. Block diagram showing IHTP support of other test facilities ...............................................44 Figure 19. IHTP top level breakdown ....................................................................................................46 Figure 20. Footprints of Proposed Geo-stationary Satellites..................................................................56 Figure 21: EGNOS Service Area for performance from RNP0.3 to RNP0.02/40 (includes the Canary

Islands)...........................................................................................................................................56 Figure 22: EGNOS Service Area for performance from RNP20 to RNP0.3 .........................................57 Figure 23. EGNOS System Test Bed - Infrastructure Assets.................................................................58 Figure 28. AOC Ground Platform Block Diagram.................................................................................72 Figure 29. AOC Ground Platform context diagram ...............................................................................74 Figure 30. AOC Ground Platform Communications DFD.....................................................................78 Figure 31. AOC Ground Platform Flight Planning DFD .......................................................................82 Figure 32. AOC Ground Platform Collaborative Decision Making DFD..............................................86 Figure 33. AOC Ground Platform Operator HMI DFD .........................................................................92

List of tables

Table 1. ADS_Plot_4D content ..............................................................................................................27 Table 2. ADS_tracks content..................................................................................................................27 Table 3. ATIS_msgs content ..................................................................................................................28 Table 4. Ground_vector content .............................................................................................................28 Table 5. Mono_radar_tracks content ......................................................................................................28 Table 6. System_Tracks content.............................................................................................................29 Table 7. TIS-B_Service_Volume content ..............................................................................................29 Table 8. TIS-B tracks content.................................................................................................................29 Table 9. Aircraft Met Report ..................................................................................................................93 Table 10. AirGroundMessages ...............................................................................................................93 Table 11. AirportAuthoritiesInformationTBD .......................................................................................94 Table 12. AlertMessage..........................................................................................................................94 Table 13. AMDARMessage ...................................................................................................................94 Table 14. APUReport .............................................................................................................................95 Table 15. APUReportRequest ................................................................................................................95 Table 16. ChangeMessage......................................................................................................................96 Table 17. CompanyFlightPlan................................................................................................................96


8

Table 18 - Delay/Divert/Reroute Proposal .............................................................................................96 Table 19 - Delay/Divert/Reroute Response............................................................................................97 Table 20 - EngineStatusReportRequest ..................................................................................................97 Table 21. EngineReport..........................................................................................................................98 Table 22. FiledFlightPlan .......................................................................................................................98 Table 23. FlightInformationUpdate........................................................................................................99 Table 24. FlightPlan ...............................................................................................................................99 Table 25. FlightPlanInformation ............................................................................................................99 Table 26. Flight Progress Information..................................................................................................100 Table 27. FlightProgressReport............................................................................................................101 Table 28. FlightProgressRequest..........................................................................................................101 Table 29. FlightProgressResponse .......................................................................................................102 Table 30. FMSMeteo............................................................................................................................102 Table 31. Freetext Uplink/Downlink....................................................................................................102 Table 32. FuelInformation....................................................................................................................103 Table 33. GRIBInformation .................................................................................................................103 Table 34. IFTM Data............................................................................................................................103 Table 35. Loadsheet..............................................................................................................................104 Table 36. METAR................................................................................................................................104 Table 37. MeteoReportRequest ............................................................................................................105 Table 38. NOTAM ...............................................................................................................................105 Table 39. OOOIReports........................................................................................................................106 Table 40. PaxBaggage ..........................................................................................................................107 Table 41. MeteoSIGMETReport ..........................................................................................................107 Table 42. SlotAllocation.......................................................................................................................108 Table 43. SNAG Reports......................................................................................................................108 Table 44. MeteoTAFReport .................................................................................................................109 Table 45. TakeoffSettings ....................................................................................................................109 Table 46. Trajectory Data.....................................................................................................................109 Table 47. Trajectory Data Request .......................................................................................................109 Table 48. Ground requirements Traceability matrix ............................................................................122

List of acronyms ACC Area Control Centre ACL ATC Clearance ACM ATC Communication Management ADS Automatic Depended Surveillance ADS-B ADS Broadcast AFAS Aircraft in the Future Air Traffic Management System AGP AOC Ground Platform AIS Aeronautical Information Service AMAN Arrival Manager ANM ATFM Notification Message AO Airline Operator AOC Airline Operations Centre API Application Programming Interface APL AOC Flight Plan ARINC Aeronautical Radio Incorporated ARMI Aircraft Registration Mark Identification ASAS Airplane Separation Assurance System ASCS Airport Surface Control System ASD Air Traffic Situational Display ASE Application Service Element ASMGCS Advanced Surface Movement Guidance Control System


9

ASTERIX All-Purpose Structured Eurocontrol Surveillance Information Exchange ATC Air Traffic Control ATCC Air Traffic Control Centre ATFM Air Traffic Flow Management ATIS Air Traffic Information Service ATM Air Traffic Management ATN Aeronautical Telecommunication Network ATS Air Traffic Services ATSU Air Traffic Service Unit CAA Communication to Airport Authorities CDM Cooperative Decision Making CDTI Cockpit Display of Traffic Information CDR Conditional Routes CD&R Conflict Detection and Resolution CFMU Central Flow Management Unit CMU Communication Management Unit CNS Communication, Navigation and Surveillance CPDLC Controller Pilot Data Link Communications CTOT Calculated Time of take-Off DBMS Data Base Management System DFIS Datalink Flight Information Service DGNSS Differential GNSS DLIC Data Link Initiation Capability DLL Data Link Logon DMAN Departure Manager DOP Daily Operational Plan DOTIS Data Link Operational Terminal Information Service ECAC European Civil Aviation Conference EEC Eurocontrol Experimental Centre EOBT Estimated Off Block Time ETD Estimated Time of Departure FAS Final Approach Segment FDDI Fibre Distributed Data Interface FDP Flight Data Processor FFAS Free Flight Air Space FI Function Information FIS Flight Information Service FLIPCY Flight Plan Consistency FMS Flight Management System FPL Flight Plan FPG Flight Plan Generation FUA Flexible Use of Airspace GACS Generic ATN Communication Service GBAS Ground Based Augmentation System GIVE Grid Ionospheric Vertical Error GNSS Global Navigation Satellite System GP&C Global Positioning & Communication system HMI Human Machine Interface IAS Independent Air Surveillance IFPL Initial Flight Plan IFPS Initial Flight Plan Processing System IFTM In Flight Traffic Management LADD Local Area Data Distribution MA-AFAS More Autonomous Aircraft in the Future ATM System MAS Managed Air Space MSP Multi Sector Planning


10

NEAN North European ADS-B Network NRN Near range Radar Network NUP NEAN Upgrade Program NOTAM Notice To Air Man OOOI Out Off On In messages OTD D-OTIS Delivery Message RTA Required Time of Arrival SATCOM SATellite COMmunication SDF Sensor Data Fusion SIGMET Significant Meteorological Information SMGCS Surface Movement Guidance and Control System SPL System Flight Plan SSIC Structured SMGCS Information Content SSR Secondary Surveillance Radar STDMA Self Organizing Time Division Multiple Access TCP/IP Transport Control Protocol / Internet Protocol TDM Track Deviation Monitoring TIS-B Traffic Information Service Broadcast TP Trajectory Prediction UDRE User Differential Range Error VDL VHF Data Link WADD Wide Area Data Distribution


11

1 Introduction

1.1 Purpose and Scope This document is the deliverable D38 – CNS/ATM Ground System Requirements Definition – produced by the MA-AFAS Consortium within the scope of Work Package 3.2. The purpose of this document is to provide a detailed description of the ground platforms, which have the aim to validate the correct functioning of the avionics and crew interactions as well as the air-ground interoperability under real flight conditions. Platform to be described are: -MEDUP -ESCAPE -PRECISION APPROACH -SMGCS -AOC

MA-AFAS Validation Platforms

MEDUP

ESCAPE SMGCS

PREC. APP.

AOC

Figure 1. MA-AFAS Validation Platform

For each platform, there will be a description of the architecture and the main functionality of each subcomponent. The requirements supported by each specific function (selected on the base of the table presented in the D11) will be stated.


12

1.2 System Overview The More Autonomous Aircraft in the Future Air Traffic Management System (MA-AFAS) project is part of a larger European undertaking, that of reducing delays by improving means for aircraft movement control in the European airspace. It aims to transform European research results into practical operational Air Traffic Management (ATM) procedures with the potential to radically improve the European ATM scenario in the near term (from 2005 onwards). The capabilities that will be validated within this programme include the following:

Evaluation of airborne 4D trajectory generation and guidance, with the Air Traffic Control (ATC) via data link.

The use of a Global Navigation Satellite System (GNSS) with ground and space based augmentation for enhancing approach procedures under 4D flight path control.

The use of received Automatic Dependent Surveillance – Broadcast (ADS-B) data transmissions (using VDL Mode 4) which will

1. Provide an Enhanced Situation Awareness via a Cockpit Display of Traffic Information (CDTI)

2. Be a facilitator for Autonomous Operations by means of an Airborne Separation Assurance (ASAS) System.

Integration of an on-board map database and data linked Taxi instructions and clearances. Support for the Airline Operational Centres in respect of aircraft maintenance, and the control

and management of their aircraft fleet. Evaluation of the flight deck Human Machine Interface (HMI) improvements to support the

increased capabilities of the FMS with particular emphasis on the 4D trajectory generation and monitoring in a more autonomous environment.

Integration of the full Aeronautical Telecommunications Network (ATN) stack (using VDL mode 4 sub networks) in the airborne environment to support Airlines Operation Centre (AOC) and ATC communications using ODIAC defined standards.

The results of the trials will then be available to form the basis of a Minimum Operational Performance Standard to be developed by a body such as EUROCAE.


13

1.3 Document Overview The present document is structured as follows: Chapter 1: The present chapter, containing a brief introduction to the document, together with the sketch of its structure and the list of the referenced documents. Chapter 2: It contains the description of the system architecture of the MEDUP platform. Chapter 3: In this chapter there is a description of the functions related to MA-AFAS that will be implemented into MEDUP. Chapter 4: This chapter contains the description of all the messages exchanged within MEDUP. Chapter 5: . It contains the description of the system architecture of the ESCAPE platform. Chapter 6: In this chapter there is a description of the functions related to MA-AFAS that will be implemented into ESCAPE. Chapter 7: This chapter contains the description of all the messages exchanged within ESCAPE. Chapter 8: It contains the description of the system architecture of the IHTP platform. Chapter 9: In this chapter there is a description of the functions related to MA-AFAS that will be implemented into IHTP. Chapter 10: This chapter contains the description of all the messages exchanged within IHTP. Chapter 11: It contains the description of the system architecture of the Precision Approach platform. Chapter 12: It contains the description of the system architecture of the SMGCS platform. Chapter 13: In this chapter there is a description of the functions related to MA-AFAS that will be implemented into SMGCS. Chapter 14: This chapter contains the description of all the messages exchanged within SMGCS. Chapter 15: It contains the description of the system architecture of the AOC ground platform. Chapter 16: In this chapter there is a description of the functions related to MA-AFAS that will be implemented into AOC ground platform. Chapter 17: This chapter contains the description of all the messages exchanged within AOC ground platform. Chapter 18: This chapter contains the description of the AOC Fleet Simulator Chapter 19: In this section there will be the traceability matrix between the requirements in the D11 and the ones in the D38.


14

1.4 Referenced Document

1.4.1 Project Documents Item Title Date

1 MA-AFAS-WP1.2.1-D11-RE-AMS-DRAFT5 31/05/2001 2 Airborne Systems Requirement Specification for More Autonomous

– Aircraft in the Future Air Traffic Management System Data Deliverable 18 [D18]

1.4.2 Other Documents Item Title Date

3 ICAO Manual of Air Traffic Services Data Link Applications 4 VDL Mode 4 Standards and Recommended Practices (SARPs),

ICAO AMCP/7, Appendix A to the report on agenda item 2, 2 March 2000.

5 Manual on detailed technical specifications for the VDL Mode 4 digital link, draft, ICAO AMCP/7, Appendix B to the report on agenda item 2, 2 March 2000.

6 VDL Mode 4 Implementation manual, ICAO AMCP/7, Appendix C to the report on agenda item 2, 2 March 2000.

7 EMC and Radio Matters (ERM); Very High Frequency (VHF) radio equipment operating in VDL Mode 4. Technical characteristics and methods of measurement, draft, ETSI, 2000-02

8 Teori for tidsluckefordelning av basstationer och basslavar, Hakan Lans, 1995-08.

10 The integrity of GPS, Richard B. Langley, University of New Brunswick, Re-printed from GPS World Magazine, Advanstar Communications Inc, 1999.

11 Draft GNSS SARPs, version 8, ICAO (GNSSP), 1999-05. 12 NUP TIS-B Service Description, version 1.1, 2001 13 NUP FIS-B Service Description, version 1.0 , 2001 14 Algorithms in Modula 3, Sedgewick, Robert, Addison-Wesley,

1993.

15 EUROCONTROL, OPERATIONAL REQUIREMENTS FOR AIR/GROUND COOPERATIVE AIR TRAFFIC SERVICES (AGC-ORD-01), Edition 1.0, 2 April 2001

16 Eurocontrol CFMU. Basic CFMU Handbook, IFPS Users Manual. Ref IFPS_MAN. Edition No. 7.0 [IF1]

17 Eurocontrol CFMU. Basic CFMU Handbook, ATFM Users Manual. Ref ATFM_MAN. Edition No. 7.0 [AT1]

18 [01] – EUROCONTROL, Operational Requirements For Air/Ground Cooperative Air Traffic Services, Edition 1.0, 2 April


15

2001 19 Generic ATN Communications stack user Guide ,ref:

DED6/MAIN-DEL/D6V1.3_GACS_USER GUIDE


16

2 MEDUP Platform Description

2.1 System Architecture MEDUP provides a set of cooperative air-ground operational services, which aim to be exploited during all phases of flight. In order to support air-ground services, an appropriate ground-ground ATS interfacility data link communications (AIDC) is incorporated.

Rome ACC building - Ciampino

ENAV Experimental Centre

compaq

CD-ROM

DAT

ATMCommsGateway

compaq

CD-ROM

DAT

SMG

ATIS HMIADSP &

FDP Client

Radio

Proc

VDL4Medup Ground

Station

VHF Antennas GPS AntennaCoax cables

RouterTo Ciampino

MEDUP GroundStation

RouterTo Ciampino

OPS Radar/FDP

ISDN lines

Rome ACC(Ciampino)

I

ISDN line

Voice Switch

Data

CDS2000Open

DFPcompaq

CD-ROM

DAT

compaq

CD-ROM

DAT

FDP ADSPcompaq

CD-ROM

DAT

Figure 2. - MEDUP system block diagram

2.2 Functions ADSP The primary function of ADSP is to enhance the controller capability to perform both the strategic and tactical control of a flight, by obtaining a suitable set of data from a/c avionics. The ADSP interacts with the properly equipped a/c through the two way transmission of ADS-B , via the Communication Gateway. The acquired data are processed and then distributed to the set of Air Traffic Control Centre (ATCC) functions strictly related to the ATC surveillance: Flight Data Processor System (FDPS), Data Fusion Processor System (DFPS), Controller Working Position (CWP). The ADSP is a system which offers a set of advanced ATM services by means the following major ADSP functions:


17

Standard Communication Interface (SCI) SCI function provides the ADSP with a standard interface module dedicated to exchange data with each of the following system segments

ADSP sends and receives ADS-B messages from the a/c through the Communication Gateway;

ADSP exchanges data concerning the flight plans with the FDPS;

ADSP exchanges messages, like deviation or monitoring data alerts, with the CWP;

ADSP provides the DFPS with ADS tracks.

Context Management Application (CMA) The basic service that the ADSP Context Management Application offers is the Management of the Initial Contact procedure. The Context Management application handles the initial connection between ADS-Broadcast equipped a/c and an ATC Centre by means of the Initial Contact Procedure. ADS Tracker Handling (ATH) In order to perform the tracking, ATH has an internal database where it stores the data relevant to the track. Incoming reports are attempted to correlate with an already existing track by correlating the identification block of the report with the ones stored in the database. When a report is associated to one track, the positional and speed data are updated with the contribution of the new information contained in the report. At the end of the updating process, the algorithm evaluates the track’s extrapolated position at the next time of presentation. Exchange Messages Management (EMM) The Exchange Messages Management function performs the connection of the new flight by inserting the aircraft identifier in the connected flight database. At this point the ADSP takes into account the a/c capabilities stored in the relative flight plan and on basis of these information the EMM establishes a connection with the aircraft. The ADSP, by means of the EMM function, offers the following services:

Management of the ADS connection: reception of periodic reports, which contain a predefined block of data, and additional reports with additional data (e.g. next waypoint information)

Dispatching of data to all other ADSP capabilities: Exchange Message Management function acts as dispatcher of data for all capabilities of the ADSP, and interact with the Communication Gateway through the SCI function.

DF The DFP Data Fusion Processor is in charge of generating system tracks through the combination of any radar and ADS-B contributes. This results in more reliable and accurate data for the controller and for conflict detection and conformance monitoring function (reduction of false alarm probability). FDP The Flight Data Processing system (FDPS) mainly provides Air Traffic Controllers accurate and update flight information during all flight control phases (flight planning, co-ordination between sectors and with adjacent ATS units, transfer of flight control between sectors. The FDP Flight Data Processor manages the flight plan database. It provides the following main functions:

Interface to the AFTN network to gather flight plans. Maintain the repetitive flight plans database. Manage status information for each flight within the FIR, as it goes through the different phases.


18

Supports the SSR Code Management function. This function is composed of: SSR code category determination and SSR code assignment.

Flight Monitoring exploiting flight intents provided by the ADS-B function. CWP The Controller work position provides the Human Machine Interface (HMI) to the controller. Its main functions are:

Display of surveillance information to ATC controllers, with the capability to indicate ADS-B equipped a/c.

To enable the controller to exchange ADS messages with the airborne system. To enable the controller to exchange CPDLC and with the pilot.

ATM COMM GATEWAY The ATM Communication Gateway provides the support for each of the ATS data link operational service implemented within MEDUP. It performs all the communication oriented functions and accesses directly to the underlying network. The following operational services are supported by the ACG, through the provision of well-defined interfaces: ODIAC operational services

Flight Plan Consistency (FLIPCY) CPDLC Data Link Applications Data link Operational Terminal Information Service (D-OTIS)

Other operational services based on the broadcast concept

ADS-B Report Distribution to ground clients Traffic Situation Picture Distribution (TSPD) through TIS-B

ATIS ATIS Server shall provide the controller the capability to compose and send ATIS messages through a graphic interface (HMI). These messages could be sent manually or automatically every “n” second, where “n” is a configuration parameter. SHADOW MODE GATEWAY The Shadow Mode Gateway performs the following actions:

Receives MRT and Flight Plan data from the Ciampino ATC Centre; Flight data alignment consists of:

1) SFPL data transmission when the SFPL change its state from inactive to pending; 2) SFPL updates when any SFPL data revision is performed in the pending state;

MEDUP GROUND STATION The Communication Segment is concerned with ground-ground and ground air data communications. It will provide a reliable way for the applications data exchange by means of a two-way data link between airborne and ground computers based on an unique VHF digital data link for air-ground and air-air broadcast and addressed communications. The ground station includes a digital radio compliant with the ICAO VDL Mode 4 and a communication component allows interconnecting to other ground stations.


19

2.3 Overall MEDUP data flow In the following picture a high level description of messages exchange between components will be presented.

Data Fusion

RadarFront-End

Flight DataProcessor

ADS

MEDUPGroundStation

ATMCOM GTW

Downlink_msgs

PSR/SSR_data

ADS_

Trac

kATIS

CWPSystem_TracksSystem_Tracks

CPDLC_msgs

TIS-B_msgs

DLL_msgs

FIS-B_msgs

Uplink_m

sgs

CPD

LC_m

sgs

CPDLC

Syst

em_T

rack

s

Figure 3. MEDUP Data Flow


20

3 MEDUP implementation of MA-AFAS related functions This chapter provides for MEDUP ground platform based in Ciampino, function (or group of functions) that is relevant to support the MA-AFAS services and trials (based on the table presented in the D11) and a list of the requirements that each function has to meet. The MA-AFAS system in Rome environment is composed of this platform:

ADS MEDUP located at ENAV Exp. Centre and the ADS MEDUP ground station (MGS) located at the Ciampino airport;

the Taxi ATC Tool TAT installed at ENAV Exp. Centre In House Platform IHTP installed at ENAV Exp. Centre (IHTP will host the AOC functionality)

Figure 4. MA_AFAS system block diagram In Rome Environment

TAXI ATC TOOL

Rome ACC building - Ciampino

ENAV Experimental Centre

ADSPcompaq

CD-ROM

DAT

ATMCommsGateway

compaq

CD-ROM

DAT

SMGcompaq

CD-ROM

DAT

DFPcompaq

CD-ROM

DAT

FDP

ATIS HMIADSP &

FDP Client

Radio

Proc

VDL4Medup Ground

Station

VHF Antennas GPS AntennaCoax cables

RouterTo Ciampino

MEDUP GroundStation

RouterTo Ciampino

OPS Radar/FDP

ISDN lines

Rome ACC(Ciampino)

I

ISDN line

Voice Switch

compaq

CD-ROM

DAT

Data

CDS2000Open

IHTP

PCData

MonitorTouchScreen

Power Panel

PC

Taxi PC


21

3.1 ADS-B, Automatic Dependant Surveillance Broadcast ADS-B is a surveillance technique for use by air traffic services in which aircraft automatically provide, via a broadcast data-link, data derived from on-board position-fixing and navigation systems. ADS-B allows ground surveillance system to obtain position data and other information from equipped aircraft in a timely manner in accordance with their requirements, and will allow the aircraft to be tracked even in non-radar airspace. Within MEDUP the objective of ADS-B application is to provide a/c position, speed and intent data that will be combined with the radar data to improve the quality of the system tracks displayed to the controller.

3.1.1 ADS-B Requirements REQUIREMENT CODE

DESCRIPTION

MDP_ADS_001 The Ground Surveillance System shall receive and process ADS-B reports received from MEDUP network.

MDP_ADS_005 The Surveillance Data Processor shall be able to generate tracks using both ADS and radar data sources.

MDP_ADS_010 The system tracks with ADS-B contribution shall be visualised on the HMI with a special symbol in order to differentiate them with respect to the radar-only system tracks.

Data Fusion

RadarData

Capture

Flight DataProcessor

System_Track

Mono_RADAR_Tracks

ADSBData

Capture

ADS_Plot

_4D

ADS Tracking

ADS_Tracks

Ground

_Vec

torController HMI

System

_Trac

ks

Figure 5. ADS-B Context Diagram


22

3.2 TIS-B, Traffic Information Service Broadcast TIS-B is a ground-based application that transmits, via a broadcast mode link, data as identification and position of targets detected by the ground surveillance system. In a scenario with the presence of both ADS-B equipped and non equipped aircraft, traffic information available on board using only ADS-B information is not complete. In that case TIS-B may provide the remaining tracks by up-linking them. The availability of TIS-B service will increase pilot awareness through the display of both co-operative and non co-operative aircraft. The CDTI achieves a complete and coherent picture of surrounding traffic correlating and integrating positional data (as well as other information) broadcast by co-operative aircraft and TIS-B data broadcast by ground ATC system. The TIS-B can work in two different ways:

• Gap-filler, only tracks without ADS-B contribution (or for which faulty ADS-B has been detected)

• Full-picture, all system tracks

3.2.1 TIS-B Requirements REQUIREMENT CODE

DESCRIPTION

MDP_TIS_001 The TIS-B shall receive the system tracks provided by Surveillance Data Processor.

MDP_TIS_005 The TIS-B shall have the capability to filter out the system tracks obtained with valid ADS-B contribution.

MDP_TIS_010 The TIS-B shall transmit the system tracks every n second (where n is a configuration parameter).

MDP_TIS_015 The TIS-B shall transmit the system tracks which position is inside a geographical area that will be configured.

MDP_TIS_020

The following information shall be transmitted:

• Number of tracks to be transmitted;

• For each track: o Aircraft identifier o SSR code o Latitude o Longitude o Ground Speed o Track Angle o Altitude o Climb/Descend Indicator (Levelled, Climbing or Descending flag) o Indication of source of data

MDP_TIS_025

The TIS-B shall display an error message if one of the following errors occurs:

• The connection to the MEDUP communication segment is not working properly;

• A received system track is corrupted.


23

Data Fusion

TIS-B Server

System_Tracks

TIS-B COMService(f-TIS-B)TIS-B_Tracks

TIS-B_Service_Volumes

Figure 6. TIS-B Context Diagram

3.3 FIS-B, Flight Information Service

3.3.1 D-OTIS The Data Link Operational Terminal Information Service (D-OTIS) service provides automated assistance in requesting and delivering compiled meteorological and operational flight information derived from ATIS, METAR and/or NOTAMs/SNOWTAMs, specifically relevant to the departure, approach and landing flight phases. In the MEDUP project, the broadcast ATIS (Automatic Terminal Information Service) service shall be implemented. ATIS is currently a voice broadcast service intended to relieve frequency congestion and air traffic Controller workload by providing pertinent information to aircraft operations in the terminal area through a local broadcast. This broadcast eliminates the need for a Controller to transmit the information to each aircraft individually. This is normally accomplished through the use of a voice recording of the information that is continuously repeated over a published VHF frequency in the vicinity of the aerodrome.


24

3.3.1.1 D-OTIS Requirements REQUIREMENT CODE

DESCRIPTION

MDP_FIS_001 The ATIS service shall provide a HMI that allows the user to manually input data.

MDP_FIS_005 The ATIS service shall send in uplink every n seconds (where n is a configuration parameter) the current ATIS information. If a parameter to be sent is not specified, a not valid value shall be sent.

MDP_FIS_010 At any time the User shall have the capability to send an ATIS message manually.

The information that shall be transmitted in uplink is described in the following table:

Type Message Information required A D C

Source/ destination

Alert

Aerodrome Identification Departure and/or arrival indicator

M M M

Contract Type M M M ATIS designator M M M Time of observation O O O Type of approach M M Arrival runways in use M M Status of arresting system O O O Departure runway M M Significant runway surface conditions

M M M

Braking action O O O Holding delay O O O Transition level O O O Other operational information O O O Surface wind direction and speed M M M Visibility M M M RVR O O O Present weather O O O Cloud M M M Air temperature M M M Dew-point temperature M M M Altimeter setting M M M Significant meteorological phenomena

O O O

Trend type landing forecast O O

ATIS Delivery

Specific ATIS instructions O O O

Ground system/ aircraft

Medium

Aerodrome Identification M M M ATIS

termination Contract termination O O O

Aircraft /ground sysstem or ground system /Aircraft

Pilot:medium; ground system

:none

MDP_FIS_015

Table Key: A: Arrival ATIS D: Departure ATIS C: Combined ATIS M: Mandatory O: Mandatory if applicable


25

3.4 MEDUP Ground Station ATN Switch There is a requirement to enhance the MEDUP ADS-B Router (AR) to support the MA-AFAS flight trials activity. The main purpose of the enhancements is to allow a remote ground network to exchange point-to-point messages with aircraft equipped with the MA-AFAS Avionics Package. Although the main objective is to allow the MA-AFAS ATN network (which is purely point-to-point) to operate over MEDUP infrastructure, the ADS-B Router also is required to provide extra information to allow the ATN ground components to identify available aircraft with which to communicate. The following figure summarises the of the point to point communication stack on the ground.

Figure 7. MA-AFAS point to point communications in the MEDUP environment

REQUIREMENT CODE

DESCRIPTION

MDP-ASW-01 The ADS-B Router shall communicate with the MA-AFAS IHTP over a UDP/IP interface. The address of the MA-AFAS IHTP and the UDP port number shall be configurable at ADS-B router start-up.

MDP-ASW-01A The ADS-B Router shall read a list of MA-AFAS DLS addresses as configuration data at start-up.

MDP-ASW-02A

The ADS-B Router shall copy C76 BLIS messages coming from the VDLM4 transponder both to the MA-AFAS IHTP, without alteration, and to the MEDUP network or only to the MEDUP network, depending on whether the DLS address of the sending transponder is a MA-AFAS address or a MEDUP address, respectively. All addresses that are not included on the MA-AFAS list are interpreted as MEDUP addresses.

MDP-ASW-02A

The ADS-B Router shall pass C75, C77 and C78 BLIS messages coming from the VDLM4 transponder to the MA-AFAS IHTP, without alteration, or to the MEDUP network, depending on whether the DLS address of the sending transponder is a MA-AFAS address or a MEDUP address, respectively. All addresses that are not included on the MA-AFAS list are interpreted as MEDUP addresses.


26

MDP-ASW-03

The ADS-B router shall pass all C1 (point-to-point) BLIS messages received from the MA-AFAS IHTP to the VDLM4 transponder, without alteration. These C1 messages are to be placed into sequence with any point-to-point or broadcast messages generated by the MEDUP network, for transfer to the transponder.

MDP-ASW-04 The ADS-B Router shall respond to all valid C1 messages received from the MA-AFAS IHTP by immediately sending a C100 message back to the MA-AFAS IHTP.

MDP-ASW-05 For C101 and C102 (ack/nack) BLIS messages received from the VDLM4 transponder in response to a C1 message originating from the MA-AFAS interface, the ADS-B Router shall route the received message to the MA-AFAS interface.

MDP-ASW-06

The ADS-B Router shall pass C87 (join/leave) BLIS messages coming from the VDLM4 transponder to the MA-AFAS IHTP, without alteration, or to the MEDUP network, depending on whether the DLS address of the sending transponder is a MA-AFAS address or a MEDUP address, respectively. All addresses that are not included on the MA-AFAS list are interpreted as MEDUP addresses.

MDP-ASW-07

The ADS-B Router shall pass C79 (point-to-point) BLIS messages coming from the VDLM4 transponder to either the MA-AFAS IHTP or internally to the MEDUP point-to-point message functions, depending on whether the DLS address of the sending transponder is a MA-AFAS address or a MEDUP address, respectively. All addresses that are not included on the MA-AFAS list are interpreted as MEDUP addresses.


27

4 MEDUP Data Dictionary In this chapter there will be a detailed description of the relevant MA-AFAS messages that will be implemented in the MEDUP platform. For each type of message there will be a list of items and a brief description of the item if it is necessary. ADS_Plot_4D This contains the 3D position and the time stamp extracted from the ADS-B reports transmitted by the aircraft. Item Notes source a/c identifier message_code latitude In WGS 84 reference system longitude In WGS 84 reference system altitude Barometric altitude in WGS 84 reference system date Time stamp, composed by: years, month, day, hour, minutes,seconds figure_of_merit

Table 1. ADS_Plot_4D content

ADS Tracks This contains all the tracks coming from the equipped aircraft under the VDL M4 coverage once they have been processed by the ADS Tracking module. Item Notes Source Time_of_track_information Track_number Calculated_track_position X-Y in stereographic coordinates Track_mode_3/A_code Calculated_track_flight_level Measured_flight_level Calculated_track_velocity Mode_of_flight Calculated_rate_of_climb/descent

Table 2. ADS_tracks content

ATIS_msgs This includes weather conditions, operating procedures, runways and approaches in use, and various other information, which may affect the departure, approach and landing phases of flight. The recorded ATIS message is updated upon the issuance of a new weather observation, or when conditions or procedures affecting various components of the ATIS message change substantially. Individual ATIS messages are identified by a designator from the ICAO alphabet, Alpha through Zulu, on a cyclical basis. Item Notes Aerodrome Identification


28

Departure and/or arrival indicator ATIS designator Time of observation Type of approach Arrival runways in use Status of arresting system Departure runway Significant runway surface conditions Braking action Holding delay Transition level Other operational information Surface wind direction and speed Visibility RVR Present weather Cloud Air temperature Dew-point temperature Altimeter setting Significant meteorological phenomena Trend type landing forecast Specific ATIS instructions

Table 3. ATIS_msgs content Ground _Vector Item Notes a/c track angle a/c ground speed a/c vertical rate

Table 4. Ground_vector content Mono_Radar_Tracks Tracks derived from the radar information. Item Notes Source Time_of_track_information Track_number Calculated_track_position X-Y stereographic coordinates Track_mode_3/A_code Calculated_track_flight_level Measured_flight_level Calculated_track_velocity Mode_of_flight Calculated_rate_of_climb/descent

Table 5. Mono_radar_tracks content


29

System_Tracks This contains all the tracks, which come from the Data Fusion that is in charge to merge radar and ADS tracks. Item Notes Source Time_of_track_information Track_number Calculated_track_position X-Y Track_mode_3/A_code Calculated_track_flight_level Measured_flight_level Calculated_track_velocity Mode_of_flight Calculated_rate_of_climb/descent

Table 6. System_Tracks content

TIS-B_Service_Volume This contains the information about the Service Volume, which is defined as a region of airspace in which full surveillance picture is guaranteed by the ground system. Item Notes type_identifier source

Table 7. TIS-B_Service_Volume content

TIS-B_Tracks Depending on the TIS-B mode, gap-filler or full-picture, it contains respectively only the radar tracks or the combination of radar tracks and those of the ADS-B equipped aircraft. Item Notes type_identifier source aircraft_id latitude longitude ground_speed track_angle altitude climb_indicator

Table 8. TIS-B tracks content


30

5 ESCAPE Platform Description

5.1 ESCAPE Architecture

BADAEONSprepIPAS

Supervision

GROUNDERGO MASS MCSEONS

Data repository

OASIS (Middleware)

Off-line data preparation facilities

On-line simulation facilities

AudioLAN

Datalink

Figure 8. ESCAPE Architecture

The ESCAPE platform consists of the following components:

Off-line data preparation facilities: • IPAS (Integrated data Preparation and Analysis System) allows to import, prepare, validate

and analyse such data as airspace structure, traffic samples and ATC constraints before the simulation exercises runs; it also includes post-simulation analysis and replay features.

• EONS prep tools is a generic software environment designed to build ATC working positions (CWP, pilot position, supervision console, etc..).

• BADA (Base of Aircraft Data) is an aircraft performance database used by MASS (in order to simulate realistic aircraft navigation), and by the Ground subsystem (for 4D profile calculations).

On-line simulation facilities (which architecture rests upon the OASIS Common Platform,

providing inter-client communication by using a CORBA middleware) : • The Mass (Multi-aircraft simplified simulator) subsystem simulates the aircraft traffic • The Ground subsystem performs the Flight Plan Data Processing and provides additional

advanced tools; • The Audio Lan system offers a low-cost, inter-operable voice communication solution in the

simulator by using “voice over IP” technologies.


31

• The Eons (Eurocontrol Open and generic ATC graphic system) runtime subsystem provides controller working positions (CWP) and pilot positions, as developed with the EONS prep tool.

• The Datalink component implements datalink messages transmission over simulated communication stacks; it also offers communication using real ATN stacks.

• The Ergo component aims to get and analyse in real time the subjective controller workload. • The MCS (Multi Cockpit Simulator) is a sophisticated Pilot Position developed for the EEC. It

includes a realistic aircraft model (currently an Airbus A320). • The Supervision subsystem (Oasis Tools) offers technical supervision capabilities over the

simulator.

5.2 Functions

5.2.1 Planned capabilities of the EAT/ESCAPE platform The following table details the prominent features of the main on-line components of ESCAPE, as they are expected to be available within the MA-AFAS tests timeframe (EAT/ESCAPE 2002B platform). ESCAPE component Expected Features / Functions in EAT2002B

ESCAPE_AIR

MASS

• Provides an air traffic simulation within the context of large-scale real-time ATC simulators. In particular, it will generate simulated aircraft data (called Aircraft State Vectors) suitable for use in the simulation of surveillance system functions. The air traffic can be generated either automatically or with the help of Pseudo-Pilots controlling simulated aircraft behaviour.

• Support of up to 1000 Flights within a Simulation Exercise and maximum of 500 Flights active simultaneously. MASS uses a Total-Energy Model (TEM) and the Base of Aircraft Data (BADA) as a basis for aircraft trajectory calculations.

• Support of up to 30 pseudo pilot positions, each one handling a maximum of 32 aircraft

• MASS can simulate the functions of ASAS systems on suitably equipped flights and follow controller traffic delegation orders.

• 4D FMS emulation (TBC)

• Response to detailed weather scenarios (TBC )

ESCAPE_GROUND • For flight plan data processing: Airspace information and aircraft performance information

management and distribution to any Ground components. Flight plan generation (FPG) aiming to get prepared flight

plans (provided by IPAS), and to manage initial flight plan to be distributed within the ground system

• Flight plan management (FM) aiming to generate and manage system flight plans (using initial flight plan information provided by the FPG and trajectory updates provided by the TP).


32

ESCAPE component Expected Features / Functions in EAT2002B 4D Trajectory prediction (TP) aiming to simulate the

progress of the aircraft along the 4D profile according to the initial flight plan, ATC constraints, the aircraft performances and the predicted weather conditions.

Track deviation monitoring (TDM) aiming to check the conformance monitoring of active flight correlated with a radar track. This consists in the comparison of the predicted 4D profile with the sensors observed actual trajectory.

• For radar processing:

Independent air surveillance (IAS) aiming to manage (creation, update and deletion) and distribute radar tracks to any Ground component. This component is connected to the Mass sub-system in order to get simulated radar track.

DIS gateway aiming to support the routing of DIS messages to communicate with the Mass system, or any DIS compliant component.

ARTAS tracks with ADS-B fusion (TBC)

• For advanced ATM features: Safety nets, based on up to date air surveillance

information and including Short term conflict alert (STCA), Minimum safe altitude warning (MSAW) based on French IGN data, Area proximity warning (AWP).

Medium term conflict detection features based on predicted 4D profiles of aircraft and including Medium term conflict alert (MTCA), Medium term minimum safe altitude warning (MTMSAW) and Medium term area proximity warning (MTAPW).

Monitoring aids (MONA) aiming to help the controllers in monitoring all the flight under control in order to detect deviations from the system trajectories. It has been specified to provide the controllers with non-conformance warning and reminders and also to automatically trigger the trajectory recalculation (following longitudinal and speed deviation detection).

ESCAPE_DATALINK • Datalink services: DLIC, ACM, ACL, AMC, DSC (TBC), CAP, FLIPCY, PPD, COTRAC (TBC), INTENT (TBC), DYNAV (TBC), DCL

• Simulated ATN communications with MASS-simulated a/c

• Real ATN communications: TAR Ground router (TBC) will be connected to ESCAPE; would still require air-ground connectivity to be provided

• Broadcast services: ADS-B fusion via ARTAS (TBC); TIS-B: TBC. Access to VDL4: to be defined. Note: these services are in fact relevant to ESCAPE’s GROUND subsystem (surveillance functions)


33

ESCAPE component Expected Features / Functions in EAT2002B

• No support of ACARS/AOC Communications

MCS It is not intended to use MCS in the frame of MA-AFAS

ESCAPE/CWP

EONS

• Up to 45 CWPs • Datalink HMI • ASAS functionalities: display of delegation information on the

CWP Audio LAN Provides with a maximum of 64 telecom positions (local/remote:

TBV)

BADA Current version of BADA supports 71 base aircraft types (plus 115 derived aircraft types), representing 90% coverage of today’s European air traffic.


34

6 ESCAPE implementation of MA-AFAS related functions The diagram below is an overview of the ESCAPE platform and it shows the relations between the ESCAPE-AIR, the ESCAPE_GROUND and the ESCAPE_CWP components. Because it’s a general overview, all data flows are not shown on the figure. The Flight Data Processing System of ESCAPE_GROUND subsystem comprises the FM, IUC, TP and GGDC modules using the data servers: Aircraft (ACR), Airspace (ASP) and Weather (WEA). The MONA Server is also part of ESCAPE_GROUND and is responsible of the production of the reminders and non-conformance warnings related to manoeuvres. Safety Nets modules include Short Term Conflict Alert (STCA), Minimum Safe Altitude Warning (MSAW) and the Area Proximity Warning (APW). These modules work on the actual position of the aircraft and are in charge of detecting STCAs, MSAWs, APWs and of sending those alerts and warnings to CWPs. Medium term planning aids include Medium Term Conflict Alert (MTCA), Medium Term Safe Altitude Warning (MTSAW) and the Medium Term Area Proximity Warning (MTAPW). These modules work on the predicted trajectory of the aircraft and are in charge of detecting medium term conflicts, minimum safe altitude and area proximity infringements and of sending those alerts and warnings to CWPs. IAS, AGDC, GGDC modules are communication interfaces between ESCAPE_GROUND and ESCAPE_AIR, the ATN and external ATC centres. The CCO is in charge of the communications services for the ESCAPE_CWP. The CWP_EONS is part of ESCAPE_CWP and it subscribes and invokes services of most of the servers in the ESCAPE_GROUND and translate the data it retrieves into the conceptual objects representation internal to EONS.

Figure 9 . ESCAPE Modules

AIRSTCA

M SAW

APW

M ONA

TDM

M TCD

M TAPW

M TM SAW

DIS

FM

AGDC

IUC

TP

ASP

FPG

W EA

ACR

CW PEONS

GGDCExternal ATC

Centre

Datasets (Traj, FP, …)

EONS

CCOCW P_EON Sreceives infofrom most components

IAS


35

6.1 Airspace data server

Figure 10. Airspace Server Component context diagram

As depicted by Figure 10 above, airspace data is centralised by the Airspace Data Server (ASP) for distribution to other ESCAPE components. The airspace data describes the airspace environment in terms of: • FIR/UIR description, ATC centre envelope, • Navigation points and beacons description, • Airport description, • Airways description, • Sectors & restricted access area description, • All airspace data encountered on aeronautical map, • SIDs, STARs, etc.

SPV

CW P

FMAirspace

data

ASPAPW

M SAWAIR

Commands


36

6.2 Aircraft server

Figure 11 . Aircraft server component context diagram

This component is in charge of retrieving from the BADA files the values of the coefficients of the BADA model (general aircraft data, aircraft performances).

6.3 Trajectory Predictor

Figure 12 . Trajectory Predictor component context diagram

The Trajectory Predictor module creates 4D trajectories from 4D flight profiles. The TP simulates the progress of the aircraft along the 4D flight profile according to its performances provided by the ACR server, and the predicted weather conditions provided by the WEA server.

SPV

Aircraft data

A/C PerformancesA/C model parameters

ACRTP

AIR

Com mands

A/C PerformancesA/C model parameters

SPV

W EAW eather dataFlight Plan Route

TPFM

Com mands

Trajectories

ACR

A/C performancesA/C model parameters


37

Currently the TP calculate the trajectory according to the whole flight plan. The trajectory is later on modified by the controller input orders or time deviation integration.

6.4 Independent Air Surveillance

Figure 13. Independent Air Surveillance context diagram

The IAS module is in charge of : • The production of radars tracks, • the system aircraft creation and update, • the plot cleaning (track deletion), • The pairing of a flight plan with a track, • The production and delivery of air situation.

SPV

IASFM

AIR

TDMCoupling

requestProposedcoupling

System air situation

STCACW P

System air situation

4D profile

Aircraft state vectors(position + speed)

+ SSR code


38

6.5 Track Deviation Monitoring

Figure 14. Track Deviation Monitoring context diagram

The TDM module is in charge of :

o the calculation of the conformance of the aircraft track with the flight plan, o the emission of deviation warnings, o the detection of beacon over flight to transmit flight progress information.

6.6 Flight Manager

Figure 15. Flight Manager server context diagram

SPV

TDMIAS FMCoupling

request

Proposedcoupling

CW P

W arnings to CW Ps

4D profile

FP data

Flight Progress,Deviation

Predicted/Coupledair situation

SPVFPG

ASP

Uplink, Downlink

Trajectories

CW P

4D profile

Rfl,Cfl

Controller inputs, resectorisation

SFPAGDC

TP

TDMIUC

Airspace data

STCA

M TCAFP data

FP

Traj.

Deviation,flight progress

Coordinationdata

FM


39

The FM generates the corresponding System Flight Plans (SPLs) with the trajectories provided by TP, and manages the update of SPLs.

6.7 IUC interfaces

Figure 16. IUC component context diagram

The IUC dedicated server will offer the communication required by the OLDI/SYSCO standard for coordination of aircraft transfer between sectors.

6.8 ASAS Delegations Identification Requirement description ESC_DEL_001 ESCAPE shall allow the Air Traffic Controllers and Simulation Pilots to implement delegation dialogues using

voice communications. ESC_DEL_002 ESCAPE shall allow the Air Traffic Controllers to enter information regarding potential and active delegations

via their HMI. ESCAPE shall then provide delegation markings on the controllers working positions, according to those information previously entered in the system by the operator. Those markings shall at least display delegated/target aircraft identification and links between those aircraft. Specifications for this functionality can be found in the EEC document "EACAC 2001 simulations - Facility specification"

ESC_DEL_003 ESCAPE shall provide assistance to the simulation pseudo-pilots by offering an automated handling of delegations (station keeping, crossing, passing) for simulated traffic. Specifications for this functionality can be found in the EEC document "MASS-ASAS URD, v3.0, 7th July 2000")

ESC_DEL_004 For the purpose of supporting MA-AFAS WP3.1 real time simulations, It shall be possible in ESCAPE to use delegation procedures where Qinetiq's RTAVS-based BAC 1-11 simulator (resp. DLR ATTAS simulator) is the subject (delegated) aircraft as well as delegation procedures where it is the target aircraft.

ESC_DEL_005 For the purpose of supporting MA-AFAS WP3.2 real time simulations (live trials) It shall be possible in ESCAPE to use delegation procedures where Qinetiq's BAC 1-11 (resp. DLR ATTAS) is the subject (delegated) aircraft as well as delegation procedures where it is the target aircraft.

ESC_DEL_006 ASAS equipped aircraft shall be displayed with a special symbol on the controller's HMI.

SPV

IUC

Logical Data for messages

FP data

GGDC

FM

CW P

Coordination input to CW P

Keypoints & Times for Triggers

(new and updated)

New FPLcreations

Coordinationinput from CWP

(forwarded)W arnings

FP data


40

6.9 ADS-B/TIS-B support Identification Requirement description ESC_ADS_001 For the purpose of supporting delegations in MA-AFAS WP3.2 simulations (and WP3.1 simulations if DIS is

not used), ESCAPE shall be able to: - access to an ADS-B infrastructure, so as to receive ADS-B data from the trials aircraft (or aircraft

simulators) - process those ADS-B data in order to generate tracks, using also if necessary radar data sources

Identification Requirement description ESC_TIS_001 For the purpose of supporting delegations in MA-AFAS WP3.2 simulations (and WP3.1 simulations if DIS is

not used), ESCAPE shall be able to: - generate TIS-B data from periodic updates of state vectors related to simulated traffic - access to a TIS-B infrastructure, so as to uplink simulated traffic data to the laboratory aircraft (or

aircraft simulators) - filter out non relevant surveillance data if necessary

6.10 Datalink services Identification Requirement description ESC_DTL_001 The following Datalink services, as specified by the ODIAC group, shall be available in ESCAPE:

- DLIC - ACM - ACL - FLIPCY - CAP

ESC_DTL_002 It shall be possible to use those datalink services listed above (ESC_DTL_001) in ESCAPE between the simulated ground ATC and the simulated aircraft during all MA-AFAS WP3 simulations, and additionally: - between the simulated ground ATC in ESCAPE and Qinetiq's RTAVS or DLR simulator (MA-AFAS

WP3.1 simulations) by means of a real ATN stack/infrastructure or via a DIS link - between the simulated ground ATC in ESCAPE and Qinetiq's BAC 1-11 or DLR ATTAS (MA-AFAS

WP3.2 simulations) by means of a real ATN stack/infrastructure

6.11 ATN stack and infrastructure Identification Requirement description ESC_ATN_001 ESCAPE shall include a real ATN stack enabling to connect the platform to an ATN router and further gain

connectivity to the air/ground ATN communication infrastructure supporting MA-AFAS ATN Datalink communications

ESC_ATN_002 ESCAPE shall provide the CM, CPDLC and ADS ASEs


41

7 ESCAPE Data Dictionary Note: ADS-B, TIS-B and datalink related data will be described in EEC's internal ESCAPE documentation A/C performances and A/C model parameters Parameters and performances of the simulated aircraft. Coupled Air Situation List of aircraft positions and speeds resulting from the track generation, associated with a flight plan. Coupling Request Probe pairing of a flight plan with a track. Deviation Deviation detected by TDM, i.e measure of the conformance between the track and the predicted trajectory. Flight Plan Route Flight Plan Route (2D) + constraints : list of route points with name, position and the ATC constraints (speed, altitude) along the route. Flight Progress Beacon overflow events information. FP Flight Plan Data Information received for creation (and updates) : Callsign, Aircraft Type, submitted Route, Requested Level, Preferred TAS, ETA, ETD, Aeroport-dest, Aeroport-dep. Predicted Air Situation Predicted trajectories(4D profiles) used for the track deviation calculation. Proposed Coupling Computation of a probe pairing.. Coordination data Coordination messages. SFP System Flight Plan Information generated and stored in the FP database. Trajectories Predicted trajectories (4D profiles) calculated by TP. Uplink/Downlink Information “sent to” or “given by” the AGDC(Trajectory info, meteo info,…) . Warnings to CWPs Warning messages emitted to controllers (lateral deviation, heading deviation…). Weather data


42

Predicted weather (wind) conditions at the A/C.


43

8 In House Test Platform, Platform Description The BAE SYSTEMS In-house Test Platform (IHTP) provides the following facilities:

Stand-alone support for Avionics Hardware and Software development, integration, and test. Support for primary test facilities, including simulators and aircraft, providing functions that

the primary test facility does not have. The HMI is basic, providing the ability to perform stored, synchronised test sequences or manual setting up of simple communications messages, and monitoring of responses. It is not a replacement for ground test platforms; in this role it is a gap filler only.

8.1 System Architecture The BAE SYSTEMS In-house Test Platform (IHTP) is hosted in a PC base unit and is summarised in the following block diagram:

Test Control Window

AOC Terminal Window

MCDU Window

ATC Comms Window

MCP Window

Aircraft Simulator Window

Traffic Control Window

RS 422 Module

Ethernet Module

VDL Mode 4 Interface

Audio Module

VDL Mode 4 Interface ARINC 702A Discretes

ARINC 702A Warnings

Figure 17. IHTP system block diagram


44

Flight Deck

or Flight Deck Simulator

(Optional)

MA-AFAS Avionics

Rack FMU+CMU

Aircraft Systems

or Aircraft Simulation

(Optional)

BAES In-house Test Rig

Function Select ATN Comms / Broadcast / Traffic / Aircraft Model / MCDU Display / Crew Inputs (MCP etc) / Aircraft Systems / AOC /

Display Outputs Crew Inputs

Data Recorder (Optional)

Discrete/Analogue

ARINC 429

Ethernet

Figure 18. Block diagram showing IHTP support of other test facilities

Depending on what functions are already available in the connected test equipment, the Test Control Window is used to enable or disable individual IHTP substitute functions. Displays are provided to allow stand-alone operation of the Avionics Rack without being connected to a flight deck or simulated flight deck. These include Autopilot Mode Control Panel, MCDU, ATC comms control, and GAGS control. Note that the Nav Display is always provided by a separate VGA device, separate from the IHTP. A simple closed loop aircraft model allows development of 4D guidance and ASAS functions. A traffic generator provides ADS-B and TIS-B targets for development of CDTI and ASAS. This may also be used in conjunction with simulators that do not have this capability. The IHTP allows manual or semi-automatic test sequences to be performed from stored files and allows simultaneous results capture to file. Functions: 1. ATN Comms Provides an ATN Stack for communication via Ethernet or simulated

VDL4/RS422/BLIS. An IHTP display shows ATC commands for uplink and received downlink

messages. Data entry and control is either manual or via automatic test files.

Note this is not a controller work station, just a simple method of generating and monitoring messages. There is no provision for injecting errors into the comms.


45

2. GACS Provides a Frame-Mode IP Stack for communication via Ethernet or simulated VDL4/RS422/BLIS.

An IHTP display shows AOC commands for uplink and received downlink messages.

Data entry and control is either manual or via automatic test files. Note this is not an AOC work station, just a simple method of generating and monitoring messages. There is no provision for injecting errors into the comms.

3. Broadcast Comms Provides FIS-B, TIS-B, and ADS-B communications via Ethernet or simulated VDL4/RS422/BLIS.

FIS-B data entry and control is manual or via automatic test file. TIS-B and ADS-B transmissions are based on the Traffic Generator function outputs.

TIS-B and ADS-B transmissions include pseudo-random drop out effect capability.

Other than the range drop out effects, there is no provision for injecting errors into the comms.

4. Traffic Generator Allows the operator to simulate other aircraft and ground vehicles and select dynamically for ADS and/or TIS transmission. Traffic can also be generated from stored files.

5. Aircraft Simulator Takes FMS output commands (to autopilot etc.) and generates aircraft state. Includes autopilot simulation. Control is either manual or via automatic test files. May be initialised at any state. The model can be flown manually but this is a crude facility to test FMS reaction to mode transitions and to allow control during taxiing. Control is via a games joystick.

6. MCDU Accepts ARINC 739A-1 commands via ARINC 429 or Ethernet. Data entry and control is either manual or via automatic test files. Display is on a dedicated PC Window with mouse-driven display control and keyboard-driven data entry. Note that this display only shows FMS outputs – it does not accept other ARINC 739A-1 sources.

7. MCP Controls simulated autopilot and provides mode data to FMU. Generates ARINC 701-1 commands via ARINC 429 or Ethernet. Data entry and control is either manual or via automatic test files. ARINC 701-1 style Mode Control Panel display is on a dedicated PC Window with mouse-driven display control and keyboard-driven data entry. Does not support TURB, FD, or LAND functions.

8. Aircraft Systems Provides interfaces to aircraft systems expected by the FMS, including: ADC AHRS GBAS SBAS Miscellaneous signals/discretes Display is on a dedicated PC Window with mouse-driven display control and keyboard-driven data entry. Allows manual and automatic control of aircraft system interfaces. Automatic control is by test file or by using a dynamic model (for example the Weight and Balance System can be interfaced crudely to the Aircraft Model to simulate fuel burn).


46

9 IHTP implementation of MA-AFAS related functions The requirements definition for the In-house Test Platform is to be found in Work Package 2 deliverable D30. The diagram below is an overview of the entire top level breakdown of the IHTP. Note that the Test Control Window, Test Control File, and Test Results File are effectively connected to all processes but this is not shown in order to aid clarity.

ATNComms

ATCCommsWindow

AOCCommsWindow

TestControlWindow

TestControl

File

TestResults

File

MCDUWindow

TrafficWindow

AircraftModel

Window

GACS BroadcastComms

TrafficGenerator

VDL4Simulator

AircraftSystemsWindow

MCDUControl

MA-AFASAVIONICS

OnboardAircraft

Simulation

On GroundSimulation

AOC FIS,ADS-B

MEDUP,NUP

FrameMode IP

BroadcastData

ATN overVDL4

GACS

ATN

BLIS

TrafficTrajectories

MCDU Interface

AttitudeData

GBASDataNav Data

Aircraft ModelData

AircraftState

SBASSimulator

AircraftSimulator

Airc

raft

Pos

ition

TIS

B A

nd A

DS

B

AP Control

Interface Switching

MCDU Data

MCPWindow

MCPControl

MCP Interface

MCP Data

ARINC429Ethernet

DiscretesRS422

OtherSystemsSimulator

GBASSimulator

AHRSSimulator

ADCSimulator

AircraftPosition

AircraftPosition

ADCData

SimulatorControl

DiscretesData

AircraftState

AircraftSystems

Data

Figure 19. IHTP top level breakdown

The following sections indicate which of the parts of the diagram are used for each of the test capabilities indicated in D11 section 6. In most of the following sections, the operator can choose the path for communications: depending on the configuration for the test, the message is sent via ATN path, through VDL4 simulations. The configuration is set up using the Test Control Window or a Test Control File.

Deleted:


47

9.1 ATC Data Link Control The ATC Data Link Control process encompasses the following facilities listed in D11: • ATN CPDLC DLL • ATN CM Note that the IHTP does not simulate the appearance and disappearance of ground stations (VDL4) as this is beyond the scope of this simple test facility. However, it does simulate several ground end systems that can be logged into and out of, to represent acquiring and leaving C-ATSUs, N-ATSUs, and D-ATSUs. Also note that the IHTP does not provide for the injection of many failure types into the simulated network. However, gross failures can be simulated by stopping the simulated end system from communicating with the avionics.

9.1.1 Overview The following sequences are intended as broad outlines of the procedure only. For full requirements, ODIAC ORD should be referred to. • Establishment of data links is implemented by the specification of a set of end systems by the

operator using the ATC Comms Window or by an equivalent command in a Test Control File. • Each simulated end system definition includes a list of the supported functions and their

version numbers. • End systems can be defined at the beginning of a test or at any point through the test. • Since the ATN Manual requires at least 4 ground systems to be handled simultaneously by the

avionics and MA-AFAS is intended to operate with 4, the IHTP will allow 5 simultaneous ground systems of each type (ATN and IP) to allow for the operator to prepare hand over activities.

• Each ground system can be accessed via the ATC Comms Window, so up to 10 sub-windows are provided to accomplish this.

• For each end system, the operator defines whether it is a C-ATSU, N-ATSU, D-ATSU, or X-ATSU using the ATC Comms Window or an equivalent command in a Test Control File. • The progression of these definitions is normally:

• C-ATSU becomes X-ATSU • N-ATSU becomes C-ATSU • D-ATSU(1) becomes N-ATSU • D-ATSU(2) becomes D-ATSU(1) and this sequence is provided automatically as a convenience.

• X-ATSU is normally removed from the defined list, but it can also be redefined as N-ATSU or a D-ATSU, using the ATC Comms Window an equivalent command in a Test Control File.

• The associated ATN stack initiates a DLL logon sequence with each ground system according to the ODIAC ORD definition. • The status of each ground system data link logon is displayed to the operator for monitoring,

and changes in status are recorded in the Test Results File. • DLL operations defined in the ODIAC ORD can be initiated independently on each ground system

by the operator via the ATC Comms Window or an equivalent command in a Test Control File.

9.2 AOC Data Link Control The AOC Data Link Control process is not listed in D11 but is required in order to establish data links specifically for AOC communications, as opposed to ATC communications.


48

Note that the IHTP does not simulate the appearance and disappearance of ground stations (and VDL4) as this is beyond the scope of this simple test facility. Also note that the IHTP does not provide for the injection of many failure types into the simulated network. However, gross failures can be simulated by stopping the simulated end system from communicating with the avionics.

9.2.1 Overview The following sequences are intended as broad outlines of the procedure only. For full requirements, ODIAC ORD should be referred to. • Establishment of data links is implemented by the specification of a set of end systems by the

operator using the GACS Window or by an equivalent command in a Test Control File. • Each simulated end system definition includes a list of the supported functions and their

version numbers. • End systems can be defined at the beginning of a test or at any point through the test. • Two simultaneous AOC connections of each type (ATN-GACS and IP) can be supported to

simulate communications with the hub AOC and a remote AOC. (TBV) • There is no difference in the representation of the two AOC end systems on the GACS

Window. • Each ground system can be accessed via the GACS Window, so up to 4 sub-windows are

provided to accomplish this. • The associated ATN stack initiates a DLL logon sequence with each ground system according to

the ODIAC ORD definition. • The status of each ground system data link logon is displayed to the operator for monitoring,

and changes in status are recorded in the Test Results File. • DLL operations defined in the ODIAC ORD can be initiated independently on each ground system

by the operator via the GACS Window or an equivalent command in a Test Control File.


49

9.3 Delegated Manoeuvres The Delegated Manoeuvre procedure is similar for the following facilities listed in D11: • COSEP • ATN CPDLC COSE

9.3.1 Overview • Cooperative Separation Assurance is implemented by the generation of a request by the operator

using ATC Comms Window or by an equivalent command in a Test Control File, based on a target (or targets) controlled from the Traffic Window or from an equivalent command in a Test Control File.

• The request is received by the MA-AFAS AVIONICS and displayed on the MCDU Window and the ND for review by the pilot.

• The pilot accepts/rejects the request via the relevant VDL path and ATN or which is then returned to the ATC Comms Window and the Test Results File.

• The pilot plans the manoeuvre using MCDU Window and/or ND and selects the correct MCP Window setting to allow the autopilot function in the Aircraft Simulator to fly the manoeuvre.

• The manoeuvre is monitored by the operator via the Traffic Window.

9.4 Clearance Delivery The Clearance Delivery process is similar for the following facilities listed in D11: • ATN CPDLC ACL C-ATSU only • ATN CPDLC DSC D-ATSU only • ATN CPDLC DCL C-ATSU only • ATN CPDLC Taxi Management (Clearance) C-ATSU only

9.4.1 Overview The following sequences are intended as broad outlines of the functions only. For full requirements, ODIAC ORD should be referred to. • Clearance delivery initiated by ATC is implemented by the generation of a request by the operator

using ATC Comms Window or by an equivalent command in a Test Control File. • The clearance is received by the MA-AFAS AVIONICS and displayed on the MCDU Window

and the ND for review by the pilot. • The review may include noting CDTI indications of near-term traffic conflicts, requiring the

Traffic Generator and Aircraft Model processes to be active and reporting information to the avionics.

• The pilot accepts/rejects the clearance via the relevant VDL path and ATN which is then returned to the ATC Comms Window and the Test Results File.

• Clearance delivery initiated by the pilot is implemented by the pilot using the MCDU Window

and/or the ND or by an equivalent command in a Test Control File. • The clearance request is displayed on the ATC Comms Window for review by the operator. • The operator reviews the request and responds with a clearance. • The clearance is received by the MA-AFAS AVIONICS and displayed on the MCDU Window

and the ND for review by the pilot.


50

• The review may include noting CDTI indications of near-term traffic conflicts, requiring the Traffic Generator and Aircraft Model processes to be active and reporting information to the avionics.

• The pilot accepts/rejects the clearance via the relevant VDL path and ATN which is then returned to the ATC Comms Window and the Test Results File.

9.5 CPDLC The CPDLC process encompasses the following facilities listed in D11: • ATN CPDLC ACM • ATN CPDLC Taxi • ATN CPDLC PPD • ATN CPDLC AMC

9.5.1 Overview • The operator can enter CPDLC messages using the ATC Comms Window or by an equivalent

command in a Test Control File. • The avionics support Baseline 1 CPDLC with extensions defined specifically to support MA-

AFAS functions, so the IHTP supports the same. • The CPDLC messages are entered using the sub-window of the ATC Comms Window

associated with the C-ATSU. • Only the C-ATSU is permitted to exchange CPDLC messages with the aircraft.

9.6 Traffic Broadcasts The Traffic Broadcasts process encompasses the following facilities listed in D11: • ADS-B • ATS-TIS • TIS-B Note that AOC use of ADS-B information is not shown here, as it is assumed to be provided by a ground-ground link between ATC and AOC systems and therefore does not fall into the IHTP system of interest.

9.6.1 Overview • The operator can create other traffic using the Traffic Window or by an equivalent command in a

Test Control File. • The traffic can be airborne or on the ground. • The traffic is defined as an identity satisfying ADS-B and TIS-B encoding requirements and as

a 4D trajectory. • The number of targets that can be simultaneously generated is 1022 per the NUP TIS-B

Service Description and as adopted for the avionics definition (this assumes the figure of 1022 is the absolute number of targets and could be 1022 duplicated ADS-B/TIS-B ones).

• The traffic items can be caused to be transmitted as ADS-B, TIS-B, or as both ADS-B/TIS-B. • The operator can inject discrepancies between ADS-B values and TIS-B values to simulate the

effects of different data sources. • The operator can set different Figures Of Merit (FOM) to cause selection of specific data

sources by the avionics.


51

• The ownship can be included as a TIS-B target to check that it is rejected as a separate target by the avionics.

• The operator can view the avionics ADS-B transmitted data via the ATC Comms Window.

9.7 Flight Information Services The Flight Information Service process encompasses the following facilities listed in D11: • FIS-B • DFIS Note that FIS-C is not considered by MA-AFAS as it is thought to be a very inefficient use of available VHF spectrum

9.7.1 Overview • The operator can create FIS messages using the ATC Window or by an equivalent command in a

Test Control File. • FIS services supported are:

• D-RVR • D-OTIS: ATIS; METAR; OFIS • D-SIGMET

• The pilot can request FIS information from the database held in the avionics via the MCDU Window or ND, or by an equivalent command in a Test Control File. • The IHTP operator responds by sending the requested information using the ATC Window or

by an equivalent command in a Test Control File.

9.8 Airline Operations Centre The Airline Operations Centre process encompasses the following facilities listed in D11: • ATN GACS • AOC Flight Plan • AOC Maintenance • Aircraft/AOC CDM • AOC Asset Management • AOC Operator HMI Note that the GACS Window hosts an AOC Ground Station, with several sub-windows. The AOC facility in the IHTP only provides AOC-Aircraft functions, it does not simulate AOC interaction with any other actors.

9.8.1 Overview • The operator can create AOC messages using the AOC Window or by an equivalent command in a

Test Control File. • These are normally received for use by the pilot on the MCDU Window, but trajectory updates

may also be displayed on the ND. • The avionics can be requested to extract information automatically from the Aircraft

Simulation and transmit it back to the operator for display. • Messages that can be generated using the AOC Window or by an equivalent command in a

Test Control File are as follows:


52

• Free-text • Weather updates (WX, SIGMET, METAR, and TAFs) • Trajectory updates (whole Flight Plans or trajectory constraints) • Loadsheet

• Aircraft systems messages that can ge generated by the operator via the Aircraft Systems Window or Aircraft Model Window are as follows: • Systems failure status • Fuel quantity (this is normally an Aircraft Model output but it can be modified) • ACMS data

• The pilot can create AOC messages using the MCDU Window or by an equivalent command in a Test Control File. • The operator can display the following messages on the AOC Window sent by the pilot or sent

automatically by the avionics: • Free-text (pilot entry) • Now cast transmissions (this is normally an Aircraft Model output but it can be modified) • Trajectory updates (pilot entry or transfer of system data) • OOOI messages (system entry)


53

10 Data Dictionary The IHTP Data Dictionary is maintained in the IHTP Structured Design Model and is published as Work Package 2 document D31. The following flows are summaries of the detailed information held in D31, presented here to clarify the flows presented in the IHTP top level breakdown diagram. In order to simplify the IHTP top level breakdown diagram, flows have been shown as bi-directional in many places. It should be noted that these are not necessarily true bi-directional flows and the following flow descriptions should clarify this. ADC Data This flow contains simulated air data information for use in the FMU, generated from the

aircraft model ADS-B This flow contains the ADS-B information broadcast by the avionics for display on the

ATC Comms Window. AHRS Data This flow contains simulated attitude, heading, and inertial reference information for use

in the FMU, generated from the aircraft model. Aircraft Model Data This flow contains the controls for the aircraft model entered via the Aircraft Model

Window and the status of the aircraft model for display on the Aircraft Model Window. Aircraft Position This flow contains the position of the ownship for selection as a simulated radar-detected

TIS-B object and for generation of SBAS and GBAS navigation solution information. Aircraft State This flow contains the complete set of aircraft data required to support the modelling of

the aircraft operation. Aircraft Systems Data This flow contains the controls for simulated aircraft systems interfacing with the

avionics entered via the Aircraft Systems Window and the status of the simulated aircraftsystems for display on the Aircraft Systems Window.

AOC This flow contains the AOC messages of all types that are received from the avionics tobe displayed on the GACS Window and the AOC messages that are generated by theoperator using the GACS Window.

AP Control This flow contains the Mode Control Panel controls for the simulated autopilot. ATN This flow contains the ATN messages of all types that are received from the avionics to

be displayed on the ATC Comms Window and the ATN messages that are generated bythe operator using the ATC Comms Window.

ATN over VDL4 This flow contains the ATN messages of all types that are received via the VDL Mode 4simulation path and the ATN messages that are generated by the operator to be sent viathe VDL Mode 4 simulation path.

BLIS This flow contains the RS-422 (BLIS) interface between the avionics and the simulatedairborne VDL Mode 4 transponder.

Broadcast Data This flow contains the ADS-B data received from the aircraft over the VDL Mode 4simulation path and the FIS-B, simulated traffic TIS-B, and simulated traffic ADS-B datato be sent to the aircraft over the VDL Mode 4 simulated path.

Discretes Data This flow contains the aircraft system information for transfer to the avionics via discretesignals and the avionics commands to the simulated aircraft systems (including warnings)via discrete signals, all per ARINC 702A.

FIS This flow contains the NUP-defined FIS-B information generated using the ATC CommsWindow for broadcast over the simulated MEDUP

Frame Mode IP This flow contains the point-to-point AOC information received over the VDL Mode 4simulation path and the point-to-point AOC information to be sent to the aircraft over theVDL Mode 4 simulation path.

GACS This flow contains the AOC messages of all types that are received from the avionics viathe ATN network to be displayed on the GACS Window and the AOC messages that aregenerated by the operator using the GACS Window for transfer over the ATN network.

GBAS Data This flow contains navigation solution information for use by the FMU. MCDU Data This flow provides the interface between the avionics and the simulated MCDU.


54

MCDU Interface This flow contains the display commands to the Multipurpose Colour Display UnitWindow from the avionics and returns MCDU key selection information to the avionics.

MCP Data This flow provides the interface between the avionics and the simulated MCP. MCP Interface This flow contains the control information from the Mode Control Panel Window to the

simulated autopilot and the autopilot status information to the MCP Window. MEDUP This flow contains the ATC messages of all types that are received from the avionics via

the simulated MEDUP network to be displayed on the ATC Comms Window and theATC messages of all types that are generated by the operator using the ATC CommsWindow for transfer over the simulated MEDUP network.

Nav Data This flow contains navigation solution information for use by the FMU. Non-ATN Data This flow contains the point-to-point MEDUP ATC information received over the VDL

Mode 4 simulation path and MEDUP ATC information to be sent to the aircraft over theVDL Mode 4 simulation path.

Simulator Control This flow allows the operator to modify the operation of the various simulation functions,injecting errors and manually changing states.

TISB And ADSB This flow contains the TIS-B and ADS-B information for the simulated traffic to bebroadcast via the simulated MEDUP.

Traffic Trajectories This flow contains the traffic simulation controls entered via the Traffic Window and thestatus of the traffic simulation for display on the Traffic Window.


55

11 Precision Approach Platform Description

11.1 Introduction The precision approach platform consists of 2 elements, SBAS and GBAS. SBAS consists of 3 segments, ground, space and air, whilst GBAS has 2 segments, ground and air. This section describes the ground aspects. Airborne aspects are covered D34.

11.2 SBAS The Space-Based Augmentation System (SBAS) makes use of a network of monitoring stations distributed across a region. These stations monitor the GNSS error components, notably the ionospheric distortion. They are connected to a central processing facility by high performance ground communications, where the errors associated with each SV are calculated, along with integrity information. This information is then uplinked to a Geo-stationary communication SV (or multiple Geo-Stationary SVs), which rebroadcasts it to all users within the SV footprint. Use of geostationary SVs for this rebroadcast provides users with enhanced navigation performance throughout an entire region. Integrity information the user of the level of service available, which can be used to judge whether the intended operation can be performed. Such a technique can provide a near Cat1 approach capability over a core area (i.e. it provides vertical guidance in addition to horizontal). It can also provide an APV-1/NPA precision approach and en-route navigation for civil aviation throughout the entire region (i.e. throughout the footprint of the geostationary satellite(s) used to broadcast the corrections and integrity data). An SBAS will operate continuously. The European Geostationary Navigation Overlay Service, EGNOS, is being produced as Europe’s contribution to the GNSS-1 SBAS concept. The US contribution is entitled the Wide Area Augmentation System (WAAS) and the Japanese contribution is MSAS based on MTSAT SV. EGNOS provides a fully SARPs compliant service comprising wide area differential and ionospheric corrections, integrity data and multiple ranging signals. Suitably equipped users utilising the GPS and GLONASS constellations for navigation will be able to utilise the EGNOS service to enhance their levels of accuracy, availability, integrity and continuity of service such that they are capable of supporting demanding safety critical aviation applications of GNSS.


56

Figure 20. Footprints of Proposed Geo-stationary Satellites

-30 -20 -10 0 10 20 30 40 5025

30

35

40

45

50

55

60

65

70

75

Figure 21: EGNOS Service Area for performance from RNP0.3 to RNP0.02/40 (includes the Canary Islands)

AOR-W POR

Artemis

MSAS

AOR-E IOR

Geostationary Broadcast Areas


57

The EGNOS system space segment will be composed of three navigation payloads mounted on Geostationary satellites: the Inmarsat F3 Atlantic Ocean Region East (AOR-E) and Indian Ocean Region (IOR) satellites together with the ESA Artemis satellite. The EGNOS ground system is composed of 4 Master Control Centres (MCCs) located in the UK, Spain, Germany and Italy. The MCCs are responsible for processing received RIMS data to establish if satellites are healthy/unhealthy as well as generating the navigation message for broadcast to the users. Ranging and Integrity Monitoring Stations (RIMS) are located throughout the European region. The RIMS collate data on the GPS, GLONASS and Geostationary satellites observable to users within the core European Civil Aviation Conference (ECAC) region, and transmit that data to the MCCs. Six Navigation Land Earth Stations (NLES) are used to uplink the EGNOS data messages and ranging signals to the geostationary satellites, which subsequently broadcast the data to users within the EGNOS service area. All of the EGNOS assets are connected via the EGNOS Wide Area Network (EWAN), a high bandwidth communication network. In addition to the core EGNOS operational system there is also a support segment consisting of the Performance Analysis and Check Facility, the PACF, based in Toulouse, France. The PACF undertakes system performance analysis, maintenance planning, anomaly investigation and real time testing. EGNOS is being developed to provide a level of performance analogous to Category I precision approach throughout the land masses of the ECAC member states (see figure 1). Furthermore, the entire ECAC area is provided with a level of performance capable of supporting operations from RNP20 through to RNP0.3 (see figure 2).

-40 -30 -20 -10 0 10 20 30 4020

30

40

50

60

70

Figure 22: EGNOS Service Area for performance from RNP20 to RNP0.3


58

11.2.1 EGNOS System Test Bed (ESTB) The ESTB is a real-time prototype of EGNOS, and it has been radiating a signal at notified hours of operation since January 2000. The ESTB has been developed with a set of objectives including: • The support to EGNOS design; • The demonstration of the capabilities of the system to users: the ESTB constitutes a strategic tool

for the European TriPartite Group (ETG). • Analysis of future EGNOS upgrades. The ESTB is guaranteed to provide a signal until the EGNOS Operational Readiness Review in late 2003, after which it will be replaced by the EGNOS signal. There are plans for the ESTB to continue beyond this date to allow testing for EGNOS expansion. Recent improvements to the ionospheric computation mean that, using GPS and the ESTB signal-in-space, users within Europe can currently determine position to within 3 metres horizontal, and 5 metres vertical, 95 percent of the time. The ESTB is also currently able to meet the integrity requirements for precision approach for some of the time. This is despite the reduced number of reference stations in the ESTB compared with EGNOS, and the current high solar activity.

Figure 23. EGNOS System Test Bed - Infrastructure Assets

Scilly Isles (GB)

Hönefoss (N)

Tromsö (N)

Cadiz (E)

Rotterdam (NL)

Höfn (Iceland)

Toulouse (F)

Ankara (T)

EURIDIS RS

Seatex RS

MTB RS

Processing Facility

NLES

Hartebeeshoek(South Africa)

Kourou(French Guyana)

Fucino (I)Matera (I)


59

11.3 GBAS The GBAS ground system is fixed ground station broadcasting the GBAS VHF Data Broadcast (VDB). It has been purchased from a third party as a unit meeting the latest standards, in order to provide a representative GBAS signal for airborne equipment. GBAS consists of a ground sub-system and an aircraft sub-system. The GBAS ground sub-system generates corrections, and then provides approach data, corrections and integrity information for the GNSS (currently GPS only – no GLONASS) ranging signals over a digital VHF data broadcast (VDB) to all of the aircraft sub-systems within its coverage on the selected frequency. Approach procedures are also contained in the same VHF Data Broadcast. The VDB contains a number of message types, only a small number of which are currently specified. It is expected that one GBAS can support more than one approach at a proposed airfield, and even approaches to other airfields in the area. The data broadcast standard for GBAS uses the VHF navigation band, and the specified data link physical layer is based on D8PSK. The minimum service area for GBAS is identical to ILS, i.e. 20 NM from the runway threshold up to FL 100. The GBAS VHF data broadcast transmits with either horizontal or elliptical polarization (GBAS/H or GBAS/E) in order to maintain compatibility with old VHF aircraft antennas. GBAS shares the frequency band with VOR, and must be FM immune. Thus the SARPS give guidance on the siting and frequency allocation requirements to avoid interference with VOR and other GBAS stations. Similar guidance to avoid interference with ILS is being developed. A ground continuity and integrity designator (GCID) is used to provide a classification of GBAS ground sub-systems. This classification will support multiple levels of service. The ground system meets the requirements of Category I precision approach when GCID is set to 1. GCID 2, 3 and 4 are intended to support future operations with requirements that are more stringent than Category I operations. The GCID is intended to be an indication of ground system status to be used when an aircraft selects an approach. It is not intended to replace or supplement an instantaneous integrity indication. The objective of the Satellite Quality Monitoring (SQM) is to detect satellite signal anomalies in order to prevent aircraft receivers from using misleading information (MI). The MI is an undetected aircraft pseudorange differential error, greater than the maximum ERRor (MERR) that can be tolerated. These large pseudorange errors are due to C/A code correlation peak distortion caused by satellite payload failures. If the reference receiver used to create the differential corrections and the aircraft receiver have different measurement mechanizations (receiver bandwidth and tracking loop correlator spacing), the signal distortion affects them differently. The SQM must protect the aircraft receiver in the cases when mechanizations are not similar. SQM performance is further defined by a probability of detecting a satellite failure and a probability of incorrect annunciation of a satellite failure. The Raytheon prototype GBAS station is compliant with ICAO GBAS SARPs (1999). It broadcasts message types 1 and 4. The installation has been classified as having a Ground Accuracy Designator A, but in fact the performance is better due to low multipath environment.

The ground station makes use of two GPS receivers, one manufactured by Canadian Marconi Company (CMC) and the other by Ashtech. These special GPS receivers have both wide and narrow correlations. The VDB is provided by a 10 Watt EIRP VHF data link on 116.9 MHz.


60

The system has a typical Navigation System Error (95%) of: • 1m Vertical. • 50cm Horizontal. Fig. 3a and 3b give the GBAS Approach Coverage Region, Plan/Profile View. The GBAS SARPs now in fact recommend that the coverage is omni-directional, and thus not confined to this plan/profile, which was based on ILS coverage.

Figure 24: GBAS Ground Antenna

Figure 25: GBAS Ground Station


61

+/- 450 ft

RDP Final Approach Path

15 nmi

+/- 35 degrees

+/- 10 degrees

20 nmi

Plan View

GPIP

greater of 7 deg or 1.75θ

0.45θ

θ: glidepath angle

Profile View

10,000 ft

Figure 26: Approach Coverage Region, Plan View

Figure 27: Approach Coverage Region, Profile iew


62

11.4 Functions The prime function of both SBAS and GBAS is to provide high performance navigation. Other than providing the correction signal, neither the SBAS ground infrastructure nor the GBAS ground station have any interface to any other MA-AFAS systems.


63

12 DLR SMGCS platform on Braunschweig Airport

12.1 System description The SMGCS infrastructure on Braunschweig Airport is based on a high-speed data network consisting of optical-fibre cable. That network connects the peripheral stations around the airfield to a master station. Different sensor subsystems or part of these are installed in the peripheral stations. The data network installed at Braunschweig Airport is an FDDI-Net (Fibre Distributed Data Interface). The connection to this network normally takes place with FDDI-boards installed in the computer. If computers with Ethernet-connections have to be connected to the network, suitable switches can be integrated. The data fusion and the situation analysis are software processes within the master station. The situation information derived can be handed over to planning tools and to the cockpit and tower simulators also available in the DLR Institute of Flight Guidance. Our existing software for a sensor data fusion can process data from the most varied sensor systems. In this case the only condition is that a certain standardisation of data acquisition and data transmission will be maintained. At this time the experimental multi sensor system is composed of four types of sensors, a database to store a priori knowledge and the data fusion:

Near range Radar Network (NRN): A non-interactive sensor system based on primary radar technology. Instead of observing the airport with one mechanical rotating antenna from the roof of the tower the NRN uses modules of four small radar stations observing the area enclosed.

Global Positioning and Communication system (GP&C): A local area DGPS system with integrated communication capability via a VHF data link.

Aircraft Registration Mark Identification (ARMI): A TV camera is staring focused on a section of a taxiway. Each video image is scanned for letters. Letters found are composed into words using relative plausibility rules concerning. Finally potential registrations are compared with a dictionary of expected aircraft

SSR Multilateration System: This interactive sensor system detects all SSR transponder equipped traffic objects taxiing on the airport or flying in the neighbourhood of the airport.

The SSR system installed in Braunschweig is called ASCS (Airport Surface Control System). Principle of operation: The multilateration sensor provides position and identification data of the transponder-equipped aircraft and surface vehicles by way of multilateration process of received signals, transmitted by the transponders. Multilateration is the process of determination of the target location in two (of three) dimensions by solving the mathematical intersection of multiple hyperbolas. It is based on the TDOA principle, the Time Difference Of Arrival between the "arrivals" of one transponder's signal received at several sensor stations.

DBMS: the database stores information on traffic objects and the airport. It contains e.g. possible identities, performance parameters of aircraft, the topography and topology of the airport network of taxiways and runways.

Sensor data fusion (SDF): It fuses the partial situation descriptions of the sensor systems to a global situation representation. From the perspective of the traffic situation clients (e.g. controller & pilot HMIs, planning & guidance systems) the data fusion encapsulates the individual sensors. The clients can consider the output of the data fusion as the output of one super-sensor.

Controller Machine Interface (HMI): An HMI programmed by the DLR will support the controller during all tasks of taxi guidance and monitoring.


64

12.2 System architecture The following figure (Figure 1) shows all components of the A-SMGCS in Braunschweig with the necessary expansions to satisfy the MA-AFAS requirement. The GP&C boxes represent two different functions of the same unit. The marked one (green) is the onboard counterpart. In the MA-AFAS framework the GP&C will be replaced by VDL-4 equipment.

Figure 1: A-SMGCS components and data flow in Braunschweig All components are connected by means of TCP/IP, serially or over ARINC. The SDF generates a picture of the traffic situation and distributes the data and can also provide the data in ASTERIX Cat10 format. The GP&C data link can be handled via the data link console software. The GP&C box on the ground sends traffic information via a serial interface to a second GP&C box on board. Additionally a connection with the pilot controller HMI must be created, in order to exchange clearances and actions of the pilots. A manual input is required if no FDPS is available.

GP&CADS-B

ARMI

ASCS

FDPS

Sensors

SDF

DBMS

NRNHMI

GP&CSTDMA-Data link

GP&CSTDMA-Data link

HMI

ASTERIXCAT10

Data Fusion Controller Display and Datalink

Pilot Display and Datalink

not constantly available

Data link console


65

13 SMGCS Implementation of MA-AFAS related functions The following basic SMGCS functions are relevant to MA-AFAS:

Surveillance Planning Guidance Control

The surveillance function provides accurate position information and identification for actual targets within the airport movement area. The A-SMGCS surveillance functionality is based on a multisensor concept with sensor data fusion. The planning function provides advisory information to the controller with the purpose of ensuring efficient and optimal aerodrome operations. Planning functionality will not be provided for MA-AFAS by the system described. The guidance function assists pilots of aircraft and drivers of controlled vehicles to manoeuvre safely and efficiently on the movement area. The A-SMGCS provides navigation and taxi route information via cockpit display and data link. The control function comprises the measures which are necessary to provide a safe and efficient taxi management. The essential sub-functions are the delivery of clearances and taxi instructions. The A-SMGCS system supports the delivery of clearances via data link. We use the SDF-, TIS-B- and CPDLC-functions to realize the listed functions. Surveillance is completely available and Control is under development. We are still working on the functions Planning and Guidance. The following list shows other available SMGCS functions especially for the test phase.

Function Remarks

9. Experiment Control The experiment can be monitored and controlled via control monitor.

10. Data Recording All traffic information can be recorded and analyzed.

11. Offline Operation The recorded data can be replayed so that the same test scenario for clients could rerun.


66

13.1 Requirements Surveillance

SMG_SUR_001 All targets in runway and taxiway areas shall be tracked. Position, speed, heading, identity and time tag for each object shall be provided and recorded.

SMG_SUR_002 Traffic data acquisition shall comprise the following features: continues object detection, localisation, classification, identification, intention (future actions of object).

SMG_SUR_003 The system should support operations of aircraft and vehicles within the following parameters:

• minimum and maximum speeds for aircraft on final approach, missed approach and runways

• minimum and maximum speeds for aircraft on taxiways

• minimum and maximum speeds for vehicles; and any heading

SMG_SUR_004 For the surveillance function, the allowable error in reported position should be consistent with the requirements set by the guidance and control functions, as appropriate.

SMG_SUR_005 Surveillance sensors shall fulfil the following criteria:

update rate 1 / s,

delay < 1 s for raw data

accuracy better 10m

SMG_SUR_006 For the overall position determination provided by the SDF the following requirements shall apply:

Position accuracy: 5 m

Velocity accuracy: 0.5 m/s

Heading accuracy: 5 °

Update rate minimum: 1/sec

Reported Position Update Rate: 1 / second

Time stamp resolution: 0.1 second

SMG_SUR_007 Probability of Identification: goal: 99 %

SMG_SUR_008 Probability of Detection: goal: 99 %

Planning

SMG_PLA_001 Planning functionality will not be provided for MA-AFAS by the system described.

Guidance

SMG_GUI_001 The guidance function shall assist pilots of aircraft and drivers of controlled vehicles to manoeuvre safely and efficiently on the movement area.

SMG_GUI_002 The guidance function shall be provided within the whole ground movement area and for


67

all possible taxi routes.

SMG_GUI_003 Surface guidance shall be based on an airport map display provided to the pilot showing the actual position of the aircraft and the taxi route intended.

SMG_GUI_004 Latency time for provision of guidance information: 2.0 s

SMG_GUI_005 Probability of correctness of guidance information: 98 %

SMG_GUI_006 The guidance functionality shall be available in a continuous, unambiguous, and reliable way.

Control

SMG_CTL_001 The control function of an A-SMGCS shall keep controllers, pilots and vehicle drivers in the decision loop. This implies that an A-SMGCS shall be an advisory system. The advisories may be accepted or rejected by the operators and users.

SMG_CTL_002 The control function of an A-SMGCS shall have a capacity sufficient for an adequate traffic rate during the trials.

SMG_CTL_003 The A-SMGCS system shall support the delivery of clearances via data link for all aircraft and controlled vehicles and all phases of ground movement.


68

14 Data dictionary

NRN data output to SDF NRN position reports contain the 2D position as surveyed by the NRN and a time stamp derived from a GPS clock. Position reports are provided via TCP / SSIC (SMGCS structured information content = DLR proprietary protocol) or UDP / ASTERIX CAT 10 protocol. Item Notes Message type Integer number Source Data Source Descriptor Time stamp Time of Day x Position in Cartesian Co-ordinates [m from ARP] y Position in Cartesian Co-ordinates [m from ARP] Velocity Speed vector [m/s, °] Track Number Integer number Track status Integer number for " Confirmed track, not coasted, slant range corrected,

measured position (not smoothed)" Standard Deviation of Position

σx, σy, σxy

Table 1. NRN position report

ASCS data output to SDF ASCS position reports contain the 2D position as surveyed by the ASCS and a time stamp derived from a GPS clock. Position reports are provided via UDP / ASTERIX CAT 10 protocol. Item Notes Message type Integer number Source Data Source Descriptor Time stamp Time of Day x Position in Cartesian Co-ordinates [m from ARP] y Position in Cartesian Co-ordinates [m from ARP] Velocity Speed vector [m/s, °] Track Number Integer number Mode 3/A Code Octal Representation Aircraft Address 24 bit ICAO address (Mode S address) Target Identification Callsign down-linked, e.g. LH3310 Track status Integer number for " Confirmed track, not coasted, tracking in sensor plane,

measured position (not smoothed)" Flight Level [ft] Measured Height [ft] Standard Deviation of Position

σx, σy, σxy

Table 2. ASCS position report

GP&C ADS-B data output to SDF


69

GP&C position reports contain the 3D position and the time stamp extracted from the ADS-B reports transmitted by the aircraft. Position reports are provided via:

TCP / GP&C typical NMEA-like hex ASCII-format TCP / SSIC format UDP / ASTERIX CAT 10 protocol

Item Notes Message type Integer number (2, 3) Source Data Source Decriptor (2, 3) latitude WGS 84 (1) longitude WGS 84 (1) altitude Geoid, [ft] (1) speed [nm/h] (1) x Position in Cartesian Co-ordinates [m from ARP] (2, 3) y Position in Cartesian Co-ordinates [m from ARP] (2, 3) Velocity Speed vector [m/s, °] Time stamp UTC seconds from 1970 (2),Time of Day (3) Target Identification Registration down-linked, e.g. D-CODE

Table 3. GP&C ADS-B report

ARMI data output to SDF The ARMI target detection reports contain the registration mark and the 2D position of the aircraft as detected when an aircraft passes the ARMI camera. A time stamp is added, derived from a central time server. Target reports are provided via TCP / SSIC protocol and UDP / ASTERIX CAT 10 protocol. Item Notes Message type Integer number Source Data Source Descriptor x Fixed Position in Cartesian Co-ordinates [m from ARP] y Fixed Position in Cartesian Co-ordinates [m from ARP] Time stamp UTC seconds from 1970 (2),Time of Day (3) Target Identification Registration mark (tail number) detected, e.g. D-CODE

Table 4. ARMI target report

DBMS data FDPS data output to DBMS: - Flight schedule data in diverse airport specific protocols. There is no flight schedule data available from the Braunschweig Airport. Flight plans must be entered manually or provided by a flight plan simulator. Output from DBMS to SDF and other clients: - flight schedule data - aircraft data available


70

- topology data Aircraft data and topology data are intended for internal use by the SDF only. A further description of the respective internal interface would exceed the scope of this document. The following flight schedule data will be provided for interfacing to diverse other customer applications. The basic transmission unit is the Data Frame for one flight plan. All flight plans will be transmitted in single packets in a burst. For synchronisation, a stop frame will be sent as the last frame in every cycle. The burst- / update rate will be configurable at start-up time, so it can be adapted on the amount of data and the rate needed by clients. The Data Frame contains only ASCII-formatted data. All data items are of variable length, each separated by a single <tab> character. Data that is not available is represented by the characters ‘NA’. Each Data Frame will be terminated by a <LF> character (‘\n’) and a binary zero (‘\0’). The sync frame is a flight plan data frame with all data set to ASCII zeroes (‘0’). Item Notes FLIGHT_PLAN_ID Consecutive ID no. of the FP Data Frame FLIGHT_NO_IATA Flight number from IATA Convention FLIGHT_NO_ICAO Flight number from ICAO Convention REG_MARK Registration Mark (Tail Number) WAKE_VORTEX_ CODE

Wake Turbulence Category (L, M or H)

AIRCRAFT_TYPE Type of Aircraft DEPARTURE_ AIRPORT

Departure Airport

ARRIVAL_AIRPORT Arrival Airport EST_ARR_ TIME Estimated Arrival Time, string in form HHMM EST_ DEP_TIME Estimated Departure Time, in form HHMM SLOT_BEGIN_TIME Start of slot, in the form HHMM SLOT_END_TIME End of slot, in the form HHMM RUNWAY Planned Runway SID_STAR SID/STAR Identifier GATE Planned Gate

Table 5. DBMS data

SDF data output to HMI The SDF traffic object reports contain the position, identity and object features as computed by SDF, based on the input from the diverse sensors and the data base. A time stamp is added, derived from a central time server. Traffic object reports are provided via TCP / SSIC (SMGCS structured information content = DLR proprietary protocol) or UDP / ASTERIX CAT 10 protocol.


71

Item Notes Message type Integer number Source Data Source Descriptor x Position in Cartesian Co-ordinates [m from ARP] y Position in Cartesian Co-ordinates [m from ARP] Velocity Speed vector [m/s, °] Calculated Acceleration x, y [m/s2] Time stamp UTC seconds from 1970 or Time of Day Mode 3/A Code Octal Representation Aircraft Address 24 bit ICAO address (Mode S address) Standard Deviation of Position

σx, σy, σxy

Target Identification Registration down-linked, e.g. D-CODE Track Number Integer number Track status Integer number for "confirmed, extrapolation, other movement, no doubt"

Table 6. SDF traffic object report

Ground data link console via STDMA data link to pilot display The access to the STDMA data link system is provided via a TCP server. The ground data link console connects as a client to the server and transmits clearances to onboard, receives clearance acknowledgements and clearance requests from onboard. The message format is the GP&C specific NMEA-like hex ASCII-format. Item Notes Message format Transmit command / received message Destination or source Transponder address Message header Message type, subtype, time stamp, source and destination application

address, message descriptor, message ID (integer numbers) Message pay load Message text (6 bit character set: Space = 20H to _ = 5FH)

Readable taxi clearances and instructions, e.g. DEICE, START_UP, PUSH_BACK, TAXI_A_F//HOLD_RWY26.

Table 7. Data link console output


72

15 AOC Ground Platform Description

15.1 System Architecture The AOC Ground Platform is a trials system which simulates the functions of an Airline Operational Centre (AOC) end system. The AOC Ground Platform is used to support trials of the MA-AFAS avionics package AOC functions. The AOC Ground Platform provides representative displays, which are used by the trials AOC system operator to interact with the MA-AFAS fitted aircraft. The AOC Ground Platform is supported by a fleet simulator, in order to increase the fidelity of the simulation. The fleet simulator also allows more complex AOC trials to be conducted than is possible with the limited number of MA-AFAS avionics packages. The AOC Ground Platform also simulates other ground systems which interface to the AOC ground system, such as the Central Flow Management Unit and weather data providers. The AOC Ground Platform is based on a single PC running the Windows NT Version 4 operating system, with a large (nominally 21”) display. The AOC functional processes are also capable of being hosted on the BAE SYSTEMS In-House Test Platform. The architecture is illustrated in the figure below.

AOC Ground System

FleetSimulator

Othersimulators

AGP

Avionics Package

CommunicationsBearer

Figure 28. AOC Ground Platform Block Diagram


73

15.2 Functions ATN Comms Provides ATN stack for communication via real or simulated VDL4 links. GACS The Generic ATN Communications Service (GACS) is an ATN application providing a generalised reliable end-to-end delivery service. The AOC messages are transported over the GACS services. AOC Flight Plan Provides general flight planning functions, including generation of company flight plans, flight plan filing and uplink, pre-flight support, and weather data exchange. AOC Maintenance Provides the means for AOC to gather information in-flight on the status of on-board systems, in the form of snag reports (failures) and diagnostic data. Collaborative Decision Making (CDM) The term CDM refers to a set of applications whereby the stakeholders involved in the decision-making process (ATC, airlines, airports, CFMU, etc) share information so that the decisions taken can be optimised to the benefit of all stakeholders. The AOC Ground Platform supports the In-Flight Traffic Management and Arrival Slot Swapping CDM applications. AOC Asset Management Provides the means for AOC to monitor the progress of flights, allows free text communications between AOC and the flight crew, and allows exchange of trajectory constraint information. AOC Operator HMI Provides the means for an operator to interact with the AOC Ground Platform.


74

15.3 AOC Ground Platform Context The context diagram for the AOC Ground Platform is shown below. This presents a logical view of the interfaces between the AOC system and external entities.

0AocGroundPlatform*

Operator*

CFMU*

AtcCentres* AIS*

AirportAuthorities*

WeatherOffice*

AirGroundCommunications*

pointToPointMessage*

airportAuthoritiesInformationTBD*

AmdarMessages*

METAR*SIGMET*

TAF*

gribInformation*

flightPlan*

filedFlightPlan*

atnMessage*

flightPlan* NOTAM*

maintenanceInputs*opertorInputs*

displayData*maintenanceData*

changeMessage*

slotAllocation*

Figure 29. AOC Ground Platform context diagram


75

16 AOC Ground Platform implementation of MA-AFAS related functions

This section provides the requirements for each of the platform functions (or group of functions) that is relevant to support the MA-AFAS services and trials.

16.1 Communications These functions will support the exchange of AOC messages to all external entities depicted in the AOC Ground Platform context diagram.

16.1.1 Air-Ground Communications The A/G Communications function will support the exchange of AOC messages through an AOC/aircraft datalink connection (GACS) over VDL-Mode4. REQUIREMENT CODE

DESCRIPTION

AGP_COM_001 The AOC Ground Platform shall use the Generic ATN Communication Service (GACS) application defined in ref [19] to support end-to-end air-ground communications.

AGP_COM_002 The AOC Ground Platform shall be capable of sending/receiving ATN messages through a VDLM4 air/ground data-link.

AGP_COM_003 The AOC Ground Platform shall provide a communication service to support the registration of a flight for datalink.

AGP_COM_004 The AOC Ground Platform shall provide a communication service to handle the non-receipt of confirmation for uplink messages sent using the GACS confirmed service.

AGP_COM_006 The AOC Ground Platform shall provide a suitable warning to the operator if confirmation of transmission of a GACS confirmed message has not been received.

16.1.1.1 AOC Flight Plan Communications REQUIREMENT CODE

DESCRIPTION

AGP_COM_011 The AOC Ground Platform shall provide a communication service to support the exchange of Meteorological data with a given aircraft.

AGP_COM_013 The AOC Ground Platform shall provide a communication service to support the exchange of flight support data with a given aircraft.

AGP_COM_015 The AOC Ground Platform shall provide a suitable warning to the operator if confirmation of the Slot Allocation has not been received by a pre-determined time before the Estimated Off Block Time.

AGP_COM_019 The AOC Ground Platform shall provide a suitable warning to the operator if confirmation of the Company Flight Plan has not been received a pre-determined time before the Estimated Off Block Time.


76

16.1.1.2 AOC Maintenance Communications REQUIREMENT CODE

DESCRIPTION

AGP_COM_021 The AOC Ground Platform shall provide a communication service to support the exchange of Aircraft Systems Information.

16.1.1.3 AOC Collaborative Decision Making Communications REQUIREMENT CODE

DESCRIPTION

AGP_COM_031 The AOC Ground Platform shall provide a communication service to support the exchange IFTM data with a given aircraft.

Post MA-AFAS AGP_COM_032

The AOC Ground Platform shall provide a communication service to support the exchange of Arrival Slot Swapping data with a given aircraft

16.1.1.4 AOC Asset Management Communications REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall provide a communication service supporting the uplink of Aeronautical and Airport Operational Information (NOTAMs) data to a given aircraft.

AGP_COM_042 The AOC Ground Platform shall provide a communication service supporting the exchange of flight progress information with a given aircraft.

AGP_COM_043 The AOC Ground Platform shall provide a communication service supporting the exchange of free text messages with a given aircraft.

AGP_COM_044

The AOC Ground Platform shall provide a communication service supporting the downlink of OOOI messages from a given aircraft.

AGP_COM_045 The AOC Ground Platform shall provide a communication service supporting the exchange of 4D trajectory data with a given aircraft.

16.1.2 Communications to CFMU The Central Flow Management Unit implements Air Traffic Flow Management for the European area. As a subsidiary function, it also provides a centralised point for the reception and dissemination of flight plans. It is a requirement for airlines operating within the European area to submit flight plans to the Integrated Initial Flight Plan Processing System (IFPS). The CFMU’s systems then determine if the submitted plans result in a demand which exceeds airspace capacity; if so, then the system adjusts the demand by applying delays to certain flights. These adjustments are communicated to the ATSUs involved, and also to the flight plan filing authority (usually the A/O).


77

REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall support communications with the CFMU IFPS system according to Issue 7.0 of the IFPS Users Manual [Ref IF1].


The AOC Ground Platform shall support communications with the CFMU ATFM systems according to Issue 7.0 of the ATFM Users Manual [Ref AT1].

16.1.3 Communications to Meteo Office REQUIREMENT CODE

DESCRIPTION

AGP_COM_070 The AOC Ground Platform shall provide a communication service to support the transmission of aircraft meteo observations in AMDAR format to an external provider. Note: For MA-AFAS this communication will be simulated.

AGP_COM_080 The AOC Ground Platform shall be able to receive TAFs, METARs and SIGMETs from an external provider. Note: For MA-AFAS this communication will be simulated.

AGP_COM_090 The AOC Ground Platform shall be able to receive meteo forecast reports from an external provider. Note: For MA-AFAS this communication will be simulated.

16.1.4 Communications to Airport Authorities Communications between AOC and airport authorities concentrate on the information required by both parties to optimise the allocation of resources. REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall support communications with Airport Authorities in [TBD] format.

16.1.5 Communications to ATC Centres REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall be able to negotiate initial and revised 4D Flight Plans with the ATC centre taking into account airspace status and available routes.

16.1.6 AIS Communications REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall be able to receive NOTAMs from an external provider.


78

3groundGroundCommunications*

2commsServer*

1airGroundCommunications*

commsLog*

atnMessage*

pointToPointMessage*meteorologicalData*flightSupportData*

aircraftSystemsInformation*

notam*freetextDownlink*

oooiMessage*

cfmuInformation*

amdarMessage*

meteoReport*

gribInformation*


notam*

flightPlan*

groundGroundMessages*

airGroundMessages*

freetextUplink*

trajectoryData*

Figure 30. AOC Ground Platform Communications DFD

16.2 AOC Flight Plan The AOC Flight Plan function is a complex process including payload determination, alternate airport determination, route selection, speed/profile calculations, flight time estimation, en-route alternate selection, fuel requirements, aircraft minimum equipment verification, flight plan co-ordination with the pilot, flight plan filing with the ATS provider and other tasks. The flight planning function uses different kinds of information such as meteo data, maintenance data and requirements, crew schedule, take-off power settings, aircraft data, airport/station data, navigation data, marketing data and flight schedule data. Some of this information (such as Take-off performance calculation and Weight & Balance calculation) may be prepared by dedicated support systems.

16.2.1 Company Flight Planning A key function of the AOC Ground Platform is the ability to generate company flight plans pre-departure, and file the plans with ATC. During the duration of the flight, ATC actions may alter the plan, and these changes need to be tracked. REQUIREMENT CODE

DESCRIPTION

AGP_FPL_010 The AOC Ground Platform shall enable an aircraft to be assigned to a flight.

AGP_FPL_015 The AOC Ground Platform shall generate a suitable alert if an aircraft cannot be assigned to a flight based on the initialising message received.


79

AGP_ FPL _020 The AOC Ground Platform shall be able to generate initial 4D trajectories from pre-defined routes based on city pairs. Note: For MA-AFAS a route generation tool will be used to generate suitable routes between airfields.”

Post MA-AFAS AGP_ FPL _030

The AOC Ground Platform shall be able to generate initial 4D trajectories from routes specified by the AOC Ground Platform operator.


The AOC Ground Platform shall produce 4D trajectories using the methods specified in Airborne Systems Requirement Specification for More Autonomous – Aircraft in the Future Air Traffic Management System Data Deliverable 18 [REF D18].

AGP_ FPL _050

The AOC Ground Platform shall send a Filed Flight Plan message to CFMU at the later of the time of generation of the initial 4D trajectory and a configurable time before the estimated time of departure of the flight. Note: For MA-AFAS all the pre-defined flight-plans will be filed with a simulated CFMU at system start-up.


The AOC Ground Platform shall provide a suitable warning to the operator if the Company Flight Plan has not been sent to the CFMU by a pre-determined time before the Estimated Off Block Time.


On a pre-departure change to a company flight plan which has previously been filed with CFMU (other than a change due to a departure slot allocation), the AOC Ground Platform shall send a Change message to CFMU, to communicate details of the change.

AGP_ FPL _090 The AOC Ground Platform shall use 4D Position data, Next Reporting Point, ETA and Fuel Information received from aircraft to track changes to the company flight plan during the flight.


The AOC Ground Platform shall consider precision approach/departure procedures in the flight planning process.


80

16.2.2 Pre-Flight Support A significant potential use of datalink for airline operations is to provide pre-departure information to the aircraft. REQUIREMENT CODE

DESCRIPTION

AGP_ FPL _110 The AOC Ground Platform shall uplink a Company Flight Plan to an aircraft at the later of the flight registering with the AOC Ground Platform for datalink communications and the generation of the initial 4D trajectory.


On a pre-departure change to a company flight plan which has previously been filed with CFMU (other than a change due to a departure slot allocation), the AOC Ground Platform shall send a revised Company Flight Plan to the affected aircraft.

AGP_ FPL _130 On receipt of a departure Slot Allocation message from CFMU for a flight which has registered with the AOC Ground Platform for datalink, the AOC Ground Platform shall transmit the Slot Allocation to the affected aircraft.

AGP_ FPL _140 On receipt of a departure Slot Allocation message from CFMU, the AOC Ground Platform shall update the company flight plan of the affected flight.


The AOC Ground Platform shall be able to negotiate departure slot improvements with CFMU.


The AOC Ground Platform shall be able to respond to CFMU proposals for departure slot improvements.

AGP_ FPL _170 The AOC Ground Platform shall be able to record Pax/Baggage information.

AGP_ FPL _180 The AOC Ground Platform shall be able to record Fuel information.

AGP_ FPL _190 The AOC Ground Platform shall be able to generate and uplink a Loadsheet message to a specified aircraft.

AGP_ FPL _200 The AOC Ground Platform shall provide a suitable warning to the operator if the Loadsheet has not been sent by a pre-determined time before the Estimated Off Block Time.

AGP_ FPL _210 The AOC Ground Platform shall provide a suitable warning to the operator if confirmation of the Load sheet has not been received by a pre-determined time before the Estimated Off Block Time.


The AOC Ground Platform shall calculate and transmit Takeoff Settings to a specified aircraft at the latest of specified time before ETD, availability of all Takeoff Settings information or flight registration for datalink.

AGP_ FPL _230 The AOC Ground Platform shall provide a suitable warning to the operator if a flight has not registered for datalink by a pre-determined time before its Estimated Off Block Time.

16.2.3 Weather Information In order to support a more accurate and up-to-date aircraft weather database the AOC must be capable to transmit from the ground a variety of weather data that will be used by the pilot and the aircraft Flight Management System (FMS).


81

16.2.3.1 FMS Meteo This function provides to the aircraft FMS the necessary meteorological information in GRIB format [TBC], for the generation of 4D trajectories, through an AOC/aircraft datalink connection. REQUIREMENT CODE

DESCRIPTION

AGP_ FPL _240 The AOC Ground Platform shall be able to store received meteo forecast reports enabling the AOC Ground Platform to provide them, at a later time, to aircraft.

AGP_ FPL _250 The AOC Ground Platform shall, when a flight registers for datalink communication, automatically associate meteo forecast reports with that flight, and transmit them to the flight as FMS Meteo messages.

16.2.3.2 Meteo Reports This Meteo Reports function must provide to a pilot all pertinent meteorological information, which includes TAF, METAR, SIGMET, though an AOC/aircraft datalink connection. REQUIREMENT CODE

DESCRIPTION

AGP_ FPL _260 The AOC Ground Platform shall be able to store meteo reports.

AGP_ FPL _270 The AOC Ground Platform shall be able to retrieve a meteo report requested by a given aircraft.

AGP_ FPL _280 The AOC Ground Platform shall encode requested meteo reports on a format suitable for transmission through the datalink.

AGP_ FPL _290 On receipt of a Meteo report request from an aircraft which has registered with the AOC Ground Platform for datalink, the AOC Ground Platform shall transmit the requested meteo report to the aircraft.

AGP_ FPL _300 If the AOC Ground Platform is unable to send a Meteo report requested by an aircraft which has registered with the AOC Ground Platform for datalink, the AOC Ground Platform shall transmit a NOT AVAILABLE message to the aircraft.


82

3preFlightSupport*

2weather*

1companyFlightPlans*

flightPlanningInformation*

fmsMeteo*

gribInformation*flightPlan*

changeMessage*

flightInformation*

companyFlightPlan*

slotAllocation*

loadsheet*

paxBaggage*

fuelInformation*

warningMessage*

takeoffSettings*

meteoReport*

meteoReportRequest*

fmsMeteo*

flightPlanInformation*

preFlightSupportInformation*

weatherInformation*

alertMessage*

Figure 31. AOC Ground Platform Flight Planning DFD


83

16.3 AOC Maintenance The goal of Maintenance Management is to allow an AOC user to manage and to clearly identify, in a timely fashion, the maintenance needs of a company fleet. The Maintenance Management activity requires updated information of different aircraft systems.

16.3.1 SNAG Reporting SNAG Reports are event-driven downlink messages containing description of specific aircraft events (failures and technical malfunctions). This function enables the AOC operator to be aware of malfunctions reported by the aircraft. REQUIREMENT CODE

DESCRIPTION

AGP_MTC_001 The AOC Ground Platform shall be able to store all SNAG reports received from a given aircraft.

AGP_MTC_002 The AOC Ground Platform shall be able to provide to the user, information about aircraft technical malfunctions based on SNAG report data.

AGP_MTC_003 The AOC Ground Platform shall provide facilities to associate information about aircraft technical malfunctions based on SNAG reports with flight progress information.

Post MA-AFAS AGP_MTC_004

The AOC Ground Platform shall provide to the user facilities to generate a maintenance request from aircraft technical malfunctions data and flight progress information.

Post MA-AFAS AGP_MTC_005

The AOC Ground Platform shall send maintenance requests to the AOC Airline Engineering.

16.3.2 Aircraft System Information The Aircraft System Information function will provide to an AOC operator the capability to monitor aircraft ACMS related information, such as engine and APU status reports.

16.3.2.1 APU Reports APU Reports function will allow the AOC platform to have the necessary information regarding the status of the aircraft systems received by the AOC Ground Platform. REQUIREMENT CODE

DESCRIPTION

AGP_MTC_011 The AOC Ground Platform shall be able to store all received APU Reports from a given aircraft.

AGP_MTC_012 The AOC Ground Platform shall be able to provide to the user, information concerning the current status of the Aircraft APU.

AGP_MTC_013 The AOC Ground Platform shall provide facilities to associate information about Aircraft APU performance with flight progress information.

AGP_MTC_014 On operator request, the AOC Ground Platform shall send a request for an APU Report to a specified aircraft.

AGP_MTC_015 The AOC Ground Platform shall receive and process APU Report Responses from an aircraft.

AGP_MTC_016 APU Report Responses shall be either an APU Report or a NOT AVAILABLE message.

AGP_MTC_017 The AOC Ground Platform shall be able to receive APU Reports from an aircraft.

AGP_MTC_018 The AOC Ground Platform shall be able to correlate APU data provided by a registered aircraft during a flight, to allow monitoring of aircraft APU performance.


84

16.3.2.2 Engine Status Report The Engine Status Report function will allow the AOC platform to have the necessary information regarding the status of the engine passed to the AOC Ground Platform. REQUIREMENT CODE

DESCRIPTION

AGP_MTC_019 The AOC Ground Platform shall provide a suitable warning to the operator if an APU report is not received within a pre-determined time after the time a demand report was requested.

AGP_MTC_021 The AOC Ground Platform shall be able to store all received Engines Reports.

AGP_MTC_022 The AOC Ground Platform shall be able to provide to the user, information concerning the current status of the Aircraft Engines.

AGP_MTC_023 The AOC Ground Platform shall provide facilities to associate information about Aircraft Engines performance with flight progress information.

AGP_MTC_025 On operator request, the AOC Ground Platform shall send a request for an Engine Report to a specified aircraft.

AGP_MTC_026 The AOC Ground Platform shall allow the operator to specify what information is required from the aircraft Engine Report in the Engine Report Request.

AGP_MTC_027 The AOC Ground Platform shall support Periodic Requests and On-demand Requests for Engine reports.

AGP_MTC_028 The AOC Ground Platform shall receive and process Engine Report Responses from an aircraft.

AGP_MTC_029 Engine Report Responses shall either be an Engine Report or a NOT AVAILABLE message.

AGP_MTC_030 The AOC Ground Platform shall be able to receive Engine Reports from an aircraft.

AGP_MTC_031 The AOC Ground Platform shall provide a suitable warning to the operator if an Engine Report is not received within a pre-determined time after the expected time. The expected time will either be defined by the reporting interval of periodic reports or the time a demand report was requested, as appropriate.

AGP_MTC_032 The AOC Ground Platform shall be able to correlate A/C engine data provided by a registered aircraft during a flight, to allow monitoring of aircraft engines performance.

16.4 Collaborative Decision Making Collaborative Decision Making (CDM) allows various stakeholders (such as ATC, airlines, airports and CFMU) to share information so decisions can be made which benefit all stakeholders.

16.4.1 In-Flight Traffic Management The In-Flight Traffic Management process uses 4D Trajectory information to allow In-Flight Re-routing negotiations between the Aircraft and ATC. REQUIREMENT CODE

DESCRIPTION

Post MA-AFAS AGP_CDM_010

The AOC Ground Platform shall be capable of obtaining and recording the details of the CFMU Daily Operational Plan. This indicates what routes are unavailable, and indicates the declared capacity of airspace elements and aerodromes.

AGP_CDM_019 The AOC Ground platform shall be able to store all received 4D Trajectory data.

Post MA-AFAS AGP_ CDM _020

The AOC Ground Platform shall provide the facility to update the details of the CFMU Daily Operational Plan.


The AOC Ground Platform shall be capable of identifying those flights affected by changes to the CFMU Daily Operational Plan.

AGP_ CDM _040 On operator request, the AOC Ground Platform shall send a request for 4D trajectory data to a specified aircraft.


85

AGP_ CDM _017 The AOC Ground Platform shall be able to receive 4D trajectory data from an aircraft.

AGP_ CDM _050 On receiving 4D trajectory data from an aircraft, the AOC Ground Platform shall check the data for validity.

AGP_ CDM _060 On receiving 4D trajectory data from an aircraft, the AOC Ground Platform shall check the trajectory against the flight plan held for that aircraft.

AGP_ CDM _070 The received 4D trajectory data shall be suitably displayed to the operator.

AGP_ CDM _080 If the received 4D trajectory data has significant differences (a configurable difference in latitude and/or longitude) from the Flight Plan, a suitable alert shall be displayed to the operator.

AGP_ CDM _090 The AOC Ground Platform shall provide a warning to the operator if the 4D trajectory data is not received within a specified time after the request.

AGP_ CDM _100 The AOC Ground Platform shall support the generation of Delay/Divert/Re-route proposals.

AGP_ CDM _110 The AOC Ground Platform shall be able to send Delay/Divert/Re-route proposals to an aircraft.

AGP_ CDM _120 The AOC Ground Platform shall be able to receive Re-route Responses from the aircraft. The Re-route Response shall be displayed to the operator.

AGP_ CDM _130 The AOC Ground Platform shall provide a warning to the operator if the Re-route Response is not received within a specified time after the request.

AGP_ CDM _140 The AOC Ground Platform shall be able to receive Re-route Results from the aircraft. The Re-route Result shall be displayed to the operator and passed in to the Flight Planning process.

AGP_ CDM _150 The AOC Ground Platform shall provide a warning to the operator if the Re-route Result is not received within a specified time after the request.


The AOC Ground Platform shall be able to send Delay/Divert/Re-route proposals to the ATC.


The AOC Ground Platform shall be able to receive Delay/Divert/Re-route response data from the ATC.


The AOC Ground Platform shall be able to receive ETAs from the aircraft.


86

16.4.2 Slot Swapping Arrival Slot Swapping may be implemented as a future enhancement but is not part of the MA-AFAS programme. REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall support the generation of Arrival Slot Swapping Proposals.


The AOC Ground Platform shall be able to send Arrival Slot Swapping Proposals to ATC.


The AOC Ground Platform shall be able to receive and process Arrival Slot Swapping Proposals from ATC.

1manageInFlightTrafficManagement*

iftmData*

trajectoryDataRequest*

trajectoryData*

delayDivertRerouteProposal*

delayDivertRerouteResponse*

iftmData*

rerouteResult*

alertMessage*

Figure 32. AOC Ground Platform Collaborative Decision Making DFD


87

16.5 AOC Asset Management Asset Management is a crucial function which enables A/Os to fulfil their statutory duty of exercising operational control of their aircraft. Monitoring flight progress, in terms of both flight phase and progress against the flight plan, allows AOC to plan ahead effectively.

16.5.1 Aircraft Movements Out Off On In (OOOI) messages are reports automatically generated by an aircraft, which are then downlink to the airline AOC centre. The AOC centre can perform a variety of analysis with this type of reports, such as time and fuel spent on airport taxi to allow flight operations to be optimized. OOOI messages are generated at various stages of the flight and sent to the AOC Ground Platform.

• Out messages are sent when leaving gate or parking position; • Off messages are sent on takeoff when the aircraft becomes airborne; • On messages are sent on touchdown; • In messages are sent on arrival at gate or parking position.

REQUIREMENT CODE

DESCRIPTION

AGP_AMG_001 The AOC Ground Platform shall be able to keep track of an aircraft flight phase using OOOI information.

AGP_AMG_002 The AOC Ground Platform shall provide facilities to monitor aircraft performance based on OOOI information.

AGP_AMG_003 The AOC Ground Platform shall be able to store all received OOOI reports.

AGP_AMG_004 The AOC Ground Platform shall calculate the time spent by aircraft in the different phases of flight.

AGP_AMG_005 The AOC Ground Platform shall calculate the fuel used by aircraft in the different phases of flight.

16.5.2 Flight Progress The Flight Progress functions are responsible for tracking the progress of flights against their flight plans, by use of information provided by, and/or requested from, the aircraft. REQUIREMENT CODE

DESCRIPTION

AGP_AMG_010 The AOC Ground Platform shall support sending Flight Progress Requests to an aircraft on operator request.

AGP_AMG_015 On receipt of an “off” message from an aircraft, the AOC Ground Platform shall send a pre-defined (configurable) request for periodic flight progress reports to that aircraft.

AGP_ AMG_021 The AOC Ground Platform shall be able to receive Flight Progress Reports from an aircraft.

AGP_ AMG_040 The AOC Ground Platform shall allow the operator to specify what information is required from the aircraft Flight Progress Report in the Flight Progress Request.

AGP_ AMG_050 The AOC Ground Platform shall receive and process Flight Progress Responses from an aircraft. Flight Progress Responses will be either an ACK or a NACK.

REQ_OC_075

The AOC Ground Platform shall provide capability to monitor aircraft 4D flight plans by exploiting position and intent data received from the aircraft.

AGP_AMG_060 The AOC Ground Platform shall be able to calculate ETAs when a Flight Progress Report is received.

Post MA-AFAS AGP_ AMG_070

The AOC Ground Platform shall support sending ETAs to the Airport.

Post MA-AFAS New ETAs shall be sent to the destination Airport when they differ from the previous ETA by more


88

AGP_ AMG_080 than a pre-determined time.

AGP_ AMG_090 When the AOC Ground Platform receives 4D Position data it shall check it for validity and compare the data with the expected 4D Position data.

AGP_AMG_095 Significant differences (a configurable difference in latitude and/or longitude) between the received 4D Position data and the expected 4D Position data shall be reported to the operator.

AGP_AMG_015 On receipt of an “off” message from an aircraft, the AOC Ground Platform shall send a pre-defined (configurable) request for periodic flight progress reports to that aircraft.”

AGP_AMG_100 When the AOC Ground Platform receives Next Reporting Point information it shall compare it with the flight plan.

AGP_AMG_110 Significant differences (a configurable difference in latitude and/or longitude) between the Next Reporting Point information and the flight plan shall be reported to the operator.

Post MA-AFAS AGP_AMG_120

When the AOC Ground Platform receives an ETA report it shall compare it with the current ETA.


Significant differences (a configurable difference in time) between the ETA report and the current ETA shall be reported to the operator.

AGP_AMG_140 On receipt of a position report, the AOC Ground Platform shall calculate the difference between the ETA at next waypoint and the expected time.

AGP_AMG_150 Significant differences (a configurable difference in time) between the ETA at next waypoint and the expected time shall be reported to the operator.

AGP_AMG_160 When the AOC Ground Platform receives Fuel Information it shall compare it with the expected fuel information.

AGP_AMG_170 Significant differences (a configurable difference in fuel quantity) between the received Fuel Information and the expected fuel information shall be reported to the operator.

AGP_AMG_175 The AOC Ground Platform shall provide capability for the association of the flight and the AOC Flight Plan data.

AGP_AMG_180 The AOC Ground Platform shall provide a suitable warning to the operator if the Flight Progress Response is not received within a pre-determined time after the request.

AGP_AMG_190 The AOC Ground Platform shall support Periodic Requests and On-demand Requests for Flight Progress reports.

AGP_AMG_200

The AOC Ground Platform shall provide a suitable warning to the operator if a Flight Progress Report is not received within a pre-determined time after the expected time. The expected time will either be defined by the reporting interval of periodic reports or the time a demand report was requested, as appropriate.

AGP_ AMG_210 The AOC Ground Platform shall be able to receive Aircraft Met reports from the aircraft.

AGP_ AMG_220 The AOC Ground Platform shall support Periodic Requests and On-demand Requests for Aircraft Met reports.

AGP_ AMG_230 The AOC Ground Platform shall convert Aircraft Met Reports into AMDAR format Observations, and send the AMDAR format Observations to the Met Office. Note: For MA-AFAS this will be a simulated transmission

AGP_AMG_240

The AOC Ground Platform shall provide a suitable warning to the operator if the Aircraft Met Report is not received within a pre-determined time after the expected time. The expected time will either be defined by the reporting interval of the periodic reports or by the time a demand report was requested, as appropriate.

16.5.3 In-Flight Support The In-Flight Support function provides assistance to company aircraft when they are in-flight. This includes transmission of updated data as it becomes available to the AOC Ground Platform and communication between the AOC Ground Platform and the aircraft.


89

16.5.4 Free text messages A Freetext message is a block of user-defined text used to pass uplink and downlink information between the AOC end users (air and ground). REQUIREMENT CODE

DESCRIPTION

AGP_AMG_250 The AOC Ground Platform shall allow the AOC operator to communicate with the aircraft (pilot) through text messages.

AGP_ AMG_260 The AOC Ground Platform shall inform the operator of the receipt of a freetext message from the aircraft.

AGP_ AMG_270 The AOC Ground Platform shall be able to store all received free text messages.

AGP_AMG_280 The AOC Ground Platform shall provide the operator facilities to select and display a free text messages.

AGP_AMG_290 The AOC Ground Platform shall enable the operator to choose between sending a free text message using the GACS confirmed service or sending it using the GACS non-confirmed service.

AGP_AMG_300 The AOC Ground Platform shall provide a suitable warning to the operator if confirmation of transmission of a GACS confirmed free text message has not been received.

16.5.5 NOTAMS NOTAM messages contain a wide range of information. For example NOTAMs can contain Air Traffic Procedures, Information about airspace closures and aerodrome usage. NOTAM messages contain fields such as the ICAO Identifier, Time of Issue and Validity Period. They also contain numerous Freetext fields describing the NOTAM Information. REQUIREMENT CODE

DESCRIPTION


The AOC Ground Platform shall be able to store all received NOTAMS.


The AOC Ground Platform shall provide facilities to associate NOTAMS with flight plan information, in order to determine a list of affected flights.


The AOC Ground Platform shall uplink updated NOTAMS reports to all affected registered flights.


90

2assetManagementServer*

1manageFlightProgress*

assetManagementLog*

flightProgressReports*

freetextUplink*

freetextDownlink*

flightProgressRequest*

aircraftMetReports*

AmdarMessages*

NOTAM*

oooiReports*

flightProgressData*alertMessage*

alertMessage*

significantDifferenceTBD*

flightProgressResponse*


16.6 AOC Operator HMI This function provides the means for an operator to interact with the AOC Ground Platform. MA-AFAS interest lies in enhancing existing AOC operator HMI to take into account new information available from the aircraft.

16.6.1 Maintenance Management Console The ability to gather aircraft system information while the aircraft is in the air can be the basis of a significant improvement in airline efficiency in regard to maintenance scheduling. REQUIREMENT CODE

DESCRIPTION

AGP_HMI_001 The Maintenance Management Console of the AOC Ground Platform shall provide facilities to display maintenance data.

AGP_HMI_002 The AOC Ground HMI shall be able to receive inputs from a keyboard and a CCD.

16.6.2 Flight Progress Display The Flight Progress Display is an interface enabling the AOC operator to monitor the company flights progress. REQUIREMENT CODE

DESCRIPTION


91

AGP_HMI_015 The Flight Progress Display shall provide facilities to display a list of all registered flights.

AGP_HMI_020 The Flight Progress Display shall provide facilities to display a scrollable list of all datalink messages exchanged between the AGP and a registered aircraft.

AGP_HMI_025 The Flight Progress Display shall provide a visual alert for messages which cannot be delivered.

AGP_HMI_030 The Flight Progress Display shall provide a map displaying current estimated position of registered aircraft within a rectangular Airline Area of Interest (AAI).

AGP_HMI_040 The Flight Progress Display shall display an aircraft symbol at the current estimated position of each registered aircraft.

AGP_HMI_045 The display of aircraft symbols shall be consistent with aircraft flight progress information (current position, heading, flight phase).

AGP_HMI_035 The Flight Progress Display shall provide facilities to filter the aircraft to be displayed.

AGP_HMI_050 The Flight Progress Display shall enable the display of the current 4D trajectory data, waypoint data and other flight plan data of selected registered aircraft

AGP_HMI_055 The Flight Progress Display shall include facilities to display flight related data, which shall be, as a minimum: flight Id, tail number, current estimated position, flight phase and trajectory.

16.6.3 Other Displays In order to support the variety of functions, described within this document, the AOC Ground Platform offers a complete set of displays to support the activities of an AOC operator. REQUIREMENT CODE

DESCRIPTION

AGP_HMI_003 The AOC Ground Platform HMI shall support the display of pre-defined weather information.

AGP_HMI_004 The AOC Ground Platform HMI shall provide functionality to enable the operator to compose, and read, text messages.

AGP_HMI_005 The AOC Ground Platform shall include a Flight Analysis console to aid in aircraft performance analysis.

AGP_HMI_006 The AOC Ground Platform HMI shall support the configuration of the AOC Ground Platform communication interface.

AGP_HMI_007 The AOC Ground Platform HMI shall provide facilities to configure the AOC Ground Platform HMI.


92

3otherDisplay*

2maintenanceManagement

Console*

1updateFlight

ProgressDisplay*

FlightProgressUplinkMessage*

DisplayData*

flightProgressInformation*

maintenanceInputs* maintenanceData*

otherInformation*

freetextDownlink*freetextUplink*

DisplayData*

weatherInformation*

AircraftSystemsData*flightProgressInformation*

SnagData* APURequests*EngineRequests*

OperatorInputs*

OperatorInputs*

weatherInformation*

Figure 33. AOC Ground Platform Operator HMI DFD


93

17 AOC Ground Platform Data Dictionary This chapter provides a detailed description of the relevant MA-AFAS messages that will be implemented in the AOC Ground Platform. For each type of message there is a list of items contained in the message and a brief description of the item if required. Aircraft Met Reports This is information about the weather conditions sent from the AOC Air System to the AOC Ground System. Item Notes Message Label A MET Report. Type of MET Format Ascent, Enroute or Descent. Date The current day. Time Departure Station Destination Station Latitude Longitude Pressure Altitude Static Air Temperature Wind Direction Wind Speed Turbulence

Table 9. Aircraft Met Report

AircraftSystemsData This supports transfer (request/retrieval) of Aircraft Systems related data between the AOC Maintenance function and the HMI function (Maintenance Console process). AirGroundMessages These messages are sent between the Air Ground Communications process and the Comms Server process. They are used to maintain a log of all air-ground communications, from which messages can be retrieved at a later point. Item Notes Message Label Characters representing an AirGroundMessage. TBD

Table 10. AirGroundMessages


94

AirportAuthoritiesInformationTBD These messages are used for communication between the AOC Ground System and Airport Authorities, to optimise allocation of resources. Item Notes Message Label Characters representing an AirportAuthoritiesInformation. AircraftId Aircraft Identifier (TBD) ETA Estimated time of arrival at destination

Table 11. AirportAuthoritiesInformationTBD

AlertMessage An alert sent if various messages [TBD] are not acknowledged within a specific time or to notify the operator of significant [TBD] events. Item Notes Message Label Characters representing Alert Message. Details Details of alert.

Table 12. AlertMessage

AMDARMessage Aircraft meteo observations in AMDAR format are transmitted by the AOC Ground System to an external provider. Item Notes Message Label Characters representing an AMDAR message. AircraftId Aircraft that originated the report. (TBD) AMDAR Meteo data in AMDAR format. (TBD)

Table 13. AMDARMessage

AssetManagementLog A log of all sent and received messages relating to Asset Management.


95

APUReport This is generated by the AOC Air System and sent to the AOC Ground System on request or when triggered by an event. APU Reports convey APU (Auxiliary Power Unit) parameters. Item Notes Message Label Characters representing an APU Report.

Contract Type Periodic/Demand/EventDriven Request Result An optional field, whose value is always “accept”, indicating

acceptance of a request. The report containing the response must be the first report (or in the case of an on-demand request, the only report) related to the request being accepted.

Start Cycles Number of APU start cycles. Operating Hours Number of APU operating hours. Serial Number APU serial number.

Table 14. APUReport

APURequest APU Requests are generated by the AOC Ground System and sent to the AOC Air System. When the AOC Air System receives the request it returns APU Report(s). Item Notes Message Label Characters representing an APU Request. Contract Type Periodic/Demand – if periodic, reporting rate also given. Request Type Implement/Cancel – only required for periodic contracts.

Table 15. APUReportRequest

ATN Message The AOC Ground System is capable of sending/receiving ATN messages through a VDLM4 air/ground datalink.


96

CFMUInformation Messages used for communication between the AOC Ground Platform and the CFMU. Used to send data such as flight plans. ChangeMessage This is sent from AOC Ground System to CFMU upon a pre-departure change to a company flight plan which has been previously filed with CFMU (other than departure slot reallocation). The message contains details of the change. Item Notes Message Label Characters representing a ChangeMessage. Flight Plan Identifier The company assigned identifier for the flight plan. Flight Plan An updated ICAO flight plan. Fuel usage Expected fuel used at various waypoints on the route. Time at waypoints Expected time to reach various waypoints.

Table 16. ChangeMessage

CompanyFlightPlan The Flight Plan for the current flight generated by the company. Item Notes Message Label Characters representing a Company Flight Plan. Flight Plan Identifier The company assigned identifier for the flight plan. Number booked Estimated number of passengers. Flight Plan An ICAO flight plan. Fuel usage Expected fuel used at various waypoints on the route. Time at waypoints Expected time to reach various waypoints.

Table 17. CompanyFlightPlan

CommsLog A log of all messages sent or received by the comms process. Delay/Divert/Reroute Proposal Delay/Divert/Reroute proposals are sent to the aircraft by the Collaborative Decision Making process. They contain the aircraft identifier and either a delay, a divert or reroute instructions. Item Notes Aircraft Identifier Delay Divert Reroute

Table 18 - Delay/Divert/Reroute Proposal


97

Delay/Divert/Reroute Response Delay/Divert/Reroute responses are sent by the aircraft to the AOC Ground Platform and handled by the Collaborative Decision Making process. Item Notes Aircraft Identifier Response

Table 19 - Delay/Divert/Reroute Response

DisplayData This represents the information that is presented to the AGP operator on the available display surfaces. EngineRequest Engine Requests are generated by the AOC Ground System and sent to the AOC Air System. When the AOC Air System receives the request it returns Engine Report(s) which provide the requested data groups. The groups that may be returned are still TBD. Item Notes Message Label Characters representing a Engine Request. Contract Type Periodic/Demand – if periodic, reporting rate also given. Request Type Implement/Cancel – only required for periodic contracts. Requested Information What information is being requested.

Table 20 - EngineStatusReportRequest


98

EngineReport This is generated by the AOC Air System and sent to the AOC Ground System on request or when a specified event occurs. Engine reports can contain various groups of engine information. There will a Basic Information group which will be included in every Engine Report. When requested the engine report can include optional data groups. Basic and optional data groups are TBD. Item Notes Message Label Characters representing an Engine Report.

Contract Type Periodic/Demand/EventDriven. Request Result An optional field, whose value is always “accept”, indicating


TBD

Table 21. EngineReport

FiledFlightPlan This message is sent from the AOC ground system to CFMU. It contains a Filed Flight Plan, and is sent at the later of the time of initial 4Dtrajectory generation and a specified time before the estimated departure time of the flight. Item Notes Message Label Characters representing a Filed Flight Plan. Flight Plan Identifier The company assigned identifier for the flight plan. Aircraft Id Aircraft identifier. Departure Airport Airport flight departs from. Off-block Time Estimated off-block time. Flight Plan An ICAO flight plan. Destination Airport Initial destination of flight. Elapsed Time Estimated elapsed time. Alternate Airports Other possible destination airports.

Table 22. FiledFlightPlan


99

FlightInformation Flight Information Update messages are sent from the aircraft to the AOC Ground System. They can contain details such as 4D Position, Next Reporting Point, ETA and Fuel Information. They are used to track changes to the Company Flight Plan during the flight. Item Notes Message Label Characters representing a Flight Information Update message. AircraftId The aircraft identifier. FlightInfoType Type of flight information FlightInfoData Details of flight information

Table 23. FlightInformationUpdate

FlightPlan These messages are used for the AOC Ground System and ATC to negotiate initial and revised 4D Flight Plans, taking airspace status and available routes into account. They are also passed to the CFMU from the AOC Ground System. Item Notes Message Label Characters representing FlightPlan message. Flight Plan Identifier The company assigned identifier for the flight plan. Plan Type Initial message is a ‘negotiate’, containing a revised flight plan. If

it is acceptable, the response is an ‘accept’. If not, the response is another ‘negotiate’ message, containing a second revision of the flight plan. Messages are exchanged until the plan is accepted.

Flight Plan An ICAO flight plan. (Only included in ‘negotiate’ message)

Table 24. FlightPlan

FlightPlanInformation This message is sent between the CompanyFlightPlans process and the FlightPlanningInformation store. It contains details such as updates to Company Flight Plans that must be recorded during the flight. Item Notes Message Label Characters representing FlightPlanInformation. Flight Plan Identifier The company assigned identifier for the flight plan. Flight Plan An updated ICAO flight plan.

Table 25. FlightPlanInformation

FlightPlanningInformation A store of all messages sent or received by the Flight Planning process. FlightProgressData Internal flow in the Asset Management process used to pass information regarding flight progress.


100

FlightProgressInformation This is a flow in the HMI which will pass various parts of information to and from the Flight Progress Display. It supports transfer (request/retrieval) of Flight Progress related data between the AOC Asset Management function and the AOC Ground Platform HMI function. Item Notes Timestamp Time Message was received. Source Where message was sent from. Destination Where message was being sent.

Current Position Current Time Flight Level

Next Report Point Where the next report will be sent from. Time Over Estimated time of reaching the next reporting point. Cruising Speed Current Mach speed.

Destination Station ETA

Fuel Quantity

Free Text User defined text.

Table 26. Flight Progress Information


101

FlightProgressReports This is generated by the AOC Air System and sent to the AOC Ground System on request. It reports information such as the current position and short-term intent of the aircraft. Flight Progress Reports can contain various groups of information (the groups are shown in the following table). The Current Position, Current Time and Flight Level group is Basic Information and is included in every Flight Progress Report. The other groups are optional. Item Notes Message Label Characters representing a Flight Progress Report.

Contract Type Periodic/Demand. Request Result An optional field, whose value is always “accept”, indicating


Current Position Current Time In the format HHMM. Flight Level

Next Report Point The position the next report will be sent from. Time Over Estimated time of reaching the next reporting point. Cruising Speed Current Mach speed.

Destination Station ETA The expected time of arrival in the format hhmm.

Fuel Quantity

Free Text User defined text.

Table 27. FlightProgressReport

FlightProgressRequest Flight Progress Requests are generated by the AOC Ground System and sent to the AOC Air System. When the AOC Air System receives the request it returns Flight Progress Report(s) which provide the requested data groups. The groups that may be returned are; basic 4D position (always present), next waypoint, ETA, and fuel report. Flight Progress Requests specify the information required in the report and optionally Free Text. Item Notes Message Label Characters representing a Flight Progress Request. Contract Type Periodic/Demand – if periodic, reporting rate also given. Request Type Implement/Cancel – only required for periodic contracts. Requested Information What information is being requested, in addition to the basic 4D

position. This could be next waypoint information, ETA, Information about Fuel on Board or any combination of the three.

Table 28. FlightProgressRequest

FlightProgressResponse Flight Progress Responses are generated by the AOC Air System in reply to a Flight Progress Request. This indicates whether or not the AOC Air System can satisfy the associated request. The Flight


102

Progress Response may be sent as a separate message, or (if the response is “accept”) as part of the first Flight Progress Report associated with the request. Item Notes Message Label Characters representing a Flight Progress Response. Contract Type Periodic/Demand. Result Accept/Reject – if reject, a reason is also given.

Table 29. FlightProgressResponse

FlightProgressUplinkMessage This is a dataflow comprising the uplink messages that can be generated within the Flight Progress Display functions. FlightSupportData The AOC Ground System is capable of sending/receiving Flight Support Data messages to/from aircraft. FMSMeteo This is a message containing Meteo information. It is uplinked as part of Flight Planning and also used internally to provide information to the Company Flight Plan process. Item Notes Message Label Characters representing a FMS Meteo Uplink. Meteo Data TBD. Free Text User defined text.

Table 30. FMSMeteo

Freetext Uplink/Downlink Freetext messages are user defined text messages usually providing some supplementary information to a report. Item Notes Message Label Characters representing a Freetext Message. Free Text User defined text.

Table 31. Freetext Uplink/Downlink


103

FuelInformation This message contains information about the amount of fuel loaded onto an aircraft. It is stored before later transmission as part of a Loadsheet. Item Notes Message Label Characters representing a FuelInformation Message. AircraftId Aircraft identifier. Fuel Amount of fuel loaded onto plane.

Table 32. FuelInformation

GRIBInformation This is sent to the AOC Ground System, where it is stored for later transmission to an aircraft in the form of an FMS Meteo message. Item Notes Message Label Characters representing a GRIBInformation Message. GRIB GRIB report

Table 33. GRIBInformation

GroundGroundMessages These messages are sent between the GroundGroundCommunications process and the CommsServer process. They are used to maintain a log of all ground-ground communications, from which messages can be retrieved at a later point. IFTM Data (In Flight Traffic Management) This is an internal flow in the Collaborative Decision Making process which is used to log any data sent or received. Item Notes Timestamp Time Message was received. Source Where message was sent from. Destination Where message was being sent. Details A log of the actual message.

Table 34. IFTM Data


104

Loadsheet Loadsheet data is generated by the AOC Ground System and sent to the AOC Air System. It is based on Pax/Baggage and Fuel information. Item Notes Message Label Characters representing a Loadsheet. Takeoff Weight (TOW) Zero Fuel Weight (ZFW) Number of passengers Information about passengers on the flight. Load in each Compartment Shows the number of passengers in each compartment. Amount of fuel Amount of fuel on board in kilograms. ZFW Center of Gravity The center of gravity with no fuel on board in kilograms. TOW Center of Gravity The center of gravity with fuel on board in kilograms. Slot Allocation The slot being used for the takeoff. Aircraft Identification Departure Aerodrome Destination Aerodrome Estimated Off-block Date In the form YYMMDD. Regulations concerning the flight Additional information regarding regulations that affect this flight.

Table 35. Loadsheet

Maintenance Data This is part of the HMI which displays maintenance data to the operator. Maintenance Inputs This is part of the HMI which allows the operator to input from the keyboard. METAR Meteorological Aerodrome Reports (METAR) are sent from the weather centre to the AOC Ground System, then to the AOC Air System. A METAR provides a report of the actual observed weather at (or in the vicinity of) the aerodrome. Item Notes Message Label Characters representing a METAR. Airport ID 4 character ICAO Identifier. Day The day in the form nn. Time Time in 24 hour mode. Time Zone METAR Information Various information relevant to the METAR. For example this

could contain Wind Direction, Wind Speed, Variable Wind Speed, Visibility, Cloud cover, Temperature, Dew point temperature and Pressure.

Table 36. METAR

MeteoReports These are weather reports sent between the AOC Ground and Air Systems. They are either TAF, METAR or SIGMET reports. MeteoReportRequest


105

This is a request for TAF/METAR/SIGMET information sent from the AOC Air System to the AOC Ground System. A TAF/METAR/SIGMET Request specifies the type of information requested, and the locations for which the reports are required. Item Notes Message Label Characters representing a request for the TAF, METAR or

SIGMET. Number of Requests How many TAF, METAR or SIGMETs are requested in this

message. Request Type An indicator showing whether this is a request for a TAF, METAR

or SIGMET. Location The area (e.g. aerodrome) where the requested report is applicable.

Table 37. MeteoReportRequest

MeteorologicalData Messages sent between the AOC Ground Platform and the Aircraft, such as Meteo Reports and AMDAR format messages. NOTAM These messages are Notices to Airmen. NOTAM messages contain a wide range of information. For example NOTAMs can contain Air Traffic Procedures, Information about airspace closures, and aerodrome usage. Item Notes Message Label Characters representing NOTAM. ICAO Identifier Where the NOTAM is applicable. Time of Issue When the message was issued. Validity Period How long the message is valid for. Freetext User defined text saying what the notices are.

Table 38. NOTAM


106

OOOI Reports These are messages sent at various points of the flight. They are Out, Off, On or In messages. OutMessage Out messages are sent when leaving gate or parking position. Item Notes Message Label Characters representing an Out Message. Departure Station OUT Time Out time represented in the form HHMM. Boarded Fuel Fuel Quantity Free Text User defined text. OffMessage Off messages are sent on takeoff when the aircraft becomes airborne. Item Notes Message Label Characters representing an Off Message. Departure Station OFF Time Off time represented in the form HHMM. Free Text User defined text. OnMessage On messages are sent on touchdown. Item Notes Message Label Characters representing an On Message. Destination Station ON Time On time represented in the form HHMM. Free Text User defined text. InMessage In messages are sent on arrival at gate or parking position. Item Notes Message Label Characters representing an In Message. Destination Station IN Time In time represented in the form HHMM. Fuel Quantity Captain/First Officer Identifier Free Text User defined text.

Table 39. OOOIReports

OperatorInputs This is part of the HMI which allows the operator to input from the keyboard. OtherInformation This will pass various parts of information to the display other than Flight Progress and Maintenance Management. PaxBaggage This message contains passenger and baggage information. The AOC Ground System records this, for later transmission as part of a Loadsheet message.


107

Item Notes Message Label Characters representing a PaxBaggage. Number of Passengers Total number of passengers on aircraft. Compartment Loads Number of passengers in each compartment. Baggage Weight Total weight of baggage on aircraft.

Table 40. PaxBaggage

PreFlightSupportInformation This is a message used to log all data sent or received by the Flight Planning process. PointToPointMessage RerouteResult The result of a reroute proposal. This is part of the Collaborative Decision Making process. SIGMET Significant Meteorology (SIGMET) reports are sent from the AOC Ground System to the AOC Air System. A SIGMET report advises of weather (other than convective activity) which is potentially hazardous to aircraft operations. Item Notes Message Label Characters representing SIGMET. Time of Issue When the SIGMET report was issued. Validity Period How long the SIGMET report is valid for. Area of Interest Where the SIGMET report is applicable. SIGMET Text Various information relevant to the SIGMET.

Table 41. MeteoSIGMETReport

SignificantDifferenceTBD This is part of the Asset Management process. When reports are received from the aircraft significant differences in various pieces of information [TBD] are reported to the operator.


108

SlotAllocation Information regarding departure slots received by the AOC Ground System from the CFMU and passed on to the AOC Air System. Item Notes Message Label Characters representing a Slot Allocation. Estimated Off Block Time Calculated Take Off Time Freetext User defined text regarding the slot (e.g. may indicate cause of

delay in terms of the most limiting regulation).

Table 42. SlotAllocation

SNAGData This supports transmission of malfunctions related data from the AOC Maintenance function to the HMI function (Maintenance Console process). SNAGReport SNAG Reports are downlink messages containing description of specific aircraft events (failures and technical malfunctions). Item Notes Message Label Characters representing a Snag Report. Departure Station Destination Station Problem Code Code assigned to the identified problem. Free Text This is an optional field containing the problem description.

Table 43. SNAG Reports


109

TAF Terminal Air Forecasts (TAF) are sent from the weather centre to the AOC Ground System, then to the AOC Air System. A TAF gives the expected meteorological conditions at an airport during a specified period.- Item Notes Message Label Characters representing a TAF. Airport ID 4 character ICAO Identifier. Day Time GMT Applicability TAF Information Various Information relevant to the TAF. This could contain, for

example, Wind Direction, Wind Speed, Visibility and Cloud cover.

Table 44. MeteoTAFReport

TakeoffSettings Takeoff settings are generated by the AOC Ground System and sent to the AOC Air System. These messages recommend settings for the aircraft takeoff based on weather conditions, aircraft weight, etc. Item Notes Message Label Characters representing Takeoff Settings. Takeoff power settings Required power settings. Flap selection Required flap settings for takeoff. Takeoff speeds Takeoff speed based on the takeoff weight. Takeoff runway The runway being used for this takeoff.

Table 45. TakeoffSettings

TrajectoryData Message sent from the Flight Management System to the AOC Ground System via the AOC Air System. This contains detailed information of the active route within the FMS. Item Notes Message Label Characters representing trajectory data. Aircraft Identifier Trajectory Information Date Time stamp showing year, month, day, hour, minute, second

Table 46. Trajectory Data

TrajectoryDataRequest This is sent from the AOC Ground System to the AOC Air System requesting a 4D Trajectory report. Item Notes Message Label Characters representing a 4D Trajectory Request message. Free Text Optional user defined text.

Table 47. Trajectory Data Request


110

Weather Information This is weather information that is required to support the display of pre-defined weather information by AOC Ground Platform HMI.


111

18 AOC Fleet Simulator Requirements This technical note forms the specification of requirements for a software item to simulate a group of aircraft in communication with the MA-AFAS Airline Operational Centre (AOC) Ground Platform. This “fleet simulator” is intended to enable system testing of the AOC Ground Platform (AGP), and also to increase the realism of the MA-AFAS AOC trials by providing multiple targets with which the AGP can interact.

18.1 SYSTEM OVERVIEW The AOC Ground Platform (AGP) is a trials system which simulates the functions of an Airline Operational Centre end system. The AGP is used to support trials of the MA-AFAS avionics package AOC functions. The AGP is supported by a fleet simulator, in order to increase the fidelity of the simulation. The fleet simulator also allows more complex AOC trials to be conducted than is possible with the limited number of MA-AFAS avionics packages.

AOC Ground System

FleetSimulator

AGP

Avionics Package

CommunicationsBearer

Figure 44. AOC Ground Platform Block Diagram

The fleet simulator is intended to be integrated into the AOC ground system process running on the AGP .


112

18.2 FUNCTIONAL REQUIREMENTS

18.2.1 Initialisation AGP_FSM_010 At startup, the fleet simulator shall input, from configuration file, details on all the flights to be simulated during the simulation. These details include:

Basic identity information, e.g. ICAO 24-bit address; Timing of datalink registration relative to simulator start; Timings for all aircraft-initiated dialogues relative to take-off time; Data for aircraft-generated messages, which cannot be derived from stored flight data; Parameters describing the behaviour of the simulated flight, e.g. specifying responses to In-

Flight Traffic Management constraint list messages.

These details are referred to in later requirements as “pre-defined” items.

18.2.2 Aircraft Model REQUIREMENT CODE

DESCRIPTION

AGP_FSM_020

The fleet simulator shall represent the trajectory of a flight by a set of 3D waypoints (latitude, longitude and altitude triples) with optional required time of arrival (RTA) against each waypoint. The trajectory starts at the departure aerodrome, and terminates at the destination aerodrome.

AGP_FSM_021

For the purposes of calculating instantaneous 2D aircraft position, the fleet simulator shall apply great circle trajectories between adjacent waypoints.

AGP_FSM_022 The fleet simulator shall calculate instantaneous aircraft position assuming a constant pre-defined ground speed, modified as necessary to achieve specified RTAs.

AGP_FSM_023 For the purposes of calculating instantaneous aircraft altitude, the fleet simulator shall interpolate linearly between the altitudes at adjacent waypoints.

18.2.3 Communications Infrastructure The simulation of the GACS service is intended to be the minimum required to transport C/C++ structures between the fleet simulator and the AOC ground system.

REQUIREMENT CODE

DESCRIPTION

AGP_FSM_030

For communications between the fleet simulator and the AOC ground system, the fleet simulator shall support a simulated GACS service, offering G-Transfer and G-Transfer-Confirmed services.

AGP_FSM_031

On receipt of a message from the AOC ground system using the simulated G-Transfer-Confirmed GACS service, the fleet simulator shall send an acknowledgement (confirmation of receipt) to the AOC ground system. Note that there is no requirement for the AOC ground system to confirm receipt of messages sent from the fleet simulator using the simulated G-Transfer-Confirmed service.

AGP_FSM_032 The fleet simulator shall log all messages received from the AOC ground system. AGP_FSM_033

The fleet simulator shall log all messages sent to the AOC ground system.


113

18.2.4 Datalink Registration REQUIREMENT CODE

DESCRIPTION

AGP_FSM_040 At the stored registration time of the flight, the fleet simulator shall construct an Initialising Message, containing the stored initialisation details, and send it to the AOC ground system. The initialisation details consist of the tail number, flight id (optional), departure aerodrome (optional) and destination aerodrome (optional).

18.2.5 Pre-Departure REQUIREMENT CODE

DESCRIPTION

AGP_FSM_050 On receipt of a FMS Meteo message from the AOC ground system, the fleet simulator shall log the message.

AGP_FSM_050 On receipt of a Company Flight Plan message from the AOC ground system, the fleet simulator shall store the flight plan for the flight.

AGP_FSM_052

On receipt of a Loadsheet message from the AOC ground system, the fleet simulator shall generate a Loadsheet Acknowledgement message, using the pre-defined acknowledgement code for the relevant flight, and send the Loadsheet Acknowledgement to the AOC ground system.

AGP_FSM_053

On receipt of a Slot Allocation message from the AOC ground system, the fleet simulator shall amend the pushback and takeoff times of the flight respectively to the EOBT and CTOT contained in the message.

18.2.6 Meteo Reports REQUIREMENT CODE

DESCRIPTION

AGP_FSM_060 At the pre-defined time for sending a request for a meteo report (TAF/METAR/SIGMET), the fleet simulator shall generate a Meteo Report Request from the pre-defined data, and send it to the AOC ground system.

AGP_FSM_061 On receipt of a TAF message from the AOC ground system, the fleet simulator shall log the message.

AGP_FSM_062

On receipt of a METAR message from the AOC ground system, the fleet simulator shall log the message.

AGP_FSM_063

On receipt of a SIGMET message from the AOC ground system, the fleet simulator shall log the message.

18.2.7 OOOI Messages REQUIREMENT CODE

DESCRIPTION

AGP_FSM_070 At the stored off-blocks time of the flight, the fleet simulator shall generate an OUT message and send it to the AOC ground system.

AGP_FSM_071

At the stored takeoff time of the flight, the fleet simulator shall generate an OFF message and send it to the AOC ground system.

AGP_FSM_072

At the time when the aircraft is calculated to have reached its destination aerodrome, the fleet simulator shall generate an ON message and send it to the AOC ground system.


114

AGP_FSM_073

At the pre-defined time after the sending of the ON message for a flight, the fleet simulator shall generate an IN message for that flight and send it to the AOC ground system.

18.2.8 Flight Progress REQUIREMENT CODE

DESCRIPTION

AGP_FSM_080

On receipt of a Flight Progress Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to accept demand-mode flight progress requests, the fleet simulator shall reply with a Flight Progress Report message, accepting the contract and providing the details requested.

AGP_FSM_081

On receipt of a Flight Progress Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to reject demand-mode flight progress requests, the fleet simulator shall reply with a Flight Progress Response message, rejecting the request.

AGP_FSM_082

On receipt of a Flight Progress Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to accept periodic flight progress requests, the fleet simulator shall accept the contract, and reply with a Flight Progress Report message, accepting the contract and providing the details requested.

AGP_FSM_083

On receipt of a Flight Progress Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to reject periodic flight progress requests, the fleet simulator shall reply with a Flight Progress Response message, rejecting the request.

AGP_FSM_084 On receipt of a Flight Progress Request message from the AOC ground system, requesting the cancellation of a periodic contract, the fleet simulator shall cancel the relevant contract, and reply to the AOC ground system with a Flight Progress Response message, accepting the request.

AGP_FSM_085

If a periodic flight progress contract is in place, the fleet simulator shall, at the required time intervals, generate a Flight Progress Report message and send it to the AOC ground system.

AGP_FSM_086 The contents of Flight Progress Reports shall be calculated from the aircraft model, according to the data requested in the contract.

18.2.9 Aircraft Weather Reports REQUIREMENT CODE

DESCRIPTION

AGP_FSM_090

On receipt of an Aircraft Met Reports Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to accept demand-mode aircraft met report requests, the fleet simulator shall reply with an Aircraft Met Report message, accepting the contract and providing the details requested.

AGP_FSM_091

On receipt of an Aircraft Met Reports Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to reject demand-mode aircraft met report requests, the fleet simulator shall reply with an Aircraft Met Reports Response message, rejecting the request.

AGP_FSM_092

On receipt of an Aircraft Met Reports Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to accept periodic aircraft met report requests, the fleet simulator shall accept the contract, and reply with an Aircraft Met Report message, accepting the contract and providing the details requested.

AGP_FSM_093

On receipt of an Aircraft Met Reports Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to reject periodic aircraft met report requests, the fleet simulator shall reply with an Aircraft Met Reports Response message, rejecting the request.


115

AGP_FSM_094 On receipt of an Aircraft Met Reports Request message from the AOC ground system, requesting the cancellation of a periodic contract, the fleet simulator shall cancel the relevant contract, and reply to the AOC ground system with an Aircraft Met Reports Response message, accepting the request.

AGP_FSM_095 If a periodic aircraft met reports contract is in place, the fleet simulator shall, at the required time intervals, generate an Aircraft Met Report message and send it to the AOC ground system.

AGP_FSM_096 The contents of Aircraft Met Reports shall be obtained from the aircraft model and (where unavailable in the aircraft model) pre-defined data.

18.2.104D Trajectory REQUIREMENT CODE

DESCRIPTION

AGP_FSM_100 On receipt of a 4D Trajectory Request message from the AOC ground system, the fleet simulator shall reply with a 4D Trajectory Data message, generated from the stored flight plan for the subject flight.

18.2.11In-Flight Traffic Management REQUIREMENT CODE

DESCRIPTION

AGP_FSM_110 On receipt of a Constraints List message from the AOC ground system, where the flight in question has been pre-defined to accept IFTM requests, the fleet simulator shall reply with a Constraints Acceptance message accepting the constraints

AGP_FSM_111

At a pre-defined time after sending a Constraints Acceptance message accepting an IFTM request, the fleet simulator shall replace the current stored flight plan for the flight with the uplinked trajectory in the Constraints List, generate a Trajectory message based on that information, and send the message to the AOC ground system

AGP_FSM_112 On receipt of a Constraints List message from the AOC ground system, where the flight in question has been pre-defined to reject IFTM requests, the fleet simulator shall reply with a Constraints Acceptance message rejecting the constraints.

18.2.12Technical Malfunctions REQUIREMENT CODE

DESCRIPTION

AGP_FSM_120 At the pre-defined time for sending information on a technical malfunction, the fleet simulator shall generate a Snag Report message from the pre-defined information and send it to the AOC ground system.

18.2.13APU Reports REQUIREMENT CODE

DESCRIPTION


116

AGP_FSM_130

On receipt of an APU Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to accept demand-mode APU requests, the fleet simulator shall reply with an APU Report message, accepting the contract and providing the details requested.

AGP_FSM_131 On receipt of an APU Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to reject demand-mode APU requests, the fleet simulator shall reply with an APU Response message, rejecting the request.

AGP_FSM_132

On receipt of an APU Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to accept periodic APU requests, the fleet simulator shall accept the contract, and reply with an APU message, accepting the contract and providing the details requested.

AGP_FSM_133 On receipt of an APU Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to reject periodic APU requests, the fleet simulator shall reply with an APU Response message, rejecting the request.

AGP_FSM_134

On receipt of an APU Request message from the AOC ground system, requesting the cancellation of a periodic contract, the fleet simulator shall cancel the relevant contract, and reply to the AOC ground system with an APU Response message, accepting the request.

AGP_FSM_135

If a periodic APU contract is in place, the fleet simulator shall, at the required time intervals, generate an APU Report message and send it to the AOC ground system.

AGP_FSM_136 The contents of APU reports shall be obtained from the aircraft model and (where unavailable in the aircraft model) ACMS simulator data.

18.2.14Engine Status Reports REQUIREMENT CODE

DESCRIPTION

AGP_FSM_140

On receipt of an Engine Status Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to accept demand-mode Engine Status requests, the fleet simulator shall reply with an Engine Status Report message, accepting the contract and providing the details requested.

AGP_FSM_141

On receipt of an Engine Status Request message from the AOC ground system, requesting the implementation of a demand contract, where the flight in question has been pre-defined to reject demand-mode Engine Status requests, the fleet simulator shall reply with an Engine Status Response message, rejecting the request.

AGP_FSM_142

On receipt of an Engine Status Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to accept periodic Engine Status requests, the fleet simulator shall accept the contract, and reply with an Engine Status message, accepting the contract and providing the details requested.

AGP_FSM_143

On receipt of an Engine Status Request message from the AOC ground system, requesting the implementation of a periodic contract, where the flight in question has been pre-defined to reject periodic Engine Status requests, the fleet simulator shall reply with an Engine Status Response message, rejecting the request.

AGP_FSM_144 On receipt of an Engine Status Request message from the AOC ground system, requesting the cancellation of a periodic contract, the fleet simulator shall cancel the relevant contract, and reply to the AOC ground system with an Engine Status Response message, accepting the request.

AGP_FSM_145 If a periodic Engine Status contract is in place, the fleet simulator shall, at the required time intervals, generate an Engine Status Report message and send it to the AOC ground system.

AGP_FSM_146 The contents of Engine Status Reports shall be obtained from the aircraft model and (where unavailable in the aircraft model) ACMS simulator data.

18.2.15Free Text Telex REQUIREMENT DESCRIPTION


117

CODE

AGP_FSM_150 On receipt of a Freetext Uplink message from the AOC ground system, the fleet simulator shall log the message.

AGP_FSM_151 At the pre-defined time for sending a freetext message, the fleet simulator shall generate a Freetext Downlink message from the pre-defined text and send it to the AOC ground system.

18.2.16 HMI REQUIREMENT CODE

DESCRIPTION

AGP_FSM_160 The fleet simulator shall provide a simple text window to display the contents of the log file (i.e. downlinked and uplinked messages).

18.3 NON-FUNCTIONAL REQUIREMENTS

18.3.1 Accuracy REQUIREMENT CODE

DESCRIPTION

AGP_FSM_210 The fleet simulator shall measure time to the nearest second. This constraint also applies to any calculations using time (elapsed or absolute) as a variable.

18.3.2 Capacity REQUIREMENT CODE

DESCRIPTION

AGP_FSM_220 The fleet simulator shall be capable of simulating at least 20 aircraft simultaneously.


118

19 AOC Traceability of the Ground Requirements The following table cross checks the requirements captured within this document against the ones listed within D11. The requirements in D11 should be reported in the first column of the table and the related D38 ground system requirements have been identified and reported in the second column.

D11 Requirements D38 Requirements MEDUP

GND_COM_050 MDP_ADS_001 GND_GEN_070 MDP_ADS_005 MDP_ADS_001

MDP_ADS_005 MDP_ADS_010

FIS-B GND_COM_020 GND_COM_060

MDP_FIS_001 MDP_FIS_005 MDP_FIS_010 MDP_FIS_015

GND_ATS_025 GND_ATS_040

MDP_FIS_001 MDP_FIS_005 MDP_FIS_010 MDP_FIS_015

TIS-B GND_ATS_001 GND_ATS_005 GND_ATS_010 GND_ATS_015

MDP_TIS_001 MDP_TIS_005 MDP_TIS_010 MDP_TIS_015 MDP_TIS_020 MDP_TIS_025

GND_COM_015 GND_COM_065

MDP_TIS_005 MDP_TIS_010 MDP_TIS_015 MDP_TIS_020 MDP_TIS_025

MEDUP Point To Point communications N/A MDP-ASW-01 N/A MDP-ASW-01A N/A MDP-ASW-02A N/A MDP-ASW-02A N/A MDP-ASW-03 N/A MDP-ASW-04 N/A MDP-ASW-05 N/A MDP-ASW-06 N/A MDP-ASW-07 N/A MDP-ASW-03 EEC

ASAS Delegation GND_ATS_050 GND_ATS_060

ESC_DEL_001


119

D11 Requirements D38 Requirements GND_ATS_065 N/A ESC_DEL_002 N/A ESC_DEL_003 N/A ESC_DEL_004 N/A ESC_DEL_005 N/A ESC_DEL_006

ADS-B GND_COM_005 GND_COM_010 GND_COM_050 GND_DMG_001 GND_DMG_005

ESC_ADS_001

TIS-B GNG_ATS_001 GND_ATS_010 GND_ATS_015 GND_COM_005 GND_COM_065

ESC_TIS_001

Data link Services GND_COM_170 GND_COM_175 GND_COM_200 GND_COM_215

ESC_DTL_001

N/A ESC_DTL_002 ATN stack and infrastructure ESC_ATN_001 GND_COM_090 GND_COM_095 GND_COM_100

ESC_ATN_002

IHTP PA SMGCS Surveillance GND_GEN_070 SMG_SUR_001 GND_GEN_100 SMG_SUR_002 GND_DMG_001 SMG_SUR_003 GND_DMG_005 SMG_SUR_004 SMG_SUR_005 SMG_SUR_006 SMG_SUR_007 SMG_SUR_008 Planning GND_ATS_040 SMG_PLA_001 Guidance GND_OPC_090 SMG_GUI_001 GND_OPC_091 SMG_GUI_002 SMG_GUI_003


120

D11 Requirements D38 Requirements SMG_GUI_004 SMG_GUI_005 SMG_GUI_006 Control GND_OPC_060 SMG_CTL_001 GND_COM_035 SMG_CTL_002 GND_COM_040 SMG_CTL_003 AOC Pre-Flight Support GND_AOC_001 AGP_FPL_020

AGP_FPL_030 GND_AOC_005 AGP_FPL_050 GND_OPC_075 AGP_FPL_090 GND_OPC_085 AGP_FPL_120 GND_AOC_010 AGP_FPL_190 Communication GND_AOC_050 AGP_COM_003 GND_OPC_011 AGP_COM_010[Post MA-AFAS] GND_AOC_045 GND_OPC_106

AGP_COM_011

GND_AOC_040 AGP_COM_013 GND_AOC_055 AGP_COM_021 GND_AOC_060 AGP_COM_031

AGP_COM_032 [Post MA-AFAS] GND_AOC_075 AGP_COM_041 [Post MA-AFAS TBC] GND_AOC_035 GND_AOC_015

AGP_COM_045

GND_AOC_065 GND_OPC_101

AGP_COM_080 AGP_COM_090

GND_OPC_030 AGP_COM_110 GND_AOC_070 AGP_COM_120 [Post MA-AFAS] AOC Asset Management GND_OPC_096 AGP_AMG_210 GND_OPC_101 AGP_AMG_230 GND_OPC_075 REQ_OC_075 AOC Maintenance AGP_MTC_001

AGP_MTC_002 AGP_MTC_003 AGP_MTC_004 AGP_MTC_005[Post MA-AFAS] AGP_MTC_011 AGP_MTC_012 AGP_MTC_013 AGP_MTC_014 AGP_MTC_015 AGP_MTC_016 AGP_MTC_017 AGP_MTC_018


121

D11 Requirements D38 Requirements AGP_MTC_021 AGP_MTC_022 AGP_MTC_023 AGP_MTC_024 AGP_MTC_025 AGP_MTC_026 AGP_MTC_027 AGP_MTC_028 AGP_MTC_029 AGP_MTC_030 AGP_MTC_031 AGP_MTC_032

Collaborative Decision Making GND_OPC_011 AGP_CDM_010 GND_OPC_075 AGP_CDM_017

AGP_CDM_040 AGP_CDM_050 AGP_CDM_060

AOC Operator HMI GND_AOC_025 AGP_HMI_020 GND_AOC_020 AGP_HMI_030

AGP_HMI_035 AOC Fleet simulator AGP_FSM_020 AGP_FSM_021 AGP_FSM_022 AGP_FSM_023 AGP_FSM_030 AGP_FSM_031 AGP_FSM_032 AGP_FSM_033 AGP_FSM_040 Pre departure AGP_FSM_050 AGP_FSM_050 AGP_FSM_052 AGP_FSM_053 Meteo Report AGP_FSM_060 AGP_FSM_061 AGP_FSM_062

AGP_FSM_063


122

D11 Requirements D38 Requirements

Table 48. Ground requirements Traceability matrix