GACS Project Achievements - International Civil … working groups library... · Web viewEUROCONTROL GACS Project Achievements Presented by: EUROCONTROL SUMMARY This information paper

EUROCONTROL

ACP WGN02-WP073 November 2003

AERONAUTICAL COMMUNICATIONS PANEL

WORKING GROUP N “Networking”

Bangkok, Thailand, 17 – 21 November 2003Agenda Item --

EUROCONTROL GACS Project Achievements

Presented by: EUROCONTROL

SUMMARYThis information paper outlines the achievements of the GACS project of the EUROCONTROL DAS/CSM Unit. The Working Group is invited to note this information.

EUROCONTROL GACS Project AchievementsRef : H/ACP/Bangkok/GACS

1. INTRODUCTION

1.1 ScopeThis report summarises the achievements of the Generic ATN Communications Service (GACS) implementation project undertaken by the EUROCONTROL DAS/CSM Unit. The GACS project started in November 1998, with the aims of:

a) Verifying the GACS concept of simple access to underlying data transfer services based on the aeronautical telecommunication network (ATN);

b) Validating the ICAO Doc 9705 Edition 3 extensions to the ATN Upper Layer Communications Service (with the exception of Secure Dialogue Service);

c) Producing rapid prototypes of new ATN utilities and ATS applications;

d) Demonstrating encapsulation of ACARS AOC protocols over ATN;

e) Validating the AEEC 637 specification for a "AEEC 620 Convergence Function";

f) Demonstrating simultaneous ATSC and AOC communication over ATN in a realistic environment;

g) Providing Member States with licensed software for their own evaluation and experimentation.

1.2 StructureThis report is organised as follows:

Section 1 provides an executive summary explaining some of the business motives for adopting GACS, and how the GACS Project validates solutions enabling the business benefits to be realised.

Section 2 (this section) describes the scope and background of the GACS Project, and provides a list of references.

Section 3 provides the reader with a general description of the ICAO standard GACS service and protocol. The GAPI programming interface, an important product of the GACS Project, is also described.

Section 4 describes the achievements of the GACS Project, in producing implementations of the GACS and ULS protocols, as specified in ICAO SARPs. Interoperability testing was performed as part of the ICAO validation activities, and an example CNS/ATM application was developed, starting from the operational service definition. Portability was demonstrated by providing the software on several different platforms.

Section 5 presents the development of an ATN application level performance-monitoring tool, as an example of rapid prototyping using the GACS service.

Section 6 describes how AOC communication via ATN was validated in a number of incremental steps, culminating in flight trials using an ATN-equipped test aircraft and the unmodified host systems of major commercial European airlines, via DSP message handling services. Direct communication with airline host systems was demonstrated using ATN-adapted HERMES, a ground messaging system employed by several airlines.

Section 7 concludes with a summary of the GACS Project achievements, the important contributions to standards validation and the synergy with the LINK 2000_ Programme.

Finally, a list of acronyms and abbreviations is included for reference.

Version: H/ACP/Bangkok/GACS Date: 3 November 2003 Page: 1


1.3 BackgroundEUROCONTROL was among the pioneers of the "Simple ATN Messaging" concept, that later evolved into GACS. As the ICAO Technical Provisions for ATN (Doc 9705 First Edition) were reaching maturity for publication in 1998, it was noted that the specifications of the CNS/ATM applications were rather inflexible. For example, it was difficult to introduce new CPDLC messages without changing the whole CPDLC application. The GACS concept was discussed in late 1997 as a means of facilitating the rapid specification and development of new applications, as well as a mechanism for enabling existing applications (e.g. ACARS-based) to migrate to ATN.

Consequently, Draft 1.0 of the GACS Technical Provisions was developed under EUROCONTROL editorship and presented to ATNP/WG3 in Naples, May 1999. The GACS material was approved at the third meeting of the ICAO ATN Panel in February 2000.

In parallel with the development of the GACS standards, EUROCONTROL embarked on a project to validate the standards by producing a portable software implementation. A requirements specification was developed in the period February – June 1998 and a Call for Tender was issued, closing 10 August 1998.

The contract for the development of GACS software was let to Airtel ATN in November 1998.

The GACS implementation project originally consisted of three phases:

I. The development of GACS software and the demonstration of its functionality;

II. The integration of an air-ground application and its demonstration in a simulated environment;

III. Flight trials of the application from Phase II.

The results of the GACS implementation project were included in the ATNP validation report for ICAO Doc 9705, covering:

GACS technical provisions,

ATN connectionless upper layers, and

Dialogue Service naming and addressing extensions

The report was available by the ATNP/WG3 meeting in September 1999 for submission to the ATN Panel meeting in February 2000.

The GACS software is available free of charge (subject to licence conditions) to EUROCONTROL Member States and other organisations to assist in their ATN evaluation and trials activities.

A CD has been produced containing the results of the project.

1.4 References[1] Manual of Technical Provisions for the Aeronautical Telecommunication Network

(ATN) - ICAO Doc. 9705 Third Edition – April 2002

[2] ARINC Specification 637-1: Aeronautical Telecommunications Network (ATN) Implementation Provisions, Part 1, Protocols and Services (April 2000)

ATNP Working papers:

[3] ATNP/WG3/IP 16-01 (11 May 1999) Potential future Operational Requirements for the Generic ATN Service – GACS –

[4] ATNP WG3/15-WP/17 (Jan 99) EUROCONTROL GACS Implementation and Validation



[5] ATNP WG3/16-WP/09 (May 99) EUROCONTROL GACS Implementation Project Update

[6] ATNP WG3/17-WP/10 (Sep 99) ATN Application Level Systems Management Utilities

[7] ATNP WG3/17-IP/01 (Sep 99) EUROCONTROL GACS Implementation Project Update

[8] ATNP WG3/19-WP/39 (Aug 2000) EUROCONTROL GACS Developments

[9] ATNP WGB/02-WP/22 (Mar 01) AOC/GACS demonstration

[10] ATNP WGB/03-IP/07 (Mar 02) EUROCONTROL GACS Project Update

Presentations to AEEC Datalink Users Forum:

[11] EUROCONTROL AOC/GACS Demonstrator (Boston, MA, 25-26 July 2001)

[12] EUROCONTROL Trials of AOC/ATN via DSP (Brussels, 4-5 Feb 2002)



2. GACS GENERAL DESCRIPTION

2.1 IntroductionThe Generic ATN Communications service (GACS) allows a user of the service to transfer data transparently across the ATN to another user (or to multiple users). The user is able to specify the required quality of service (QoS) and recipient addressing parameters on a per-message basis. In principle, the GACS service can operate over any bearer service.

The GACS protocol specification is designed to optimise the use of communications bandwidth, and consequently uses the Dialogue Service defined in Sub-Volume 4 of ICAO Doc 9705, including extensions for unit data and presentation address handling services. The Dialogue Service in turn uses the ATN Transport service defined in Sub-Volume 5 of ICAO Doc 9705.

The GACS user is able to select the required level of service, which in turn results in the use of either a connection-oriented (CO) or connectionless (CL) supporting protocol stack.

ICAO Doc 9705 allows the GACS service provision to be realised alternatively as an "Application Layer message protocol" or as a "simple generic service". The two approaches as illustrated in Figure 1 are very different and have different fields of applicability.

For the GACS implementation project, the GACS Application Entity (AE) approach was adopted, as illustrated in the left-hand side of Figure 1. This provides an ATN access point to existing (e.g. ACARS-based) and future applications that are not specified as ASEs within the defined ATN upper layer architecture.

However, the GACS software is designed to be modular and portable, so that it could be adapted in the future to realise the alternative GACS Application Service Object (ASO) or "service" approach, as illustrated in the right-hand side of Figure 1. This would provide effectively an enhanced Dialogue Service to future air-ground and ground-ground ATN applications (either ATC and AOC) that are specified as ASEs.

The GACS AE approach is appropriate for the migration of existing applications. The GACS ASO (enhanced dialogue service) approach would be preferred for any new ATC or AOC application.

The GACS Application Entity is a distinct ATN application installed in aircraft and ground systems acting as a point of access to the ATN. An ATN address is allocated to the


Figure 1. GACS Application versus GACS ASO


GACS AE. The existing CM Application could be used without modification to exchange the address and version number of the GACS application in the air-ground environment where GACS is used to host ATS Services.

GACS-Users in this approach are not considered as fully integrated ATN applications; they have no distinct ATN names and no ATN addresses. CM is not used to negotiate version numbers for the users. Specific mechanisms need to be implemented to switch the incoming data to the relevant GACS-User, based on the message-type identifier.

The GACS service is exposed via a well-defined application programming interface (API), providing a communications interface to user applications.

Several GACS-Users are able simultaneously to use services from the same GACS Application. The GACS Application multiplexes data supplied by GACS-Users over the same dialogue when the intended recipient and the requested communication characteristics are identical.

The GACS Application itself does not know anything about the user message contents, or the encoding rules for these messages. Typical communication functions, such as sequence numbering and request/reply correlation are entirely the responsibility of the GACS-User applications.

2.2 GACS Service Definition

2.2.1 OverviewThe GACS software provides the services listed in Table 1.

Table 1. Summary of GACS Service primitives

Service Description

G-TRANSFER This is an unconfirmed service used to transfer User-Data between communicating GACS-Users.

G-TRANSFER-CONFIRMED

This is a confirmed service used to transfer User-Data between communicating GACS-Users, and to provide the sender with confirmation that the data was received at the remote peer system(s).

G-END This is an unconfirmed service used optionally to terminate an established communications relationship between communicating GACS-Users.

G-MULTICAST This is an unconfirmed service used optionally to indicate whether a user wishes to receive messages sent to a particular group address.

For the basic G-TRANSFER and G-TRANSFER-CONFIRMED services, a number of options are defined, and these can be selected via the “Level Of Service” parameter:

a) Connectionless Mode. If the user does not require a resilient communications service (e.g. because the message is not mission-critical, or because the user application itself implements an error recovery protocol) then this can be requested per message. In this case, a connectionless (CL) protocol stack, if available, will be used to transfer the message, provided the size constraints of the CL stack are not exceeded.

b) Connection-Oriented Mode. If the user does require a resilient communications service (e.g. because the message is mission-critical, and the user application itself does not implement an error recovery protocol) then this can be requested per message. In this case, a connection-oriented (CO) protocol stack will be used to transfer the message.



c) Single-shot option. If the GACS user wants to send just a single message or infrequent messages to a given recipient, then "single-shot" mode can be selected. This optimises communication resources by using a connectionless or transient connection mode relationship between the communicating entities, depending upon the data integrity requirements.

c) Multi-shot Option. If the user intends to send multiple messages with the same Quality of Service (QoS) requirements to the same destination(s), then it can optionally request a “multi-shot” mode. This establishes and maintains a communication relationship with the specified peer(s), and provides an optimised use of the communications link, using a CO protocol stack. The G-END service is an optional service, which allows a user of the multi-shot option to inform the GACS service that a communications relationship with the specified peer(s) is no longer required to be maintained. This allows an orderly freeing of resources, and an assurance that there are no messages in transit to or from that particular peer(s). If G-END is not used, then any established communications relationship between two peers will automatically be ended by the GACS service on expiry of a configurable inactivity timer.

2.2.2 The G-TRANSFER serviceThe G-TRANSFER service enables the transparent transmission of data between GACS-Users.

G-TRANSFER is an unconfirmed service, invoked by one GACS-User (the initiator) to send data to a peer GACS-User (or multiple peer users). G-TRANSFER request and indication service primitives are defined, as illustrated in Figure 2.

Figure 2. G-TRANSFER Sequence Diagram

The initiating GACS-User issues a G-TRANSFER request primitive. When the receiving GACS-User receives the G-TRANSFER indication primitive, the User Data is presented transparently to that user. It is a local matter to decide whether or not any reply is needed. Either GACS-User may issue a G-TRANSFER request at any time. Any sequencing constraints must be enforced by the GACS-Users themselves.

2.2.3 The G-TRANSFER-CONFIRMED serviceThe G-TRANSFER-CONFIRMED enables the transparent transmission of data between GACS-Users, with confirmation of data delivery to the recipient system(s).

G-TRANSFER-CONFIRMED is a confirmed service, invoked by one GACS-User (the initiator) to send data to one or more peer GACS-User(s). Request, indication and confirmation service primitives are defined, as illustrated in Figure 3.



The initiating GACS-User issues a G-TRANSFER-CONFIRMED request primitive. When the GACS service delivers the G-TRANSFER-CONFIRMED indication primitive, the User Data is presented transparently to the recipient, and a confirmation primitive is automatically returned to the initiator. It is a local matter to decide whether or not any user reply to the indication primitive is needed. Either GACS-User may issue a G-TRANSFER-CONFIRMED request at any time. Any sequencing constraints must be enforced by the GACS-Users themselves.

2.2.4 The G-END serviceThe G-END service enables the orderly termination of a communications relationship between GACS-Users.

G-END is an unconfirmed service which is optionally invoked by one GACS-User (who is then the initiator) to terminate a communications relationship with one or more peer GACS-User(s). G-END request and indication service primitives are defined, as illustrated in Figure 4.

Figure 4. G-END Sequence Diagram

The initiating GACS-User issues a G-END request primitive at any time after using the G-TRANSFER or G-TRANSFER-CONFIRMED service with a multi-shot Level of Service. When the receiving GACS-User receives the G-END indication primitive, it knows that the current communications relationship with the peer is over. A new relationship may be established at any time. It is a local matter to decide whether or not any user reply is needed. Any sequencing constraints must be enforced by the GACS-Users themselves.


Figure 3. G-TRANSFER-CONFIRMED Sequence Diagram


2.2.5 The G-MULTICAST serviceThe G-MULTICAST service is a placeholder to enable or disable the receipt of messages addressed to a group address, if the ATN lower layers are ever enhanced to support this facility.

G-MULTICAST is an unconfirmed service, optionally invoked by a GACS-User to inform the local communications system whether that user wishes to receive messages sent to a particular group address.

Only a G-MULTICAST request primitive is defined, as illustrated in Figure 5, which the initiating GACS-User will be able to issue at any time.

Figure 5. G-MULTICAST Sequence Diagram

The multicast service is not currently implemented.

2.3 The GAPI InterfaceOne of the key deliverables of the EUROCONTROL GACS project was the definition of the GACS Application Programming Interface, or "GAPI". This is a portable C language interface library that allows user applications to be developed independently of the GACS software, and linked with the GACS client at system build time.

The GAPI consists of a number of procedure calls that map to the GACS service primitives, and some additional procedure calls for initialisation, termination and flow control.

2.4 The GACS ProtocolThe GACS protocol utilises a header, specified in ASN.1 and encoded using the Packed Encoding Rules, that contains the necessary control, quality of service and addressing information. The user data, whose encoding is completely transparent to the GACS protocol, is embedded in the header.

GACS in turn makes use of the ATN Dialogue Service, which maps to OSI upper layer protocols as defined in the ATN SARPs.



3. INITIAL GACS DEVELOPMENT

3.1 Basic GACS and ULS DeliverablesThe first phase of the GACS implementation project produced software implementations of the following components:

The ATN Connection-oriented Upper Layers (CO Session layer efficiency enhancement option, CO Presentation layer efficiency enhancement option, CO ACSE edition 2 and Control Function).

The ATN Connectionless Upper Layers (CL Session layer efficiency enhancement option, CL Presentation layer efficiency enhancement option, CL ACSE edition 2 and Control Function).

The Generic ATN Communications Service (GACS), providing a well-defined GAPI interface for applications to use the full ATN protocol stack, using a client-server architecture in which multiple users can utilise GACS services from a single Server process.

A demonstration Graphical User Interface (GUI) based on the draft operational requirements for the Pilot Preferences Downlink (PPD) application.

The portable software implementation uses the services of the EUROCONTROL TAR-TTS (components of ATIF - ATN Trials Infrastructure) to provide the ATN CO and CL Transport Services, thereby comprising a full 7-layer ATN stack.

The EUROCONTROL Agency formally accepted delivery of the GACS and supporting ULS software and associated documentation on 27 August 1999.

3.2 Interoperability TestingThe objective was to plan, conduct and document interworking trials between the software developed under the GACS Implementation Project, and similar software developed independently. This was to enhance the level of validation achieved for the ATNP “Package 2” Upper Layer enhancements.

Contact was established with other implementers of the "Package 2" ULCS provisions, connection-oriented and especially connectionless, as a starting point for the interworking trials. Activities included liaison with the third-party software provider(s), test planning and definition, execution of agreed tests, and production of a test report.

Interoperability tests were conducted at the level of the Connectionless Dialogue Service (CLDS) between the EUROCONTROL software and software developed independently under the CENA CHARME project.

3.3 GACS Demonstration Application - PPDThe GACS software was delivered with demonstration functionality, which gives an example of the usage of the GACS product. This consists of a sample Pilot Preferences Downlink (PPD) application, which has a Graphical User Interface (GUI).

The GACS demonstration application serves the following needs:

It provides an example of how the GAPI may be utilised.

It provides a tool for demonstration of the GACS package.

It provides a tool capable of black box testing the GACS package.



The demo application consists of a command line interface (CLI), which can fully exercise the GAPI, and a graphical user interface (GUI), which is provided for demonstration purposes. The demo application is developed using the Tk/Tcl toolkits. The Tcl toolkit aids in the development of the CLI and the Tk toolkit provides GUI support.

PPD is an ATM application whereby the flight crew informs the controller of various preferences they hold regarding the flight parameters. This enables the controller to make more informed decisions. The GUI implementation of the PPD application (included with GACS) does not follow any PPD specifications and is intended purely for GACS demonstration purposes only. It enables the airborne sender to select and downlink the following PPD messages:

Preferred Operating Climb Airspeed

Preferred Cruise Flight Level

Maximum Flight Level

Preferred Operating Cruise Airspeed

Top of Descent Time

Preferred Operating Descent Airspeed

Current Configuration Operational Speed Range

Minimum Clean Manoeuvring Speed

Preferred Arrival Holding Speed

Intermediate Approach Speed

Minimum Uncorrected Approach Speed

Preferred Landing Runway

3.4 Portation OptionsThe software was designed to be portable for execution on different hardware and operating system environments. It was delivered pre-ported to HP-UX and PC Solaris platforms. A further porting exercise produced:

a Windows 98 version of the GACS client and PPD demonstator (requires a GACS/ATN server running on UNIX platform)

a Windows NT version of the GAPI cleint in order to support the Rockwell-Collins HERMES ground messaging system.



4. ATN “HEALTH CHECK” UTILITY

4.1 Functional DescriptionA standardised application-level responder utility could be an invaluable aid to real-time operational fault diagnosis and performance evaluation of the ATN as a whole. If implemented on all ATN end systems, the utility outlined here could provide an authorised user with a simple consistent means to perform the following functions:

a) to determine the reachability of a given remote end system (application level “ping” function);

b) to provide a simple health check of the end-to-end path between two systems;

c) to measure round-trip delay, as a function of ATSC class and priority;

d) with time synchronisation, to measure the transit delay, as a function of ATSC class and priority;

e) to measure connection set-up time for application associations;

f) over time, to build up statistics enabling the general performance metrics required by ICAO Doc 9694 (Manual of Air Traffic Services Data Link Applications) to be monitored;

g) to verify data integrity across the ATN;

h) to execute simple management commands on a remote end system.

Since the GACS service provides applications with all the ATN communications capabilities they require, it should be relatively easy to construct a simple responder application on top of GACS, and this could form the basis of a globally useful ATN application Healthcheck Utility.

With this in mind, a prototype utility was developed, providing two basic functions for

Simple confidence test and round trip time measurement;

Automatic response supporting data integrity check and measurement of transit delay and application association establishment delay.

Figure 6. Simple confidence test and round trip measurement

These are illustrated in Figure 6 and Figure 7, respectively, showing the relationship to the GACS services used. GACS was considered a suitable basis for such a utility, as it provides much of the required functionality in terms of services defined, message demarcation and parameter selection.



Figure 7. Automatic response supporting data integrity check and transit delay monitoring

4.2 Implementation ApproachThe Healthcheck Utility was implemented using the GACS-AE. It comprises two distinct functional elements, the initiator and responder elements, as illustrated in Figure 8.

Figure 8. SM Initiator and Responder functions

The initiator is driven by a graphical user interface (GUI), an example of which is illustrated in Figure 9. The user of the Healthcheck Utility simply enters details of the test(s) to be performed via the data entry screen, and the results can be displayed in real time. Multiple tests may be scheduled to run automatically or until stopped by the user.

The measured end-to-end delays can be analysed as a function of Class of Communication or of Priority, and can be displayed in a summary table, as shown in the example in Figure 10.

EUROCONTROL accepted delivery of the GACS-based Healthcheck Utility on 10 May 2000. It is available, under licence, to EUROCONTROL member States and other interested parties.



Figure 9. Example Test Schedule Screen

Figure 10. Example of Results Display, analysed by Class



5. THE EUROCONTROL AOC/ATN DEMONSTRATOR

5.1 Introduction to AEEC Specification 637Prior to ATN availability, data communications across the air-ground link have traditionally been accomplished by using the Aircraft Communication Addressing and Reporting System (ACARS). A requirement therefore arises to provide a migration path for existing ACARS applications to operate over an ATN infrastructure.

AEEC Specification 637 was produced by the Airlines Electronic Engineering Committee (AEEC), and was published by ARINC in April 2000. Its scope is to describe the communication functions that should be performed by aircraft avionics and ground systems to transfer ACARS messages using ATN protocols and services.



Figure 11. ARINC 637-1 ATN Architecture for AOC and ATC

The AEEC made the crucial decision to specify the use of GACS over a connectionless ATN protocol stack as the migration path for AOC communication via a datalink service provider. The defined architecture also enables Airlines to use the connection mode stack for their own purposes.

AEEC Specification 637 specifies how legacy ACARS applications, both AOC and ATC, can be migrated to an ICAO standard ATN infrastructure by means of the standard Generic ATN Communications Service (GACS), which is specified in the 3 rd edition of the ICAO ATN SARPs.

Figure 11 illustrates the airborne architecture specified in AEEC 637 for accommodating both ICAO-defined ATSC applications and legacy ACARS applications over an ATN air-ground data link.

The important feature to note is the use of GACS to bridge the ATN and non-ATN worlds by allowing ACARS messages to be encapsulated as GACS user-information. The “AEEC 620 Messaging Convergence Function (620CF)” component simulates the



ACARS 618 air-ground message protocol. A similar component on the ground can then extract the ACARS messages from the GACS user-information and process them as existing ACARS messages.

With GACS/ATN, AOC messages can be routed between an airline’s host computer system and an individual aircraft by means of the “traditional” ACARS approach. That is, a Datalink Service Provider (DSP) such as ARINC or SITA would serve as an intermediary and perform ATN message routing over the air-ground datalink. The ground-ground communication between the airline and DSP is unaffected, and no changes to the airline’s host system are necessary.

Alternatively, for airlines that are equipped with their own ATN Router, AOC messages can be transferred directly between flight deck and airline host system without the use of an intermediary, using ATN routing over the end-to-end path.

5.2 Integration with e-Cockpit SimulationAOC messaging is supported in the cockpit by means of the Multi-Function Control and Display Unit (MCDU), as described in AEEC Characteristic 739. Aircrew can display received (uplink) messages on this device, and can compose and send downlink messages by means of a nested menu of formatted data entry screens.

An airborne simulation was developed that is effectively a prototype of a real AEEC 637 compliant AOC solution, with the potential to interwork with existing DSP ACARS systems, once GACS-enabled. This can be seen as a stepping-stone to a full aircraft CMU and Router. A simulated ground implementation was also produced, with appropriate functionality to drive the airborne implementation.

The EUROCONTROL implementation builds on the existing GACS-AE implementation and provides the following additional functionality:

Software implementation of the ACARS Convergence Function;

Graphical user interface (GUI) for cockpit display unit emulation;

Simple ground message generator/receiver.

The airborne AOC simulator developed in EUROCONTROL comprises an MCDU emulation with a gateway to ATN GACS software. A counterpart Ground Application Emulation was also developed, also using GACS.

The GACS software has a client-server architecture, as illustrated in Figure 12. The GACS server process links directly to an ATN upper layer communication stack, which in turn interfaces to the ATN Transport Service offered by the Trials Transport Server (TTS). The GACS client is linked to the GACS-user application, and one or more clients communicate with the GACS-server via a sockets interface. The GACS client subsystem provides a well-defined C language interface, the GAPI, providing air and ground applications with an interface to the GACS service and hence to the ATN.

The “CF620” is a GACS-user component that implements the AOC/GACS protocol defined in AEEC Specification 637. This provides a higher-level interface to user software developed in either C or Java.

Using the CF620, it is possible to emulate both modes of communication described in ARINC 637, i.e.:

AOC over ATN to/from Datalink Service Provider (DSP) and

AOC over ATN to/from an Airline Host.

A mechanism to select one of these options is provided to the user of the emulation.



Figure 12. Components of AOC/ATN Demonstrator

The implementation was integrated with the existing EUROCONTROL e-Cockpit emulator (www.eurocontrol.fr/projects/freer/e-Cockpit14Apr2000/index.html) to provide a realistic GUI environment. The e-Cockpit (also used for the ECAC Cockpit Display of Traffic Information (CDTI) evaluation system) interface is completely written in Java. The simulated cockpit display unit (MCDU) has software buttons that invoke event handlers when activated. For the e-Cockpit event handlers, components can be plugged into the HMI as Java Beans. The e-Cockpit realisation is based on the ILOG JViews product (www.ilog.com/products/jviews). The GUI is illustrated in Figure 13.

The GACS project included integration of the C language GACS Application Programming Interface (GAPI) with the Java environment. The Java API socket interface was mapped to GAPI and ATN by the implementation of ATN/XTI and GACS interfaces, in addition to the standard TCP/IP interface, in the Java.net library. The actual interface used in any instance is selected by environment variable. In this way, applications written in Java can access TCP/IP, the ATN Transport Service, or the GACS service, with no need to use the Java Native Interface.

For a real aircraft communications management unit (CMU) running the Vertex real time environment, the software 620CF should be developed in (a cut-down version of) C, as it is believed that Java is not supported under Vertex. Therefore, rather than develop the 620CF as a Java application using the java.net GACS interface, the 620CF was integrated into java.net itself, thus providing a Java interface for AOC applications.

Uplinked information is displayed on the simulated MCDU, using input gathered from existing ACARS users obtain a realistic emulation.


http://www.ilog.com/products/jviews

http://www.eurocontrol.fr/projects/freer/e-Cockpit14Apr2000/index.html


Figure 13. View of the Eurocontrol e-Cockpit graphical user interface

The MCDU emulation software allows demonstration of how airline users could make use of Airline Operational Communications (AOC) during the lifetime of a typical flight, with a data link communications service based on the Generic ATN Communications Service (GACS).

For the ground side, the existing GACS demonstration graphical user interface (DemoGUI) was extended to allow AOC messages in 637-1 format (i.e. with 618 fixed-length headers) to be entered for uplink and displayed on downlink.

5.2.1 AOC Demonstration ScenarioTypically, on power-up, the MCDU offers aircrew a choice of applications. The required application may be selected at any time by pressing the appropriate line select key. The main application menu would offer a choice of:

AOC MAIN Entry to the top-level AOC index – the main subject of this scenario.

ATC Entry to the FANS-1/A applications

TECHNICAL/COMM Miscellaneous commands.

Having selected AOC MAIN, the MAIN INDEX would be the initial screen displayed to the flight deck user. This menu provides flight crew access to AOC datalink menus and functions. For example, the following choice might be presented:

PREFLIGHT*

ENROUTE

POSTFLIGHT*

MESSAGE LOG

MAINTENANCE*

ATC*

AIRLINE COMM*

REPORTS

REQUESTS

FLT DATA*



Note.— The items marked with an asterisk (*) are not implemented in the EUROCONTROL e-Cockpit MCDU demonstration system.

An informal study of one airline showed that the following AOC messages are used in a typical flight, and these messages were implemented in the demonstration system:

OUT, OFF, ON, IN (OOOI) (aircraft movements)

AIRPORT DELAYS

AIRPORT NOTAMS

APU REPORT

DISPATCH MSG

ENGINE REPORT

ENROUTE NOTAMS

FLIGHT PAPERS RQST

GATE ASSIGNMENT

HOWGOZIT REQUEST (flight monitoring)

MISC REPORT (free text)

RUNWAY DATA

WEATHER BRIEFING

5.2.2 Use of MCDU Screens and ButtonsMany of the formatted screens presented to users have one of more fields into which data can be entered. In some cases, the fields may be pre-loaded by the system with default values or values obtained from other systems (e.g. FMS). The user can overwrite such fields if required.

In some cases, users can enter free text by means of an alphanumeric keyboard. The Edit Free Text page allows the operator to review and edit free text. This page is accessible from the EDIT TEXT prompt on any page providing free text entry. When the ENTER button is pressed, the entered free text is passed back to the calling page.

Many screens also have a SEND button. When this is pressed, a message is queued for downlinking over the air/ground datalink.

Many screens also offer a PRINT function, allowing hard copies of certain reports to be printed via the cockpit printer.

Uplink AOC messages may be received in an aircraft via a DSP or direct from an airline host computer system.

Received uplink messages are stored in a buffer. The MESSAGE LOG page allows the operator to select an individual uplink display message for viewing. A total of twenty messages can be held for review. Once the queue is fill, a new message replaces the oldest message in the queue. The queue is cleared at the flight state transition to the BEGIN LEG state. A View Status attribute distinguishes between new messages that have not been displayed and messages requiring acknowledgement that have not yet been acknowledged, and messages that have been displayed.

Once a received message is selected by the user, the Message Log review page is displayed, giving the full text of the message, together with the UTC time that the message was received and an option to PRINT the message on the cockpit printer.



5.2.3 Message IdentificationAll ACARS messages between air and ground have an associated two-character “Label”, and this is retained in the AOC/GACS specification. The Label is used to refer to the message contents and may also be used to determine routing and addressing. A list of assigned Labels is defined in AEEC Specification 620.

In the initial implementation, the majority of downlink messages in the emulated system, have an ACARS label of “5Z” (Airline Designated Downlink).

The majority of uplink messages in the emulated system have an ACARS label of “RA” (Command/Response Uplink). The first 16 characters of message text, or the characters preceding the first CR or LF, whichever is the shorter, are interpreted as the message title. In this case, a sub-label field defines how the message is to be queued or actioned:

1 – Display and Store. The message is held in the received message queue. Optionally, displayed text is scanned for the presence of an acknowledgement field, identified by the format “(nnnn)” (this is not implemented in the demonstration system).

2 – OOOI (Out, Off, On, In) Information Request. The airborne system would respond with an RB~2 (Command/Response Downlink) message (not implemented in the demonstration system).

4 – Loopback Test Request. The airborne system would respond with an RB~4 message (not implemented in the demonstration system).

5 – Display Once. Once viewed, this message is deleted from the queue.

6 – Display Overwrite Message. Upon reception, any held message with the same message title (defined as above) is deleted from the queue.

5.3 AOC/ATN ArchitectureFurther work was undertaken in the GACS project to produce a realistic demonstration of Airline Operational Control (AOC) communications using ATN, as specified in AEEC Specification 637, in parallel with ATS applications.

This required the development of airborne and ground test systems, as described in the following subsections.



5.3.1 Airborne System

Figure 14. Airborne software architecture

Figure 14 shows the airborne software architecture. The "GACS" component refers to the complete ATN ULCS and ICS communication stacks as specified in Doc 9705 third edition. The "CF620" component refers to the ACARS Convergence Function specified in AEEC Specification 637.

The ATSC (PETAL II) communication stack is shown in parallel for comparison. Laboratory trials were performed of ATSC and AOC communications operating simultaneously.

There are effectively two independent AOC systems, with different purposes:

The Java-based Multi-function Control and Display Unit (MCDU) emulation.

This is the previously described laboratory demonstration system, providing ATN access to applications written in the Java programming language. The MCDU emulation is one component of EUROCONTROL's e-Cockpit, a simulation of the Boeing 777 cockpit.

The simplified cockpit AOC Data Link Terminal (ADLT) implementation.

This is a further development, which uses the same touch screen aircrew interface device as the PETAL-ATIF ATSC services flight trials. In order to interface with the HMI, an "AOC Service Function" (ASF) was developed. This is analogous to the PETAL Service Function (PSF), which implements the "User" part of the Doc 9705 Sub-Volume II air-ground applications.

The role of the ASF is to handle the different AOC message types, and to interface between the record-oriented AOC touch-screen terminal (ADLT) and the CF620. The initial version of the ASF component was restricted to handling the AOC message types used with the e-Cockpit emulation, described above. This software was delivered to EEC Brétigny on 7 August 2001 . An enhanced version, capable of using GACS confirmations for selected AOC message types, was accepted on 2 November 2001.



5.3.2 Ground System – Airline Host Emulation

Figure 15. Ground software architecture

Figure 15 shows the ground system software architecture. Again, the ATSC communication stack is shown in parallel for comparison.

There are effectively two independent AOC systems, with different purposes:

The simple AOC messaging emulation.

This is a laboratory demonstration system, which is essentially an engineering interface, allowing AOC messages to be sent and received, in order to exercise the functionality of the counterpart airborne system. It is relatively inflexible and offers no message processing functionality.

The HERMESTM ground system.

In collaboration with Rockwell-Collins UK, the commercially offered HERMES Ground System was integrated with the EUROCONTROL AOC demonstrator by means of a prototype "GACS connector" component. This provides a real interface to ground AOC users, as used by actual airline operations. This serves to provide a PC-based demonstration system for showing ACARS over ATN, as well as demonstrating that:

a) Existing communication applications can readily be integrated with ATN by means of the GACS Application Programming Interface (GAPI)

b) The AEEC 637 protocols are a valid and complete way of encapsulating ACARS air-ground communication over an ATN infrastructure

c) The EUROCONTROL airborne system correctly formats and interprets the AEEC 637 air-ground message format (via interoperability between the airborne test system and a commercial ground system).

In order to support the HERMES NT platform, the GAPI client was ported to the Windows NT environment.

5.3.3 Ground System – Service Provider ConfigurationUp to this point, the description has dealt with direct communication between a simulated ATN-enabled airline host system and the flight deck of one of that airline's aircraft. A



perhaps more typical transition scenario envisaged by AEEC 637 is that airlines may initially continue to use the services of Datalink Service Providers (DSPs) who currently provide ACARS communication services. Thus, the aircraft would be ATN enabled for both ATS and AOC communication, but the airline's ACARS ground system would not need to change.

This mode of operation has been validated, using connectionless communication between aircraft and ground system, in collaboration with a commercial DSP and major European airlines, as described below.

Figure 16. Airline host communication via DSP

The ground ATN end system acts as a DSP's remote ground station (RGS), using GACS to send and receive air-ground AOC messages over ATN in AEEC 618 format. The messages are relayed via X.25 to the DSP central message switch.

This required the evolution of the ground CF620 component and the development of a new AOC-to-DSP Interface component, known as "ADIX". The role of ADIX is to handle X.25 communication with the DSP, supporting the AEEC 618 acknowledgement protocols, and inserting the AEEC 618 protocol fields that are missing in the header format specified in AEEC 637 for air-ground communication via GACS. The enhanced CF620, incorporating ADIX functionality, underwent site acceptance testing at EEC Brétigny on 4 – 7 March 2001.

The DSP message processor converts between AEEC 618 format and AEEC 620 ground-ground format, and routes messages to/from the airline's ACARS ground host system, using traditional IATA Type B communication.

The ground end system was delivered to the EUROCONTROL Experimental Centre in March 2002, following successful communications tests between the DSP and simulated airborne system, using the AOC message set implemented in the e-Cockpit simulation.

No change is required to either the airline host system or the DSP message switch.

This configuration has allowed a number of interoperability and addressing issues to be addressed experimentally. It provides a realistic demonstration of airline operational communications with ATN-equipped aircraft in its fleet.



5.4 ATS/AOC Flight Trials with SITA, BA and LufthansaUsing the airborne and ground systems described above, AOC and ATSC systems were installed in a test aircraft to perform flight trials while communicating with operational airline AOC messaging systems. This allowed trials of AOC and ATC communication operating in parallel over an ATN datalink. The trials used the QinetiQ (DERA) BAC 1-11 test aircraft. A SATCOM datalink was used in the trials, though the results are applicable also to the VDL-2 technology adopted for the EUROCONTROL co-ordinated LINK 2000+ programme.

During flights over southern England in May 2002, the research aircraft was registered as part of the airlines' operational fleet, and was given a simulated flight number. Messages relating to the aircraft operation were interchanged between flight deck and airline host system using the ATN gateway system hosted at the EUROCONTROL Experimental Centre and routed via the SITA message switch test bed in Montreal. To the SITA system, the ATN gateway appeared as a conventional Remote Ground Station (RGS) as used for ACARS communication today.

5.4.1 British Airways Trials ScenariosThe first AOC/GACS flight trials were performed in collaboration with British Airways (BA). The BA test ACARS system (an exact replica of their operational system) at Heathrow was used to send and receive messages to/from the QinetiQ BAC 1-11 test aircraft, which appeared to the BA host as flight BA9999 in aircraft G-TEST. Message routing was:

IATA "Type B" messages between BA ground system, via Amadeus network, and SITA test bed DSP in Montreal

ACARS 618 messages between SITA test bed DSP and ATN Gateway at EEC Brétigny

AEEC 637 (ACARS encapsulated in GACS) messages between EEC and test aircraft, via Inmarsat SATCOM link and Aussaguel Ground Earth Station.

The airborne software (ASF component) was modified to handle a subset of the messages used operationally by BA in managing their aircraft fleet worldwide. The message set used for the trials scenarios is listed in Table 2 and Table 3. These tables show the ACARS air-ground message label and Type B ground-ground Standard Message Identifier (SMI) as seen by the BA Host system. The software changes were made conditional upon a compilation flag so that it is possible, by recompiling, to use either the original UAL message set or the BA message set defined here. The modified airborne software was delivered to EEC Brétigny on 11 April 2002.

Table 2. Uplinks Sent from BA Host or Simulated ATC Centre

ACARS Label

Type B SMI

Description

10 M10 User-defined uplink:INI11 INITIALIZATION DISPLAY MESSAGEMET11 WEATHER DATA MESSAGEMET12 WEATHER SUMMARY DATA MESSAGEAIS11 AIS DATA MESSAGESIG11 SIGMET DATA MESSAGEDFM11 DATA FREQ TABLE UPDATE MSGDIA11 ACARS DIAGNOSIS DATA REQUESTFRM11 DEFECT REPORT REQUESTFPL11 FLIGHT PLAN DATA MESSAGEWAB11 WEIGHT/BALANCE MESSAGE



PRI11 PRINTER MESSAGEDIS11 DISPLAY MESSAGE

PAD11 PRINTER AND DISPLAY MESSAGE

FST11 FLIGHT STATUS DATA REQATC11 ATC ADDRESS MENU UPDATEPER11 PERFORMANCE DATA MESSAGE

33 M33 User-defined uplink: VHF VOICE CALL MESSAGE

34 M34 User-defined uplink: HF VOICE CALL MESSAGE

35 M35 User-defined uplink: SATCOM VOICE CALL MESSAGE

54 GVR Voice Go-Ahead (or ACARS Frequency Uplink) : VHF VOICE CALL (NON-COMPANY) MESSAGE

A1 CLX Oceanic Clearance from ATC (623 message)

A3 CLD Departure Clearance from ATC

A4 FSM Flight Systems Message (Clearance Request from ATC)

A9 DAI ATIS Report from ATC

H1 various Peripheral messages (619 message)Sublabels: DF, T1, M1, M2, MD, CF, S1, S2, SD)SMIs: DFD/DFX, TT1, FCL/FML, FCR/FMR, FCD/FMD, CFD/CFX, SDL, SDR, SDD

RA CMD Command/Response Uplink (~2, ~3, ~4 only)

S1 NSR Network Statistics Report Request

Uplink messages used in the trials scenario are listed in Table 2. The main airborne processing of these messages is to format them and pass them to the ADLT for display in the cockpit. Uplinks originating from a simulated ATC Centre (Simulated AEEC 622 and 623 messages) are also displayed. The following uplinks, as well as being displayed, generate an automatic downlink message:

RA~2 (OOOI dump).

RA~4 (Loopback test).

10/WAB11 (Weight and balance message).

Downlink messages used in the trials scenario are listed in Table 3. These messages are generated by the test operator in the trials aircraft and received by the BA ground ACARS processing system.

Table 3. Downlinks sent to BA Host

ACARS Label

Type B SMI

Description

10 M10 User-defined downlink:DTO01 Delayed Takeoff ReportAIS01 AIS RequestFTX01 Free Text DownlinkFPL01 Flight Plan RequestWAB01 Weight & Balance RequestMET01 Weather Data RequestWAB02 Weight and Balance Acknowledgement (automatically generated)

15 M15 User-defined downlink:FST01 Flight Status Report



H1 various Peripheral messages (619 message)Sublabel DF/SMI DFD/DFX ACMS/STARS DownlinkSublabel M1/SMI FML FMC Message

11 M11 OUT Report

12 M12 OFF Report

13 M13 ON Report

14 M14 IN Report

B6 PAR Simulated 622 Message (Provide ADS report) (Routed to simulated ATCC)

BF CWR Simulated 623 Message (CPC WILCO/UNABLE Response) (Routed to simulated ATCC)

RB RDO Messages generated automatically in response to certain uplinks:~2 OOOI Dump~4 AIS Request

5.4.2 Lufthansa Trials ScenariosAlthough in general each airline will have its own private message set, the ATN messaging solution is generic. This is demonstrated by the fact that trials were performed with Lufthansa using a different message set to that used in the BA trials. This required only that the airborne ASF software be re-compiled.

Further flight trials were held with the QinetiQ test aircraft simulating a Lufthansa flight, with Lufthansa in this case providing the ground airline host system.

For uplinks the Lufthansa host system generates Type B messages of standard message identifier (SMI) types AGM (which maps to Label C1) and FML (which maps to Label M1). The airborne software needed only a minor configuration file change to accept and display these labels.

For downlinks, the original UAL message set was used, with Labels 5Z, QA, QF, QC, QD and H1/WO (mapped by SITA to SMIs AGM, DEP, DEP, ARR, ARR and WXO, respectively).



6. CONCLUSIONS

6.1 SummaryThis report has described the development of GACS and ULS software compliant with the ATN technical provisions of ICAO Doc 9705 third edition. Indeed the software development was instrumental in refining and clarifying the ICAO technical provisions.

Also developed were some examples of application software that make use of the ATN communications access offered by GACS. These include an example ATC application, an ATN Healthcheck utility and AOC messaging software.

During development of the GACS and AOC software, the work resulted in a number of clarifications to the AEEC 637 specification and improved understanding of the issues involved in executing AOC/ATSC scenarios.

The EUROCONTROL GACS project has demonstrated that ATN communication is usable simultaneously by both ATS and AOC applications. The results have been presented in a number of fora, including AEEC Data Link Users Forum and ICAO ATNP Working Group meetings.

The EUROCONTROL GACS implementation project played a major role in ATNP/3 SARPs validation. The developed software provides a migration path for non-ATN (e.g. ACARS-based) applications and a rapid prototyping platform for the development of new ATM applications. The software will be important for ATN trials and exploitation in the future and will be available for free distribution under licence for non-commercial experimental use to EUROCONTROL Member States and other organisations.

A CD has been produced containing the results of the project.

6.2 Validation ContributionsThe lessons learnt from the GACS implementation project have resulted in important contributions to the validation of the ATNP Technical Provisions for:

GACS (ICAO Doc 9705, chapter 4.9),

ATN connectionless upper layers (ICAO Doc 9705, chapter 4.7), and

Dialogue Service naming and addressing extensions (ICAO Doc 9705, chapters 4.2, 4.3).

The main contributions have resulted from the implementation activity itself. This established that the relevant draft Technical Provisions are unambiguous, complete and accurate. Traceability between the individual requirements (“shall” and “should” statements) in the draft Technical Provisions on the one hand, and the software development documentation on the other hand has been maintained throughout the project lifecycle.

The GACS developments contributed to the validation of the Third Edition of the ATN Technical Provisions, and:

a) Demonstrate that new applications can be straightforwardly developed with little overhead in terms of software development or additional specification.

b) Demonstrate that legacy applications (e.g. AOC ACARS messaging) can readily be migrated to ATN.

c) Allow a number of ATN performance parameters to be monitored in a straightforward manner, via the completed Healthcheck Utility.

d) Validate the standard method for ACARS-to-ATN migration specified in AEEC Specification 637, and provide a prototype platform for AOC messaging.



6.3 LINK 2000+The flight trials demonstrate complete end-to-end communication between flight deck and airline legacy host system, based on ATN datalink technology.

The results of these trials strengthen the LINK 2000+ business case for airlines by demonstrating that a single avionics communications package can provide secure, reliable ATN datalink for airline as well as ATC messaging, without requiring expensive changes to existing airline ground infrastructures.

So it can be seen that ATN provides a general-purpose communications solution for both ATC and airline operational data communication. For these trials, no changes were required to either the BA or Lufthansa ground systems.



7. GLOSSARY620CF ACARS Convergence Function (in AEEC 637)

ACARS Aircraft Communications Addressing and Reporting System

ACSE Association Control Service Element

ADIX AOC to DSP Interface software component

ADLT AOC Data Link Terminal

AE Application Entity (in OSI architecture)

AEEC Airlines Electronic Engineering Committee

AOA ACARS over AVLC

AOC Airline Operational Control

API Application Programming Interface

ASE Application Service Element

ASF AOC Service Function software component

ASO Application Service Object

ATC Air Traffic Control

ATIF ATN Trials Infrastructure

ATM Air Traffic Management

ATN Aeronautical Telecommunication Network

ATNP ICAO Aeronautical Telecommunication Network Panel

ATSC Air Traffic Services Communication

AVLC Aircraft VHF Link Control

BA British Airways

CL Connectionless

CLI Command-Line Interface

CMU Communications Manage met Unit

CO Connection Oriented

CPDLC Controller-Pilot Datalink Communication

DSP Datalink Service Provider

EEC EUROCONTROL Experimental Centre, Brétigny-sur-Orge

FMS Flight management System

GACS Generic ATN Communications Service

GAPI GACS Application programming Interface

GUI Graphical User Interface

HMI Human-Machine Interface

ICAO International Civil Aviation Organisation



MCDU Multifunction Control and Display Unit

OSI Open Systems Interconnection

PPD Pilot Preferences Downlink application

SARPs ICAO Standards and Recommended Practices

SMI Standard Message Identifier (in AEEC 620)

TAR Trials ATN Router

TTS Trials Transport Server

UAL United Airlines

ULS ATN Upper Layer Communications Service

VDL VHF Data Link


Documents

GACS Project Achievements - International Civil … working groups library... · Web viewEUROCONTROL GACS Project Achievements Presented by: EUROCONTROL SUMMARY This information paper