INTERNATIONAL CIVIL AVIATION ORGANIZATION

ASIA AND PACIFIC OFFICE

GUIDANCE MATERIAL

FOR THE ASIA/PACIFIC REGION

FOR ADS/CPDLC/AIDC GROUND SYSTEMS

PROCUREMENT AND IMPLEMENTATION

Version 2 – May 2008

Issued by the ICAO Asia/Pacific Regional Office, Bangkok

 Version 2 - May 2008

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION...................................................................... 1
1.1 Objective .......................................................................................... 1
1.2 Scope................................................................................................ 1
1.2.1 Procurement and Implementation ............................................................. 2
1.2.2 Requirements............................................................................................ 2
1.2.3 Specification.............................................................................................. 2
1.3 Systems Overview........................................................................... 2
1.3.1 ADS........................................................................................................... 3
1.3.2 CPDLC ...................................................................................................... 3
1.3.3 AIDC.......................................................................................................... 4

CHAPTER 2 PROCUREMENT ..................................................................... 5

2.1 General ............................................................................................. 5
2.1.1 System Quality .......................................................................................... 5
2.1.2 Roles and Responsibilities of the ANSP ................................................... 5
2.1.3 Relationships: Requirements, Specification and Test/Evaluation ............. 6
2.2 Project Management ....................................................................... 7
2.3 Planning and Contracting ............................................................... 8
2.3.1 Operational Requirements ........................................................................ 8
2.3.2 Design and Review ................................................................................... 9
2.3.3 Request for Proposal (RFP).................................................................... 11
2.3.4 Evaluation of Proposals .......................................................................... 12
2.3.5 Contract Negotiation ............................................................................... 13

CHAPTER 3 IMPLEMENTATION ............................................................... 14

3.1 Implementation Schedule ............................................................. 14
3.2 Contract Supervision .................................................................... 14
3.3 System Design Review ................................................................. 14
3.4 Factory Acceptance Test .............................................................. 15
3.5 Preparation for Operation ............................................................. 15
3.5.1 Operational Procedures .......................................................................... 16
3.5.2 System Management Procedures........................................................... 16
3.5.3 Preparation of System Data .................................................................... 16
3.5.4 Establishment of System Parameters ..................................................... 16
3.5.5 Development of Training Courses........................................................... 16
3.5.6 Operational Transfer Plan ....................................................................... 17
3.5.7 Safety Assessment ................................................................................. 17

i
 Version 2 - May 2008

3.6 Training .......................................................................................... 17

3.6.1 Controller Training................................................................................... 17
3.6.2 System Operator Training ....................................................................... 18
3.6.3 Maintenance Training.............................................................................. 18
3.6.4 Simulator Based Training........................................................................ 18
3.7 Site Acceptance Test .................................................................... 19
3.7.1 Physical Checks...................................................................................... 19
3.7.2 Technical Tests ....................................................................................... 19
3.7.3 Operational Tests.................................................................................... 19
3.7.4 Results .................................................................................................... 19
3.8 Operational Transfer ..................................................................... 20
3.8.1 Parallel Operation Transfer ..................................................................... 20
3.8.2 Phased Transfer...................................................................................... 20
3.8.3 Preparation for Transfer .......................................................................... 20

CHAPTER 4 REQUIREMENTS .................................................................. 22

4.1 General Requirements .................................................................. 22
4.1.1 Notification of Error Messages ................................................................ 23
4.1.2 Time Stamps and Timers ........................................................................ 23
4.1.3 Applicable Documents ............................................................................ 24
4.1.4 Data Recording ....................................................................................... 25
4.1.5 System Performance Monitoring Tool..................................................... 25
4.2 Data link Initiation Capability........................................................ 25
4.2.1 AFN Logon Functions ............................................................................. 25
4.2.2 Use of AIDC for Forwarding AFN Message ............................................ 26
4.3 CPDLC ............................................................................................ 26
4.3.1 General ................................................................................................... 26
4.3.2 Transfer of CPDLC between ATC Sectors.............................................. 26
4.3.3 CPDLC Message Exchange Requirements ............................................ 27
4.3.4 Message Handling Order ........................................................................ 27
4.3.5 Responses .............................................................................................. 27
4.3.6 Message Closure .................................................................................... 27
4.4 ADS................................................................................................. 27
4.4.1 General ................................................................................................... 27
4.4.2 Message Handling .................................................................................. 28
4.5 AIDC................................................................................................ 28
4.5.1 General ................................................................................................... 28
4.5.2 Asia/Pacific Interface Control Document (ICD) ....................................... 29
4.5.3 Message Header..................................................................................... 29
4.5.4 ATS Coordination Messages .................................................................. 29
4.5.5 Detailed Information Provided in ICD...................................................... 30
4.5.6 Performance Requirements .................................................................... 30

ii
 Version 2 - May 2008

CHAPTER 5 SPECIFICATION ................................................................... 31

5.1 System Configuration ................................................................... 31
5.2 Interfaces ....................................................................................... 32
5.2.1 Data link Service Provider....................................................................... 32
5.2.2 ATN ......................................................................................................... 32
5.2.3 AFTN/AMHS ........................................................................................... 32
5.2.4 ATS systems ........................................................................................... 33
5.2.5 Radar Data.............................................................................................. 34
5.2.6 ADS B Data............................................................................................. 34
5.2.7 Meteorological Data ................................................................................ 34
5.3 Functionality .................................................................................. 34
5.3.1 ADS......................................................................................................... 34
5.3.2 CPDLC .................................................................................................... 36
5.3.3 ACF ......................................................................................................... 37
5.3.4 AFN ......................................................................................................... 37
5.3.5 AIDC........................................................................................................ 38
5.4 Operator Interface ......................................................................... 38
5.4.1 Human Factors........................................................................................ 38
5.4.2 Displays................................................................................................... 38
5.4.3 Message Handling .................................................................................. 39
5.4.4 Input Devices .......................................................................................... 39
5.5 Controller Tools............................................................................. 40
5.5.1 Conflict Probe.......................................................................................... 40
5.5.2 Temporary Maps ..................................................................................... 40
5.5.3 Bearing-Distance Line............................................................................. 40
5.5.4 Velocity Vectors ...................................................................................... 41
5.5.5 Label Overlap Avoidance ........................................................................ 41
5.6 System Capacity............................................................................ 41
5.7 Recording and Data Analysis ....................................................... 42
APPENDIX A Glossary ............................................................................... 44
APPENDIX B References ........................................................................... 46
APPENDIX C Performance Criteria........................................................... 47

iii
 Version 2 - May 2008

CHAPTER 1 INTRODUCTION

This material has been developed under an initiative of the Regional Airspace Safety
Monitoring Advisory Group (RASMAG) of the Asia Pacific Air Navigation Planning and
Implementation Regional Group (APANPIRG) to assist air navigation service providers
(ANSP) with the implementation of data link-based air traffic management (ATM)
systems. The material was adopted as Asia/Pacific regional guidance material by
APANPIRG/18 (3-7 September 2007) under the provisions of Conclusion 18/5. The
RASMAG retains editorial responsibility for the document.
For the purposes of this document, a data link-based ATM system is one which
supports automatic dependent surveillance (ADS), controller-pilot data link
communications (CPDLC) and air traffic service (ATS) interfacility data link
communications (AIDC).
Integrated data link systems are playing an increasingly important role in air traffic
management. Data link operations support reduced separation minima and so directly
contribute to increased airspace capacity. Controller and pilot workload is reduced, and
operational safety enhanced, by the automation enabled by data link systems. As the
use of these systems spreads, so more ANSPs must equip with the appropriate
facilities.
The material covers two main aspects of implementation: specification and deployment.
Technical systems must be carefully specified from both the technical and operational
aspects, and at the right level of detail: enough to ensure that the requirements are met,
but not so much that good solutions may be excluded.
The deployment of a new system involves a number of vital steps, such as testing,
training, integrating and commissioning.
This material offers guidance, rather than solutions, with the emphasis on specifying
systems supporting ADS, CPDLC and AIDC. It is not the intention of this document to
provide the detailed technical information required to specify data link applications: this
information may be found in the various ICAO and other documents referenced.

1.1 OBJECTIVE
The objective of this document is to provide guidance on the specification, procurement
and implementation of data link systems for States and service providers unfamiliar with
these systems.

1.2 SCOPE
The material is divided into three sections. The first covers the generalities of
procuring and implementing a new system, the second is concerned with the

1
 Version 2 - May 2008

requirements of a data link-based ATM system, and the third gives guidance on
specifying a system.
For the purposes of this material, it is assumed that the ANSP is the organisation setting
out to procure a system.

1.2.1 Procurement and Implementation

Procurement and implementation includes:
ƒ Planning and contracting
ƒ Supervision and inspection
ƒ Preparation for operation
ƒ Operational transfer

1.2.2 Requirements
The Requirements section covers general requirements for data link systems
and specific requirements for:
ƒ Data link Initiation Capability (DLIC)
ƒ ADS
ƒ CPDLC
ƒ AIDC

1.2.3 Specification
The Specification section offers guidance on the specification of:
ƒ System configuration
ƒ Interfaces
ƒ Functionality
ƒ Human-Machine Interface
ƒ Capacity and parameters
ƒ Recording and data analysis

1.3 SYSTEMS OVERVIEW

A key objective of data link systems is to support reduced separation minima: any new
data link system should be capable of supporting 30NM lateral and 30NM longitudinal
reduced separation minima based on PBN RNP 4.

2
 Version 2 - May 2008

1.3.1 ADS
Automatic Dependent Surveillance is a surveillance technique in which aircraft
automatically provide, via a data link, data derived from on-board navigation and
position-fixing systems, including aircraft identification, four-dimensional position,
and additional data as appropriate. There are two forms of ADS: broadcast
ADS (ADS-B) and contract ADS (ADS-C). With ADS-B, aircraft broadcast
positional data up to twice per second; the data may be used by ground systems
(and other aircraft). With ADS-C, aircraft report directly to one or more ground
systems with specified data at predetermined intervals (usually tens of minutes).
Note: Throughout this document, the abbreviation ADS refers to ADS-C.
The ADS data link application allows the implementation of reporting
agreements, or “contracts”, which, with the exception of an aircraft in an
emergency situation, are established exclusively by the ground. An ADS
contract is an ADS reporting plan which establishes the conditions of ADS data
reporting (i.e. the data required by the ATC system and the frequency of the ADS
reports which have to be agreed upon prior to the provision of the ADS services).
ADS information may be exchanged between the ground system and the aircraft
by means of a single contract or a series of contracts. An ADS contract
specifies under what conditions an ADS report will be initiated, and what data
groups will be included in the reports.
There are three types of contract:
ƒ Periodic contracts provide a report at a regular periodic interval
determined by the ground system.
ƒ Event contracts provide a report when or if a specified event or events
take place.
ƒ Demand contracts provide a single report when requested by the
controller.

1.3.2 CPDLC
Controller Pilot Data Link Communications (CPDLC) is a data link application
that provides a means of communication between controller and pilot, using data
link for ATC communications.
Sending a message by CPDLC consists of selecting the addressee, selecting
and completing, if necessary, the appropriate message from a displayed menu
or by other means which allow fast and efficient message selection, and
executing the transmission. The messages include clearances, expected
clearances, requests, reports and related ATC information. A “free-text”
capability is also provided to exchange information not conforming to defined

3
 Version 2 - May 2008

formats. Receiving the message will normally take place by display and/or
printing of the message.
CPDLC overcomes a number of the shortcomings of voice communication, such
as voice channel congestion, misunderstanding due to bad voice quality and/or
misinterpretation, and corruption of the signal due to simultaneous
transmissions.

1.3.3 AIDC
ATS Interfacility Data link Communications is a data link application that provides
the capability to exchange data between ATS units in support of critical ATC
functions.
AIDC defines messages which are related to three phases of coordination as
perceived by an ATSU.
ƒ Notification, in which the aircraft trajectory and any changes may be
conveyed to an ATSU from the current ATSU prior to coordination.
ƒ Coordination, in which the aircraft trajectory is coordinated between two
or more ATSUs when the flight approaches a common boundary.
ƒ Transfer, in which communications and executive control authority is
transferred from one ATSU to another.
Other AIDC messages support ancillary ATC data changes between ATSUs,
including the exchange of free-text messages.
Other than the formal international communication protocol standards, internet
protocol (TCP/IP) as a flexible and low cost de-fact industry standard is
recommended.

4
 Version 2 - May 2008

CHAPTER 2 PROCUREMENT

2.1 GENERAL
2.1.1 System Quality
The overall quality of a system, the Total System Quality, is the product of three
main elements: the quality of the design, the quality of production and the quality
in operation.
The Design Quality is a measure of how well the design process has translated
the operational requirements into user specifications and the user specifications
into product specifications. The design quality depends upon both the
definition of operational requirements and development of user specifications by
the ANSP and the system design skills of the vendor. If the operational
requirements are not well defined, the specification will be compromised and the
system design cannot be expected to be meet the real requirements. Similarly,
if the specification does not correctly reflect the operational requirements,
neither will the system design.
The Production Quality is a measure of how exactly the products match the
specifications, and applies to the hardware, the software and the integration of
these to form the system as a whole. In general, the vendor is responsible for
production quality.
The Operational Quality is a measure of how the actual operation of the system
realizes the operational objectives. This depends primarily on the way the
system is operated: a badly operated system is not a good system. The
operational quality is mainly influenced by the operational management of the
ANSP.
The Total System Quality is the product of design quality, production quality
and operational quality. To achieve high total system quality is clearly
necessary to maintain the highest possible quality in each of the three areas.
Cooperation between the ANSP and the vendor is essential to achieve a high
total system quality.

2.1.2 Roles and Responsibilities of the ANSP

The ANSP is ultimately responsible for successful implementation of the system.
It is therefore vital that the ANSP takes a positive and active role throughout the
system procurement and implementation.
The vendor is only responsible for developing and integrating a system to the
ANSP’s specific requirements.

5
 Version 2 - May 2008

Air traffic controllers, as the end-users of the system, must play a positive and
active role throughout the procurement and implementation activities. The
clear and complete definition of operational requirements and the final testing in
an operational environment are both critical and are unlikely to be completed
successfully without significant controller input. Clearly defined system
requirements and specifications are vital in order for potential vendors to be able
to offer a suitable system.
Controllers should also be able to contribute to the design, development and
integration activities, and must be directly involved in the testing and
commissioning processes.

2.1.3 Relationships: Requirements, Specification and

Test/Evaluation
The figure below shows the relationships between the operational requirements,
the system requirements, the specification, the design and the test and
evaluation process. Only the combination of a complete and feasible definition
of the requirements, consistent design, quality assured development and
adequate review, testing and evaluation at each stage can provide a quality
system.

6
 Version 2 - May 2008

Operational Operational
Requirements Evaluation

System Total System Test

Requirements (Site Acceptance Test)

System Design System Integration Test

(Specification) (Factory Acceptance Test)
Design Quality determined Production Quality determined

(ANSP)

Subsystems Design Subsystems Unit Test

(Detail Specification) (Factory Test)
Design Quality determined

Subsystems/Components
Development/Production

Figure1. Relationship between Requirement, Specification and Test/Evaluation

2.2 PROJECT MANAGEMENT

A project manager should be appointed as early as possible in the project. The basic
role of the project manager is to ensure that the project proceeds within predetermined
time, resource and cost boundaries. Project management requires a range of special
skills, and serious consideration should be given to employing a professional project
manager for the duration of the project.
The project manager must be given appropriate levels of financial and organisational
authority so that he or she can make project decisions without constant recourse to
higher management. It is essential that the terms of reference of the project manager
are clearly documented and that they detail these authorities.
The project manager will be responsible for managing all aspects of the project, with
particular emphasis on scheduling the many activities of ANSP personnel to match
those of the system supplier. He or she will also play a major role in keeping the
project within the time and budget constraints by determining what, if any, changes are
made to the scope of the contract.

7
 Version 2 - May 2008

2.3 PLANNING AND CONTRACTING

2.3.1 Operational Requirements
The first, and perhaps most critical, stage of the planning and contracting phase
is the definition of the ATS Operational Requirements; these must clearly define
precisely what the system is to do. Operational requirements should not define
how the results are to be achieved – that can be done in the specification.
There is no place for choice in a requirement, and the wording must reflect this;
“must”, “shall” and “will” make requirements mandatory. The use of words such
as “may”, “should” and “could”, “maximum” and “minimum” and “if”, “except” and
“unless” make a requirement imprecise, because the reader does not know
exactly what is required. “There should be 10 sectors” or “there should be at
least 10 sectors” is vague. “There will be 10 sectors” is precise and leaves no
doubt as to what is required.
The operational requirements should be established by a team of experienced
controllers whose professional knowledge and experience encompasses all
aspects of the ATS operation; the team should also include engineers and, as
necessary, other specialists.
2.3.1.1 Studies of Existing Systems
The operational requirements team must have an appreciation of how
data link systems work in the operational environment; this is best
achieved by studying existing systems and talking to experienced
controllers, engineers and managers in other ATS facilities. The study
should cover operational and technical practices and should pay
particular attention to problems encountered and lessons learnt.
Controllers using these systems will be well aware of any features that do
not work well or are not user-friendly, and will have suggestions for how
the system could be improved. This is valuable information that should
be considered when developing the specification and during the contract
negotiation phase; in the latter case, a supplier could be invited to
change such features in an otherwise satisfactory system.
2.3.1.2 Confirmation of Service Environments
The operational requirements team should establish the current ATS
environment as the baseline, taking into account:
ƒ Airspace structure and major airports.
ƒ Sector configuration and VHF/radar coverage.
ƒ The required separation minima (30/30NM horizontal separation
or better)

8
 Version 2 - May 2008

ƒ Traffic flows (routes, number, flight levels, etc.).

ƒ ATS procedures.
ƒ Related ATS facilities.
2.3.1.3 Operational Requirement Analysis
From the baseline, the team should analyse trends to determine the
likely changes in the operational environment over the projected life of
the system. The operational requirements can then be determined, if
necessary using the projected environment at several points during the
projected system life, and should detail, at the very least:
ƒ The anticipated peak and mean traffic levels.
ƒ The number of sectors, based on the traffic levels.
ƒ Specific services for each sector.
ƒ Inter-sector services.
ƒ Inter-ATSU services.
Once these are established, the specific requirements to provide these
services, such as displays and communications, can be determined.,

2.3.2 Design and Review

The next stage is for the team to define the system concept in terms of both
operational requirements and technical feasibility, perhaps using other facilities
as a base reference. The concept should be reviewed by controllers and
managers who are not part of the team; any changes proposed should be
discussed with the team and the concept modified accordingly.
2.3.2.1 Conceptual Design
The conceptual design must be documented clearly and should include
the following:
ƒ ATS functions needed (e.g. ADS reports, traffic display).
ƒ Performance goals for the targeted airspace.
ƒ Sector configuration.
ƒ Physical configuration and layout.
ƒ System operation (e.g. redundant parallel operation, automatic
recovery, etc.).
ƒ Standards to be applied (e.g. ARINC-745, RTCA DO-258A).
ƒ Interface requirements for related ATS facilities.
ƒ Communications Service Provider (CSP) and interface.

9
 Version 2 - May 2008

ƒ Human Machine Interface (e.g. display size, use of colour, input

devices).
The document should also identify any new operational procedures that
may be required, both for new techniques, such as the use of ADS,
CPDLC and AIDC, and for other changes.
2.3.2.2 Technical Feasibility Study
The team may then determine the technical feasibility of meeting the
operational requirements, particularly in terms of the functionality
required, the characteristics and performance of existing systems and
the available budget. Preliminary information from vendors will give an
indication of the systems and capabilities that are available, so that the
team can decide on the most appropriate procurement option:
ƒ A standard “off-the-shelf” system.
ƒ A customized off-the-shelf system.
ƒ A custom-built system.
The criteria to be used in evaluating systems in the market will include:
ƒ Functionality meeting the requirements.
ƒ Adequate performance and capacity to handle future traffic.
ƒ User-friendly and intuitive operation.
ƒ High reliability under all anticipated service conditions.
ƒ Simple connection with related systems and facilities.
ƒ Required standards are met.
2.3.2.3 Specification
When the operational requirements and the feasibility studies have been
completed the specification can be developed. This is discussed in
detail in CHAPTER 5.
2.3.2.4 Design Review
The purpose of this design review is to ensure that the conceptual design
meets each and every one of the operational requirements and that it is
technically achievable and attainable.
The design review team should be independent of the requirements team
but should also comprise controllers, engineers and managers. The
review may take the form of a walk-through of the conceptual design
documents or a desk-top simulation.

10
 Version 2 - May 2008

The design review report should cover:

ƒ Compliance with operational requirements.
ƒ Connectivity with related systems and adjoining facilities.
ƒ Flexibility and expandability in the future.
ƒ Any operational or technical issues.

2.3.3 Request for Proposal (RFP)

A fully-documented and approved Request for Proposal (RFP) should be
submitted to prospective vendors.
2.3.3.1 Objective
The objective of the RFP is to secure fully compliant proposals from a
number of competent vendors.
2.3.3.2 Content
The RFP should contain all the information required for prospective
vendors to make a complete and compliant proposal. Any omissions
will result in enquiries from vendors, which will take time and effort to
respond to. The RFP should contain:
ƒ The specification.
ƒ Operating environment, including:
o External temperature and humidity ranges.
o Temperature and humidity ranges in the equipment area
and operational area.
o Mains power supply voltage and frequency.
ƒ Acceptance testing requirements.
ƒ Maintenance support requirements.
ƒ Training requirements.
ƒ Warranty requirements.
ƒ A draft contract, to allow vendors to see what contract
requirements they will have to meet, and what arrangements they
may have to make to meet them.
ƒ Bidding conditions, including:
o Submission of separate technical and financial bids.
o Confidentiality.
o The enquiry process.

11
 Version 2 - May 2008

o The closing date for enquiries.

o The closing date for bids.
o Notification of short-listed bidders.
o Notification of preferred bidder.
ƒ Financial conditions, including
o Bid bonds (if required).
o Requirements for financing (if necessary).
o Proposed payment schedule.
ƒ The proposal evaluation process, including the evaluation criteria.
2.3.3.3 Enquiry Process
It is inevitable that some bidders will ask for clarification of details or for
additional information. To avoid giving advantage to any particular
bidder, there should be a formal process to ensure that all bidders
receive the same information. This may be done by issuing a bulletin to
all bidders containing each question received and the response. This
should be done at frequent intervals so that vendors have time to adjust
their proposals if necessary.

2.3.4 Evaluation of Proposals

Proposals must not be opened before the stated final date for bids.
The evaluation of proposals must be, and be seen to be, fair and traceable. All
stages of the evaluation process should be clearly documented and the reasons
for each decision recorded.
Ideally, the evaluation team will include all the members of the team that drew up
the specification, complemented by other personnel as necessary. It is good
practice to isolate the evaluation of the financial proposal from the rest of the
process. Besides maintaining the confidentiality of the financial bids, this
avoids any influence of the technical evaluation on the financial and vice versa.
The evaluation process and criteria stated in the RFP must be strictly followed:
this should avoid any protest by unsuccessful bidders.
Proposals are not always perfect, nor do they always fully cover every item of
the RFP, and so there may be a need for clarification during the evaluation
phase. It may be necessary to request additional technical or financial
information in order to complete the evaluation; this should take the form of a
simple request for the specific information required. However, there should be
no negotiation at this stage, of either technical or financial elements.

12
 Version 2 - May 2008

Once the preferred bidder has been selected, the other bidders should be
informed that they may be invited to negotiate if a contract cannot be concluded
with the preferred bidder.

2.3.5 Contract Negotiation

There should be no negotiation with bidders before the selection process has
been completed. Once the preferred bidder has been determined, negotiations
on the detailed conditions are acceptable. Negotiations may be by
correspondence or face-to-face, and should involve the appropriate experts from
the ANSP.
It is important that the negotiations cover all aspects of the contract, including
the vendor’s schedule. The negotiating advantage is with the purchaser until
the contract is signed; it then passes to the vendor. Changes made after the
contract has been signed are inevitably costly and often time-consuming.
The negotiations must be clearly documented.
If a satisfactory contract cannot be concluded, the next preferred bidder may be
invited to negotiate a contract; alternatively, the tender process may be started
again, but this is a costly process and is unlikely to produce a better outcome.
When the contract has been signed, the other bidders should be informed.

13
 Version 2 - May 2008

CHAPTER 3 IMPLEMENTATION

The implementation phase begins when the contract is signed.

Typically, the vendor’s activities during the implementation phase include design review,
manufacture, factory testing, documentation, training, delivery, installation, site
acceptance testing and handover.
The ANSP is involved in all these activities to some degree, except manufacture; but the
ANSP must also prepare for the operation of the system. This will involve developing
test requirements, planning training, organising staff deployment, developing
procedures and planning the operational transfer from the existing to the new system.

3.1 IMPLEMENTATION SCHEDULE

The project manager can now use the vendor’s schedule as the basis for finalising the
overall project schedule. The project schedule should detail all anticipated activities,
including system design reviews, factory and site acceptance tests, training (both
vendor training and internal training), commissioning and operational transfer. The
schedule should also show related activities such as development of operational and
technical procedures and preparation of operational material such as charts.

3.2 CONTRACT SUPERVISION

The project manager is normally responsible for supervision of the contract works.
This can generally be achieved by monitoring the vendor’s progress reports, at least
until the vendor starts work on site.
It is likely that desirable changes to the specification or the contract will be identified
during design reviews or factory testing. However, careful management of change is
essential. Every change will incur costs and delays.
A formal change control system should be implemented, with every change being
submitted for approval only after costs and delays have been established. The
procedure should identify the levels of cost and delay that the project manager can
approve.

3.3 SYSTEM DESIGN REVIEW

This review takes place after the vendor has completed the design for the system, and,
as with the concept design review, is intended to ensure that the design meets all the
operational and technical requirements. The design review is the point at which the
design quality is determined It is also the last stage at which design changes should
be made; however, changes made at this stage are likely to incur costs and delays.

14
 Version 2 - May 2008

3.4 FACTORY ACCEPTANCE TEST

The factory acceptance test is the last opportunity for the ANSP to identify problems
before the system is shipped out from the factory and is the point at which the
production quality is determined. It is also usually the first opportunity for ANSP
personnel to examine and try out the system, and is often combined with factory-based
training. It is important that operational as well as technical personnel attend the
factory acceptance: it should be a test of operational features as well as of technical
compliance.
The vendor should produce a detailed test schedule well before the beginning of the test,
so that the ANSP can consider whether the tests meet the requirements and whether
any additional tests should be included.
The results of any tests performed by the vendor before the acceptance test should be
made available at the start of the acceptance test.
Any problems that are encountered during the factory test should result in agreed
corrective actions to be undertaken by the vendor. These may be carried out before
shipping or on site, according to the nature of the problem. The results of the factory
test form an important part of the contract documentation, as they record the
performance of the system and the agreed corrective actions.

3.5 PREPARATION FOR OPERATION

There are a number of items that the ANSP must address in preparation for operation of
the new system. These include:
ƒ Development of operational procedures.
ƒ Development of system management procedures.
ƒ Preparation of system data (for maps, etc).
ƒ Establishment of system parameters.
ƒ Development of internal training courses for controllers, system operators and
technical staff.
ƒ Development of operational transfer plan.
ƒ Safety assessment.
The ANSP is responsible for carrying out these tasks, although some assistance and
information from the vendor will be necessary to complete them. Some of the work can
be carried before the installation begins, but it may be more convenient to leave some
until the vendor’s specialists are on site.
While it is not appropriate for this guidance material to address each item in detail, some
items do merit discussion.

15
 Version 2 - May 2008

3.5.1 Operational Procedures

The FANS 1/A Operations Manual (FOM) has been adopted for Regional use
and contains the procedures for the use of the data link applications.
The ANSP may need to develop other procedures.

3.5.2 System Management Procedures

Procedures for managing the system must be developed. These should cover
such topics as system start, changeovers between “main” and “standby”
systems, contingency operations, map data management, data recording and
monitoring,

3.5.3 Preparation of System Data

The ANSP will be required to provide data to define, for example, FIR
boundaries for hand-off processing and airspace maps for the display system.
The vendor will provide details of the information required and may either
process the data into the system or, preferably, train and assist the ANSP staff to
do so.
The preparation of this type of data can be a very detailed and time-consuming
process, and due allowance should be made in the project plan.

3.5.4 Establishment of System Parameters

System parameters are used to set values for a number of variables used in the
software. These parameters can be changed, but normally only by software
specialists. Typical system parameters include timer intervals, for example to
set the default interval between ADS periodic contracts, standard range settings,
display colours, etc.
The vendor will detail the system parameters and will be able to suggest suitable
values; however, the ANSP must make the final decision on each parameter.
The parameters should be set before site acceptance testing, so that their effect
can be determined. The parameter values should be finalised before
operational transfer and changes avoided during the initial period of operation.

3.5.5 Development of Training Courses

It may not be practical or appropriate for the vendor to provide initial training for
all personnel, and future training requirements must also be considered. The
ANSP must develop its own training courses to complement the initial training by
the vendor and to meet its future training requirements.

16
 Version 2 - May 2008

3.5.6 Operational Transfer Plan

The operational transfer plan should detail each step of the transfer, particularly
with regard to contingency measures to recover from system problems or
unexpected operational difficulties.
For each step, the plan should give details of the timing, the people involved and
any other resources that may be required. It is important to clearly define the
measures or events that determine that each step has been satisfactorily
completed.
It is also important that the plan is made widely available so that everyone
involved understands what will happen.
The operational transfer process is discussed in 3.8 below.

3.5.7 Safety Assessment

It is most important that a safety assessment (or safety case) is prepared for the
introduction and operation of the system. The purpose of the safety
assessment is to identify all the risks associated with the introduction and
operation of the system, to establish the level of each risk and to determine how
those risks can be removed or reduced to an acceptable level.
Examples of risks are ADS link failure, workstation failure, inadequate controller
training, and failure to close a CPDLC message sequence.
The resulting safety assessment document will list all the risks that have been
identified, the associated risk levels and the measures adopted to remove or
mitigate each risk.
Safety assessments are described in detail in ICAO Doc 9859, Safety
Management Manual.

3.6 TRAINING
Comprehensive training is vital so that controllers, system operators and maintenance
personnel must all be able to carry out their tasks competently and effectively as soon
as the system becomes operational. A comprehensive training plan is a prerequisite
for a successful training programme.
Training is perhaps the most important of all the preparatory tasks.

3.6.1 Controller Training

While the separation standards that controllers apply will probably not change, at
least not immediately on introduction of the new system, the tools they use will
have changed significantly. The training must cover both the operation of the
new workstations and the associated tools and, equally importantly, the
procedures for using the data link applications.

17
 Version 2 - May 2008

Training on the manipulation of the displays and controls should be provided

initially by the vendor, and the ANSP’s training staff should be included in the first
courses. The training staff can then develop and deliver that training.
The procedures for the use of data link applications have been developed within
the Region and are laid out in regional documents. The vendor cannot be
expected to provide training on data link procedures; this is a task that must be
performed by professional training controllers. The training modules must be
developed well in advance, ideally in cooperation with the training sections of
other ANSPs that have experience of data link operations.
The timing of the training is important. There will almost certainly be several
courses to train all controllers, and all training should be completed before
operational transfer. The controllers on the earliest courses may have difficulty
remembering what they have been taught; one solution is to provide short
refresher courses shortly before operational transfer.

3.6.2 System Operator Training

The operation of the system includes starting and stopping the system, switching
between operational and standby units, rebooting, system recovery, changing
system parameters, loading data for maps, etc, and installing software changes.
The vendor must provide the first training courses for system operators. The
syllabus must include the items identified above, with sufficient background to
allow the operators to understand the implications of the various actions that
they will be expected to perform. They should also be given a good
understanding of the various functions of the system.
The training should include practical sessions using the full system, so that the
operators experience the various tasks at first hand.

3.6.3 Maintenance Training

The first training courses for maintenance technicians must also be carried out
by the vendor. With systems of this type, technicians must be able to diagnose
faults down to circuit board level. However, as these systems include a number
of computers, technicians must have an understanding of the general software
structure. They should also be trained to differentiate between hardware and
software faults, and to undertake simple software recovery activities.

3.6.4 Simulator Based Training

If simulator facilities are provided as part of the system, a large proportion of the
training can be carried out using these facilities. Simulators are particularly
valuable in allowing controllers to experience unusual or exceptional conditions,
such as traffic overloads, weather deviations, route changes, emergency
descents, conflictions and system failure.

18
 Version 2 - May 2008

3.7 SITE ACCEPTANCE TEST

The site acceptance test is the last stage before handover by the vendor. This test is
crucial. It is the last opportunity to identify problems while the system remains the
responsibility of the vendor and should be resolved at the vendor’s expense. Once the
acceptance documents are signed, the vendor can fairly claim that any new problems
are the responsibility of the ANSP and will seek costs if asked to rectify them.
The vendor should produce a test schedule well before the tests are due to start, but it is
unlikely that the schedule will contain tests that exercise operational procedures. The
ANSP, in consultation with the vendor, should develop operational scenarios that will
test a wide range of procedures and functions and add these to the schedule.

3.7.1 Physical Checks

The first stage is typically a physical inspection and inventory check to ensure
that all items are present and serial numbers recorded accurately. It is
important to inspect the physical condition of all units and record any defects.

3.7.2 Technical Tests

This is generally followed by the technical tests which establish whether the
system is correctly set up and is working properly. The system parameters are
usually set during these tests, though some may need to be adjusted during the
operational tests. System start-up, changeover and shut-down procedures, as
well as contingency degradation and recovery processes, must also be tested.

3.7.3 Operational Tests

The operational tests determine whether the operational characteristics are
correct, the controls function as expected and the system handles incoming and
outgoing data correctly. There should also be tests to ensure that the system
operates correctly under the specified maximum load.
These tests will typically take several days to complete as all functions must be
tested from all workstations. A number of typical scenarios should be prepared
in advance so that the tests can be carried out in a realistic environment.
It is essential that live testing of the data link functions takes place. Tests of
ADS and CPDLC will require the cooperation of either one or more airlines or
alternatively an aircraft manufacturer with a suitable test-bench. If airlines are
used, it must be quite clear that ATS instructions passed are for test purposes
and are not to be complied with.

3.7.4 Results
As with the factory test, it is most important to record, in detail, all problems and
unusual occurrences.

19
 Version 2 - May 2008

The outcome of the test should include an list of corrective actions to be

undertaken by the vendor within an agreed timescale.

3.8 OPERATIONAL TRANSFER

The most usual ways of transferring operation to a new system are the phased transfer
and the parallel operation transfer.

3.8.1 Parallel Operation Transfer

The parallel operation transfer starts with old system being used operationally
and the new system running in parallel with its controllers going through their
tasks as though that system was operational. When the time comes to switch
over to the new system, the old is system is operated in parallel for a short time
as a fall-back in case of unforeseen problems. Operation of the new system
need not be full-time until shortly before transfer: for example, it would be
appropriate to start parallel operations during low traffic periods and work up to
busy periods. H24 parallel operation is not necessary until immediately before
and after transfer.
The parallel operation transfer is generally preferable as it allows the new
system to be run, in its entirety, in an environment that is as close as possible to
fully operational before actually taking over the operational load. However, it
does require full staffing of both systems during periods of parallel operation.

3.8.2 Phased Transfer

In the phased approach, operations are transferred bit by bit, typically one sector
at a time, until the whole operation is running smoothly on the new system.
This type of transfer may be more appropriate where the space available
dictates that only one or two positions can be transferred at a time or where
limited staff numbers mean that it is impossible to operate both systems
simultaneously.
In this type of transfer, it is good practice to keep at least one sector available on
the old system as a contingency position.

3.8.3 Preparation for Transfer

The transfer must be carefully planned; in particular, there must be close
coordination with external ATS units that may be affected. Staff must be
thoroughly briefed before the start of the transfer process and must be kept
informed of any changes to the plan.
The criteria for deciding when operations can be transferred to the new system
must be clearly defined in advance. If a phased transfer is planned, transfer
criteria should be set for each phase.

20
 Version 2 - May 2008

It is quite possible that problems will arise and it may be necessary to return the
operation to the current system or to the last successful step, as appropriate.
The reversion process should be established in advance – if contingencies have
not been planned for, it is very likely that mistakes will be made and the problem
compounded.
After the transfer has been successfully completed, it is useful to hold a debriefing to
determine what went well and what did not. This can identify potential problems and
possible areas of concern with both the technical and the operational aspects of the
system and the new procedures.

21
 Version 2 - May 2008

CHAPTER 4 REQUIREMENTS

4.1 GENERAL REQUIREMENTS

The integrated ATS data link system will incorporate AFN, ADS, CPDLC and AIDC.

The system will be linked with other automated systems. The FDP system provides
flight plan data, such as the flight identification and flight path. The ATS operation will
be enhanced if the system has the ability to feedback current aircraft positions to the
FDP system to update the flight data.
The system will be linked to aircraft by a communications service provider (CSP).
The system will be capable of transmitting and receiving AFN, ADS and CPDLC
messages complying with RTCA/DO258A-EUROCAE/ED-100 and AIDC messages
complying with the Asia/Pacific Regional Interface Control Document for AIDC (ICD).
The system will include the ACARS Convergence Function (ACF) to convert messages
between the character-oriented data of ACARS and the bit-oriented data used in ADS
and CPDLC.
The system will provide air traffic controllers with:
ƒ Display of message exchanges.
ƒ Display of updated aircraft positions and maps.
ƒ Tools for measuring separation in distance or time.
ƒ Tools for measuring angles between aircraft flight paths.
ƒ Information on aircraft flight status.
ƒ HMI tools for composing ADS and CPDLC messages.
ƒ Alerts for exception conditions (e.g. expected message not received,
coordination overdue).
ƒ Conflict probe capability.
ƒ Electronic flight progress strips, and paper strips if required.
ƒ Presentation of emergency status.
ƒ Other information pertinent to ATS operations.
The system capacity will be determined from:
ƒ Traffic density at the peak hours.
ƒ Frequency and size of messages per aircraft.
ƒ Airspace size and number of waypoints.

22
 Version 2 - May 2008

ƒ Number of FANS capable aircraft operating in the airspace.

ƒ Anticipated growth of FANS operation.
ƒ Number of displays.
ƒ Number of connections for terminal systems.

4.1.1 Notification of Error Messages

The system will be capable of performing the cyclic redundancy check (CRC) on
each message.
The system will be capable of format and validity checks appropriate to each
message.
Controllers will be notified when the system detects:
ƒ A message error.
ƒ A message sequence error.
ƒ A duplicate message identification number.
ƒ Message non-delivery.
ƒ An expected response not received.

4.1.2 Time Stamps and Timers

All time sources used in data link communications must be accurate to within 1
second of UTC in accordance with Annexes 2 and 11.
It is important to note that GPS time is more than 10 seconds ahead of UTC;
where GPS time is used as the source, the system time must be corrected to
UTC.
CPDLC and AIDC messages will be time-stamped; however, the form of some
timestamps is actually set differently from that specified in Doc 9694.
By setting and/or deactivating various timer values for the messages received in
response to transmitted messages, the system will monitor whether or not
aircraft responses arrive within a specified time limit.
Timers are generally based on the operational requirements of each ATSU.
However, the timers for sending messages relating to the automatic transfer of
CPDLC connection and to AIDC will be set according to bilateral agreements
with adjacent ATSUs concerned.
A timer file will be provided in the system for:
ƒ Timeout settings for delayed response.
ƒ Timing to initiate actions in ADS/CPDLC operations for:

23
 Version 2 - May 2008

ƒ Connection request (CR).

ƒ ADS periodic, event and demand requests.
ƒ Automated transfer of connection to the next ATSU.
ƒ Sending Next Data Authority (NDA) message.
ƒ Sending AFN Contact Advisory (FN_CAD): at least 30 minutes
prior to FIR boundary message.
ƒ Sending End Service message prior to the aircraft crossing the
FIR boundary (e.g. 5 minutes before).
ƒ Timer to trigger actions for sending AIDC messages.
ƒ Timer for re-transmission of the message when no response is received
within a specified time.

4.1.3 Applicable Documents

4.1.3.1 ICAO Documents
Annex 10, Volume III, Communication Systems
Manual of Technical Provisions for the Aeronautical Telecommunication
Network – Doc 9750
Manual of Air Traffic Services Data Link Applications – Doc 9694
Regional Supplement to the ASTERIX Interface Control Document (ICD)
for the Asia/Pacific Region
Asia/Pacific Regional Interface Control Document (ICD) for ATS
Inter-facility Data Communications (AIDC)
Guidance Material for End-to-End Safety and Performance Monitoring of
ATS Data Link Systems in the Asia Pacific Region
4.1.3.2 Industry Standards
The industry standards for ATS data link systems are described in the
latest versions of the following documents.
ƒ ARINC 622: ATS Data Link Applications over ACARS Air-Ground
Network (end-to-end).
ƒ RTCA DO-258/EUROCAE ED-100: Interoperability Requirements
for ATS Applications Using ARNC 622 Data Communications.
ƒ ARINC 620: Data Link Ground System Standard and Interface
Specification (ground-to-ground).
ƒ ARINC 619: ACARS Protocols for Avionics End Systems
(Airborne).

24
 Version 2 - May 2008

ƒ ARINC 429: Mark 33 Digital Information Transfer System (DITS).

ƒ FANS 1/A Operations Manual (FOM)
ƒ RTCA DO-306/EUROCAE ED-122 Safety and Performance
Standard for Air Traffic Data Link Services in Oceanic and Remote
Airspace (Oceanic SPR Standard)
Note: It should be noted that some message parameters for avionics are
categorized as ‘option’ data, but provide information useful for ATS operations.

4.1.4 Data Recording

The contents and timestamps of all messages will be recorded by the system.
There will be a facility to retrieve, display and printout the recorded data.

4.1.5 System Performance Monitoring Tool

The Central Reporting Agencies (CRAs) perform safety assessments of data link
performance, and to support this function, in accordance with the FOM, ATSUs
are required to produce monthly statistics of end-to-end system performance in
daily operations. The system performance criteria from the RTCA
DO-306/EUROCAE ED-122 Oceanic SPR Standard are reproduced at
APPENDIX C. The system should have appropriate tools for monitoring and
analysing the performance data for reporting to the appropriate monitoring
agency.

4.2 DATA LINK INITIATION CAPABILITY

4.2.1 AFN Logon Functions
The AFN logon functions provide the necessary information to enable ADS and
CPDLC communications between the system and aircraft avionics systems for:
ƒ Logon.
ƒ Forwarding logon information to the next ATSU.
Note: Details of Data Link Initiation Capability (DLIC) functional capabilities are
provided in Doc 9694 Part 2.
The required capacity for AFN logons will be determined from the operational
requirements, such as estimated number of FANS aircraft at the peak hours and
anticipated growth of FANS traffic.
The system must be capable of accepting or rejecting AFN logon requests.
The system will be linked with the FDPS to correlate the AFN logon data
automatically with the aircraft flight plan.
The controller’s workstation should be capable of displaying the following data:

25
 Version 2 - May 2008

ƒ Address and version number of the aircraft applications, if required.

ƒ Response from the aircraft with timestamp.
ƒ Status of correlation of the aircraft with its stored flight plan.
ƒ Indication of ‘Acceptance’ or ‘Rejection’ to the logon request from aircraft.
When an aircraft downlinks its supported applications and their version numbers
in an FN-CON message, the ground system response must indicate whether or
not it supports those version numbers.
The system must be capable of sending the Acceptance message or the
Rejection message with reason, as appropriate.

4.2.2 Use of AIDC for Forwarding AFN Message

The ATS system should be capable of sending the FANS application message
(FAN), in accordance with the ICD. When possible, the system should use the
AIDC FAN message for address forwarding in preference to the AFN application.

4.3 CPDLC
4.3.1 General
The required capacity of the CPDLC function will be determined by taking
account of the operational policy and procedures and the airspace
characteristics, such as the number of FANS-capable aircraft, airspace size and
number of waypoints, the communications necessary in ATS operations, and of
the estimated future growth of data link operations.
The system will be capable of processing the specified number of message
exchanged with each of the aircraft.
Down-linked CPDLC messages will be displayed to controllers. Tools must be
provided to allow simple and intuitive initiation of, or response to, CPDLC
messages.
Note: The size of the free text field is limited to 80 characters (instead of 256) for
some specific aircraft types.
CPDLC position reports should be used to display aircraft positions when no
ADS report is available.
The system will have the capability of terminating CPDLC connection with the
aircraft.

4.3.2 Transfer of CPDLC between ATC Sectors

The system will allow transfer of CPDLC between sectors of an ATSU without
changing the data authority and with the same CPDLC link.

26
 Version 2 - May 2008

4.3.3 CPDLC Message Exchange Requirements

The system will be capable of handling the message set and the standardized
free text messages defined in the RTCA DO-306/EUROCAE ED-122 Oceanic
SPR Standard and the FOM, as well as free text.
The system will allow controllers to review uplink messages prior to sending.

4.3.4 Message Handling Order

Messages will be handled in order of priority.
Messages with the same priority will be processed in the time order of receipt.
The controller will be alerted to unsuccessful receipt of the required response in
the specified time or receipt of Message Assurance Failure (MAF).

4.3.5 Responses
The system will allow controllers to send any response messages linking with
the reference number of the message received. The relationship between the
message and its intent and the response requirement is defined in the FOM.

4.3.6 Message Closure

A CPDLC dialogue will not be closed until an appropriate closure response for
that message with same reference number is received.
When the closure response message is sent, the dialogue is closed and the
system will reject any further attempt to send a response message.
The capability of closing a CPDLC dialogue, independent of CPDLC closure
message receipt, will be provided.

4.4 ADS
4.4.1 General
The capacity of the ADS function will be determined from the operational policy
and procedures and the airspace characteristics, including number of FANS
capable aircraft, periodic reporting rate, airspace size, waypoint event report
frequency, usage of event and demand contracts, and projected traffic growth.
The system will be capable of initiating periodic, event and demand contracts.
The system will be able to support a demand, an event and a periodic contract
simultaneously with each aircraft.
The system will apply validation checks to incoming data by reference to flight
plan data in relation to time, altitude, direction and position.
The system will be capable of processing ADS reports to display aircraft
positions, tracks and altitude. Between ADS reports, aircraft positions will be
extrapolated and displayed automatically at specified intervals.

27
 Version 2 - May 2008

The data link system should have the capability of supporting 30NM lateral and
30NM longitudinal distance based separation standards.
Air and earth reference data of ADS reports will be provided for controllers if
required.
The types of ADS contract are described at 5.3.1 ADS.

4.4.2 Message Handling

ADS messages will be processed by the system in the following order:
1. ADS emergency mode.
2. Demand/event reports.
3. Periodic report.
Within these categories, messages will be handled in the order received.
The following errors will be notified to controllers:
ƒ Message validation error.
ƒ Message sequence error detected with time stamp.
ƒ Time-out of ADS report in response to request.
ƒ Periodic and waypoint event report failure.

4.5 AIDC
4.5.1 General
General descriptions of AIDC applications, requirements, functional capabilities,
and message contents are provided in the latest version of the ICD.
The AIDC application exchanges ATC coordination information between ATSUs.
Bilateral agreements between ATSUs are necessary to determine the
operational and system requirements for both ATSUs, and should be made
before developing the system. These agreements should cover:
ƒ The ICD to be applied – Asia/Pacific or other ICD.
ƒ message set to be used.
ƒ usage of messages (e.g. timing of transmission).
The AIDC application requires that:
ƒ messages are generated and sent in time-ordered sequence.
ƒ messages are delivered in the order in which they are sent.

28
 Version 2 - May 2008

When an ATSU queues received messages, messages with the highest urgency
type will be placed at the beginning of the queue. Messages will be assigned
one of the following urgency attributes:
ƒ Normal.
ƒ Urgent.
ƒ Distress.
The time used in the AIDC application will be accurate to within 1 second of
UTC.
A timestamp will be generated when the message is dispatched and will consist
of the date (YYMMDD) and time (HHMMSS).
Where an AIDC message is linked to a previously sent message, the message
will contain reference information, including the ID of the referenced message.

4.5.2 Asia/Pacific Interface Control Document (ICD)

The Asia Pacific ICD for AIDC provides the standardized procedures for
inter-facility message exchanges.
(The purpose of the ICD is to ensure that inter-facility message exchanges
between ATSU equipped with automated ATS systems in the Asia/Pacific
Region are harmonized to a common standard.)
Until ATN becomes available, the engineering details needed to implement the
exchange of messages described in Appendix A of the ICD will need to be
agreed to bilaterally.

4.5.3 Message Header

Every message will contain an AFTN header. The AFTN IA-5 message header,
including the use of the Optional Data Field defined in Annex 10, will be
employed for the exchange of data. AFTN priority indicator FF will normally be
used for all data exchanges.
A message header consists of the optional data field (ODF), addressing,
message/data identification number, reference information, time stamp and
cyclic redundancy check (CRC).

4.5.4 ATS Coordination Messages

AIDC provides the means by which data is exchanged between and within
ATSUs for the notification of flights approaching FIR boundary, the coordination
of boundary crossing conditions and the transfer of ATC services.
AIDC messages are also used to exchange emergency, track definition, and
application management information as well as for transfer of surveillance data.

29
 Version 2 - May 2008

4.5.5 Detailed Information Provided in ICD

The appendices to the ICD describe:
ƒ ATS coordination messages (Appendix A).
ƒ Error codes (Appendix B).
ƒ ATM application naming conventions (Appendix C).
ƒ Implementation Guidance Material – IGM (Appendix D).
ƒ Relationship to ICAO AIDC messages (Appendix E).

4.5.6 Performance Requirements

The performance requirements for the trip time of messages need to be
specified and agreed to with neighbouring ATSUs to ensure effective use of
AIDC. Recommended performance figures are specified in Appendix D of the
ICD.
The methodology for monitoring AIDC performance is provided in Appendix A of
the Guidance Material for End-to-end Safety and Performance Monitoring of
ATS Data Link Systems in the Asia/Pacific Region.

30
 Version 2 - May 2008

CHAPTER 5 SPECIFICATION

The development of the specification should, wherever possible, be a team effort, with
operational and technical personnel working together to achieve the optimum result.
System specifications should be based primarily on operational requirements; the
technical specifications should be framed to support those requirements.

In developing a specification for any technical system, it is important to achieve the right
level of detail. Too little detail leaves the purchaser at the mercy of potential suppliers,
while too much may preclude suppliers from offering very suitable equipment. In
general, it is probably appropriate to specify requirements in great detail only where
those requirements are essential to the operation, and otherwise to leave the supplier a
reasonable amount of freedom. An off-the-shelf system can be expected to be less
expensive than one that is custom-designed.

It is also important to get the specification right. Proposals will be priced on the
specification, and any changes required later, particularly after the contract is signed,
will be costly in terms of price and completion time.

This section on specification covers the system configuration, its interfaces with other
systems, its functionality, the operator interface, system capacity, and recording and
data analysis.

5.1 SYSTEM CONFIGURATION

The system configuration depends upon the operational environment. In specifying
the configuration, a number of issues must be considered:
ƒ Is it to be a stand-alone ADS/CPDLC/AIDC system, is it to be part of an
integrated system or is it to be interfaced with a separate ATM system?
ƒ How many sectors are required?
ƒ How many workstations are required per sector? If more than one, why?
ƒ What contingency configuration is required?
ƒ Is complete duplication of the system required?
ƒ What are the requirements for main/standby computers and independent
contingency workstations?
ƒ Will there be duplication of communications bearers? If so, which ones?
ƒ Assuming the normal operational configuration is one workstation per sector,
how many contingency workstations are required?

31
 Version 2 - May 2008

5.2 INTERFACES
The System must have a number of interfaces to send and receive data; some of these
are essential, others may be useful or just nice to have. This section concentrates on
the essential and the useful.

5.2.1 Data Link Communications Service Provider

In the current FANS 1/A environment, ADS and CPDLC messages are passed
between aircraft and the System using the ACARS data messaging system.
ACARS was developed by the data link communications services providers
(CSPs) to pass information between the airline operating centre (AOC) and the
aircraft. ADS and CPDLC required an air-ground data link and, in the absence
of the Aeronautical Telecommunication Network (ATN), the ACARS system was
used.
Access to the ACARS data link is available only from the CSPs; ARINC and SITA
are the major CSPs; they provide global coverage and complete management of
the signal between the ATSU and the aircraft, including selection of most
appropriate data link path (VHF, satellite or HF). There are also some national
or regional CSPs, such as AVICOM Japan.
It is essential therefore to specify the appropriate interface port(s) to connect to
the chosen CSP. This is typically an RS232 serial port, but the exact
requirement should be confirmed with the CSP.

5.2.2 ATN
It is intended that the ADS and CPDLC functions will eventually be carried by the
ATN. The purpose of the ATN is to “provide data communication services and
application entities in support of the delivery of air traffic services (ATS) to
aircraft; the exchange of ATS information between ATS units; and other
applications such as aeronautical operational control (AOC) and aeronautical
administrative communication (AAC).” [Annex 10, Vol III, 3.3]
It is important, therefore, that any new system should either include provisions
for, or have a defined upgrade path to provide, interfacing with the ATN.
ICAO Doc 9705 - Manual of Technical Provisions for the Aeronautical
Telecommunication Network (ATN) is the appropriate source of interface data for
the ATN.
At present, the ATN is under development and trials are being carried out in
several ICAO Regions.

5.2.3 AFTN/AMHS
The AFTN is currently the carrier for ground-ground messaging between ATC
units and carries AIDC messages in the FANS 1/A environment. The AHMS
(Aeronautical Message Handling System) is the ground-ground messaging

32
 Version 2 - May 2008

application of the ATN. The AMHS is also referred to as the ATSMHS (ATS
Message Handling System).
AIDC messages will be passed via the AFTN until the ATN is operational.
However, AFTN/AMHS gateways will increasingly be used to provide a transition
between the AFTN and ATN. These gateways transpose AFTN messages into
AMHS format and vice versa.
Any new system should include at least one AFTN/AMHS gateway. AIDC
messages generated in AMHS structure can then be transmitted via the AFTN
and incoming messages from the AFTN will be transposed to AMHS structure.
After the ATN becomes operational and the AFTN is no longer used, the
gateway can be removed.

5.2.4 ATS systems

In many cases, interfaces to other ATS systems will be necessary. This may be
because an ADS/CPDLC system will use the flight data or other processing
capability of another system or because the new system will be directly
connected to another system.
5.2.4.1 Flight Data Processing System
Where an ADS/CPDLC system is to rely on an existing system to provide
flight data, the interface required will depend on the data to be passed.
The ADS/CPDLC system may have no flight data processing capability
and merely require flight plan information for identification purposes, or it
may have some capability to up-date flight plans received from the other
system and return the up-dated information.
In either case, the interface may need to transform data formats between
the 2 systems. It is therefore essential that the data formats used by the
existing system are detailed in the specification so that they are allowed
for in proposals; otherwise, costly contract variations may be required.
5.2.4.2 Radar Data Processing System
Data imported from a separate radar data processing system will take the
form of track data or possibly plot data. As with interfaces for flight data,
it is most important to detail the radar data formats in the specification.
If ADS data is to be exported to a separate radar data processing system
or display system, the formats required by those systems also must be
detailed.
5.2.4.3 Direct Connection between Systems
When a full system (with FDPS and perhaps RDPS as well as
ADS/CPDLC/AIDC) is to be connected directly to an existing system for

33
 Version 2 - May 2008

full data interchange, details of all the data formats of the existing system
should be included in the specification.

5.2.5 Radar Data

If the System is to receive direct radar feeds from existing radars, the output data
format of each radar must be detailed.
Most new systems are designed around the ASTERIX surveillance data formats;
specifying ASTERIX where possible will allow the greatest flexibility for the
future. The ASTERIX Standard was adopted as the ICD for surveillance data
exchange for the Asia/Pacific Region in 1998. Information on ASTERIX may be
found at:
http://www.eurocontrol.int/asterix/public/subsite_homepage/homepage.html
The “Regional Supplement to the ASTERIX Interface Control Document for the
Asia/Pac Region” gives details of location-specific ASTERIX coding.
Inputs from military radars may be non-standard or require additional
processing; any available details should be included.

5.2.6 ADS-B Data

Where ADS-B data is available or anticipated, the system should be capable of
accepting and processing such data.

5.2.7 Meteorological Data

Many modern systems make provision for the use of meteorological data for
updating predicted waypoint times in near-real time. However, this type of
prediction may require very large amounts of data and may not be justified if
experience shows that weather variations have very little effect on the routes
concerned or where the weather patterns are such that occasional manual input
would suffice.
If there is a requirement for regular automatic data input, the available sources of
data should be investigated and the appropriate formats should be specified.

5.3 FUNCTIONALITY
This section covers the core applications of the system, ADS, CPDLC and AIDC, and
their supporting functions, AFN and ACF.

5.3.1 ADS
ADS is a means of surveillance in which an aircraft reports its current position,
intent and other pertinent information via the data link function to an ATSU.
ADS is detailed in ARINC 745-2.

34
 Version 2 - May 2008

The ADS reporting rate and the types of data to report are determined by ADS
contract requests from an ATSU. An aircraft can report to up to four ATSUs
simultaneously.
There are three types of ADS contract: the periodic contract, the event contract
and the demand (“one-shot”) contract.
5.3.1.1 Periodic Contract
The ATSU sets up a periodic contract with the aircraft to obtain regular
position reports; the contract specifies to the aircraft the reporting rate,
any optional data groups be added to the basic ADS report, and the
frequency at which the optional groups are to be included in the reports.
Only one periodic contract can be established between an ATSU end
system and a particular aircraft at any one time. The periodic contract
normally remains in effect until the contract is cancelled by the ATSU.
The system must be capable of pre-defining the reporting rate as a
system parameter and of allowing the controller to change the rate, on a
case by case basis, to meet operational requirements.
The system must also allow the controller to include any of the
permissible additional data groups in a periodic contract request.
Some systems have the capability of automatically changing the
reporting rate from one area to another; however, this could increase
system cost and complexity.
5.3.1.2 Event Contract
An event contract specifies a request for reports whenever a defined
‘event’ occurs. Only one event contract can be established between a
ground system and a particular aircraft at any one time; however, the
event contract can contain multiple event types. There are four event
types.
The Vertical Rate Change Event is triggered when the aircraft’s vertical
rate is either less than or greater than a parameter defined in the
contract.
The Lateral Deviation Change Event is triggered when the aircraft’s
actual position exceeds a lateral distance parameter from the aircraft’s
expected position on the active flight plan in the FMC.
The Altitude Range Change Event is triggered when the aircraft’s
altitude exceeds the altitude ceiling or floor defined in the contract by the
ground system.

35
 Version 2 - May 2008

Once a vertical rate, lateral deviation or altitude range event trigger has
occurred, a recurrence of this event no longer triggers an event report.
If required, a new event contract must be initiated each time one of these
specific events occurs.
The Waypoint Change Event is triggered by a change to the next or the
next-plus-one waypoints. Such a change normally occurs due to
routine waypoint sequencing. However, it will also be triggered by
occurrences such as a change to a non-ATS waypoint entered by the
pilot for operational reasons, or execution of a new route affecting the
next or next-plus-one waypoints. Unlike the other event contracts, the
waypoint change event trigger remains in effect for all waypoint changes.
Once an event contract has been established, it remains in effect until
the specific event requests are fulfilled, or it is cancelled by the ground
system.
The system must be capable of pre-defining the event trigger parameters
and of allowing the controller to change the event parameters as
required.
5.3.1.3 Demand Contract
The demand contract is a “one-off” request from the ground system for
an ADS report containing specific data as defined in the request. A
demand contract can be requested by the ground system at any time.
The demand contract request does not affect any existing contracts.
The system must allow the controller to initiate a demand contract,
including optional data fields.
5.3.1.4 Emergency Mode
The emergency mode can only be activated by the pilot and is normally
cancelled by the pilot. While it is possible for a ground system to cancel
the emergency mode status, most ground systems do not have this
capability; however, some ground systems allow the controller to modify
the “display” of the emergency mode status.
The system must recognise the emergency flag and display the
emergency status to the controller.

5.3.2 CPDLC
CPDLC provides a two-way message system between controller and pilot. It
comprises an number of pre-defined up-link and down-link messages, some of
which are complete in themselves, while others require data (such as time, flight
level, etc) to be added. There are also two free-text messages available in
each direction, one reserved for emergency use.

36
 Version 2 - May 2008

To send a message, the controller selects the required message and enters any
required data. (Options for selecting messages and entering data are
discussed below under Human-Machine Interface.) The system then
automatically codes the message in bit-oriented format and presents it for
transmission.
On reception of a down-link message, the CPDLC application decodes the
message and presents it to the controller.
The current message set is detailed in the RTCA DO-306/EUROCAE ED-122
Oceanic SPR Standard and the FOM, and the system must provide the complete
up-link message set and be capable of accepting and decoding the complete
down-link message set.
Some message sequences require “closure”:
ƒ A message requiring a response remains open until a referenced response
is received.
ƒ A message is closed when either a response is not technically required, or
after a referenced response other than STANDBY or REQUEST
DEFERRED has been received.
The system must manage message closure protocols in accordance with the
requirements of the RTCA DO-306/EUROCAE ED-122 Oceanic SPR Standard
and the FOM.

5.3.3 ACF
ADS and CPDLC both operate on bit-oriented data, while ACARS is
character-oriented. The ACARS Convergence Function (ACF) converts the
bit-oriented data of ADS and CPDLC to the character-oriented data used by
ACARS, and vice versa.
If the system is to operate over ACARS, the ACF must be specified as an
essential requirement.
(The ACF is not required where the ATN is the carrier.)

5.3.4 AFN
The AFN function provides the transfer of information required to support the
initiation of data link connectivity between an aircraft and an ATSU. The AFN is
a character-oriented application.
Because it is essential to ADS and CPDLC operation over ACARS, the AFN
function as detailed in ARINC 622-4 must be a requirement of the system
specification.

37
 Version 2 - May 2008

5.3.5 AIDC
The AIDC application supports information exchanges for notification,
coordination, and the transfer of communications and control functions between
automated ATS systems located at different ATSUs.
The AIDC message set is defined in the ICD. This message set was based on
ICAO agreed methods and messages wherever possible; elsewhere, new
messages used existing ICAO field definitions to the extent possible.

5.4 OPERATOR INTERFACE

5.4.1 Human Factors
Human factors play a major part in the success or failure of a system to meet its
operational objectives. A system that is uncomfortable to use will lead to
controller dissatisfaction, which as controllers are an essential part of the overall
system, can only degrade the overall system performance.
Displays and keyboards that are poorly designed from a human factors aspect
will be inefficient and may cause actual harm to the users. Bad display design
can affect the eyes and bad keyboard design may result in occupational overuse
syndrome (repetitive strain injury). The human factors implications of the
system specification should be very carefully considered, and it may be
appropriate to get specialist advice.

5.4.2 Displays
One or more displays are required to handle the ADS, CPDLC and AIDC
messages. Many systems incorporate message handling in the situation
display.
Modern displays use LCD technology and may be as large as 600 x 600mm,
with typical resolution of 2048 x 2048 pixels. Smaller displays may be more
appropriate for some uses, particularly if there are 2 displays at a controller
position: a second display is often used for flight data handling. However, the
arrangement of displays will largely depend on the extent to which the new
system is to be integrated with existing systems.
While colour displays offer great advantages in differentiating between different
categories of data, the choice of colours for the various categories can be very
contentious. It is essential that colour allocation is not arbitrarily decided, but is
based upon sound human factors principles. Inappropriate colour choices can
contribute to fatigue, confusion and errors. To avoid these problems, a human
factors expert should be engaged to advise on the use of colour.

38
 Version 2 - May 2008

Different symbols should be used for radar tracks, ADS-B tracks, ADS-C tracks
and tracks generated from flight plan information. The track symbol should be
that of the source of the highest quality information. At the current stage of
development of ADS-B systems, radar is generally accepted as the best
surveillance data, followed by ADS-B and then by ADS-C. Flight plan tracks
are the lowest quality.
The status of the CPDLC connection is important information for the controller
and is best displayed in the track label.

5.4.3 Message Handling

Message handling for ADS, CPDLC and AIDC messages is usually achieved by
some form of menu access for generating messages and by pop-up windows for
replying to incoming messages. Most systems now offer access via the track
label.
For CPDLC, there are two elements to generating most messages: selection of
the specific message and entry of necessary data. The message selection
should be simple: there are about 180 uplink messages available. Some
systems present a selection of appropriate messages – for example, by offering
only height-related messages if the height field in the track label is selected.
ADS contract messages are more simple and infrequently required, so that a
simple menu-type operation is normally adequate. AIDC messages can
usually be generated automatically form flight plan data.
If a particular message handling method is required, it should be clearly stated in
the specification.
The language for all menus and message sets should be English: English is the
de facto language for radiotelephony within the Asia-Pacific Region. While it
may seem attractive for menus and CPDLC messages to be displayed in a local
language, this will inevitably lead to loss of English language proficiency and so
will work against the ICAO language proficiency provisions in Annexes 1, 6, 10
and 11. These provisions require that from March 2008, pilots, aeronautical
station (radio) operators and air traffic controllers shall demonstrate the ability to
speak and understand the language used for radiotelephony communications to
specified levels.

5.4.4 Input Devices

The controller input devices include the text input device and the pointing device.
The text input device is normally a keyboard and there are various types of
keyboard (standard, ergonomic, etc). The type should be specified if it is
considered important; however, it is worth noting that controllers do not have to
input large amounts of text in an ADS/CPDLC system. Touch panels may be
offered instead of keyboards.

39
 Version 2 - May 2008

The mouse is the most common and probably most flexible pointing device;
others include the track-ball and the light pen. It is difficult to locate a track-ball
and keyboard so that they are well-placed for both left- and right-handed people,
and light pens have been poorly received by many controllers.
Wireless connections for the input devices will reduce the clutter on the
workstation working surface and allow more freedom of movement for the
pointing devices. However, electro-magnetic compatibility with nearby
equipment must be carefully considered.

5.5 CONTROLLER TOOLS

Controller tools include such items as:
ƒ Conflict probe
ƒ Temporary maps
ƒ Bearing-distance lines
ƒ Velocity vectors
ƒ Label overlap avoidance

5.5.1 Conflict Probe

Conflict Probe is a tool to determine whether a proposed flight plan will come
into conflict with another during a specified period.
The Conflict Probe is normally initiated by the controller for a particular aircraft.
The probe compares the proposed trajectory with the current planned
trajectories of other aircraft information and displays the position and time of
calculated conflicts to the controller. The period covered by the probe is
typically fairly long (up to several hours), as the main use of Conflict Probe is
when a routing change is proposed under a flexible track regime.
Conflict Probe is a very complex function, requiring considerable computer
power, and consequentially can be expected to be expensive.

5.5.2 Temporary Maps

Temporary maps allow controllers to depict on the display areas of interest on a
temporary basis. Temporary maps should be simple both to construct – a few
straight lines is usually adequate – and to switch on or off on the display.

5.5.3 Bearing-Distance Line

As its name suggests, a bearing-distance line allows a controller to measure the
bearing and distance between 2 points on a display. The points might be an
aircraft track symbol and a reporting point or 2 aircraft track symbols.

40
 Version 2 - May 2008

Some systems allow one or both ends of the line to lock on to an aircraft track
symbol, so that the bearing and distance information displayed is updated as the
aircraft move.
Multiple bearing distance lines, if available, can be useful.

5.5.4 Velocity Vectors

Velocity vectors display a vector from the track symbol showing the calculated
position of the track after a specific time. The time is normally preset to a
default value (typically 2 minutes); most systems allow the controller to set a
different value.
Some systems also allow velocity vectors to be shown for all tracks or for a
selected track only.

5.5.5 Label Overlap Avoidance

Label overlap avoidance allows the track labels to be moved to avoid labels
overlapping one another. This is done by rotating some labels to new positions
relative to the track symbol or by changing the distance of some labels from their
symbols. The process is normally automatic, but should allow the controller to
set selected labels to a preferred position.

5.6 SYSTEM CAPACITY

The required system capacity is directly related to the number of ADS, CPDLC and
AIDC messages, the number of radar tracks, the number of active flight plans, the
number of workstations and so on. These, in turn, are directly related to the volume of
traffic, particularly the peak traffic volume.
The system capacity is normally expressed as the number of active flight plans that the
system can handle at one time; in this context, “active” means that the system is using
or processing the flight plan information in some way.
It is clearly important that the system capacity should allow for traffic growth over the
projected life of the system, which for modern systems is typically 5 to 7 years between
major upgrades or replacement. The anticipated growth should therefore be carefully
assessed using the best projections available, and should allow for daily and seasonal
traffic peaks.
However, it is also important not to set the capacity requirement too high, as this will
almost certainly result in increased cost.
Some growth rates over those periods are shown below to give an indication of future
capacity requirements based on current traffic:

41
 Version 2 - May 2008

Anticipated Total Growth over

Annual Growth
5 years 6 years 7 years

5% 28% 34% 41%

7.5% 44% 54% 66%

10% 61% 77% 95%

5.7 RECORDING AND DATA ANALYSIS

The system should record all incoming and outgoing ADS, CPDLC and AIDC messages
for use in incident and accident investigations. It is imperative that all recordings are
time-stamped. Messages are typically recorded onto a tape cartridge or DVD, and the
system should allow change-over of the cartridge or DVD with no interruption to the
recording.
Annex 10 Vol II and Annex 11 require communications, including AIDC and CPDLC, to
be recorded and the recordings to be retained for at least 30 days for accident/incident
investigation purposes. Chapter 3 of the FOM details some specific recording
requirements for both safety investigation and performance monitoring.
The recording system should allow replaying of the situation and identification of
messages were sent or received by the system.
Provision should also be made to record data for use by the agencies monitoring
reduced horizontal separation (lateral and longitudinal) being applied in accordance with
ICAO Performance Based Navigation (PBN) provisions, RVSM and data link
performance. These are the Safety Monitoring Agency (SMA), the Regional
Monitoring Agency (RMA) and the Central Reporting Agency (CRA) respectively.
Generally, the data required by RMAs and SMAs is captured by the FDPS.
Increasingly, the requirements associated with reduced separation minima will include a
specified Required Communication Performance (RCP) parameter to be met (e.g.
RCP240, RCP400) and data link performance will also need to be monitored against the
technical elements of RCP. Therefore, arrangements should be made to also record
appropriate data to enable RCP analysis to be conducted.
To meet CRA requirements, the specification should include a requirement for data link
performance monitoring tools and analysis software. The analysis software should, at
the least, be capable of extracting time-stamps, addressees and message types from all
incoming and outgoing messages.

42
 Version 2 - May 2008

The table below summarises the FOM data link monitoring requirements for ANSPs.

Requirements Monitor/Record
Operational Procedures Time stamped ATS messages with
identification and reference numbers
Message Assurance
Anomaly event report
Performance End-system availability
Transit times
Safety (i.e. operational, performance Time stamped ATS messages with
and interoperability requirements identification and reference numbers/MAS
which are used to mitigate the effect of
a failure condition)
Anomaly event reports
Interoperability Time stamped ATS messages with
identification and reference numbers/MAS

43
 Version 2 - May 2008

APPENDIX A GLOSSARY
ACARS Aircraft Communications Addressing and Reporting System
ACAS Aircraft Collision Avoidance System (ICAO
ADS Automatic Dependent Surveillance
AEEC Airline Electronic Engineering Committee
AFN ATS Facilities Notification
AFTN Aeronautical Fixed Telecommunication Network
AIDC ATC Inter-Facility Data Communications
AIP Aeronautical Information Publication
AMHS Aeronautical Message Handling System
ANSP Air Navigation Service Provider
AOC Airline Operational Communications
APANPIRG Asia/Pacific Air Navigation Planning and Implementation Regional Group
ARINC Aeronautical Radio Incorporated
ATC Air Traffic Control
ATM Air Traffic Management
ATN Aeronautical Telecommunication Network
ATS Air Traffic Services
ATSMHS ATS Message Handling System
ATSU ATS unit
AVICOM AVICOM Japan Co. LTD
CAA Civil Aviation Authority
CNS Communications, Navigation, Surveillance
CPDLC Controller Pilot Data Link Communications
CRA Central Reporting Agency (for data link)
CRC Cyclic Redundancy Check
CSP Communications Services Provider
DL Downlink message
DSP Data Link Service Provider
EUROCAE European Organization for Civil Aviation Equipment
FANS Future Air Navigation System
FIR Flight Information Region
FIT FANS Interoperability Team (IPACG, ISPACG)
FANS Implementation Team (FIT-BOB, FIT-SEA)
FMC Flight Management Computer
FMS Flight Management System
GES Ground Earth Station (satellite)
GPS Global Positioning System (USA)
HF High Frequency (3-30 MHz)
IATA International Air Transport Association

44
 Version 2 - May 2008

ICAO International Civil Aviation Organisation

IFATCA International Federation of Air Traffic Controllers Associations
IFALPA International Federation of Air Line Pilots’ Associations
IPACG Informal Pacific ATC Coordinating Group
ISPACG Informal South Pacific ATS Coordinating Group
MAS Message Assurance (data message)
MCDU Multipurpose Control Display Unit (ACARS & FMC)
MU Management Unit (ACARS)
NDA Next Data Authority
NOTAM Notice To AirMen
PBN Performance Based Navigation
RASMAG Regional Airspace Safety Monitoring Advisory Group of APANPIRG
RCP Required Communication Performance
RMA Regional Monitoring Agency (for RVSM)
RNP Required Navigation Performance
RTCA RTCA Inc.
RVSM Reduced Vertical Separation Minima
SATCOM Satellite Communication
SATVOICE Satellite Voice Communication
SITA Société Internationale de Télécommunications Aéronautiques
SMA Safety Monitoring Agency (for RNP)
SR&O System Requirements and Objectives (FANS-1 document)
TCAS Traffic Alert and Collision Avoidance System (USA)
TMU Traffic Management Unit
UL Uplink message
VHF Very High Frequency (30-300 MHz)

45
 Version 2 - May 2008

APPENDIX B REFERENCES

Annex 10, Volume III, Communication Systems ICAO

Procedures for Air Navigation Services, Air Traffic
Doc 4444 ICAO
Management
Manual of Technical Provisions for the Aeronautical
Doc 9750 ICAO
Telecommunication Network (ATN)
Basic Air Navigation Plan – Asia and Pacific Regions Doc 9673 ICAO
Manual on Airspace Planning Methodology for the
Doc 9689 ICAO
Determination of Separation Minima
Manual of Air Traffic Services Data Link Applications Doc 9694 ICAO
Safety Management Manual Doc 9859 ICAO
Asia/Pacific Regional Plan for the new CNS/ATM ICAO Asia
Systems Pacific Office
Regional Supplement to the ASTERIX Interface Control ICAO Asia
Document (ICD) for the Asia/Pac Region Pacific Office
Asia/Pacific Regional Interface Control Document (ICD) ICAO Asia
for ATS Inter-facility Data Communications (AIDC) Pacific Office
Guidance Material for End-to-End Safety and
ICAO Asia
Performance Monitoring of ATS Data link Systems in the
Pacific Office
Asia Pacific Region
FANS 1/A Operations Manual
Interoperability Requirements for ATS Applications using DO-258A / RTCA and
ARINC 622 Data Communications ED-100A EUROCAE
Safety and Performance Standard for Air Traffic Data link
DO-306 / RTCA and
Services in Oceanic and Remote Airspace (Oceanic SPR
ED-122 EUROCAE
Standard)
Air-Ground Character-Oriented Protocol Specification 618-5 ARINC
Data Link Ground Systems Standard and Interface
620-5 ARINC
Specification (DGSS/IS)
ATS Data Link Applications Over ACARS Air-Ground
622-4 ARINC
Network
Aircraft Communications Addressing Reporting System
724B-5 ARINC
(ACARS)
Air Traffic Services Systems Requirements & Objectives
Boeing
(ATS SR&O)

46
 Version 2 - May 2008

APPENDIX C PERFORMANCE CRITERIA

SYSTEM PERFORMANCE CRITERIA

The RTCA DO-306/EUROCAE ED-122 Safety and Performance Standard for

Air Traffic Data link Services in Oceanic and Remote Airspace (Oceanic SPR
Standard) contains the safety and performance requirements for data link
services that need to be met and verified. This does not prevent ATS service
providers from negotiating more constraining contractual requirements with
their communication service providers if necessary.
Note The Oceanic SPR standard provides an availability requirement for
safety of 0.999, however to enable operational efficiency in some
environments, the FANS-1/A availability requirement is set at 0.9999. This
0.9999 availability requirement translates on a per ATSP basis to:
¾ No more than 4 outages (affecting a significant portion of aircraft) greater
than 10 minutes for any 12 month period;
¾ Failures causing outages for multiple OACs are not counted more than
once; and
¾ No more than 50 minutes of total downtime for any 12 month period.

The Tables and Figure below summarise the requirements of the Oceanic SPR
Standard

Performance Definition Values

Criteria

RCP 240/D Normal means of communication for Communication

application of 30 NM lateral separation and Transaction time
reduced distance-based longitudinal
ET 240 (sec)
separation minima

Note: Communication Transaction time is defined as the maximum time for the completion
of an operational transaction after which the initiator reverts to an alternative procedure.
(ICAO Doc 8689)

47
 Version 2 - May 2008

RCP400/D Normal means of communication for ET 400 (sec)

application of lateral separation greater than or
equal to 50 NM and time-based longitudinal
separation.
Alternative means of communication for
application of 30 NM lateral separation and
reduced distance-based longitudinal
separation minima

Surveillance Normal Surveillance: ET 180 (sec)

(position report delivery)
50 NM
Longitudinal Non-normal Surveillance:
ET 240 (sec)
(Controller initiated position report request)
30 NM
Longitudinal
30 NM Lateral

Surveillance Normal Surveillance ET 400 (sec)

>50NM Lateral
>=10 mins time
based

Availability The probability that an operational 99.99%

communication transaction can be initiated
when needed (ICAO Doc 8689)

Continuity The probability that an operational 99.9%

communication transaction can be completed
within the communication transaction time
(ICAO Doc 9869)

Integrity The probability of one or more undetected 10-5/hour

errors in a completed communication
transaction.

48
 Version 2 - May 2008

RCP type RCP 240/D RCP 400/D

Time Parameter ET 95% ET 95%

Time Value 240 210 400 350

RCP Time Allocations

Initiator 30 30 30 30

TRN 210 180 370 320

TRN Time Allocations

Responder 60 60 60 60

RCTP 150 120 310 260

RCTP Time Allocation

Aircraft 15 10 15 10

Communication service 120 100 280 240

ATS unit 15 10 15 10

Note 1: Values shown in seconds.

Note 2: Expiration time (ET) is at the continuity requirement, which is 99.9%.

Table 1: 50 longitudinal and 30/30 - intervention (DO-306/ED-122, Table 5-6)

Flight crew/ Aircraft Comm. Ground Controller/

HMI System service System HMI
Clearance used for
1 intervention
Operational communication transaction

Initiator
RCTP
Responder RCP
TRN type
2

Acknowledgement of
clearance
Human
confident that
transaction is
Information Report complete
3

Figure 1: RCP allocations for intervention capability (DO-306/ED-122, Figure 5-3)

49