Copy No.

AIRPORT INTEGRATION SERVICES

AIDX ACTIVE FLIGHTS UPDATE SERVICE (AAFUS)

APPLICATION SERVICE DEFINITION

dev\Products\UltraIB\Controlled\118 Issue 7.0

Date: 19/11/2013

Prepared on behalf of Ultra Electronics Airport Systems by:

Paul Crisp

© Ultra Electronics Limited 2012-2013

All rights reserved. No part of this document may be reproduced, duplicated,
distributed or sold in any form or by any means without prior permission in
writing from Ultra Electronics Limited.

Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

LIST OF CONTENTS

1. INTRODUCTION................................................................................................................. 3
1.1 PURPOSE................................................................................................................... 3
1.2 SERVICE DESCRIPTION............................................................................................3
2. SCOPE................................................................................................................................ 3
3. OUTLINE DESCRIPTION...................................................................................................4
3.1 BACKGROUND........................................................................................................... 4
3.2 SCHEMA, MESSAGES, WSDL...................................................................................4
3.3 FLIGHT DATA UPDATE...............................................................................................4
3.4 FLIGHT CREATE OPERATIONS.................................................................................4
3.5 FLIGHT DELETE......................................................................................................... 5
3.6 PERIOD OF USAGE....................................................................................................5
3.7 FLIGHT LEG IDENTIFICATION...................................................................................5
3.7.1 Flight Key (LegIdentifier)..........................................................................................5
4. APPLICATION LEVEL SPECIFICATION............................................................................7
4.1 MESSAGE SEQUENCE PARADIGM...........................................................................7
4.2 STATUS REQUEST/RESPONSE (HEARTBEAT)........................................................8
4.3 RESPONSE AND ERROR HANDLING........................................................................8
4.3.1 General.................................................................................................................... 8
4.3.2 Error Detection and Recovery..................................................................................8
4.4 DATA ELEMENTS USED BY AAFUS.........................................................................10
4.5 IB CONFIGURATION.................................................................................................10
4.6 ADDITIONAL INFORMATION....................................................................................10
5. BUSINESS RULES AND SECURITY................................................................................11
5.1 BUSINESS RULES....................................................................................................11
5.2 security features......................................................................................................... 11

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 2 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

1. INTRODUCTION

The AAFUS enables client systems to update active flight information. This
document describes the interface to this service, to enable a client system to
access the service.

1.1 PURPOSE
The purpose of this document is to provide detail on the architectural design of the
service, messages to be transferred and the real-time interaction between the IB
and client systems.
It is used to assist the design and implementation of third-party interface software
and defines how the non-functional requirements are satisfied and supported.

1.2 SERVICE DESCRIPTION

The AAFUS enables client systems to create, update and delete active flight
information. Active flight information is defined as the short-term airport operational
flight data typically stored in an AODB for yesterday, today, and maybe a small
number of days into the future. This document describes the interface to this
service, to enable client systems to access the service.
The IB will accept valid AAFUS requests to change active flight data from client
(consumer) systems and pass these to the provider system (normally AODB) for
action. The response from the provider system is routed back to the client system.

2. SCOPE

The message schemas, which are defined separately, form part of the specification
of this interface and must be used in conjunction with this document during the
interface development process.
The service is designed to satisfy a wide range of client system requirements and
is therefore described in a generic manner.
The interface for a specific system is defined in the Interface Definition Document
(IDD), which contains the following information:
1. Description of the use of separate application services, which are combined to
satisfy the overall interface requirements
2. The data element table for each service listing the elements which are sent or
received
3. Business rules defined in the IB configuration for the client system, which
restrict the allowable parameters which can be selected in a subscription
request.
4. Specific transportation or protocol functionality that is used by a service
consumer.

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 3 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

3. OUTLINE DESCRIPTION

3.1 BACKGROUND
The AAFUS provides a service for updating active flight information using AIDX
compliant schemas. Any system located on the network, or with remote access,
can access the service, subject to the necessary business arrangements and
security/configuration aspects.
All communication is in the form of XML messages, conforming to the AIDX
schemas for flight leg based data and Ultra schemas for all other (control)
messages.

3.2 SCHEMA, MESSAGES, WSDL

The following messages are used by this service and are defined in corresponding
schema (called messagename.xsd) in the SDK (schema definition, AAFUS folder):
1. IATA_AIDX_FlightLegNotifRQ – This contains a request from a client
system to update/create/delete a flight.
2. IATA_AIDX_FlightLegRS – This is sent to the client in response to a
IATA_AIDX_FlightLegNotifRQ.
3. StatusRequest – AIDX does not currently specify how a connection can be
maintained and so Ultra have defined a simple request/response
mechanism. A StatusRequest can be used by the client system to query the
status of the AFUS service and inform the IB that it is present.
4. StatusResponse – This is sent to the client in response to a
StatusRequest to state to the client the IB is present and whether the
service is available or not.
If Web Services is being use then refer to the aafus.wsdl file
Example messages are also provided in the SDK (schema definition, AAFUS folder
and the core folder). Although care is taken to ensure the sample messages are
valid they should be used as general guidance only. They do not form part of the
formal specification, since the message structures are defined by the XML
Schemas (XSDs).

3.3 FLIGHT DATA UPDATE

A client uses the AAFUS service by sending an IATA_AIDX_FlightLegNotifRQ
message, specifying the flight data which is to be changed.
The service provider will acknowledge the update message using an
IATA_AIDX_FlightLegRS message. This message will either indicate the
successful update or notify of warnings.

3.4 FLIGHT CREATE OPERATIONS

The AAFUS provides a service for creating and updating flight key information. In
addition with any newly created flight the sender also provides the initial flight
parameters.

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 4 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

3.5 FLIGHT DELETE

A flight may be deleted using AAFUS by sending an
IATA_AIDX_FlightLegNotifRQ message, specifying in the LegIdentifier the flight
to be deleted, and including the SpecialAction element with value “Delete”.

3.6 PERIOD OF USAGE

The time period for which the AAFUS can be used is dependent on the system
using the service and is therefore defined in the IDD for the system. There is a
restriction on the number of days in advance of the day of operation that individual
flight updates can be made.
There may be additional restrictions on the usage of individual AAFUS operations
under certain conditions.

3.7 FLIGHT LEG IDENTIFICATION

All AAFUS messages relating to scheduled passenger flights include a unique
flight identification made up from natural elements associated with a flight leg and
are:

3.7.1 Flight Key (LegIdentifier)

All AAFUS messages relating to scheduled passenger flights include a mandatory
unique flight identification made up from the following natural elements associated
with a flight leg:
Data element Notes
Airline Either the airline IATA code or the 3
character ICAO code.
The element attribute CodeContext
should be used to identify which code
standard is used according to PADIS
Code List 3055 either
‘3’ = IATA or
‘5’ = ICAO
Flight number: This 4-character field contains the
numeric flight number. The number is
left filled with zeros up to 3 digits (e.g.
1=’001’).
Flight Suffix (optional) The operation suffix for the flight
Departure Airport The scheduled departure airport.
The element attribute CodeContext
should be used to identify which code
standard is used according to PADIS
Code List 3055 either
‘3’ = IATA or
‘5’ = ICAO

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 5 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

Arrival Airport The scheduled arrival airport.

The element attribute CodeContext
should be used to identify which code
standard is used according to PADIS
Code List 3055 either
‘3’ = IATA or
‘5’ = ICAO
Origin Date The scheduled flight origin date based
on the flight not the flight leg.
Repeat count The repeat count is used for
situations where the flight number is
reused – for example return, general
aviation or training flights

TABLE 1: FLIGHT IDENTIFICATION KEYS

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 6 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

4. APPLICATION LEVEL SPECIFICATION

4.1 MESSAGE SEQUENCE PARADIGM

AAFUS may be configured to run either in synchronous or asynchronous mode.

The mechanism used will be defined in the appropriate Interface Definition
Document. The AAFUS operates on a Request-Response basis. A typical AAFUS
message dialog is shown below. Where a synchronous method is used then the
Request and Response are encapsulated in the same call.
sd AAFUS

Client IB

Establish Conenction()

Connection Accepted()

loop Repeat ev ery minute (configurable)

StatusRequest()

StatusResponse()

loop Repeat as required

send_message(IATA_AIDX_FlightLegNotifRQ)

send_message(IATA_AIDX_FlightLegRS)

Close Connection()

FIGURE 1: AAFUS MESSAGE SEQUENCE

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 7 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

4.2 STATUS REQUEST/RESPONSE (HEARTBEAT)

A status request/response cycle (heartbeat) is normally not required for AAFUS.
However, if it is required to ensure that the state of an important connection is
known then a request/response cycle should be used.
The client system sends a StatusRequest. This should be sent every N minutes
(configurable) and if no IATA_AIDX_FlightLegNiotifRQ has been sent in the last
N minutes.
If the IB detects lack of any IATA_AIDX_FlightLegNiotifRQ or StatusRequest
message from the client system for 2*N minutes then it will raise an ERROR level
log.

4.3 RESPONSE AND ERROR HANDLING

4.3.1 General
Each IATA_AIDX_FlightLegNotifRQ message contains the CorrelationID attribute
which is set by the requester client system. The IATA_AIDX_FlightLegRS
message contains both the outcome of the operation and the CorrelationID of the
request. This allows the sender of the original request to correlate the response
with the original request.
Note that the LegIdentifier element is not populated in the
IATA_AIDX_FlightLegRS message.

4.3.1.1 Asynchronous Message Delivery

As each change request is sent, the sending client system should hold the
messages in a local queue, which is used for recovery purposes as described
below.
The IATA_AIDX_FlightLegRS message contains both the outcome of the
operation and the CorrelationID of the request. Therefore when an
IATA_AIDX_FlightLegRS is received the sender of the original request is able to
correlate the response with the original request and therefore to delete the
message from its local queue, where the update has been successful.
The use of AAFUS in asynchronous mode allows multiple update requests to be
outstanding. There is no need to wait for a response before sending the next
request, but it is recommended to do so to assist system-wide flow control.

4.3.1.2 Synchronous Message Delivery

In synchronous delivery mode, the sender will receive the
IATA_AIDX_FlightLegRS response within the same data exchange session. The
IATA_AIDX_FlightLegRS message will still have the same CorrelationID as the
original IATA_AIDX_FlightLegNotifRQ message. This synchronous interaction will
force the sender to block and wait for the response.

4.3.2 Error Detection and Recovery

The IATA_AIDX_FlightLegRS contains the Success and Errors elements to
indicate the completion status of the update. The AIDX implementation Guide (see
document reference 9) recommends that the Type is either 294 or 911 and this

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 8 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

should be used by the client to determine how to handle an error response. Ultra is
proposing to the AIDX committee that the Status element should be used instead
for the client action allowing Type to be used freely for other error codes. However
for now, where UltraDB is used, it will provide consistent values of Type and Status
to allow the client to be able to determine how to proceed using either attribute.
1. Success
This means that the request was forwarded to the AODB which has responded
that the message has been successfully processed.
This does not necessarily mean that the request has been acted upon by the
AODB, as it may have business rules which affect the update. For example, the
AODB may choose to ignore particular updates where more accurate data
exists e.g. where the update is an ETA from an airline, but the AODB has more
accurate data from ATC.
Further information on the Success status may be available in the optional
Warnings element.
After receiving the response, the client system may safely discard the original
request from any local queuing system and send the next request.
2. Error
The following table defines the possible errors, meaning and recommended
client action
Status Type Error Meaning Client System
Message Action
(example)
Incomplete 294 “Received The XML is Do not resend the
message is invalid or does message.
invalid” not agree to
Raise an alert for
specific interface
“Correlation system support,
agreements.
Id is missing” including details of
the request and
“Version is
response.
missing”
The next request may
Incomplete 118 “"System An unexpected be sent
Unable to system level error
Process” has occurred.

NotProcessed 911 “Message Service error has Resend the message

has timed occurred after suitable timeout
out” (eg. 10 seconds).
If the same error
occurs repeatedly
(e.g. for 5 minutes)
then:
- Save the
message for
possible
resending later
- Raise an alert for
system support

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 9 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

- Send the next

message
- Reconsider re-
establishing a
connection to see
if that resolves
the issue
any other value any N/A Not currently Treat as for
(for future use) other used Incomplete/294
value
(for
future
use)

If the client system is unable to (re-)establish communication with the IB, then the
recovery process to be used is client system-dependent and is described in the
client system IDD.

4.4 DATA ELEMENTS USED BY AAFUS

The data elements used by the AAFUS are dependent on the individual client
system and are therefore defined in the client system IDD.

4.5 IB CONFIGURATION
The IB will be configured to know which client systems are allowed to send an
IATA_AIDX_FlightLegNotifRQ message.
If the IB does not specifically enable a client system for the service, then an
AAFUS IATA_AIDX_FlightLegNotifRQ message will be rejected, as indicated in
the IATA_AIDX_FlightLegRS message or the client system will be unable to place
the message on a queue.

4.6 ADDITIONAL INFORMATION

Additional information on AIDX can be found in document Ref. 9. This is an
externally maintained site and so the structure and contents may change. At the
time of writing, information regarding the AIDX schema and implementation are
available.
Also refer to AIDX Operations [Ref. 13] where an UltraDB system is being
deployed.

5. BUSINESS RULES AND SECURITY

5.1 BUSINESS RULES

Please refer to the Business Rules Overview document [Ref.12] for details of how
messages are processed by the provider system.

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 10 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

5.2 SECURITY FEATURES

Security features are defined in the relevant Interface Definition Document.

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 11 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

LIST OF FIGURES
Figure 1: AAFUS Message sequence..........................................................................................7

LIST OF TABLES
Table 1: Flight Identification Keys................................................................................................6

REFERENCES AND RELATED DOCUMENTS

No. Title Reference Issue

1 Key words for use in RFCs to Indicate RFC 2119 latest
Requirement Levels
ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt
2 Extensible Markup Language (XML) REC-xml-20001006 1.0 (Second
http://www.w3.org/TR/REC-xml Edition)

3 Annotated XML Specification REC-xml-19980210 (10-February-

http://www.xml.com/axml/testaxml.htm 1998)

4 Java Message Service Specification - version 1.1

http://java.sun.com/products/jms/docs.html
5 Service Frequently Asked Questions dev\Products\UltraI Latest
B\Controlled\25
6 AIDX Active Flight Distribution Service dev\Products\UltraI Latest
AAFDS B\Controlled\134
7 UltraIB Abbreviation dev\Products\UltraI Latest
B\Controlled\154
8 SDK Overview dev\Products\UltraI Latest
B\Controlled\189
9 AIDX – Various reference information http://www.aidx.aero/ Latest
including AIDX XML Implementation Guide
10 IATA XML Best Practices https:// Latest
extranet2.iata.org/sites/p
adis/XMLWG
%20170310/IATA
%20XML%20Best
%20Practice
%20Document
%20ver1.2%20%20Feb
%202010.doc
11 IATA PADIS Codeset Directory https://extranet2.iata.org Latest

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 12 of 13

Issue 7.0 Commercial in Confidence
Ultra Electronics Airport Systems AIDX Active Flight Update Service

/sites/padis/Files/PADIS
%20EDIFACT%20AND
%20XML%20Code
%20set%20Directory
%20v10.1.pdf
12 Business Rules Overview dev\Products\UltraI Latest
B\Controlled\190
13 AIDX Operations dev\Products\UltraI Latest
B\Controlled\211

AMENDMENT RECORD

Issue Date Reason for change Section(s) Author

amended
1 29/3/2012 Initial Release N/A Paul Crisp
2 21/06/2012 Addition of heatbeat and All James Chan
document restructuring
3 21/12/2012 Minor clarifications 3.2, 4.6 Phil Broughton
4 7/3/2013 Updated References to latest References James Chan
document number and Related
Documents
5 10/04/2013 Reference to Service FAQ now References James Chan
refer to the ‘Latest’ issue and Related
Documents
6 22/10/2013 Error handling is amended 4.3.2 Phil Broughton

7 19/11/2013 Error handling is amended 4.3.2 Muzammil

Shahbaz

APPROVALS

Name Position Signature

Approved by: Paresh Solanki Client Integration Team Leader
Authorised by: Simon Wilkins Chief Technology Officer

dev\Products\UltraIB\Controlled\118© Ultra Electronics Limited 2012-2013 Page 13 of 13

Issue 7.0 Commercial in Confidence