AAFDS Service Specification

Copy No.
AIRPORT INTEGRATION SERVICES

AIDX ACTIVE FLIGHT DISTRIBUTION SERVICE (AAFDS)
AAFDS SERVICE SPECIFICATION

dev\Products\UltraIB\Controlled\134 Issue 11.0
Date: 02/02/2015
Prepared on behalf of Ultra Electronics Airport Systems by:
Paul Crisp
© Ultra Electronics Limited 2012-2015
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 Distribution Service
LIST OF CONTENTS
1. INTRODUCTION................................................................................................................. 4
1.1 PURPOSE................................................................................................................... 4
1.2 SERVICE DESCRIPTION............................................................................................4
1.3 RELATIONSHIP TO OTHER SERVICES AND DOCUMENTS.....................................4
2. SCOPE................................................................................................................................ 4
2.1 GENERAL.................................................................................................................... 4
3. OUTLINE DESCRIPTION...................................................................................................5
3.1 GENERAL.................................................................................................................... 5
3.2 SCHEMA, MESSAGES, WSDL...................................................................................6
3.3 PERIOD OF USAGE....................................................................................................6
3.4 FLIGHT IDENTIFICATION...........................................................................................6
4. APPLICATION LEVEL SPECIFICATION............................................................................7
4.1 SUBSCRIPTION OPTIONS.........................................................................................7
4.1.1 Flight Window.......................................................................................................... 7
4.1.2 Flight Window Example............................................................................................8
4.1.3 FLIGHT MESSAGE FILTERS..................................................................................9
4.2 MASTER AND CODESHARE FLIGHTS......................................................................9
4.3 MESSAGE CONTENT TRANSFORMATIONS...........................................................10
4.4 ADDITIONAL COMPLEX BUSINESS RULES...........................................................10
4.5 FLIGHT RECORDS...................................................................................................10
4.6 NIL FIELDS................................................................................................................ 11
4.6.1 Flight identifier operations......................................................................................11
4.6.2 Delete..................................................................................................................... 11
4.6.3 Do Not Display.......................................................................................................11
4.7 DATA DOWNLOAD CAPABILITY...............................................................................11
4.8 NORMAL DAY-TO-DAY OPERATION........................................................................12
4.9 AFTER FLIGHT OPERATION....................................................................................12
4.10 CHARACTER SETS..................................................................................................13
4.11 ADDITIONAL INFORMATION....................................................................................13
5. MESSAGE SEQUENCES.................................................................................................13
5.1 STARTUP.................................................................................................................. 13
5.2 SUBSCRIPTION REQUEST......................................................................................13
5.3 DOWNLOAD DATA....................................................................................................13
5.4 NORMAL OPERATION..............................................................................................14
5.4.1 Event Driven Notifications......................................................................................14
5.5 CANCELLATION OF SUBSCRIPTION......................................................................14
dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 2 of 20

Issue 11.0 Commercial in Confidence
5.6 DETECTION OF IB ERROR CONDITIONS...............................................................14

5.6.1 Maintaining a Connection.......................................................................................14
5.6.2 Event Driven Notifications......................................................................................14
5.6.3 Message Expiry.....................................................................................................14
5.7 MESSAGE SEQUENCE DIAGRAM...........................................................................16
6. CLIENT SYSTEM IMPLEMENTATION GUIDELINES.......................................................17
6.1 GENERAL..................................................................................................................17
6.2 RECOVERY FROM IB ERROR CONDITIONS..........................................................17
6.3 RECOVERY FROM CLIENT ERROR CONDITIONS.................................................18
6.4 MESSAGE PROCESSING REQUIREMENTS...........................................................18
7. BUSINESS RULES AND SECURITY................................................................................18
7.1 BUSINESS RULES....................................................................................................18
7.2 SECURITY FEATURES.............................................................................................18

1. INTRODUCTION
The AIDX Active Flight Distribution Service (AAFDS) provides a distribution service
for active flight information relating to flights operating at an airport using AIDX
standard messages. This document describes the interface 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 AAFDS provides a distribution service for active flight information. Any system
located on the network, or with VPN access, can subscribe to the service, subject
to the necessary agreement and security aspects.
All communication is in the form of XML messages.
The service can supply a different subset of the data to each client system if
necessary by applying an XSLT.
1.3 RELATIONSHIP TO OTHER SERVICES AND DOCUMENTS
This document is one of a series of Application Service Definitions (ASD) which

define the services provided by the IB.
The interface for a specific client system is defined in an Interface Definition
Document (IDD).
1. AAFDS AIDX Active Flights Distribute Service - this document
2. AAFUS AIDX Active Flights Update Service – see reference 5.
2. SCOPE
2.1 GENERAL
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.
From the point of view of the client system, the IB provides the AAFDS service.
However the actual flight information is sourced by the IB from the back-end
AODB, in a manner hidden from the client system. The internal working of the IB
and the interfaces between the IB and the back-end database is outside the scope
of this document.

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 client system is defined in the Interface Definition
Document (IDD), which contains the following:
1. Description of the use of separate application services (e.g. AAFDS), 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 configured in the IB configuration for the client system, which
restrict the allowable parameters which can be selected in a subscription
request.
4. Implementation information such as:
JMS queue names (if appropriate)
Web Service endpoint URL (if appropriate)
Time out values to be used
The client system IDD takes precedence over information in this document.
The IDD may therefore override recommended information given in this
specification, for example, configurable items such as timeouts suggested in this
document.
3. OUTLINE DESCRIPTION
3.1 GENERAL
The AAFDS provides a distribution service for active flight information. Any system
located on the network, or with VPN access, can subscribe to the service, subject
to the necessary agreement and security aspects.
All communication is in the form of XML messages.
The service can supply a different subset of the data to each client system.
A client system subscribes to the service by sending a flight leg request message
(IATA_AIDX_FlightLegRQ). The request message allows the client system to
request data according to a specific carrier, otherwise further filtering on:
 Flight Window
 Flight direction
 Terminal
 Flight sector
 Service type IATA code
can be applied automatically provided agreed in advance.
The client system can request a snapshot of the current data, to enable the client
system to initialise itself. The IB then sends messages to the client system in real-

time as updates to flight data take place. The AAFDS service is long running and
the distribution of flight information continues until the subscription is cancelled.
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, AAFDS folder):
1. IATA_AIDX_FlightLegRQ – This contains a request from a client system
for a subscription.
2. IATA_AIDX_FlightLegRS – This is sent to the client in response to a
IATA_AIDX_FlightLegRQ. This message is also used to send details to the
client if the flight data subsequently changes.
3. StatusRequest – This can be used by the client system to query the status
of the AAFDS service
4. StatusResponse – This is sent to the client in response to a
StatusRequest
If Web Services is being used then refer to the WSDL file in the SDK (schema
definition, AAFDS folder).
Example messages are also provided in the SDK (schema definition, AAFDS 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 PERIOD OF USAGE

The time period for which the AAFDS can be provided is dependent on the system
providing the service and in some cases on the client system, and is therefore
defined in the IDD for the system.
The client can terminate the subscription on request, or the IB may terminate the
subscription if a service problem occurs.
3.4 FLIGHT IDENTIFICATION

The AIDX Flight Leg data include a mandatory unique flight identification made up
from natural elements associated with a flight and are:
Data element Notes

Carrier code: This may be the 2- The CodeContext attribute specifies:
character IATA code or the 3-
3 – IATA Code
character ICAO code.
13 – ICAO Code
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’).
Operational Suffix (optional) This is an optional suffix added to the

end of the flight number.

Departure Airport Field giving the departure airport, the
CodeContext attribute specifies:
5 – IATA Code
13 – ICAO Code
Arrival Airport Field giving the arrival airport, the
CodeContext attribute specifies:
5 – IATA Code
13 – ICAO Code
Origin Date Scheduled date (UTC) the flight
originated.
Repeat count Default to 0. The repeat count is used
for situations where the flight number
is reused – for example GA or training
flights
4. APPLICATION LEVEL SPECIFICATION
4.1 SUBSCRIPTION OPTIONS

The request message is used by a client system to initiate an AAFDS subscription
from the IB.
The request message contains a number of parameters which control both the
sequence and the contents of the messages sent to the client system. These
parameters enable the generic AAFDS service to be tailored to the specific
requirements of a client system and allow the client system to perform the
necessary recovery operations.
Parameters in the subscription message include the following:
1. Carrier Code, with Code Context specifying if this is an IATA or ICAO code.
The other allowable subscription options are limited by the configuration
parameters in the IB held for the client system (see section 3.1, which provides
control over selection of AAFDS options.
The subscription options are described in the following sections.
4.1.1 Flight Window

The AODB holds operational flight information for an active flight window of a
number of days. The exact size of the flight window and its behaviour may vary
from airport to airport. The IB is capable of supporting these different windows. The
appropriate Interface Definition Document (IDD) defines the flight window for each
particular client system.
There follows an example of one such flight window.

4.1.2 Flight Window Example

The AODB holds flight information for an active flight window of 7 days, comprising
D0 (the day of operation) to D+6, which is 6 days ahead of the day of operation.
Operational N
Day e
x
t
Seasonal Flight
D-1 D0 D+1 D+2 D+3 D+4 D+5 D+6
Schedule
Short Term Window
FIGURE 1: FLIGHT WINDOWS
A service client can subscribe to a window of AIDX flight data messages which
starts a defined number of days before the day of operation – up to a maximum of
6 days before. The start day of the flight window is defined by the FlightWindow
configuration data element.
For example, where the FlightWindow configuration element is set to D+3 then
the subsystem receives flight information for the window from D+3 to D0.
When the system moves into a new day, the flights for that new D+n day (e.g. D+3)
is sent to the client and the window is extended to this new day.
All flight windows operate in the same manner, except for the window start time.
For example all windows include the day of operation and extend into the period
after operation.
A client system supplier, in conjunction with Ultra, will agree on the value for the
FlightWindow. Note, that to increase conformity, it is expected that most clients
will subscribe to the same flight window.
The operation of the flight schedule window is as follows:
Every night a process decides which flight data messages to send to each
subsystem.
For each flight, if the scheduled operation date of the flight has now entered the
required flight window for the client system, then the flight record is sent to the
client system. As this is the first time the flight is sent, then it is sent as a complete
flight record.

4.1.3 FLIGHT MESSAGE FILTERS

Flight message filters are configured within the IB interface and operate on the
basis that a flight data message is only sent to the client system if it satisfies the
filter criteria defined.
This filter mechanism ensures that a client system only receives messages which
are relevant to the operation of the client system and it provides central control to
restrict information distribution.
When a subscription is requested the volume of data in the snapshot may be
reduced by applying the filter to the selected data. Otherwise the filtering takes
place in an XSLT when the data is delivered to the client.
Filter criteria may include some or all of the following:
1. Selected Terminal – This refers to Public Terminal
2. Selected Carrier
3. Flight Service Type
4. Flight Window (as described in 4.1.1)
Note that as AIDX refers to master flights which contain codeshare data,
codeshare elements should simply be ignored by the client if these are not
required.
Where a filter criterion is not specified then this indicates “all carriers” or “all
terminals” and so on.
Flight message filtering operates on both snapshot data and on normal ad-hoc
data updates, as described in the following sections.
The flight message filters are defined in the IDD for each client system.
Note that AIDX does not hold information regarding the previous value of an
element. This means it is not possible for the IB to handle some situations that
might be expected where a flight moves in or out of a client’s filter “window”. E.g.
Client C is interested in flights in terminal A only so subscribes using a filter for
terminal A only. A flight operates from terminal A and so client C receives updates.
If the flight moves operation to terminal B then the IB just receives a new AIDX
message with terminal of B and so does not send this to Client C which may think
that this flight is still operating at terminal A.
Where this might cause a problem to the client then the filter should not be applied
in the IB, and instead the client performs this filtering after checking whether a
flight has moved in or out of its operational window.
4.2 MASTER AND CODESHARE FLIGHTS

AAFDS flight data messages contain the element CodeShareInfo which contains
the data regarding codeshare flights. Up to 20 codeshare flights can be contained
within the leg data message. The provider and client systems may impose other
limits.
Codeshare flights may be sent as separate data records (as agreed in the client
system ICD) to support certain airport systems operations, although strictly
according to AIDX these should not be sent.

4.3 MESSAGE CONTENT TRANSFORMATIONS

Where an XSLT is configured on the IB, every data message sent to the client
system will be first transformed in the IB from the generic message schema to a
specific message using the specified transformation. It applies to initial download
and normal flight data update messages
The flight identification (see section 3.4) will always be present following XSLT
transformation.
The XSLT transformation will be created by Ultra as a mapping between the
generic flight data message to the specific data message defined for the client
system.
4.4 ADDITIONAL COMPLEX BUSINESS RULES

Additional complex business rules, such as conditional message transformations,
will use XSLT methods and, if any, these will be defined in the client system IDD.
This can be used to satisfy requirements such as ‘Where airline identity is XX then
include element ZZZ, but where airline identity is not XX then do not include
element ZZZ’.
This technique allows sensitive data (such as passenger numbers) to be removed
from messages delivered to specific client systems.
4.5 FLIGHT RECORDS
Some AAFDS data messages contain only changed data elements and some
messages contain a complete record of all data elements with a current value held
in the AODB.
1. When the complete record is sent, then all non-null elements are present. The
client system can use this to update an existing record or to create a new
record if the flight does not already exist.
2. A message may be sent with only data changes, then only the elements which
have been changed in the AODB (since the previous message sent for this
flight) are present in the message. The client system can use this to update a
record in its local database, using the flight identification included in the
message.
If an AIDX data message does not contain a certain element, this simply means
that the service provider is not supplying any information about that element. This
could be because there has not been a change to that element when the message
was constructed. A client would not be expected to remove the value of the
element from its internal database.
If an AIDX data message contains an element but it has the nil attribute assigned
to it then that indicates that the value for that particular element should be cleared.
Complete data messages are sent only in the following circumstances:
a. When the message is first sent as a result of either flight schedule entering the
request flight window period for the client system or where a new flight has
been created on the AODB (e.g. by an airline)

b. Where the flight messages are sent as a download in response to the initial
IATA_AIDX_FlightLegRQ request
c. Where a change has been made in the AODB to a message element used for
message filtering, which results in the message now satisfying the message
filtering specification where previously it did not.
d. When the AODB only supports complete data records
4.6 NIL FIELDS
Where a field is specifically set to “no value” in the AODB, then this information is
passed to subscribing systems by using the “nillable=true” attribute which can be
attached to any nillable) data element in the AAFDS data message. Where a data
element is received with this attribute set, then client system should delete the
contents of the equivalent field in the local database.
The applicable fields are defined in the message schemas.
4.6.1 Flight identifier operations

Flight Identifier operations are detailed using the Special Action element.
4.6.2 Delete
When a flight is deleted from the AODB, a data message is sent with the Special
Operation set to “Delete” to indicate that the client system should delete the flight
from its local database.
When a new flight is created or updated in the AODB, the flight will be sent as a
normal IATA_AIDX_FlightLegRS message.
If a flight key (FlightIdentity, FlightDirection, ScheduledDate) is changed in the
AODB, then AAFDS sends a Delete for the old flight followed by the new flight.
4.6.3 Do Not Display

When the flight should not be displayed by the client system the Special Action
element is set to ‘DoNotDisplay’
4.7 DATA DOWNLOAD CAPABILITY

The AAFDS provides a download feature, which enables a client system to recover
information following partial or total loss of data or other failure.
The download feature should only be used for this purpose and must not be used
as a regular method of obtaining data updates.
A download can be requested within the IATA_AIDX_FlightLegRQ request. The
following snapshot options are available:
1. Full download: In a full data download, flight leg data messages are sent for
the complete flight window for which the client system is configured. This
mechanism allows a client system to recreate the full local flight database and
can be used as an initialisation mechanism.

Since the Full Download causes IB to send all flight data messages satisfying
the requested flight window, it will send a large number of flight leg data to the
client.
The full data download is requested by sending an IATA_AIDX_FlightLegRQ
request and setting the TransactionStatusCode to ‘Start’.
2. Partial download: In a partial data download, the client system defines a
date/time for the start of the snapshot data. In this download, a flight data
message is sent for every flight which has been modified since the specified
date/time.
This mechanism is provided so that a client system can recover more quickly
from a situation where recent flight update messages have been lost (e.g. due
to temporary communications loss), but the client system database is
otherwise valid.
The partial data download is requested by sending an IATA_AIDX_FlightLegRQ
request and setting the TransactionStatusCode to ‘Continuation’ and the
Timestamp attribute to the start date/time window. This date/time should be set to
a value of Timestamp attribute of last successfully received
IATA_AIDX_FlightLegRS message. After the download data has been sent, the
subscription will revert to the transmission of normal real-time AAFDS notification
messages. Any flight data updates to the AODB that occurred during transmission
of the download will be queued by the IB on a First-in / First-out basis and sent
following the download.
4.8 NORMAL DAY-TO-DAY OPERATION

The AAFDS is a long running service. Once the subscription has been started and
the download messages sent, then the daily sequence of flight data message
transmissions operates in the following manner:
1. Every night, at a time outside peak hours, the IB sends the flights which have
entered the flight window specified for the client system. This mechanism
ensures that the client system continues to hold flights for the flight window.
Note: this behavior is dependent on AODB functionality.
2. Flight updates corresponding to the updates to current flights that are made
to the AODB will be sent to the client system in real time. The messages are
subject to both message filtering and to message transformation, as specified
by the client system.
3. Where a flight has been created such that it falls within the time window for
the client system then it is sent to the client system.
4. When the flight window moves on, if no new updates have been made to
flights and no new flights created then no data will be sent to the client
system.
5. For flights that are delayed over midnight, the original flight identification will
continue to be used. Client systems are required to handle this situation.
4.9 AFTER FLIGHT OPERATION

Flight updates may occur after the flight has operated. If a flight update occurs,
then the equivalent AIDX flight data message will be sent. These are allowed for a

limited time (to be defined on a per client system basis in the IDD) and can include
updates during the day after scheduled operation.
4.10 CHARACTER SETS
As defined in the XML Coding standards [Ref 1], AAFDS character coding uses
UTF-8 which allows a wide range of special symbols and character sets.
4.11 ADDITIONAL INFORMATION

Additional information on AIDX can be found in document reference 6. 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 8] where an UltraDB system is being deployed.
5. MESSAGE SEQUENCES
5.1 STARTUP
To subscribe to the service, the client should first send a StatusRequest message.
The IB will normally reply with a StatusResponse indicating the current service
state. If this state indicates that the service is currently unavailable (or if no
response is received) then the client system should continue sending status
requests until state of “Down” is received. When a “Down” StatusResponse has
been received the client system sends a IATA_AIDX_FlightLegRQ message to
the IB.
5.2 SUBSCRIPTION REQUEST

To subscribe to the service, the client system sends an IATA_AIDX_FlightLegRQ
message to the IB, with parameters specifying the data it wishes to receive and the
TransactionStatusCode set to ‘Start’ (for a full download) or ‘Continuation’ (for a
partial download) – see Section 4.7.
In reply, the IB sends IATA_AIDX_FlightLegRS messages either containing a
Success data element and the flight records, or the Error data element and the
reason for failing to subscribe, such as a request to access data which is not
permitted to the particular client system. [See section 7.1]
The filtering parameters for a specific client system will be agreed and defined in
the client system IDD.
5.3 DOWNLOAD DATA

When a client system first subscribes to the service it may request a full download
of the current data. Subsequent request can be Partial (See Section 4.7).
The IB will send this download as series of IATA_AIDX_FlightLegRS messages
for all flight legs that are valid according to the client systems filtering criteria.

5.4 NORMAL OPERATION

The IB supports Event Driven Notifications. Check the IDD for details regarding
how normal operation notifications are managed at the particular airport.
5.4.1 Event Driven Notifications

Once the client system has subscribed and the IB has sent the download data, the
IB may send subsequent flight updates in an event driven manner.
These flight records include any record that has been modified in the AODB and
are sent as IATA_AIDX_FlightLegRS messages.
The AAFDS subscription is long-running and transmission of
IATA_AIDX_FlightLegRS messages will continue until the subscription is
cancelled.
5.5 CANCELLATION OF SUBSCRIPTION

The subscription may be cancelled by the client by sending a
IATA_AIDX_FlightLegRQ message with TransactionStatusCode="End"
The IB will cancel the subscription by sending a IATA_AIDX_FlightLegLegRS with
TransactionStatusCode="End" in response to the client request. The IB may also
send this should a serious problem occur with the service which prevents
continuation of the subscription.
5.6 DETECTION OF IB ERROR CONDITIONS
5.6.1 Maintaining a Connection

A “heartbeat” should be maintained by the client so the status of the connection
can be determined by both the client and the IB.
To do this the client should send a StatusRequest at a regular interval. This
interval should be configurable (refer to the client system ICD) but normally set to 1
minute.
The IB will normally reply with a StatusResponse indicating the current service
state (Up or Down).
5.6.2 Event Driven Notifications

In Event Driven Notifications the IB will assume the subscription from the client is
valid until an internal error occurs or a message queued for the client expires.
If the IB is unable to deliver messages to the client system, then the messages are
queued and held for a period of up to a maximum time (‘Time to live’). The value
of this parameter can be set per client system and has a default value of 10
minutes.
5.6.3 Message Expiry

When the maximum time is reached the IB will discard all stored AAFDS messages
and cancel the AAFDS subscription.

The IB may also cancel the subscription if some other problem occurs, such as
loss of communication between the IB and the back-end database.
Note that an IATA_AIDX_FlightLegRS message queued for receipt by a client
system is subject to the same time to live as other messages. This message is
primarily to inform the client system more quickly that its subscription has been
cancelled. If the client system is unsure about the state of the subscription then the
client should restart the whole subscription process.

5.7 MESSAGE SEQUENCE DIAGRAM

The following diagram shows the sequence of messages.
FIGURE 2: MESSAGE SEQUENCES – EVENT DRIVEN NOTIFICATIONS

6. CLIENT SYSTEM IMPLEMENTATION GUIDELINES
6.1 GENERAL
Refer to the AIDX Implementation Guide which can be found in reference 6 and if
an UltraDB is used, then also the AIDX Operations guide in reference 8.
6.2 RECOVERY FROM IB ERROR CONDITIONS

If the client system detects a loss of service from an IATA_AIDX_FlightLegRS
with an Error element, or receives a timeout in response to a data request, then it
needs to take recovery action. It is recommended that it makes a new Partial
IATA_AIDX_FlightLegRQ request, with the ‘Continuation’ option (See Section
4.7).
The following table defines the possible errors that a client could receive from a
subscription request, 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
“Version is system support,
agreements.
missing” including details of
the request and
response.
Incomplete 118 “System An unexpected
Unable to system level
Process” error has
occurred.
Unavailable 118 “The Provider Provider is Resend the message

is unavailable after suitable timeout
unavailable” (e.g. 10 seconds).
Unavailable 911 “The provider Provider has Client should attempt

interface is become to re-subscribed after
unavailable” unavailable and a suitable timeout (or
cancelled the next ‘Down’ Status
client’s Response)
subscription
NotProcessed 911 “Message has Service error has Resend the message
timed out” occurred after suitable timeout
(e.g. 10 seconds).
If the same error
occurs repeatedly
(e.g. for 5 minutes)
then:
- Raise an alert for
system support

- 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)
6.3 RECOVERY FROM CLIENT ERROR CONDITIONS

Where the client system consists of a pair of servers operating as live and standby,
in the event of the failure of the live server, the standby can reconnect to the JMS
(or web service) queues within the time out period (default 2 but can be up to 20
minutes) without loss of message data. The standby can then receive queued
messages.
If the client system considers that its database requires re-initialisation, then a new
IATA_AIDX_FlightLegRQ with the ‘Start’ TransactionStatusCode should be sent.
Since this involves the transmission of a large number of messages, it should be
used only when absolutely necessary. Normally, the Partial download should be
used (See Section 4.7)
The client can use the SequenceNmbr attribute to ensure that there is no missing
data after a failover or during normal running.
6.4 MESSAGE PROCESSING REQUIREMENTS

It is important that real time flight updates close to time of operation are received
and processed by client systems in a timely manner.
The client system must be capable of processing messages at a sustained
rate of 10 messages per second.
This ensures that updates for current days flights are processed in a timely
manner and do not get delayed and do not build up in the IB.
7. BUSINESS RULES AND SECURITY
7.1 BUSINESS RULES

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

Security features are defined in the relevant Interface Definition Document.

LIST OF FIGURES
FIGURE 1: FLIGHT WINDOWS..................................................................................................8

Figure 3: Message sequences – Event Driven Notifications......................................................16
LIST OF TABLES
None
REFERENCES AND RELATED DOCUMENTS

No. Title Reference Issue
1 Extensible Markup Language (XML) REC-xml-20001006 1.0 (Second Edition)
http://www.w3.org/TR/REC-xml
2 Annotated XML Specification REC-xml-19980210 (10th Feb-1998)
http://www.xml.com/axml/testaxml.htm
3 Java Message Service Specification - version 1.1
http://java.sun.com/products/jms/docs.h
tml
4 Application Services User Guide dev\Products\UltraI Latest
B\Controlled\25
5 AIDX Active Flight Update Service dev\Products\UltraI Latest
AAFUS B\Controlled\118
6 AIDX - Various reference information http://www.aidx.aero/ Latest
including AIDX XML Implementation
Guide
7 Business Rules Overview dev\Products\UltraI Latest
B\Controlled\190
8 AIDX Operations dev\Products\UltraI Latest
B\Controlled\211
9 PADIS EDIFACT XML http://www.aidx.aero/ Latest
10 UltraIB Abbreviations dev\Products\UltraI Latest
B\Controlled\154
11 SDK Overview dev\Products\UltraI Latest
B\Controlled\189
12 Service Frequently Asked Questions dev\Products\UltraI Latest
B\Controlled\25
AMENDMENT RECORD

Issue Date Reason for change Section(s) Author

amended
1 07/10/2011 Initial Release N/A Paul Crisp
2 22/06/2012 Addition of heartbeat and All James Chan
document structuring
3 30/10/2012 Clarification of subscription and 4.1 Phil Broughton
filtering
4 21/12/2012 Clarification of points and minor All Damian Fox
change to core schema location
5 05/03/2013 Updated References to latest References James Chan
document number and Related
Documents
6 11/04/2013 Reference to Service FAQ now References James Chan
refer to the ‘Latest’ issue and Related
Documents
7 17/05/2013 Added Partial Download 4.7 James Chan
8 20/11/2013 Additional description for error 6.2 Phil Broughton
codes
9 07/05/2014 Updated error code section for Various Srinath
Unavailable Ponnamudi
Clarification added for partial Paresh Solanki
snapshot
10 01/07/2014 Updated error code section for 6.2 Srinath
Unavailable Ponnamudi
11 02/02/2015 Minor corrections 3.1, 4.1.3, Phil Broughton
6.4
APPROVALS
Name Position Signature

Approved by: Paresh Solanki Development Manager
Authorised by: Simon Wilkins Chief Technology Officer


AAFDS Service Specification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AAFDS Service Specification

Uploaded by

Copyright:

Available Formats

Copy No.

AIRPORT INTEGRATION SERVICES

AAFDS SERVICE SPECIFICATION

Prepared on behalf of Ultra Electronics Airport Systems by:

© Ultra Electronics Limited 2012-2015

All rights reserved. No Part of this document may be reproduced, duplicated,

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 2 of 20

5.6 DETECTION OF IB ERROR CONDITIONS...............................................................14

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 3 of 20

1.2 SERVICE DESCRIPTION

1.3 RELATIONSHIP TO OTHER SERVICES AND DOCUMENTS

This document is one of a series of Application Service Definitions (ASD) which

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 4 of 20

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 5 of 20

3.2 SCHEMA, MESSAGES, WSDL

3.3 PERIOD OF USAGE

3.4 FLIGHT IDENTIFICATION

Data element Notes

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 6 of 20

end of the flight number.

4. APPLICATION LEVEL SPECIFICATION

4.1 SUBSCRIPTION OPTIONS

4.1.1 Flight Window

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 7 of 20

4.1.2 Flight Window Example

Short Term Window

FIGURE 1: FLIGHT WINDOWS

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 8 of 20

4.1.3 FLIGHT MESSAGE FILTERS

4.2 MASTER AND CODESHARE FLIGHTS

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 9 of 20

4.3 MESSAGE CONTENT TRANSFORMATIONS

4.4 ADDITIONAL COMPLEX BUSINESS RULES

4.5 FLIGHT RECORDS

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 10 of 20

4.6 NIL FIELDS

4.6.1 Flight identifier operations

4.6.3 Do Not Display

4.7 DATA DOWNLOAD CAPABILITY

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 11 of 20

4.8 NORMAL DAY-TO-DAY OPERATION

4.9 AFTER FLIGHT OPERATION

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 12 of 20

4.10 CHARACTER SETS

4.11 ADDITIONAL INFORMATION

5.2 SUBSCRIPTION REQUEST

5.3 DOWNLOAD DATA

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 13 of 20

5.4 NORMAL OPERATION

5.4.1 Event Driven Notifications

5.5 CANCELLATION OF SUBSCRIPTION

5.6 DETECTION OF IB ERROR CONDITIONS

5.6.1 Maintaining a Connection

5.6.2 Event Driven Notifications

5.6.3 Message Expiry

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 14 of 20

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 15 of 20

5.7 MESSAGE SEQUENCE DIAGRAM

FIGURE 2: MESSAGE SEQUENCES – EVENT DRIVEN NOTIFICATIONS

dev\Products\UltraIB\Controlled\134© Ultra Electronics Limited 2012-2015 Page 16 of 20

6. CLIENT SYSTEM IMPLEMENTATION GUIDELINES

6.2 RECOVERY FROM IB ERROR CONDITIONS

Unavailable 118 “The Provider Provider is Resend the message

Unavailable 911 “The provider Provider has Client should attempt