9906 - Vol III - Flight Procedure Design Software Validation (1) 2010

Doc 9906
AN/472
Quality Assurance Manual

for Flight Procedure Design
Volume 3
Flight Procedure Design
Software Validation
Approved by the Secretary General

and published under his authority
First Edition — 2010
International Civil Aviation Organization

Doc 9906
AN/472
Quality Assurance Manual

for Flight Procedure Design
________________________________
Volume 3
Flight Procedure Design
Software Validation
Approved by the Secretary General

and published under his authority
First Edition — 2010

)
Published in separate English, French, Spanish, Russian,
Arabic and Chinese editions by the
INTERNATIONAL CIVIL AVIATION ORGANIZATION
999 University Street, Montréal, Quebec, Canada H3C 5H7
For ordering information and for a complete listing of sales agents

and booksellers, please go to the ICAO website at www.icao.int
First edition 2010
ICAO Doc 9906, Quality Assurance Manual for Flight Procedure Design
Volume 3 — Flight Procedure Design Software Validation
Order Number: 9906-3
ISBN 978-92-9231-450-7
© ICAO 2010
All rights reserved. No part of this publication may be reproduced, stored in a

retrieval system or transmitted in any form or by any means, without prior
permission in writing from the International Civil Aviation Organization.
AMENDMENTS
Amendments are announced in the supplements to the Catalogue of ICAO

Publications; the Catalogue and its supplements are available on the ICAO
website at www.icao.int. The space below is provided to keep a record of
such amendments.
RECORD OF AMENDMENTS AND CORRIGENDA
AMENDMENTS CORRIGENDA
No. Date Entered by No. Date Entered by
1 8/8/13 ICAO 1 22/2/11 ICAO
(iii)
PREFACE
The Quality Assurance Manual for Flight Procedure Design (Doc 9906) consists of six volumes:
Volume 1 — Flight Procedure Design Quality Assurance System;
Volume 2 — Flight Procedure Designer Training (Development of Flight Procedure Designer Training Programme);
Volume 3 — Flight Procedure Design Software Validation;
Volume 4 — Flight Procedures Design Construction (to be developed);
Volume 5 — Validation of Instrument Flight Procedures; and
Volume 6 — Flight Validation Pilot Training and Evaluation (Development of a Flight Validation Pilot Training
Programme).
Instrument flight procedures based on conventional ground-based navigational aids have always demanded a high level
of quality control. The implementation of area navigation and associated airborne database navigation systems,
however, means that even small errors in data can lead to catastrophic results. This significant change in data quality
requirements (accuracy, resolution and integrity) has led to the need for a systemic quality assurance process. The
Procedures for Air Navigation Services — Aircraft Operations (PANS-OPS, Doc 8168) Volume II, Part I, Section 2,
Chapter 4, Quality Assurance, refers to this manual and requires that a State take measures to “control” the quality of
the processes associated with the construction of instrument flight procedures. To this end, this manual has been
assembled to provide guidance in attaining these stringent requirements for quality assurance in the procedure design
process. All four volumes address crucial areas related to the attainment, maintenance and continual improvement of
procedure design quality. Data quality management, procedure designer training, and validation of software are all
integral elements of a quality assurance programme.
Volume 1 — Flight Procedure Design Quality Assurance System provides guidance for quality assurance in the
elements of procedure design, such as procedure design documentation, verification and validation methods, and
guidelines about the acquisition/processing of source information/data. It also provides a generic process flow diagram
for the design and implementation of flight procedures.
Volume 2 — Flight Procedure Designer Training provides guidance for the establishment of flight procedure designer
training. Training is the starting point for any quality assurance programme. This volume provides guidance for the
establishment of a training programme.
Volume 3 — Flight Procedure Design Software Validation provides guidance for the validation (not certification) of
procedure design tools, notably with regard to criteria.
Volume 4 — Flight Procedures Design Construction (to be incorporated later).
Volume 5 — Validation of Instrument Flight Procedures provides guidance for the implementation of a validation
process of instrument flight procedures.
Volume 6 — Flight Validation Pilot Training and Evaluation provides guidance for the establishment of a flight validation
pilot training programme.
(v) 8/8/13
No. 1
(vi) The Quality Assurance Manual for Flight Procedure Design — Volume 3
Note.— In the independent volumes, when a reference is made to the term “manual” in the context of this
document, without any further specification, it is presumed to refer to this volume of the Quality Assurance Manual for
Flight Procedure Design.
_____________________
8/8/13
No. 1
TABLE OF CONTENTS
Page
PREFACE ......................................................................................................................................................... (v)
TABLE OF CONTENTS .................................................................................................................................... (vii)
ABBREVIATIONS.............................................................................................................................................. (ix)
DEFINITIONS .................................................................................................................................................... (xi)
FOREWORD ..................................................................................................................................................... (xiii)
STRUCTURE OF THE MANUAL ..................................................................................................................... (xv)
Chapter 1. Introduction ................................................................................................................................ 1-1
1.1 Automation in the procedure design domain..................................................................................... 1-1

1.2 The need for validation of procedure design tools ............................................................................ 1-1
1.3 Application of the manual.................................................................................................................. 1-1
Chapter 2. Scope .......................................................................................................................................... 2-1
2.1 Goal of the manual ........................................................................................................................... 2-1

2.2 Functional validation ......................................................................................................................... 2-1
2.3 Validation with regard to criteria ........................................................................................................ 2-1
2.4 Aeronautical and geographical data used in procedure design tools ................................................ 2-2
2.5 Applicability of the validation to procedure design tools .................................................................... 2-2
2.6 Report of the validation with regard to criteria................................................................................... 2-3
2.7 Requirements for revalidation ........................................................................................................... 2-3
2.8 Ambiguities in reference material ...................................................................................................... 2-3
Chapter 3. Overview of procedure design tools ........................................................................................ 3-1
3.1 Main functions of procedure design tools.......................................................................................... 3-1

3.2 The two main types of procedure design tools.................................................................................. 3-3
Chapter 4. Implementing a validation programme .................................................................................... 4-1
4.1 Preparation ....................................................................................................................................... 4-1

4.2 Software validation coverage ............................................................................................................ 4-1
4.3 Tool testing requirements ................................................................................................................. 4-1
4.4 Validation methodology..................................................................................................................... 4-2
4.5 Validation documentation.................................................................................................................. 4-2
(vii)
(viii) The Quality Assurance Manual for Flight Procedure Design — Volume 3
Chapter 5. Environment of procedure design ............................................................................................ 5-1
5.1 Tool documentation .......................................................................................................................... 5-1

5.2 Geographical information .................................................................................................................. 5-1
5.3 WGS-84 calculations ........................................................................................................................ 5-1
5.4 Magnetic variation ............................................................................................................................. 5-2
Chapter 6. Tool inputs .................................................................................................................................. 6-1
6.1 Aeronautical data integration and updates........................................................................................ 6-1

6.2 Terrain data input validation.............................................................................................................. 6-2
Chapter 7. Procedure design functions ...................................................................................................... 7-1
7.1 Considerations about units and rounding processes ........................................................................ 7-1

7.2 Validation of basic data and parameters ........................................................................................... 7-2
7.3 Basic element validation ................................................................................................................... 7-2
7.4 Modelling of criteria validation........................................................................................................... 7-3
7.5 Application of criteria modelling validation to design and layouts (conventional/RNAV) ................... 7-4
7.6 Application to the standard modelling validation for calculations ...................................................... 7-41
7.7 Specific cases ................................................................................................................................... 7-41
Appendix A. Geographical transformations/conversions......................................................................... App A-1
Appendix B. WGS-84 calculations .............................................................................................................. App B-1
Appendix C. Basic data and parameters .................................................................................................... App C-1
C-1 Raw data and reference values for procedure design calculations ................................................... App C-1
C-2 MOC values ...................................................................................................................................... App C-2
Appendix D. Basic element validation ........................................................................................................ App D-1
D-1 Fixes and waypoints construction ..................................................................................................... App D-1

D-2 Sample results for the calculation of TAS ......................................................................................... App D-3
D-3 Nominal track construction................................................................................................................ App D-4
D-4 Obstacle evaluation in departure procedures ................................................................................... App D-5
D-5 ILS MLS surfaces construction ......................................................................................................... App D-5
D-6 Obstacle evaluation in ILS/MLS approaches .................................................................................... App D-6
D-7 Obstacle evaluation in RADAR approaches ..................................................................................... App D-6
D-8 Straight-in approach ......................................................................................................................... App D-7
D-9 OCH adjustment ............................................................................................................................... App D-7
D-10 Slope and rate of descent ................................................................................................................. App D-7
Appendix E. Sample validation documentation ......................................................................................... App E-1
Quality Assurance Feedback Form................................................................................................................ Q-1
_____________________
ABBREVIATIONS
AIXM Aeronautical information exchange model

ARP Aerodrome reference point
ATS Air traffic services
ATT Along-track tolerance
CAD Computer-aided design
CMMI Capability maturity model integration
CRM Collision risk model
CTR Control zone
DAFIF Digital aeronautical flight information files
DME Distance measurement equipment
DTM Digital terrain model
eTOD electronic terrain and obstacle data
FTA Fix tolerance area
GIS Geographic information system
IAS Indicated air speed
IEEE Institute of electrical and electronic engineers
ILS Instrument landing system
LOC Localizer
MOC Minimum obstacle clearance
MOCA Minimum obstacle clearance altitude
MSA Minimum sector altitude
NDB Non-directional radio beacon
OAS Obstacle assessment surface
OCA/H Obstacle clearance altitude/height
OLS Obstacle limitation surfaces
PDG Procedure design gradient
RNAV Area navigation
SI International system of units (Système International)
TACAN (UHF) tactical air navigation aid
TMA Terminal area
UTM Universal transverse mercator
VOR VHF Omnidirectional radio range
WGS-84 World Geodesic System — 1984
WP Waypoint
XTT Cross-track tolerance
_____________________
(ix)
DEFINITIONS
Acceptance. The act of accepting with formal approval (favourable reception).
Automation. The automatic operation or control of equipment, a process, or a system.
Basic element. The lowest level object identified within a specific function.
Basic parameter. Reference parameter or constant defined in the applicable criteria for procedure design calculations.
Modelling of criteria. A schematic description of criteria that accounts for its properties and may be used for further
study or application of its characteristics.
Procedure design function. An element of a procedure design software executing a predefined task and providing
output to the procedure designer.
Note.—The description of a procedure design function needs to include all required input (values, format,
etc.) and a comprehensive description of the expected outputs. For example, outputs may include:
• result of checks for consistency of input with the applicable regulation;

• results of various calculations (area width, MOCA, etc.); and
• protection area drawing.
Procedure design tool. Automation system that provides calculations and/or designs and layouts in the field of
procedure design.
Software environment. Software used to support an automation tool, such as an operating system, or database
management system.
Software validation. Acknowledgement, derived from a series of tests, of the compliance of an automation system with
the applicable standards.
Functional validation. Confirmation of the correct implementation of automation functions and of the compliance of
the human machine interface with the user requirements.
Validation with reference to criteria. Confirmation through a series of tests of the compliance of the results with
reference to applicable criteria.
Test. A basis for critical evaluation.
Validation. Confirmation, through the provision of objective evidence, that the requirements for a specific intended use
or application have been fulfilled (see Annex 15 — Aeronautical Information Services).The activity whereby a data
element is checked as having a value that is fully applicable to the identity given to the data element, or a set of
data elements that is checked as being acceptable for their purpose.
Verification. Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
(see Annex 15).The activity whereby the current value of a data element is checked against the value originally
supplied.
_____________________
(xi)
FOREWORD
The Foreword to the Procedures for Air Navigation — Operations (PANS-OPS, Doc 8168) Volume II, states that “The
implementation of procedures is the responsibility of Contracting States.” This implies that the State authorities have the
final responsibility for the procedures published within their territory.
The procedure design process may be carried out by States themselves or by delegation from States to third parties
such as air traffic services (ATS) providers, private companies or another State.
When automation is used during the procedure design process, States must ensure that automation functions have
been validated to ensure compliance of the final results with applicable criteria.
Implementation of the validation can be carried out by States themselves or by delegation to any recognized third party
(such as another State, an ATS provider or a private company).
This manual is guidance material; it provides one means, but not the only means, for validation of the functions of
procedure design tools. Other means include a Software Safety Assurance System, as part of a Safety Management
System (comprising requirements for software assurance level, software verification assurances, software configuration
management assurances, software requirements traceability assurances, software requirements validity assurance).
Note.— The manual may also be useful for software development companies wishing to demonstrate
conformance to applicable criteria. It may also be of interest to any person or organization involved in the procedure
design domain.
This manual has been developed with active input from representatives of the procedure design software industry. It is
recognized that other software validation documents not specific to the flight procedure design domain exist, such as the
ones defined by IEEE, CMMI, EUROCONTROL and RTCA.
Comments on this manual, particularly with respect to its application, usefulness and scope of coverage, would be
appreciated from States and ICAO Technical Cooperation field missions. These will be taken into consideration in the
preparation of subsequent editions. Comments concerning this manual should be addressed to:
The Secretary General

999 University Street
Montréal, Quebec, Canada
H3C 5H7
_____________________
(xiii)
STRUCTURE OF THE MANUAL
This manual is organized as follows :
Chapter 1 — Introduction presents a rationale for automation in the procedure design domain and the need for validation
of the procedure design tools. It states the main principles regarding the applicability of the manual.
Chapter 2 — Scope specifies the goal of the manual and reviews the various types of validation and their applicability to
procedure design tools. The chapter includes requirements about the reporting of validation and the iterative validation
process, as well as some guidance on reporting of inconsistencies within PANS-OPS.
Chapter 3 — Overview of procedure design tools provides general information about these tools, their main functions
and the main types of existing tools.
Chapter 4 — Implementing a validation programme provides practical guidance to prepare and carry out an actual
validation programme applied to procedure design tools.
Chapter 5 — Environment of procedure design sets general requirements about the documentation of the tools, the
management of geographical information, and WGS-84 calculations.
Chapter 6 — Tool inputs provides requirements about the input and update of aeronautical and terrain data.
Chapter 7 — Procedure design functions is the main part of the manual. It includes four main parts: considerations about
units and rounding processes, basic parameter validation, basic element validation and modelling of criteria validation.
Drafting conventions
The following drafting conventions are used in this manual:
• “must” indicates a statement of specification, the compliance with which is required to achieve the
implementation of the specification;
• “should” indicates a recommendation or best practice; and
• “may” indicates an optional element.
_____________________
(xv) 22/2/11
Corr.
Chapter 1
INTRODUCTION
1.1 AUTOMATION IN THE PROCEDURE DESIGN DOMAIN
1.1.1 Thanks to the latest developments in computer techniques, procedure design tools are increasingly being
used by designers with the goal of quality control and integrity enhancement in the procedure design domain.
1.1.2 The term “procedure design tool” stands for any numerical automation system that provides calculations
and/or designs and layouts in the field of procedure design. This encompasses products ranging from automated
formulas included in spreadsheets to dedicated software packages.
1.1.3 Procedure design tools aim to aid the design of conventional and/or area navigation (RNAV) procedures
for the departure, en-route, arrival, terminal and/or approach phases, through a series of dedicated integrated functions.
They facilitate design work through a certain level of automation in calculations and procedure layout generation
compliant with the applicable criteria. In addition, this automation in calculations contributes to the improvement of data
integrity.
1.1.4 Procedure design tools include devices which facilitate the work of the designer during the whole process
of procedure design, from data management to the final output (preparation of the publication).
1.1.5 Use of automation is not intended to replace the procedure designer’s expertise.
1.2 THE NEED FOR VALIDATION OF PROCEDURE DESIGN TOOLS
1.2.1 Although procedure design tools are increasingly available to designers and can save significant time
when creating designs, as well as improve compliance with collaborative work, they can be misleading if they contain
errors, or if procedure design criteria compliance is not ensured through all the functions provided by such tools. Thus,
there is a significant need to define a validation process for procedure design tools. Additionally, the validation is a
means for users to gain confidence in a tool.
1.2.2 It is recommended that both the procedure design organization using a tool and the procedure design
software developer/provider be involved in its validation.
1.3 APPLICATION OF THE MANUAL
1.3.1 This manual is based on the criteria defined by ICAO, especially those contained in the Procedures for Air
Navigation — Aircraft Operations (PANS-OPS, Doc 8168).
Note.— The version of PANS-OPS referenced in this manual is the fifth edition, Volumes I and II.
1-1 22/2/11
Corr.
1-2 Quality Assurance Manual for Flight Procedure Design — Volume 3
1.3.2 Amendments to the reference criteria must be reflected as soon as possible in the software tools.
1.3.3 The guidelines provided in this manual constitute a framework that can be adapted to other criteria (e.g.
national criteria) as appropriate.
_____________________
Chapter 2
SCOPE
2.1 GOAL OF THE MANUAL
2.1.1 The goal of the manual is to provide guidelines for the validation of procedure design tools in compliance
with criteria.
Note.— Validation is an acknowledgement that the standards derived from a series of tests have been
complied with, and does not imply any certificate delivery. A procedure design tool validation means that compliance
with standards is recognized for most significant cases of the tool use. A validation assumes the existence of applicable
standards and a given methodology (guidance and pre-defined tests). Validation may occur after development, using
“off-the-shelf” products.
2.1.2 The scope of this manual excludes the certification of procedure design tools.
Note.— Certification is defined as an official acknowledgement that the standards derived from a given
procedure (certification procedure) have been complied with, and implies the delivery of a certificate of compliance. As
such, a procedure design tool certification would imply that the tool is in compliance with applicable standards in all the
studies that can be carried out with it. The certification assumes the existence of applicable standards and a certification
procedure. Moreover, the certification must cover the whole tool, including the software development phase (with a
DO-278B-like approach) and must be set up as from the initial development (algorithm generation) of the tool.
2.2 FUNCTIONAL VALIDATION
2.2.1 Functional validation consists of confirmation that the automation functions in the tool have been correctly
implemented (e.g. when selecting an item in a menu, the item appears), and that the human machine interface complies
with the user’s requirements. As such, this validation type is dependent upon the user needs and can be carried out
during the acceptance phase by the end users. Moreover, the functional validation does not refer to procedure design
criteria, but to general specifications (interface and ergonomics, general computerized tool specifications, etc.).
2.2.2 Functional validation falls outside of the scope of this manual. However, it may be considered by users in
addition to the guidelines provided in this manual.
2.3 VALIDATION WITH REGARD TO CRITERIA
2.3.1 Validation with regard to criteria consists of a compliance verification of the results obtained in a series of
tests of the tool using applicable criteria. The applied tests must cover all the relevant functions of the tool (including
general functions and some input/output functions). These tests should include the comparison between the results
obtained with the tool and the ones obtained manually or with a previously validated independent tool. These tests must
be carried out according to a predefined list and guidance.
2-1
2.3.2 The series of tests recommended in this manual should be considered as a minimum, and the actual
validation may include additional tests if deemed relevant.
2.4 AERONAUTICAL AND GEOGRAPHICAL DATA

USED IN PROCEDURE DESIGN TOOLS
2.4.1 The quality of procedure designer work is highly dependent on the quality of information used by the
designer. With the advent of automation, information is now mostly stored in databases, both for aeronautical data and
geographical data.
2.4.2 Notwithstanding the data quality itself (this falls outside the scope of this manual), the methods used to
integrate and update the data constitute a critical element in obtaining the correct results computed by tools. Thus,
guidance for validation of data input and updates is included in this document.
2.4.3 Processing aeronautical data (e.g. WGS-84 geodetic calculations, transformation between reference
systems and projection-based systems) can be critical for the validity of procedure design. Guidance about these
processes is included in this manual.
2.4.4 As far as geographical data are concerned, some procedure design tools use terrain data (digital terrain
models, triangular irregular networks, etc.) for display purposes, while others use them as a part of internal calculation
and for procedure layout generation. The validation of the use of terrain data only addresses tools that use the data for
calculations. The validation of the use of geographical data for display purposes only falls outside the scope of this
manual.
2.4.5 It has been shown that some inconsistencies concerning the correct input of terrain data (in terms of
geographical reference coherency) may not be detected by procedure designers, but actually do occur and could
introduce large discrepancies in the final results when these data are used in the calculations. Considering the potential
consequences of such errors, and the difficulty in detecting them, particular care must be taken in the validation of
terrain data integration in procedure design tools, whenever they are used as part of calculations.
2.5 APPLICABILITY OF THE VALIDATION TO PROCEDURE DESIGN TOOLS
2.5.1 This validation manual may be applicable to individual functions of a given tool, or to the whole tool. It is
acknowledged that an individual tool may not include all the procedure design functions and consequently some
validation items may not be applicable to each and every tool. It is also recognized that a given user may not require a
function included in a given tool. The applicability of each item of the validation manual should thus be determined at the
time of the validation execution.
2.5.2 The composition of the validation should include all the critical functions in the procedure design process,
but some items can, at least during a first phase, be taken over from other domains (e.g. quality of the aeronautical data
taken over from the aeronautical information services domain).
2.5.3 The validation of a tool should be carried out for a given software environment (operating system,
geographic information system (GIS) or computer-aided design (CAD) supporting system, database management
system, etc.). Should this environment change, a further validation may have to be carried out (see 2.7.3).
Chapter 2. Scope 2-3
2.6 REPORT OF THE VALIDATION WITH REGARD TO CRITERIA
2.6.1 The validation process must be recorded in a report that clearly states the criteria that were considered as
reference (with dates and reference to the last considered amendment), and the extent of coverage of the software tool
with respect to these criteria.
2.6.2 The report must precisely mention all the items that were tested (with detailed results) and the items that
were excluded from the validation process. Any limitation to a given function (e.g. altitude restriction for holding patterns)
must be recorded.
2.6.3 The validation report must mention the characteristics of the tests (dates, name of individuals that have
conducted the tests, etc.). The version of the tool, of the software environment (GIS, CAD, database management
system, etc.), and of the operating system that were used must be recorded in the report.
2.6.4 Notes and comments from the final users about the compliance with criteria should be recorded in the
validation report.
2.6.5 A template for the validation report is provided in Appendix E.
2.7 REQUIREMENTS FOR REVALIDATION
2.7.1 Whenever the applicable procedure design criteria are updated, the impact on the procedure design tool
must be identified by the procedure design software developer/provider and evaluated. Should the changes have an
impact on procedure design tool functions, the corresponding functions of the tool must be revalidated.
2.7.2 Whenever a new version of the software tool is issued, the changes with reference to the previous version
must be identified and their consequences must be evaluated. Should the new version include new functions or
amendments to previous functions, the tool must be revalidated.
2.7.3 As the computing environment of the software (operating system, GIS or CAD supporting system,
database management system, etc.) evolves, the consequences on the tool must, whenever possible (*), be identified
and evaluated. If deemed necessary, full or partial revalidation should then be conducted.
(*) It is acknowledged that some updates may not be documented or notified. In those cases, the
identification and evaluation of consequences may not be possible.
2.8 AMBIGUITIES IN REFERENCE MATERIAL
2.8.1 It is recognized that the validation process may lead to pointing out ambiguities in the current PANS-OPS.
2.8.2 Any problem encountered during the validation process that is assumed to be due to ambiguities in
PANS-OPS should be reported to ICAO for consideration throughout the appropriate process.
_____________________
Chapter 3
OVERVIEW OF PROCEDURE DESIGN TOOLS
3.1 MAIN FUNCTIONS OF PROCEDURE DESIGN TOOLS
Introduction
3.1.1 Procedure design tools provide users with functions that can be split into three main categories:
environment for design, inputs and outputs, and specific procedure design.
Environment for design
3.1.2 The category “environment for design” corresponds to the whole set of general aspects that a procedure
designer has to take into consideration during design, but which are not specifically related to standard criteria.
3.1.3 This includes the following aspects:
• geographical information: coordinate reference system integration, WGS-84 calculations, conversion

between various reference systems, charting projections, etc.;
• graphical tools: creation and management of graphical objects (segments, curves, texts, etc.), 2-D or
3-D display of geographical information;
• reference material: direct access to reference criteria and documentation used for design;
• recording and archiving the work of the designer for subsequent studies; and
• reports of procedure design studies.
3.1.4 The correct implementation of the environmental functions contributes to the correct functioning of the
tools. Thus, the validation of these functions is necessary, and it is included in this manual.
3.1.5 It should be noted that these functions are generally issued from validated systems such as GIS for
geographical information, CAD systems for graphical tools, digital copies of paper reference material and general
automation functions for recording and archiving.
Tool inputs and outputs
3.1.6 The tool inputs and outputs correspond to the integration and release of digital information and data
to/from the software tools. These functions include the management of input and output data format for some of the
aeronautical and terrain data the designers utilize (collision risk model (CRM) obstacles, AIXM, ARINC 424, DAFIF).
3.1.7 The input function corresponds to the capabilities to integrate information and/or data useful for the
procedure design. It encompasses the original acquisition of information/data, and the update processes.
3-1
3.1.8 This includes the following items :
• integration of raster data: “bitmap” charts, images, digital terrain models (DTM), etc.;
• integration of vector files: vector DTM, topographical data, etc.;
• integration, management and update of aeronautical information: navaids, aerodromes, obstacles,

airspace, etc.
3.1.9 The input of data in a procedure design tool may be carried out either through the automatic loading from a
database or through manual data capture. In both cases, it is of paramount importance to ensure that the integrity of the
data imported into the tool meets the requirements set for the data in the applicable ICAO Standards (Annex 11 — Air
Traffic Services and Annex 14 — Aerodromes).
3.1.10 The input functions are critical for the correct functioning of software tools. For instance, if the aeronautical
database updates are not correctly processed, the results may be wrong because of the use of outdated raw
information. This is why the validation manual addresses the input functions.
3.1.11 The output functions allow the procedure designers to get some output results (layouts or files) of the
design: layout displays; calculation result files; procedure design coding according to various formats (e.g. ARINC 424).
They include the following functions:
• 2-D or 3-D procedure design layout display;
• output file including all the calculation results;
• graphical representation of the procedures (from the design mode to an aeronautical chart); and
• procedure coding (ARINC 424, AIXM, etc.).
3.1.12 The validation manual considers the outputs as part of the results produced by the procedure design tools.
However, the conformance of graphical representation of the procedures to applicable Standards (as defined in Annex 4
— Aeronautical Charts) falls outside the scope of this manual.
Procedure design
3.1.13 The category “procedure design” corresponds to the core of the design process: compliance with reference
criteria, procedure layouts (with protection area templates), and procedure calculations. The available functions will
depend upon the type of tool (see section 3.2).
3.1.14 This includes the following aspects:
• integration of ICAO parameters for calculations;
• modelling of the considered criteria (if applicable): criteria algorithm implementation, compliance
checks, information to the user in case of non-compliance (warning and error messages). In some
tools, the modelling may not be included, or only partially included, and in those cases the algorithms
are replaced by drawing tools with coherency checks;
• RNAV/conventional, en-route/terminal/approach procedure layouts, with protection areas, for all the
procedure elements:
Chapter 3. Overview of Procedure Design Tools 3-3
– Holding patterns
– Reversals
– Arrivals and departures
– Initial, intermediate and final segments
– Precision approach
– Missed approach
– Links between segments
– Circling
– VHF omnidirectional radio range/non-directional radio beacon (VOR/NDB) routes;
• RNAV/conventional, en-route/terminal/approach procedure calculations:

– Obstacle clearance altitude/height (OCA/H)
– Procedure design gradient
– Descent slope or rate of descent
– Minimum safety altitudes – procedure altitude
– Other parameters including indicated airspeed (IAS), start and end of segment altitude, bank
angle, etc.;
• CRM calculations; and
• Annex 14 surfaces (obstacle limitation surfaces) computation, drawing and evaluation with respect to
obstructions and terrain.
3.1.15 The correct implementation of the design functions is the essential part to verify in the validation process.
The difficulty lies in the fact that the degree of automation of this type of function may vary widely between the tools.
3.2 THE TWO MAIN TYPES OF PROCEDURE DESIGN TOOLS
3.2.1 Notwithstanding the various functions of procedure design tools (see section 3.1), two main types of
procedure design tools can be defined: the aiding tools and the expert tools.
Aiding tools
3.2.2 In this category, the level of automation is not exhaustive, and there are a limited number of restrictions
linked to the applicable criteria, but the user is provided with aiding functions that contribute, as long as the designer’s
knowledge and expertise are sufficient, to efficient work in terms of quality and time.
3.2.3 Nevertheless, some consistency checks for compliance with general rules (maximum length of segments,
alignment of the final approach segment with respect to the runway, etc.) are generally included in the software tool.
3.2.4 Since the software tools belonging to this category essentially rely on the designer's expertise, the
validation process parameter applicable to them might be less extensive. However, there is still a need for validation so
as to ensure that the designs do not fall outside the criteria because of incorrect implementation of general rules (see
above) or due to issues associated with the tool environment and input/output functions (geographic information
management, aeronautical and geographical data integration, etc.).
Expert tools
3.2.5 In this category the level of automation is high. The aim is for an optimum compliance with the considered
criteria, and that most of the criteria are actually implemented in the software through criteria modelling and subsequent
algorithm generation.
3.2.6 The wide range of integrated checks provides the user with information on the strict conformance with
criteria, but also offers capabilities to overstep some criteria (via dispensations).
3.2.7 Since the software tools belonging to this category include actual extensive modelling of some criteria, the
validation process applied to them is vital, as an error could remain undetected even by expert procedure designers.
_____________________
Chapter 4
IMPLEMENTING A VALIDATION PROGRAMME
This chapter provides practical guidance for preparing and carrying out an actual validation programme applied to
procedure design tools. It is applicable to initial validation as well as revalidation for new functions and/or updates to the
procedure design tool and/or to the system environment.
4.1 PREPARATION
4.1.1 The procedure design tool validation requires time and effort. It needs to be prepared early enough to
ensure proper implementation.
4.1.2 For this purpose, it is recommended to develop a work plan defining:
— the software validation coverage;
— the overall objective schedule;
— the available resources;
— the validation team for the validation process, including the expertise according to the validation
coverage;
— the tasks to be carried out;
— the roles and responsibilities of each team member for each task; and
— a tentative detailed work programme (work items and timeframe).
4.2 SOFTWARE VALIDATION COVERAGE
4.2.1 The software validation coverage corresponds to the overall work programme related to the procedure
design tool validation and must be based on the extent of the concerned procedure design tool’s functions (see 2.5.1).
4.2.2 The software validation coverage needs to be defined to tailor the validation to the actual procedure design
tool subject to validation.
4.3 TOOL TESTING REQUIREMENTS
4.3.1 The validation implementation includes a series of tests to be carried out according to the validation
coverage.
4-1
4.3.2 Prior to any validation task, it must be confirmed by the procedure design software developer that
hardware and software are installed and configured according to the hardware and software specifications.
4.3.3 The validation should take into account the tests that the procedure design software developer may have
performed. Whenever possible any evaluations previously performed by the developer should be repeated at the user
site. The developer may be able to furnish the user with some of the test data sets to be used for this purpose.
4.3.4 The tool testing should follow a predefined written plan with a formal summary of testing and a record of
formal acceptance. The tests should cover the full range of operating conditions so that the system can encounter a
wide spectrum of conditions and events (detection of any latent faults not apparent during more normal activities).
4.3.5 Tool tests should be carried out at the user location, at least for part of the validation programme. User site
testing should be accomplished in the actual working environment that will be part of the installed system configuration.
The testing should be accomplished through use of the tool within the context in which it is intended to function. During
user site testing, records should be maintained of both proper system performance and any system failures that are
encountered. The revision of the system to compensate for faults detected during this user site testing should follow the
same procedures and controls as for any other procedure design tool change.
4.3.6 Knowledge of test planning, definition of expected test results, and recording of all test outputs are
required. Support in these areas from the procedure design software developer/provider would be beneficial.
4.4 VALIDATION METHODOLOGY
The validation methodology is presented in Chapter 7. It includes validation of basic parameters and basic elements as
well as modeling of criteria validation through assessment of methods and concepts, input data, output data and
graphical checks.
4.5 VALIDATION DOCUMENTATION
4.5.1 During the validation implementation, detailed documentation of the tests being carried out should be
compiled. This documentation should include the history of the tests, including input data and test results. A sample of
validation documentation is provided in Appendix E.
4.5.2 For the purpose of continuous improvement of the software, the user is encouraged to make the validation
documentation available to the procedure design software developer/provider.
_____________________
Chapter 5
ENVIRONMENT OF PROCEDURE DESIGN
5.1 TOOL DOCUMENTATION
5.1.1 The tool documentation should follow from the technical reference criteria and material. The tool
documentation provided must conform to the functionalities of the tool.
5.1.2 The validation of the tool documentation must be carried out through a thorough review of the reference
criteria.
5.1.3 A comparison with the applicable criteria must demonstrate that there is no discrepancy between these
criteria and the tool documentation. If discrepancies exist, the validation results must describe the differences and the
appropriate rationale, and it must be demonstrated that the consequences for procedure design are acceptable.
5.2 GEOGRAPHICAL INFORMATION
5.2.1 The validation of geographical information aims at verifying (if applicable) that the geographical data are
correctly processed in the tool. According to ICAO, all the coordinates used for air navigation must be expressed in the
World Geodetic System of WGS-84 (for more information, refer to ICAO’s World Geodetic System — 1984 (WGS-84)
Manual (Doc 9674)).
5.2.2 The parameters of geodetic reference systems and geographical projections must comply with reference
geographical standards.
5.2.3 The transformation parameters between various reference systems or projection-based coordinates must
also be verified against reference material. An alternative method to verify the correct transformation is to compare the
coordinates of a set of representative given points known in two reference systems/projection systems with the
coordinates processed through actual transformation in the tool. This process should be carried out for all the reference
systems and projection systems that are used for procedure design.
5.2.4 Appendix A provides tables of transformations between several common geodetic reference systems and
tables of conversion from WGS-84 geographical coordinates to common projection-based coordinates.
5.3 WGS-84 CALCULATIONS
5.3.1 The validity of WGS-84 geodetic calculations computed with the tool must be assessed (if applicable).
5.3.2 Geodetic calculations to be considered include at least the following :
• coordinates of a point defined by azimuth and distance from a known point;
5-1
• azimuth and geodetic distance between two known points; and
• coordinates of a point defined by the intersection of two geodetic lines.
5.3.3 The main process to validate WGS-84 calculation results is to implement a representative sample of
calculations of various kinds (see 5.3.2). The results should then either be compared to the results from surveys on the
field or validated by an official geodetic institute, or compared to results from a geodetic calculator that was previously
validated.
5.3.4 Appendix B provides tables of geodetic calculations and results for a sample of input data and functions
which can additionally be used for complements of validation.
5.4 MAGNETIC VARIATION
5.4.1 The validity of the magnetic model used in the tool must be assessed (if applicable).
5.4.2 The validation of the magnetic model should be based upon the assessment of magnetic values at a
representative sample of specific locations (coordinates) for given dates. The results should then either be compared to
values obtained from various sources (such as a national model or map information) or to the results from surveys on
the field.
_____________________
Chapter 6
TOOL INPUTS
6.1 AERONAUTICAL DATA INTEGRATION AND UPDATES
6.1.1 The validation of aeronautical data integration and updates aims at verifying the correct integration of data
elements (and associated attributes) from the originating database to the tool itself.
6.1.2 The data considered for integration into procedure design tools should include all the data that may be
used during the process of procedure design, such as :
• navaids — attributes include type, coordinates, and (if used by the tool) declared operational
coverage;
• landing aids — attributes include type and elements (e.g. localizer, glide, distance measuring
equipment (DME), etc.) with their respective coordinates, and, if used by the tool, additional attributes
(category, angle, etc.);
• aerodromes — attributes include name and/or location indicator, aerodrome reference point (ARP)
coordinates, aerodrome elevation, and runway indicators;
• runway features — thresholds, ends, etc., with their respective coordinates;
• obstacles — attributes include coordinates, elevation, height (where applicable);
• airspace features — boundaries of restricted areas, control zone, terminal area, flight information
region, etc., and relevant attributes (e.g. geometry descriptors); and
• waypoints, intersections, fixes, reporting points — attributes include name, type and coordinates.
6.1.3 In order to ensure that the data are correctly integrated in the tools, it is recommended that the metadata
(data about the concerned set of data) associated to the database can be accessed in the tool. Metadata should include
at least the following items:
• data source;
• horizontal reference system (e.g. WGS-84);
• vertical reference (e.g. mean sea level); and
• units.
6.1.4 The validation of the data integration must be carried out through integration of a representative set of the
initial data into the tool, and comparison between the tool data set and the initial data set. Critical issues that may induce
a major difference between these two sets are differences between reference systems or projection-based coordinates,
the rounding of numerical values, and unit system differences.
6-1
6.1.5 The comparison must be processed for each data element, either in an exhaustive way or in a
representative random way. Functions such as “print file” or “logsheet” may facilitate this process.
6.1.6 The validation of the data updating process must be carried out in a similar way, by comparison of the
updated initial set and the updated data in the tool. It must address each data element. Particular care must be given to
assuring that the updating process does not alter the initial data, and thus verification of non-updated data must also be
included in the comparison process.
6.1.7 This manual does not address the effects of aeronautical data changes on the end-results obtained
through the various functions of tools.
6.2 TERRAIN DATA INPUT VALIDATION
6.2.1 This section deals with the validation of the terrain data integration, but the actual validation of the terrain
data falls outside the scope of this manual.
6.2.2 The terrain data integration validation applies only to those tools where terrain data are used in the process
of procedure design calculations (e.g. for determination of the most critical point in a given area). (Also see Chapter 2,
2.4.4.)
6.2.3 Whenever terrain data are used for calculations in a tool, the following attributes must be stated: horizontal
and vertical reference system; horizontal and vertical accuracy; and resolution of the terrain data set. Additional optional
attributes include area of coverage, data source and time stamps. Additional information concerning terrain data
attributes is given below:
— the horizontal/vertical reference system is the datum to which the horizontal positions/elevations of the
data points are referenced;
— the accuracy is the degree of conformance between the estimated or measured value and the true
value;
— the resolution of terrain data is defined as the mean angular or linear distance between two adjacent
elevation points;
— the area of coverage is a descriptor of the boundary of the terrain data;
— the data source is the identifier of the data originator; and
— time stamps are information about the origination or modification date of the data.
6.2.4 The validation of the terrain data integration aims at verifying that the terrain data included in the tool do
not differ from the original terrain data. The validation of the integration of terrain data into procedure design tools should
be carried out by comparing the 3-D coordinates provided for a set of representative points in the tool with the ones
provided in the initial terrain data set via an alternate method (e.g. comparison of the two sets of data in a GIS). Critical
issues that may induce a major difference between the values include shifts linked to reference systems or projections
and change in the resolution of terrain data.
6.2.5 The display of terrain data sets that have been integrated in the tool is an additional means for checking
the relevant accuracy and the way the software manages the data, for instance by comparison with appropriate charts.
Chapter 6. Tool Inputs 6-3
6.2.6 Annex 15, Chapter 10 (Electronic Terrain and Obstacle Data – eTOD) sets Standards and Recommended
Practices for electronic terrain and obstacle data, and contains general guidance that may be useful for the validation
process.
6.2.7 In particular, Annex 15 states that sets of electronic terrain and obstacle data shall be collected and
recorded in databases in accordance with the following coverage areas, and that they shall satisfy the numerical
requirements specified in Appendix 8 of Annex 15, Table A8-1 while obstacle data shall satisfy the numerical
requirements specified in Appendix 8, Table A8-2.
• Area 1 (entire territory of a State) shall cover the entire territory of a State, including
aerodromes/heliports.
• Area 2 (terminal control area) shall be the terminal control area as published in a State’s aeronautical
information publication or limited to a 45-km radius from the aerodrome/heliport reference point
(whichever is smaller). At instrument flight rules (IFR) aerodromes/heliports where a terminal control
area has not been established, Area 2 shall be the area within a 45-km radius of the
aerodrome/heliport reference point.
• At IFR aerodromes/heliports, Area 3 (aerodrome/heliport area) shall cover the area that extends from
the edge(s) of the runway(s) to 90 m from the runway centre line(s) and for all other parts of
aerodrome/heliport movement area(s), 50 m from the edge(s) of the defined area(s).
• Area 4 (Category II or III operations area) shall be restricted to those runways where precision
approach Category II or III operations have been established and where detailed terrain information is
required by operators to enable them to assess, by use of radio altimeters, the effect of terrain on
decision height determination. The width of the area shall be 60 m on either side of the extended
runway centre line while the length shall be 900 m from the runway threshold measured along the
extended runway centre line.
Notes:
— The provisions of Annex 15, Chapter 10, are applicable as from November 2008 for Areas 1
and 4, and will be applicable as from November 2010 for Areas 2 and 3.
— Guidelines for Electronic Terrain, Obstacle and Aerodrome Mapping Information (Doc 9881)
provides detailed guidance material about terrain and obstacle data.
_____________________
Chapter 7
PROCEDURE DESIGN FUNCTIONS
This chapter provides guidelines for the validation of software tool procedure design functions. A procedure design
function is the process which a tool follows in order to provide a result from a given set of input data.
This chapter is divided into four parts:
• Units of measurement and rounding considerations;
• Basic parameters validation. This section and its related appendices address the reference
parameters and constants to be used for procedure design calculations;
• Basic element validation. This section identifies the basic drawing and calculation methods which must
be checked prior to final result validation and provides examples in appendices; and
• Modelling of criteria validation. This section proposes a methodology for the modelling of criteria
validation through assessment in four domains: methods and concepts; input data; output data; and
graphical checks. It includes the required input data and expected output data for the procedure
design tool functions, as well as some examples of graphical outputs for illustration.
7.1 CONSIDERATIONS ABOUT UNITS AND ROUNDING PROCESSES
7.1.1 Most software tools can perform calculations using any unit system, but many tools (and users) around the
world commonly use the international system of units (SI) values for convenience of calculation and only later do they
convert to non-SI values for display of results. Some tools however may make calculations based on the unit system
selected by the user. Different tools will also treat some values with different levels of accuracy and resolution of the
data, and rounding of values may also differ. However, generally, procedure design tools will use values and perform
calculations to greater degrees of accuracy than are available through manual calculations.
7.1.2 Thus, during the validation process, the implementation of unit systems, the conversion factors used, the
accuracy and resolution of data used, and rounding considerations are all factors to be considered in terms of how the
validation is undertaken and with regard to evaluation of results.
7.1.3 The conversion between unit systems implemented in the software must comply with Annex 5 — Units of
Measurement to be Used in Air and Ground Operations. Table 7-1 provides the most common conversion factors used
in the procedure design process.
7-1
Table 7-1. Common conversion factors
Conversion factor Value Source
Nm to Metre (m) 1 852.0 Annex 5, Table 3.3
* Foot (ft) to Metre (m) 0.3048 Annex 5, Table 3.3
Metre (m) to Foot (ft) = 1 / 0.3048
Knot (kt) to m/s 0.514444 Annex 5, Table 3.3
(*) Attention must be paid to the foot-to-metre conversion factor which was changed in Amendment 13 to PANS-OPS,
Volume II (Doc 8168).
7.2 VALIDATION OF BASIC DATA AND PARAMETERS
7.2.1 The list of the raw data and parameters used for calculations in the tool must be provided, and the
parameters’ values must be easily available for checks.
7.2.2 Appendix C, Section 1, provides a representative sample of the raw data that may be used in procedure
design tools, and the reference value (when applicable) or range of values associated with these elements.
7.2.3 Appendix C, Section 2, provides the minimum obstacle clearance (MOC) values included in PANS-OPS.
7.3 BASIC ELEMENT VALIDATION
7.3.1 This section, along with Appendix D, provides some guidelines for the validation of the calculations which
are implemented to construct the areas, and for the validation of elementary concepts connected with the design of
instrument flight procedures. Some of these elements may be compiled in a function of the tool.
7.3.2 The functions request values for the input data and provide a result. The tool should check that these data
values and results lay inside the limits specified in the criteria. In case the function allows input values outside these
limits, this information should be made available to the procedure designer.
7.3.3 During the validation process, the following calculations should be checked with reference to PANS-OPS:
— taking altitude into account when calculating true air speed;
— converting indicated air speed into true air speed;
— calculating a turn radius;
— calculating the wind effect during a turn, and corresponding drawing;
— calculating the wind drift along a non-guided straight path, and corresponding drawing;
— calculating a fix tolerance area for vectoring and at the intersection, for all known fixes in conventional
navigation; and
Chapter 7. Procedure Design Functions 7-3
— calculating cross-track tolerance (XTT) and along-track tolerance (ATT) for all types of waypoints.
7.3.4 In order to facilitate the above recommendation, Appendix D, Sections 1 to 7, provides details about the
reference criteria, values and formulas corresponding to several basic functions. Also included, in Sections 8 to 10, are
recommendations about the determination of straight-in approach, OCH adjustments, and computation of slope and rate
of descent.
7.3.5 During the validation process, the method used for some elementary concepts where reference criteria are
particularly difficult to model should be described on request. Examples include taking oblique distances into account
(DME, TACAN), calculating a rate of descent, partitioning the area associated with a segment, and the management of
altitudes.
7.4 MODELLING OF CRITERIA VALIDATION
7.4.1 The modelling of criteria validation consists in verifying that the results obtained through the use of the tool
are compliant with the criteria. To this end, guidelines and representative examples are provided in this manual.
7.4.2 The examples provided in this manual are representative ones but should not be considered as being
exhaustive or as covering all situations. The examples included in this manual are provided for a given set of raw data. A
subsequent validation could lead to different results if the raw data have changed.
7.4.3 The modelling of criteria validation must be based on the comparison of results achieved using the tool
with results obtained through manual implementation of the criteria (drawings, calculation results, etc.) for realistic
examples. The differences between these results must be identified and analysed, so that they can be either accepted
or rejected, on the basis of advice from procedure design experts.
7.4.4 The analysis of differences must take into consideration the several known potential sources of differences
that are listed below:
• Units (*) used for calculation. It is acknowledged that different unit systems may lead to slight
differences in results when converted to a single unit system;
• Conversion factors between units. Application of a strict regulatory or conventionally used conversion
factor (e.g. 984.25 ft vs. 1 000 ft for conversion of 300 m) may lead to differences in final results;
• Rounding rules. Depending on the rounding process (single final application or intermediate
applications), end results may differ slightly;
• Projection. The projection used for display of the results may lead to slight differences when
comparing the tool’s results with manual results;
• Intermediate steps. Within some automated tools, the display of the template is mathematically
computer driven, while manual design usually involves mandatory steps of graphical handling (wind
spirals and template are calculated before being drawn and used for the design of a specific area); this
may lead to difficulty for a direct visual comparison with a model of template.
(*) It must be noted that Doc 8168 introduces ambiguities by rounding SI units to non-SI units and vice versa in a
non-coherent manner (e.g. 300 m = 1 000 ft).
7.4.5 Additionally, differences can occur in cases where the reference criteria are not explicit enough, because
this may lead to different implementations (*). This situation is all the more pertinent with automation as the reference
criteria originally designed for manual implementation can be applied for all kinds of cases, even for non-realistic ones.
(*) For instance, consideration of the altitude for the calculation of the uncertainty to the vertical of a navaid is open to
interpretation and it may lead to discrepancies in the end-result.
7.4.6 The analysis of end-result differences must then be made with particular caution, since it is not likely that
results obtained through one software match exactly those obtained manually or with another independent software.
However, the purpose of the comparison must be to determine whether the differences are acceptable or not given the
known sources of potential differences. The acceptability of the differences must be based on the demonstration that the
tool results provide a protection that is equal to or greater than the one obtained through manual design or with a
previously validated independent tool, or that the differences are minor (*) and can be accepted.
(*) It is acknowledged that increased accuracy of computation by software tools may in some cases lead to results that
are marginally less conservative than manual results.
7.4.7 The modelling of criteria validation must include tests (comparison of results) for each type of design,
layout or calculation available in the tool. The tests must systematically state:
• the reference criteria, including the version number (PANS-OPS edition and amendment number);
• the reference material paragraph containing the figure/description;
• the input data (aeronautical and geographical data, as appropriate);
• all the constructive parameters; and
• the element data to survey.
Note.— When terrain data are used for tests, the terrain data points involved in the computation must be
marked.
7.4.8 All the test results must include a complete list of the most significant terrain data points or obstacles that
have been used. This list must contain the coordinates, the altitude, the required MOC (if applicable) and the penetration
(if applicable). A log file for each test should be created. Coordinates and positions within the list of results should be
reflected onto the graphic for an easy check.
7.4.9 Application of the proposed process of the standard modelling validation is detailed in the following
sections for design and layouts (section 7.5), procedure calculations (section 7.6), and specific cases (section 7.7).
These sections include a series of tests for a representative set of procedures all over the world, with associated input
data (both aeronautical and geographic information) and detailed results.
7.5 APPLICATION OF CRITERIA MODELLING VALIDATION TO DESIGN

AND LAYOUTS (CONVENTIONAL/RNAV)
The application of criteria modelling validation is based upon three key-points: knowledge of the applicable regulation;
experience in procedure design; and the practice of the tool subject to validation. An overall process mixing these key-
points may be sufficient to successfully carry out this validation. However, to achieve a more formal process, a step-by-
step methodology has been developed. It is nevertheless acknowledged that the actual implementation of the validation
may be a balance between the overall process and the formal process described hereafter.
7.5.1 Methodology
7.5.1.1 Description
7.5.1.1.1 The proposed methodology is not only based on a visual comparison between a given validated sample of
a segment protection area and the corresponding protection area produced by a software tool, it recommends a defined
step-by-step process based on checking specific domains and elements included in the protection area design. The aim
is to associate each checked topic/element with a level of conformity/acceptance (yes/no). Within each of these topics, a
list of parameters or criteria is to be assessed/checked in accordance with an associated input/output range of values, if
applicable.
7.5.1.1.2 This methodology can be applied to all features of the application. It is the responsibility of the validating
body to determine the level of detail within this methodology.
7.5.1.1.3 The methodology requires the use of the application to be validated; for this reason, only very generic
examples are provided in this manual.
7.5.1.2 Validation domains
7.5.1.2.1 There are four validation domains, each one of the domains corresponds to an appropriate question and
each question leads to a level of assessment. There are four possible (and exclusive) levels of assessment:
• yes = the element/topic is acceptable;
• no = the element/topic is not acceptable;
• unknown = the element/topic cannot be assessed;
• out of coverage = the element/topic is not included in the validation coverage.
7.5.1.2.2 The definition of the threshold between “Yes” and “No” is up to the validating team and should be recorded
in the validation plan.
7.5.1.2.3 The domains described hereafter are considered the minimum set, and the validating body is encouraged
to expand the domains as necessary.
Note.— Among the domains, some may be not applicable according to the type of the application (expert
or aiding tool).
7.5.1.3 Domain 1 — Methods or concepts used by the software tool
The question is: for a given topic does the model conform to the regulation criteria? To answer this question, the
validation team must investigate how the software interprets and utilizes the regulation criteria associated to this
element. It must then make a decision about the appropriateness of the methodology used by the application for the
assessed element (acceptance = yes/no). It must also assess if the software tool provides enough satisfactory
information on its method and the potential differences between this method and the regulation. That information can be
provided through a digital or paper document delivered by the developer/provider or within the application through
dedicated interfaces (step-by-step or globally).
7.5.1.4 Domain 2 — Input data
For a given item, are the proposed values used by the tool applicable with respect to usage? The software, according to
its type (expert or aiding tool), will allow more or less flexibility as far as the form of input values are concerned which
could be:
• proposed locked values;

• managed input fields, i.e. input data submitted to consistency/plausibility checks; and/or
• unmanaged input fields.
Note.— In this domain, focus should remain on the input values not on the user interface.
7.5.1.5 Domain 3 — Output values
7.5.1.5.1 Is the output applicable with respect to the input? Or is it not available (and de facto it cannot be
assessed)?
7.5.1.5.2 For this domain, the validating team must compare the output against data which meet quality
requirements. If this result is not available for the assessed topic, the level of assessment cannot be valid.
Note.— Checks carried out for this domain should not prevent the validating team from controlling the
design (See domain no. 4).
7.5.1.6 Domain 4 — Graphical check
7.5.1.6.1 Does the final proposed design conform to reference criteria? If applicable with the software, a graphical
check can be done by comparing specific values, such as:
• angular value of fix tolerance;
• length of fix tolerance;
• angular value of the area splay; and
• surface of a given protection area.
7.5.1.6.2 The comparisons can be done through various methods, e.g.:
• page layout, by handling measures, using classical drawing tools (ruler, compass, etc.); and
• on-screen measure through an adapted tool.
7.5.1.6.3 For each topic the validating team should create and record a minimum list of relevant elements with
appropriate references.
7.5.1.7 Practical implementation
Practically, the validation can be done using tables regarding the checked topic, as in the following example:
A GENERAL TOPIC TO TEST [TITLE]

A1 Topic [Identification] [Short description]
Reference documentation : Documentation version :
A 11 Element or parameter [Identification] e.g. « Doc 8168 – Chapter XXX » e.g « Amendment XX »
Levels of assessment
Domains Details Out of Comments
Yes No NA
Cov.
Method/Concept …
Input data …
Output data …
Graphical check …
Score
Reference documentation : Documentation version :
A12 Element or parameter [Identification] e.g. « Doc 8168 – Chapter XXX » e.g « Amendment XX »
Levels of assessment
Domains Details Out of Comments
Yes No NA
Cov.
Method/Concept …
Input data …
Output data …
Graphical check …
Score
7.5.2 Application of the methodology
7.5.2.1 The following list represents an exhaustive compilation of functions that ideally would be included in an
extensive validation programme. However, it is recognized that all tools do not include all the corresponding functions.
Moreover, such a comprehensive validation programme would imply an extensive workload that may not be possible to
assign to the validation process.
7.5.2.2 This is why this list is to be considered as a maximum list, and it is incumbent upon the user of this manual
to determine the elements within this list that correspond to the concerned tool and to select those that are the most
relevant for the concerned tool validation.
7.5.2.3 Unless otherwise stated, the following list applies both to conventional navigation and performance-based
navigation:
• En-route
• Arrivals
• Minimum sector altitude (MSA)
• TAA (RNAV only)
• Holding patterns
• Reversals and racetracks (conventional only)
• Initial approach segment
• Intermediate approach segment
• NPA final approach segment

• Approach with vertical guidance (RNAV only)
• Precision segment
• Missed approach
• Circling (conventional only)
• Departures
• Connections between segments.
7.5.3 Examples
7.5.3.1 Circling
The following example aims at assessing the acceptability of a circling based upon the output results and the graphical
output.
a) Method/concept
The method and concepts as described in the tool documentation (or other appropriate material) for
the circling function are recorded. In this example, the documentation is available and deemed
acceptable.
OBJECT CIRCLING
Reference documentation Doc 8168 – Volume II – Part I – Section 4 – Chapter 7
Documentation version Amendment 13
b) Input data
1) The software asks for the following values:
• category of aircraft;
• aerodrome elevation;
• temperature;
• type of wind;
• IAS;
• threshold coordinates; and
• bank angle.
2) The following table includes the required values.
Input data
THR 16 coordinates 41° 55' 45''.8883 N 012° 25' 40''.1264 E

Temperature ISA + 15
IAS (kt) 100 135 180 205 250
AD ELEV (ft) 313
Bank Angle (°) 19.3 20 20 20 20
Aircraft CAT A B C D E
3) Consistency check of the input. Check that if an input value is not compliant with the applicable
criteria, it is either rejected or “flagged” through a warning to the user. In the above example, the
input data were compliant with the criteria, so they were integrated in the tool.
Yes No Unknown Out of scope Comment

Input Data
Category of aircraft x
Aerodrome elevation x
Temperature x
Type of wind x
IAS x
THR coordinates x
Bank angle x
c) Output data
1) The computation with the tool leads to results summarized in the following output data:
• TAS (V);
• Turn radius (r);
• Wind velocity (W);
• Radius from threshold.
Aircraft CAT A B C D E
Output data
V + W/V (kt) 128 164 210 236 283
R (°/s) 3.00 2.42 1.89 1.68 1.41
r (NM) 0.68 1.08 1.77 2.23 3.20
S SEG (NM) 0.3 0.4 0.5 0.6 0.7
Radius from THR (NM) 1.66 2.56 4.04 5.06 7.1
Radius from THR (Km) 3.1 4.7 7.5 9.4 13.1
The inconsistency in units between NM and km has to be noted in the check.


Output Data
TAS x
Turn radius x
Wind velocity x
Radius from threshold x Inconsistency between NM and km
d) Graphical check
This step consists in assessing the graphical output, such as shape of the area, relation with
thresholds, use of threshold, measurement of distances (see Figure 7-1).
17
+
CAT A
1.66 NM + 16
CAT B 09
2.56 NM
+ 27
+
+
CAT C
35
4.04 NM
+
34
CAT D
5.06 NM
1 NM
Figure 7-1.
Circling Areas A-D

Graphical check x
e) Conclusion
The following table sums up the outcome of the circling validation.
OBJECT CIRCLING
Method/concept x

Input Data
Aerodrome elevation x
Temperature x
Type of wind x
IAS x
THR coordinates x
Bank angle x
Yes No Unknown Out of Scope Comment
Output Data
TAS x
Turn radius x
Wind velocity x
Radius from threshold x Inconsistency between NM and km

Graphical check x
Conclusion This circling function is accepted.
7.5.3.2 Holding patterns
The following example aims at assessing the acceptability of a holding template function based upon comparison of the
graphical output with a manual drawing.
a) Method/concept
the holding template function are recorded. In this example, the documentation is available and
deemed acceptable.
b) Input data
1) The software asks for the following values:

• category of aircraft;
• IAS;
• temperature;
• type of wind (ICAO, statistic, etc.);
• outbound time; and
• holding protection altitude.
2) Consistency check of the input. Check that if an input value is not compliant with the applicable
criteria, it is either rejected or flagged through a warning to the user.
c) Output data
The computation with the tool leads to results summarized in the following output data:
• TAS (V);
• Turn radius (r); and
• Wind velocity (W).
d) Graphical check
This step consists in assessing the graphical output.
For this purpose a manual drawing with the same input data is constructed according to PANS-OPS
criteria (see below). The software-based graphical output and the manual drawing are overlaid for
comparison.
Significant differences between the manual drawing and the graphical output need to be investigated
and rationalized (see 7.4.2).
To illustrate the above process, a manual drawing has been constructed according to the following
data and calculations.
DATA
NON-SI UNITS
IAS 230 kt
Altitude 14 000 ft
T 1 min
Temperature ISA + 15°C
CALCULATIONS USING NON-SI UNITS

Line Parameter Formula Value
1 K Conversion factor for 14 000 ft 1.2755
and ISA + 15°C
(see Appendix 2 to Volume 2, Part 1,
Section 2, Chapter 1)
2 V V = K IAS* 293.4 kt
* The true airspeed may also be deduced from Part II,
Section 4, Chapter 1, Appendix A.
3 v v = V / 3 600 0.0815 NM/s
4 R R = 509.26 / V, or 3°/s, whichever is less 1.722°/s
5 r r = V / 62.83 R 2.71 NM
6 h in thousands of feet 14
7 w w = 2h + 47 75 kt
8 w' w’ = w / 3 600 0.0208 NM/s
9 E45 E45 = 45w’/ R 0.544 NM
10 t t = 60T 60 s
11 L L=vt 4.89 NM
12 ab ab = 5v 0.41 NM
13 ac ac = 11v 0.90 NM
14 gi1 = gi3 gi1 = gi3 = (t – 5) v 4.48 NM
15 gi2 = gi4 gi2 = gi4 = (t + 21)v 6.60 NM
16 Wb Wb = 5w’ 0.10 NM
17 Wc Wc = 11w’ 0.23 NM
18 Wd Wd = Wc + E45 0.77 NM
19 We We = Wc + 2E45 1.32 NM
20 Wf Wf = Wc + 3E45 1.86 NM
21 Wg Wg = Wc + 4E45 2.41 NM
22 Wh Wh = Wb + 4E45 2.28 NM
23 Wo Wo = Wb + 5E45 2.82 NM
24 Wp Wp = Wb + 6E45 3.36 NM
25 Wi1 = Wi3 Wi1 = Wi3 = (t + 6)w’ + 4E45 3.55 NM
26 Wi2 = Wi4 Wi2 = Wi4 = Wi1 + 14w’ 3.84 NM
27 Wj Wj = Wi2 + E45 4.38 NM
28 Wk = Wl Wk = Wl = Wi2 + 2E45 4.93 NM
29 Wm Wm = Wi2 + 3E45 5.47 NM

30 Wn3 Wn3 = Wi1 + 4E45 5.73 NM
31 Wn4 Wn4 = Wi2 + 4E45 6.02 NM
32 XE XE = 2r + (t + 15)v + 15.68 NM
(t + 26 + 195/R)w’
33 YE YE = 11 v cos 20° + 8.31 NM
r(1 + sin 20°) +
(t + 15)v tan 5° +
(t + 26 + 125/ R)w’
The resulting drawing, Figure 7-2, can then be used for subsequent comparison with graphical output from the software
using the same input data.
Procedure protected for:
Altitude: 14 000 ft
IAS: 230 kt
Outbound time: 1 min
Scale
0 1 2 3 4 5 NM
Figure 7-2.
The conclusion of the example is as follows:
OBJECT Holding Pattern

Reference documentation Doc 8168 (Fifth Edition (2006)) – Volume II – Part I – Section 4 – Chapter 2 and Part II – Section 4
Method/concept x

Input Data
Aircraft category x
IAS x no consistency check between IAS and
aircraft category
Protection altitude x
Temperature x
Outbound time x warning provided if time inconsistent with
altitude
Type of wind x
Inbound track x
Turn direction x to be considered
Navaid type x
Required entries x
Navaid altitude x
Navaid coordinates x

Output Data
TAS x
Turn radius x
Wind value x
Holding template (graphical) x
Holding basic area x
Holding entries x

Graphical check x
Conclusion This function is accepted. It is recommended that both turn directions are considered.
Note 1.— Additional functions to provide holding base area + entries are considered highly desirable.
Note 2.— Additional function to provide computation of minimum holding altitude is desirable.
7.5.3.3 Reversals and racetracks
7.5.3.3.1 Base turn. The following example aims at assessing the acceptability of a base turn based upon the output
results and the graphical output.
a) Method/concept
the base turn function are recorded. In this example, the documentation is available and deemed
acceptable.
b) Input data
The software asks for the following values:
• ISA VAR;
• indicated airspeed and aircraft category;
• wind speed;
• bank angle;
• navaid type, coordinates and elevation;
• direction of turn;
• initial fix altitude;
• final fix altitude;
• inbound track;
• outbound time;
• entry angle.
The following table includes the required values.
INPUT DATA
ISA VAR ISA + 15°
INDICATED AIRSPEED 250 kt
WIND SPEED 58.826 Kt
BANK ANGLE 25 deg
NAVAID TYPE VOR
NAVAID ELEVATION 0 ft
NAVAID COORDINATES 41° 48' 13.751'' N 12° 14' 15.029'' E
DIRECTION OF TURN Right
INITIAL FIX ALTITUDE 6 000 ft
FINAL FIX ALTITUDE 3 000 ft
INBOUND TRACK 305.31 deg
OUTBOUND TIME 90 s
ENTRY ANGLE 30 deg
c) Output data
• inbound distance;
• outbound track;
• inbound descend gradients;
• outbound descend gradients;
• turn altitude;
• radius of turn; and
• outbound distance.
OUTPUT DATA
INBOUND DISTANCE 7.01 NM
OUTBOUND TRACK 86.64 deg
DESCEND GRADIENT (Inbound leg) 802.49 ft/min
DESCEND GRADIENT (Outbound leg) 1 197.5 ft/min
TURN ALTITUDE 4 203.74 ft
RADIUS OF TURN 2.462 NM
OUTBOUND DISTANCE 7.01 NM
d) Graphical check
This step consists in assessing the graphical output, such as shape of the area, the navaid location,
the location and the length of the outbound leg, and the turn radius. (See Figure 7-3.)
4 203.74 (ft)
6 000.00 (ft) NM)
7.02 6 NM (7
(%)
87 de g) –4.2
86.6 deg (T
3 000.00 (ft)
30 7.0
5. 4 2 2.462
d e 2 NM NM (2
NM )
g( (7
T3 NM
05
de )
g)
–2
.8
(%
)
4 203.74 (ft)
Figure 7-3.
e) Conclusion
OBJECT Base turn VOR (time limited)

Method/concept x

Input Data
ISA VAR x
Indicated airspeed and x
aircraft category
Wind speed x
Bank angle x
Navaid type, coordinates x
and elevation
Direction of flight x
Initial fix altitude x
Final fix altitude x
Inbound track x
Outbound time x
Entry angle x
Output Data
Inbound distance x
Outbound track x
Inbound descend gradients x
Outbound descend gradients x
Turn altitude x
Radius of turn x
Outbound distance x

Graphical check x
Conclusion This base turn VOR (time limited) is accepted.
7.5.3.3.2 Procedure turn. The following example aims at assessing the acceptability of a procedure turn based upon
the output results and the graphical output.
a) Method/concept
the procedure turn function are recorded. In this example, the documentation is available and deemed
acceptable.
b) Input data
• ISA VAR;

• wind speed;
• bank angle;
• navaid type, elevation and coordinates;
• direction of turn;
• type of procedure turn;
• outbound leg distance;
• procedure axis distance; and
• procedure axis angle.
INPUT DATA
ISA VAR ISA + 15°
WIND SPEED 58.826 kt
BANK ANGLE 25 deg
NAVAID TYPE VOR
DIRECTION OF TURN Right
TYPE 80/260 deg
OUTBOUND LEG DISTANCE 6 NM
PROCEDURE AXIS DISTANCE 7 NM
PROCEDURE AXIS ANGLE 45 deg
c) Output data
• outbound leg time;

• inbound leg distance;
• turn altitude;
• outbound descend gradients; and
• inbound descend gradients.
OUTPUT DATA
OUTBOUND LEG TIME 76. 930 sec
INBOUND LEG DISTANCE 12.455 NM
OUTBOUND DESCEND GRADIENT 243.45 ft/NM
INBOUND DESCEND GRADIENT 97.04 ft/NM
d) Graphical check
The purpose of this step is to assess the graphical output, such as shape of the area, the navaid
location, the location and the length of the outbound leg, the direction and the layout of the turn. (See
Figure 7-4.)
)
(%
NM 8.0
4 208.69 (ft)
–
)
(1 g)
e
N 5d
2
2
.4 (T2
M
12 eg
55
d
.7
4
22
4 208.69 (ft)
)
(%
)
NM
.0
(7
–4
NM
g)
de
58
45
3
7.
(T
g
de
.0
45
3 000 (ft)
6 000.00 (ft)
Figure 7-4.
e) Conclusion
OBJECT Procedure turn VOR/DME (distance limited)

Method/concept x

Input Data
ISA VAR x
aircraft category
Wind speed x
Bank angle x
and elevation
Type of procedure turn x
Outbound leg distance x
Procedure axis distance x
Procedure axis angle x

Output Data
Outbound leg time x
Inbound leg distance x
Turn altitude x

Graphical check x
Conclusion This procedure turn VOR/DME (distance limited) is accepted.
7.5.3.3.3 Racetrack
The following example aims at assessing the acceptability of a racetrack based upon the output results and the
graphical output.
a) Method/concept
the base turn function are recorded. In this example, the documentation is available and deemed
acceptable.
b) Input data

• ISA VAR;
• wind speed;
• bank angle;
• navaid type, elevation and coordinates;
• entry on facility;
• direction of flight;
• outbound leg time; and
• outbound leg angle.
INPUT DATA
ISA VAR ISA + 15°
WIND SPEED 58.826 Kt
BANK ANGLE 25 deg
NAVAID TYPE NDB
ENTRY ANGLE Omnidirectional
DIRECTION OF FLIGHT Right
OUTBOUND LEG TIME 120 sec
OUTBOUND LEG ANGLE 90 deg
c) Output data
• outbound leg distance;

• inbound leg distance;
• turn altitude;
• outbound descend gradients; and
• inbound descend gradients.
OUTPUT DATA
OUTBOUND LEG DISTANCE 8.956 NM
INBOUND LEG DISTANCE 8.953 NM
OUTBOUND DESCEND GRADIENT 909.448 ft/min
INBOUND DESCEND GRADIENT 590.551 ft/min
d) Graphical check
This step consists in assessing the graphical output, such as shape of the area, the navaid location,
the location and the length of the racetrack. (See Figure 7-5.)
Additionally, a comparison using the Template Manual for Holding, Reversal and Racetrack
Procedures (ICAO Doc 9371) can be carried out within the validation process.
6 000.00 (ft) 8.956 NM (9 NM) 4181.10 (ft)
90.0 deg (T90 deg) –3.3 (%)
8.953 NM (9 NM)
3 000.00 (ft) 270.2 deg (T270 deg) –2.2 (%) 4181.10 (ft)
Figure 7-5.
e) Conclusion
OBJECT Racetrack
Method/concept x

Input Data
ISA VAR x
aircraft category
Wind speed x
Bank angle x
and elevation
Entry on facility x
Outbound leg time x
Outbound leg angle x

Output Data
Outbound leg distance x
Inbound leg distance x
Turn altitude x

Graphical check x
Conclusion This racetrack is accepted.
7.5.3.4 TAA
The following example aims at assessing the acceptability of a TAA layout. This example only includes graphical output.
a) Method/concept
The reference for TAA design is the PANS-OPS, Volume II, Part III, Section 2, Chapter 4. In this
example, the documentation is available and deemed acceptable.
b) Input data
• type of approach (T or Y);

• IAF coordinates (straight-in, right and left base);
• IF coordinates;
• FAF coordinates;
• bearing of initial segments;
• bearing of intermediate and final segments;
• coordinates and elevation of obstacle(s) / terrain in the TAA area (or relevant eTOD file)
• radius of each sector; and
• radius of the inner step-down arc (if applicable).
Note.— It should be noted that, depending on the tool, input data may not require all of the above items.
c) Graphical check
The graphical check should be carried out by comparing the manual drawing (using CAD systems or
similar) with the flight procedure design system output. (See Figure 7-6.)
Below are examples of input data and corresponding graphical layout for TAA.
Type of TAA T–bar
IAF (1) coordinates (straight-in) 41° 54' 20.1568'' N

012° 37' 01.8645'' E
IAF (2) coordinates (left base) 41° 47' 55.7210'' N

012° 33' 03.3757'' E
IAF (3) coordinates (right base) 41° 57' 18.8597'' N

012° 28' 25.2903'' E
IF coordinates 41° 52' 37.3157'' N

012° 30' 44.5025'' E
FAF coordinates 41° 50' 54.1296'' N

012° 24' 27.4765'' E
Bearing of the initial segment (straight-in) 250°
Bearing of the initial segment (left base) 339.8°
Bearing of the initial segment (right base) 159.7°
Bearing of the intermediate-final segment 250°
Coordinates and elevation of obstacle/terrain for straight-in sector 41° 57' 37.4619'' N
012° 52' 05.0609'' E
3 000 ft
Coordinates and elevation of obstacle/terrain for right sector 42° 02' 50.1827'' N
012° 10' 57.6461'' E
3 500 ft
Coordinates and elevation of obstacle/terrain for left sector 41° 36' 09.7808'' N
012° 26' 22.0812'' E
2 500 ft
Minimum TAA altitude for the straight-in sector 4 000 ft
Minimum TAA altitude for the right sector 5 500 ft
Minimum TAA altitude for the left sector 3 500 ft

IAF (3)
IAF (1)
FAF
IF
IAF (2)
5 NM
Figure 7-6.
d) Conclusion
OBJECT TAA
Reference documentation Doc 8168 – Volume II – Part III – Section 2 – Chapter 4
Documentation version Fifth Edition, 2006
Method/concept x

Input Data
Type of the approach x
IAFs coordinates x
IF coordinates x
FAF coordinates x
Radius of step-down arc x
Bearing of initials segments x
Coordinates and elevation of x
obstacles/terrain

Output Data
Minimum TAA altitude x
Graphical output x

Graphical check x
Conclusion The TAA design is accepted.
7.5.3.5 Initial approach segment
The following example aims at assessing the acceptability of an initial approach segment area calculation. This example
does not include any graphical output.
OBJECT Initial Segment

Reference documentation Doc 8168 – Volume II – Part III – Chapter 4
Method/concept x

Input Data
IAS range x
Temperature x
Type of wind x
Max protection altitude x
IAS x

Output Data
Wind velocity x
Navaid range x
Initial approach fix tolerance x
Ending fix tolerance x
Fixes acceptability x
Beginning area width x
Area splay angle x
Ending area width x
Primary/Secondary area x
width

Graphical check x Graphical output is recommended
Conclusion The initial segment function is accepted.

7.5.3.6 Intermediate approach segment
The following example aims at assessing the acceptability of an intermediate approach segment area calculation and
drawing.
OBJECT Intermediate Segment

Method/concept x

Input Data
IAS range x
Type of wind x
IAS x

Output Data
Wind velocity x
Navaid range x
Min/Max length of the x
segment
Intermediate approach fix x
tolerance
Area splay angle x
Ending area width x
width

Graphical check x A graphical output is required
Conclusion The intermediate function is not accepted until graphical output can be provided and checked.
7.5.3.7 NPA final approach segment (conventional)
The following example aims at assessing the acceptability of an NPA final approach segment area calculation. This
example does not include any graphical output.
OBJECT Final Segment

Method/concept x

Input Data
IAS range x
Type of wind x
IAS x

Output Data
Wind velocity x
Navaid range x
Min/Max length of the x
segment
Final approach fix tolerance x
MAPt tolerance x The MAPt tolerance is smaller than in
PANS-OPS
Area splay angle x
Ending area width x
width

Graphical check x
Conclusion The function is not accepted until MAPt tolerance issue has been resolved.
7.5.3.8 RNAV GNSS NPA final approach segment
a) Method/concept
The reference for RNAV GNSS NPA approach design is the PANS-OPS (Doc 8168), Volume II,
Part III, Section 1, Chapter 2. In this example, the documentation is available and deemed acceptable.
b) Input data
• thresholds coordinates;
• coordinates of the FAF; and
• coordinates of the MAPt.
Additionally, for the latest limit construction, the following input data are considered:
• aircraft category;
• IAS range;
8/8/13
No. 1
• type of wind; and

• maximum protection altitude.
c) Output data
• wind velocity;
• FAF ATT and XTT
• semi-width abeam FAF;
• semi-width abeam MAPt;
• primary/secondary area width; and
• graphical output of waypoints, final segment, fixes tolerances (ATT/XTT) and protection areas.
d) Graphical check
This step consists in assessing the graphical outputs, shape of protection areas, area semi widths,
ATT/XTT for each waypoint FAF and MAPt, minimum/maximum length of the segment. (See
Figure 7-7.)
Secondary area
semi-width
IF area
FAF area MAPt area

Primary area semi-width semi-width
30°
IF FAF MAPt
WP ATT XTT ½ AW
FAF 0.24 NM 0.3 NM 1.45 NM

(Cat. H 1.15 NM)
MAPt 0.24 NM 0.3 NM 0.95 NM

(Cat. H, 0.8 NM)
Figure 7-7.
8/8/13
No. 1
The same process can be applied to any other straight RNAV approach segment, as shown in Figure 7-8 for the
intermediate segment.
Secondary area
semi-width
IF area
FAF area MAPt area

Primary area semi-width semi-width
30°
IF FAF MAPt
WP ATT XTT ½ AW
FAF 0.24 NM 0.3 NM 1.45 NM

(Cat. H, 1.15 NM)
IF 0.8 NM 1.0 NM 2.5 NM

(Cat. H 2.2 NM)
Figure 7-8.
8/8/13
No. 1
e) Conclusion
OBJECT Final Segment

Method/concept x

Input Data
Aircraft category x
IAS range x
Type of wind x
Maximum protection altitude x
Threshold coordinates x
FAF coordinates x
MAPt coordinates x

Output Data
Wind velocity x
FAF ATT and XTT x
Semi-width abeam FAF x
Semi-width abeam MAPt x
width
Graphical output x

Graphical check x
Conclusion The function is accepted.

Note. — The connection with the previous and subsequent segments are not part of this function.
7.5.3.9 Approach with Vertical Guidance (APV)
The following example aims at assessing the acceptability of an APV Baro-VNAV final segment. This example does not
include any graphical output.
OBJECT Final Segment (APV)

Method/concept x

Input Data
Threshold elevation x
Airfield elevation x
IAS x
RDH x
FAP height above threshold x
(intermediate segment
height)
Design VPA x
Minimum probable x
temperature
Intermediate approach MOC x
Final approach MOC x
Sensor x

Output Data
OAS FAS area width (start) x
OAS FAS area width (end) x
FAP/FAF location or point x
where FAS intersects the
MOC of the preceding
segment
Cold temperature corrected x
VPA
RDH coordinates x
FAS angle x
FAS origin (X FAS) x
Minimum promulgated x
temperature
Minimum VPA x

Graphical check x
Conclusion The function is not accepted until a graphic output capability exists and can be verified.
7.5.3.10 Visual Segment Surfaces (VSS)
a) Method/concept
The validation test is intended to validate the VSS for straight-in non precision approach procedures.
The reference for VSS is the PANS-OPS, Volume II, Part 1, Section 4, Chapter 5. In this example, the
documentation is available and deemed acceptable.
b) Input data
• procedure type;
• runway reference code;
• inner approach surface width;
• offset angle between track and centerline (if applicable);
• offset distance between track and centerline (if applicable);
• OCH;
• threshold coordinates and elevation;
• final approach segment definition including approach angle; and
• coordinates and elevation of obstacle(s) / terrain (or relevant eTOD file).
c) Output data
• VSS shape; and

• penetrating obstacle/terrain.
d) Graphical check
This step consists in assessing the graphical output. It includes checks of the VSS itself, its relative
position to the runway, the penetrating obstacle(s)/terrain if any. (See Figure 7-9.)
Note.— The graphical check may not be sufficient to assess the validity of the terrain and obstacle(s)
penetrating the surface. See 6.2 for additional guidance on terrain and obstacle data validation.
The following section provides an example of VSS surface construction for a specific set of input data.
Input Data
Procedure type Straight-in NPA
Runway reference code 3 or 4
Offset angle between track and centerline 0
Offset distance between track and centerline 0
Final approach segment definition Gradient 3°

Bearing 267.763°
OCH 350 ft
THR coordinates 41° 29' 04.9576'' N, 010° 27' 44.8054'' E
THR elevation 0 ft
Obstacle coordinates 41° 29' 07.3272'' N, 010° 28' 04.4657'' E
Obstacle elevation 200 ft
Output Data
Height above threshold 15 m
Distance from threshold 60 m
Width base 300 m (150 m either side of extended rwy)
Splay 15% (either side of extended rwy)
VSS slope 1.88 °
End of surface (horizontal distance from the 3 257 m

approach THR to the end of the VSS)
Obstacle penetration Yes

FAS
1 NM
Obstacle elevation THR elevation
Figure 7-9.
e) Conclusion
OBJECT VSS
Method/concept x

Input Data
Procedure type x
Runway reference code x
Inner approach surface width x
Offset angle track/centreline x
Offset distance x
track/centreline
OCH x
THR coordinates and x
elevation
Final approach segment x
Obstacle(s) output x

Output Data
VSS shape x The VSS is only provided graphically.
Penetrating terrain/obstacle x
Graphical output x

Graphical check x
Conclusion The function is accepted.

Note. — Key 3-D coordinates of VSS should be provided.
7.5.3.11 Precision approach segment
The following example aims at assessing the acceptability of an instrument landing system (ILS) precision segment
based on the obstacle assessment surface (OAS) method.
Note.— In the following example, the OAS are based on an OAS template but they differ from the template
as they are extended up to the FAP.
a) Method/concept
1) In this example, the tool documentation describes the method used to compute the OAS
extension on the final side and its limitation on the missed approach side. It also describes the
interpolation methods used to compute the equations of the plane surfaces to fit with the exact
distance between the localizer (LOC) antenna and runway threshold.
2) The method and concepts provided in the tool documentation as presented above are deemed
acceptable.
b) Input data
• aircraft category;
• wing span;
• distance between glide path antenna and aircraft wheels;
• selected runway and localizer orientation;
• threshold coordinates;
• threshold elevation;
• ILS category;
• coordinates of the LOC antenna (or distance between LOC antenna and selected threshold);
• LOC beam width at threshold;
• offset LOC (if applicable);
• glide path angle;
• reference datum height (RDH);
• missed approach slope;
• final approach point altitude (or distance between FAP and threshold);
• final approach fix (if applicable);
• end of precision segment (if applicable).
Note.— It should be noted that, depending on the tool, input data may not require all of the above items.
c) Output data
• reference system used for coordinates of OAS significant points;

• coordinates of the specific points named C, D, E and C”, D”, E”;
• equations of the plane surfaces given in a specific format (z = Ax + By + C);
• elevation of the specific plane surfaces at requested points; and
• graphical output of the OAS surfaces.
Note.— With additional input (terrain and obstacle), other output data can be provided, such as:
• computation of the OCA/H of the precision segment for each aircraft category;
• obstacles ignored by the use of the FAF;
• critical obstacle;
• Start of Climb (SOC) location (x, y, z).
22/2/11
Corr.
d) Graphical check
This step consists in assessing the graphical output, such as shape of the OAS, the LOC antenna and
FAP location, the runway threshold location, and the final axis.
The following sections provide an example of OAS surface construction for a specific set of input data:
• aircraft category: Cat D;

• wing span: 32.5 m;
• distance between glide antenna and aircraft wheels: 7 m;
• ILS category: Cat I;
• distance between LOC antenna and landing THR: 2 500 m;
• LOC beam width at threshold: 210 m;
• glide path angle: 3°;
• reference datum height (RDH): 15 m;
• missed approach slope: 2.5%;
• final approach point altitude: 1 500 ft;
• end of precision segment: at 1 000 ft above THR; and
• final approach fix: not used.
The output data are as follows :
• coordinates system: standard x,y,z system based at the THR location (unit m); and
• coordinates of the specific points named C, D, E and C", D", E".
x y z
C 281 49 0
D -286 135 0
E -900 205 0
C" 10 807 153 300
D" 5 438 967 300
E" -12 900 3 058 300
• equations of the plane surfaces given in a specific format (z = Ax + By + C).
Surface A B C
W 0.0285 0 -9.01
X 0.026747 0.176346 -17.60
Y 0.023023 0.201942 -22.33
Z -0.025 0 -22.50
• elevation of the specific plane surfaces at requested points.
Surface x y z
W 2 000 250 79.98
X 1 200 1 000 207.24
Y -1 500 1 000 145.08
Z -2 500 500 40
e) Conclusion
OBJECT Precision Segment

Reference documentation Doc 8168 – Volume II – Part II – Section 1 – Chapter 1
Method/concept x

Input Data
Wing span x
Distance glide path antenna- x
wheels
Selected runway and x
localizer orientation
THR coordinates x
THR elevation x
ILS category x
LOC antenna coordinates x
LOC beam width x
Offset LOC x Check the function by using an offset ILS
Glide path angle x
RDH x
Missed approach slope x
FAP coordinates x
Use of FAF x
End of precision segment x

Output Data
Reference system x Check coordinates of the THR in this
system
Coordinates of specific x
points
Plane surfaces equation x
Elevation of plane surfaces x
Graphical check x
Conclusion The function is not accepted until a graphical check can be carried out.
7.5.3.12 Missed approach
The following example aims at assessing the acceptability of an NPA missed approach segment (straight-in) area
calculation. This example does not include any graphical output.
OBJECT Non Precision Missed Approach Segment (straight-in segment)

Method/concept x

Input Data
IAS range x
Type of wind x
IAS x

Output Data
Wind velocity x
Navaid range x
MAPt tolerance x
SOC position x
Area splay angle x
Ending area width x
width
Graphical check x
Conclusion The NPA missed approach segment is not accepted until the documentation about method and concept is
made available and is reviewed.
7.5.3.13 Departures
The following example aims at assessing the acceptability of straight departure with track adjustment. This example only
includes graphical output.
a) Method/concept
The reference for this type of departure is the PANS-OPS (Doc 8168), Volume II, Part I, Section 3,
Chapter 3 with Figure I-3-3-2.
In this example, the documentation is available and deemed acceptable.

b) Input data
• DER location, in order to draw the departure in the correct location;

• RWY direction, used with the procedure design gradient (PDG) to find the latest track adjustment
point;
• PDG, used with RWY direction to find the latest track adjustment point;
• departure track, used to draw the departure outer edges; and
• departure distance.
c) Graphical check
This step consists in assessing the graphical output, for instance angles and distances. (See
Figure 7-10.)
Figure 7-10.
d) Conclusion
OBJECT Straight departure (with track adjustment)

Method/concept x

Input Data
DER location x
RWY direction x
PDG x
Departure track x
Departure distance x

Output Data x No output data available (only 2-D drawing)

Graphical check x 2-D only
Conclusion The departure (2-D) is accepted.
7.6 APPLICATION TO THE STANDARD MODELLING VALIDATION FOR CALCULATIONS
7.6.1 The calculations carried out to get minimum altitudes (or gradients) include several steps:
— identification of the terrain and obstacle data that are relevant for the given segment or procedure;
— application of the relevant MOC to the previously identified terrain and obstacle data, taking into
account the differences linked to primary and secondary areas; and
— identification of the controlling obstacle (or terrain) and calculation of the MOCA (or OCA or PDG)
taking into account the PANS-OPS rounding rules.
7.6.2 These steps should be submitted to validation in a manner identical to the one developed in section 7.5, as
appropriate: method/concept assessment; input and output data checks; and graphical checks.
7.7 SPECIFIC CASES
7.7.1 It is acknowledged that the methodology proposed in this manual is not sufficient for functions where the
tests cannot be implemented by a series of manual calculations, visual checks or key-points to be surveyed.
7.7.2 This is the case for the CRM and the FAS data block generator.
7.7.3 For these specific cases, external validation processes, based on processes such as the Software Safety
Assurance System are necessary.
_____________________
Appendix A
GEOGRAPHICAL TRANSFORMATIONS/CONVERSIONS
(Reference: Section 5.2)
This appendix provides tables of transformations between WGS-84 and various common geodetic reference systems as
well as tables of conversion from WGS-84 geographical coordinates to common projection-based coordinates. The
tables are provided for a sample of input data, which can be used within the validation process.
CONVERSION MODEL
INPUT (WGS-84) OUTPUT (ED50) (parameters)
Latitude Longitude Latitude Longitude
41° 0' 0".0 012°0' 0".0 41° 00' 03".6300 12° 00' 03".5800 multiple regression (Sardinia)
51° 0' 0" 0° 0' 0",0 51° 00' 03".1417 0° 00' 04".9774 multiple regression (ED50 UK)
40° 0' 0".0 -5°0' 0".0 40° 00' 04".3681 -4° 59' 55".2049 multiple regression (ED50 western)
Projection from WGS-84 to universal transverse mercator (UTM) WGS-84
INPUT WGS-84 UTM ZONE UTM WGS-84
Latitude Longitude X Y
39°00'00,00'' N 008°00'00,00'' W 29 586592,678 4317252,165
54°00'00,00'' N 012°00'00,00'' E 33 303379,102 5987687,71
72°00'00,00'' N 031°00'00,00'' E 36 431030,463 7990077,472
WGS-84 to South American 1969, Argentina
Ellipsoidal
Datum Ellipsoid Latitude Longitude Height (m)
W071 09
WGS-84 WGS-84 S40 04 46.02 03.22 0
South American W071 09

South American 1969, Argentina 1969 S40 04 44.72 00.73 -32
WGS-84 to North American 1927, Mexico
Datum Ellipsoid Latitude Longitude Height (m)
WGS-84 WGS-84 N16 45 25.55 W099 45 13.75 0
North American 1927, Mexico Clarke 1866 N16 45 22.71 W099 45 12.61 16.3
App A-1
App A-2 Quality Assurance Manual for Flight Procedure Design — Volume 3
Projection from WGS-84 to Lambert Conformal Conic (South American 1969 Argentina)
Map Projection Ellipsoid Latitude Longitude
WGS-84 WGS-84 S40 04 46.02 W071 09 03.22
Datum Ellipsoid Projection Easting/Y (m) Northing/X (m)
South American 1969 South American Lambert

Argentina 1969 Conformal Conic -15644582 6594544.1
_____________________
Appendix B
WGS-84 CALCULATIONS
This appendix provides tables of WGS-84 geodetic calculations and results for three functions and for a sample of input
data, which can be used within the validation process. The three functions are the following:
a) Function 1 (“Direct”) presents calculation results for a point defined by azimuth and distance from a
known point. The sample of input data includes:
• the known point coordinates (cells including latitude and longitude described in front of “input
data”), expressed in sexagesimal degrees (*);
• the sample azimuths (in column), expressed in degrees; and
• the sample distances (in rows), expressed in nautical miles.
(*) Sexagesimal degrees are degrees, minutes and seconds.
The results are provided within the table cells with the latitude and longitude of the resulting point expressed in
sexagesimal degrees.
Example (example appears in bold italics in the table): the coordinates of the point defined as being at 30° and 10 NM
from the point defined by (latitude N45°00'00,00'', longitude E45°00'00,00'') are:
Latitude: N45°08'39,34'' – Longitude 045°07'03,86'' E.
b) Function 2 (“Reverse”) presents calculation results for the azimuth (forward and reverse ones) and
distance between two given points. The sample of input data includes:
• the first given point coordinates (cells including latitude and longitude described in front of “input
data”), expressed in sexagesimal degrees; and
• the second point coordinates (in column in front of points called P1, P2, etc.), expressed in
sexagesimal degrees.
The results are provided within the table cells with the forward and reverse azimuth expressed in decimal degrees and
the distance expressed in nautical miles.
Example (example appears in bold italics in the table): the azimuth and distance between the point defined by (latitude
N45°00'00,00'', longitude E45°00'00,00'') and the point defined by (latitude S000°01'00,00'', longitude W000°00'01,00'')
are:
Forward azimuth 234,88° – Reverse azimuth 35,40° – Distance 3598,268 NM
App B-1
App B-2 Quality Assurance Manual for Flight Procedure Design — Volume 3
c) Function 3 (“Intersection”) presents calculation results for the calculation of a point defined as being at
the intersection of two geodetic lines (each geodetic line being defined by two points belonging to this
line). The sample of input data includes:
• the coordinates of the two points defining the first geodetic line (cells including latitude and
longitude in front of points P1 and P2) expressed in sexagesimal degrees; and
• the coordinates of the two points defining the second geodetic line (cells including latitude and
longitude in front of points P3 and P4) expressed in sexagesimal degrees.
The results are provided within the table in the column labelled “intersection” with the latitude and longitude of the
intersection point expressed in sexagesimal degrees.
Example (example appears in bold italics in the table): the point P is defined as being at the intersection of the geodetic
line defined by point P1 and point P2 and of the geodetic line defined by point P3 and point P4. The input data are the
coordinates of P1-P2-P3-P4:
P1: latitude S85°00'00,00'', longitude W175°00'00,00''

The results are P coordinates: latitude S69°49'50,99'' and longitude W168°22'36,58''

Forward azimuth 234,88° – Reverse azimuth 35,40° – Distance 3598,268 NM
Important notes
WGS-84 parameters are the ones defined by the World Geodetic System — 1984 (WGS-84) Manual (Doc 9674).
In the examples provided in this appendix, a geodetic line is considered as a line extending beyond starting and ending
points.
Due to rounding processes, some slight differences (typically lower than 1/10th of a second for coordinates) may exist
between the results obtained with the automated system and the results presented in the tables. Any result differing from
the table in the 1/100th of second unit (e.g. W168°22'36,56'' compared to W168°22'36,57'') could be disregarded.
Due to their specific characteristics, calculations for values in very high latitudes (>85 degrees) may need specific care
with geodesic experts’ advice.
Appendix B App B-3
Function 1 (“Direct”)
INPUT LATITUDE S85 00 00,00 INPUT LATITUDE S000 01 00,00

LONGITUDE W175 00 00,00 LONGITUDE W000 00 01,00
Azimuth/Distance 1 10 100 Azimuth/Distance 1 10 100
0 84°59'00,30'' S 84°50'03,04'' S 83°20'30,21'' S 0 00°00'00,30'' N 00°09'02,96'' N 01°39'29,60'' N
175°00'00,00'' W 175°00'00,00'' W 175°00'00,00'' W 000°00'01,00'' W 000°00'01,00'' W 000°00'01,00'' W
30 84°59'08,28'' S 84°51'20,62'' S 83°30'39,05'' S 30 00°00'07,78'' S 00°07'42,18'' N 01°26'01,61'' N
174°54'18,53'' W 174°04'31,14'' W 167°38'41,18'' W 000°00'28,95'' E 000°04'58,46'' E 000°49'54,24'' E
60 84°59'30,08'' S 84°54'54,24'' S 83°59'49,28'' S 60 00°00'29,85'' S 00°04'01,48'' N 00°49'14,50'' N
174°50'07,84'' W 173°22'46,62'' W 161°08'08,92'' W 000°00'50,87'' E 000°08'37,68'' E 001°26'26,19'' E
90 84°59'59,90'' S 84°59'50,13'' S 84°43'58,35'' S 90 00°01'00,00'' S 00°01'00,00'' S 00°00'59,98'' S
174°48'35,10'' W 173°05'53,47'' W 156°37'35,26'' W 000°00'58,89'' E 000°09'57,93'' E 001°39'48,25'' E
120 85°00'29,77'' S 85°04'50,95'' S 85°35'21,89'' S 120 00°01'30,15'' S 00°06'01,48'' S 00°51'14,47'' S
174°50'05,88'' W 173°19'30,52'' W 155°58'57,71'' W 000°00'50,87'' E 000°08'37,69'' E 001°26'26,23'' E
150 85°00'51,67'' S 85°08'34,44'' S 86°20'28,02'' S 150 00°01'52,22'' S 00°09'42,18'' S 01°28'01,60'' S
174°54'16,57'' W 174°01'14,83'' W 161°53'47,29'' W 000°00'28,95'' E 000°04'58,46'' E 000°49'54,28'' E
195 85°00'57,66'' S 85°09'35,94'' S 86°34'29,17'' S 195 00°01'58,24'' S 00°10'42,42'' S 01°38'04,09'' S
175°02'57,83'' W 175°30'31,12'' W 177°47'56,73'' E 000°00'16,50'' W 000°02'36,01'' W 000°25'51,55'' W
210 85°00'51,67'' S 85°08'34,44'' S 86°20'28,02'' S 210 00°01'52,22'' S 00°09'42,18'' S 01°28'01,60'' S
175°05'43,44'' W 175°58'45,18'' W 171°53'47,29'' E 000°00'30,95'' W 000°05'00,46'' W 000°49'56,28'' W
225 85°00'42,16'' S 85°06'57,06'' S 85°59'50,64'' S 225 00°01'42,64'' S 00°08'06,36'' S 01°12'03,26'' S
175°08'05,43'' W 176°22'38,04'' W 167°57'17,36'' E 000°00'43,35'' W 000°07'04,51'' W 001°10'36,66'' W
INPUT LATITUDE N45 00 00,00

LONGITUDE E045 00 00,00
Azimuth/Distance 1 10 100
0 45°00'59,99'' N 45°09'59,93'' N 46°39'58,49'' N
045°00'00,00'' E 045°00'00,00'' E 045°00'00,00'' E
30 45°00'51,95'' N 45°08'39,34'' N 46°26'12,46'' N
045°00'42,29'' E 045°07'03,86'' E 046°12'17,43'' E
60 45°00'29,99'' N 45°04'59,31'' N 45°48'52,99'' N
045°01'13,24'' E 045°12'13,36'' E 047°03'49,61'' E
90 44°59'59,99'' N 44°59'59,13'' N 44°58'33,07'' N
045°01'24,56'' E 045°14'05,59'' E 047°20'53,52'' E
120 44°59'30,00'' N 44°54'59,38'' N 44°08'56,12'' N
045°01'13,22'' E 045°12'11,24'' E 047°00'17,44'' E
150 44°59'08,04'' N 44°51'20,22'' N 43°33'02,70'' N
045°00'42,27'' E 045°07'01,74'' E 046°08'44,98'' E
195 44°59'02,05'' N 44°50'20,44'' N 43°23'18,62'' N
044°59'38,12'' E 044°56'21,76'' E 044°24'30,56'' E
210 44°59'08,04'' N 44°51'20,22'' N 43°33'02,70'' N
044°59'17,73'' E 044°52'58,26'' E 043°51'15,02'' E
225 44°59'17,57'' N 44°52'55,34'' N 43°48'35,05'' N
044°59'00,22'' E 044°50'03,30'' E 043°22'20,85'' E
App B-4 Quality Assurance Manual for Flight Procedure Design — Volume 3
Function 2 (“Reverse”)
INPUT LATITUDE S85 00 00,00 INPUT LATITUDE S000 01 00,00

LONGITUDE W175 00 00,00 LONGITUDE W000 00 01,00
2nd POINT Forward Azimuth Reverse azimuth Distance 2nd POINT Forward Azimuth Reverse azimuth Distance
P1 S75 10 10,00 42,47 193,29 648,588 P1 S75 10 10,00 188,54 144,64 6134,191
W145 30 30,00 W145 30 30,00
P2 S50 50 50,50 80,37 187,83 2291,496 P2 S50 50 50,50 218,73 98,54 5811,213
W100 45 45,00 W100 45 45,00
P3 S27 27 27,00 102,02 185,53 3816,414 P3 S27 27 27,00 241,88 83,34 4635,052
W75 30 00,00 W75 30 00,00
P4 S000 01 00,00 174,98 180,44 5700,026 P4 S000 01 00,00 0,00 180,00 0
W000 00 01,00 W000 00 01,00
P5 N000 01 00,00 174,98 180,44 5702,017 P5 N000 01 00,00 0,96 180,96 1,99
E000 00 01,00 E000 00 01,00
P6 N20 20 20,20 195,89 178,54 6905,899 P6 N20 20 20,20 43,32 227,00 1705,719
E020 20 20,20 E020 20 20,20
P7 N45 00 00,00 223,53 175,12 8317,37 P7 N45 00 00,00 35,40 234,88 3598,268
E045 00 00,00 E045 00 00,00
P8 N65 30 30,30 313,81 171,27 9131,085 P8 N65 30 30,30 19,00 308,44 6353,785
E 130 59 59,59 E 130 59 59,59
P9 N89 59 30,00 0,10 265,91 10499,682 P9 N89 59 30,00 359,99 91,00 5401,616
W89 00 00,00 W89 00 00,00
INPUT LATITUDE N45 00 00,00 INPUT LATITUDE N89 59 30,00

LONGITUDE E045 00 00,00 LONGITUDE W89 00 00,00
2nd POINT Forward Azimuth Reverse azimuth Distance 2nd POINT Forward Azimuth Reverse azimuth Distance
P1 S75 10 10,00 174,73 194,67 8965,814 P1 S75 10 10,00 236,48 0,03 9906,751
W145 30 30,00 W145 30 30,00
P2 S50 50 50,50 243,25 91,25 9396,851 P2 S50 50 50,50 191,76 0,00 8442,851
W100 45 45,00 W100 45 45,00
P3 S27 27 27,00 269,65 52,90 7810,802 P3 S27 27 27,00 166,50 360,00 7040,705
W75 30 00,00 W75 30 00,00
P4 S000 01 00,00 234,88 35,40 3598,268 P4 S000 01 00,00 91,00 359,99 5401,616
W000 00 01,00 W000 00 01,00
P5 N000 01 00,00 234,90 35,42 3596,627 P5 N000 01 00,00 91,00 359,99 5399,626
E000 00 01,00 E000 00 01,00
P6 N20 20 20,20 227,77 33,99 1918,193 P6 N20 20 20,20 70,66 359,99 4185,953
E020 20 20,20 E020 20 20,20
P7 N45 00 00,00 0,00 180,00 0 P7 N45 00 00,00 45,99 359,99 2709,324
E045 00 00,00 E045 00 00,00
P8 N65 30 30,30 33,61 289,43 2914,448 P8 N65 30 30,30 320,01 0,01 1476,595
E 130 59 59,59 E 130 59 59,59
P9 N89 59 30,00 359,99 45,99 2709,324 P9 N89 59 30,00 0,00 180,00 0
W89 00 00,00 W89 00 00,00
Appendix B App B-5
Function 3 (“Intersection”)
INPUT DATA INPUT DATA

P1 S85 00 00,00 P1 S000 01 00,00
W175 00 00,00 W000 00 01,00
P2 S80 30 30,00 P2 N002 02 02,02
W170 50 50,00 E004 04 04,00
P3 P4 Intersection P3 P4 Intersection
S84 48 48,48 S87 50 50,50 85°07'31,82'' S S05 05 05,05 N00 00 00,00 00°02'15,57'' S
W175 00 00,00 W 179 59 59,00 175°13'35,55'' W W005 40 40,40 E00 00 00,00 000°02'30,74'' W
S82 30 30,30 S 89 59 30,00 83°01'05,99'' S S03 00 40,00 N03 03 03,03 00°59'27,41'' N
W172 30 30,30 W170 00 02,00 172°30'29,56'' W W000 01 00,00 E003 02 02,02 001°59'48,49'' E
S87 50 50,50 S 84 55 55,55 69°49'50,99'' S N03 03 03,03 S05 05 05,05 00°54'11,35'' N
W 179 59 59,00 W172 30 30,30 168°22'36,58'' W E004 30 30,30 W005 40 40,40 001°49'21,72'' E
S 84 55 55,55 S85 00 00,00 86°48'14,08'' S N05 05 05,00 S05 05 05,05 00°54'59,32'' N
E180 00 00,00 E180 00 00,00 E180 00 00,00 E000 00 00,50 E004 30 30,30 001°50'56,85'' E
S 89 59 30,00 S78 25 25,25 87°31'31,84'' S
W170 00 02,00 E175 50 50,50 175°53'04,51'' E
INPUT DATA
P1 N45 00 00,00
E045 00 00,00
P2 N36 30 30,30
E046 00 01,01
P3 P4 Intersection
N43 50 40,30 N50 00 01,01 61°28'22,87'' N
E035 00 00,00 E036 45 45,45 041°45'17,87'' E
_____________________
Appendix C
BASIC DATA AND PARAMETERS

C-1. Raw data and reference values for procedure design calculations
Constant Value
PI 3.1416
Mean Earth Radius
6 378 137 m
(Doc 9674, WGS-84 manual)
1 7
Flattening
2
9
8
.
2
5
2
2
3
5
6
3
(Doc 9674, WGS-84 manual)
g 9.80665 m/sec2
Nautical Mile
1 852.0 m
(Annex 5, Table 3.3)
Reference pressure to define the flight levels and QNH
1 013.2 hPa
(Doc 4444)
Missed approach climb gradient (Z) Default value 2.5%
(Doc 8168, Volume II, Part 1, Section 4, Ch. 6) Additional values 2%, 3%, 4%, 5%
Pressure altimeter Radio altimeter
CAT A (m/ft) (m/ft)
40 (130) 13 (42)
Height loss (HL) CAT B 43 (142) 18 (59)

CAT C 46 (150) 22 (71)
CAT D 49 (161) 26 (85)
CAT H 35 (115) 8 (25)
OIS altitude at the DER (H) 5 m (16 ft)
App C-1 22/2/11

Corr.
App C-2 Quality Assurance Manual for Flight Procedure Design — Volume 3
C-2. MOC values
The MOC values incorporated in the software may be higher than the values provided in the following table for the
various segments of flight :
MOC value in the primary area

(for the secondary area it will be
Segment of flight reduced linearly from the entire value Mountainous areas
to 0 on the outer border of the
secondary area)
Initial approach segment 984 ft (300 m) Up to the procedure designer
Intermediate approach segment 492 ft (150 m) Up to the procedure designer
Non precision final approach 246 ft (75 m) or 295 ft (90 m) Up to the procedure designer
segment in case of no FAF procedure.
98 ft (30 m) or 164 ft (50 m) Up to the procedure designer

depending on the position of
Missed approach segment
the obstacle in the missed
approach area.
0.008*D where D is the Up to the procedure designer

distance from the obstacle to
Departure the Departure end of Runway
(DER) or 295 ft (90 m),
whichever is greater.
Arrival 984 ft (300 m) Up to the procedure designer
• 450 m (1 476 ft) between 900 m

(3 000 ft) and 1 500 m (5 000 ft)
En-route 984 ft (300 m)
• 600 m (1 969 ft) greater than
1 500 m (5 000 ft)
_____________________
Appendix D
BASIC ELEMENT VALIDATION

D-1. Fixes and waypoints construction
The following table describes the parameters to compute the fix tolerance area (FTA) for conventional fixes as described
in Doc 8168, Volume II, Part I, Section 2, Chapter 2:
Splay angle for

the protection FTA overhead
Navaid type area construction Tracking Intersecting the antenna
VOR 7.8° 5.2° 4.5° 50°
NDB 10.3° 6.9° 6.2° 40°
LOC NA 2.4° 1.4° NA
DME NA 0.46 km (0.25 NM) + 1.25% of the distance NA

to the antenna
Conventional fixes construction
The next table describes the WP construction referenced in Doc 8168, Volume II, Part III, Section 1, Chapters 2, 3
and 4.
In the next table the following values have been used:
D distance from the reference facility to the WP = (D12+D22)1/2

FTT flight technical tolerance
ST system computation tolerance
VT D1-Dcos(Q+ α)
DT DTT cos Q
AVT D2- D sin (Q- α)
ADT DTT sin Q
TSE Total system error
For the GNSS parameters, please refer to Doc 8168, Volume II, Part III, Section 1, Chapter 2.
For the DME/DME, parameters have been referenced in Doc 8168, Volume II, Part III, Section 1, Chapter 3.
For the VOR/DME parameters, please refer to Doc 8168, Volume II, Part 3, Section 1, Chapter 4.
App D-1
App D-2 Quality Assurance Manual for Flight Procedure Design — Volume 3
WP type XTT (KM/NM) ATT (KM/NM)
VOR/DME ±(VT2+DT2+FTT2+ST2)1/2 ±(AVT2+ADT2+ST2)1/2
DME/DME ±(VT2+DT2+FTT2+ST2)1/2 ±(AVT2+ADT2+ST2)1/2
DME/DME
(when DME stations
± (TSE² + FTT² + ST²)½ ± (TSE² + ST²)½
are commissioned
after 1 January 1989)
3.70/2.00: IAWP located

7.41/4.00: IAWP located
outside the circle of
outside the circle of 30 NM
30 NM from the
from the approach ARP
approach ARP
2.78/1.50: IAF located 1.85/1.00: IAF located

inside the circle of 30 NM inside the circle of 30 NM
from the approach ARP from the approach ARP
2.78/1.50 fix in the initial 1.85/1.00 fix in the initial

segment segment
2.78/1.50 IF 1.85/1.00 IF
GNSS
1.11/0.60 FAF 0.56/0.30 FAF
0.93/0.50 MAPt 0.56/0.30 MAPt
2.78/1.50 fix in missed 2.78/1.50 fix in missed

approach located inside the approach located inside the
circle of 30 NM from the circle of 30 NM from the
approach ARP approach ARP
7.41/4.00 fix in the missed 7.41/4.00 fix in the missed

approach located outside the approach located outside the
circle of 30 NM from the circle of 30 NM from the
approach ARP approach ARP
RNP value RNP value

RNP (from 0.93 km/0.5 NM (from 0.93 km/0.5 NM
up to 0.03 km/0.02 NM) up to 0.03 km/0.02 NM )
Parameters for the RNAV waypoints construction

Appendix D App D-3
D-2. Sample results for the calculation of TAS
The following table provides sample results for the calculation of TAS given several altitudes.
IAS Altitude ISA + 15 TAS

160 1000 1.0411 166.569460
160 2000 1.0567 169.079422
160 3000 1.0728 171.645361
160 4000 1.0892 174.268937
160 5000 1.1059 176.951871
160 10000 1.1958 191.321781
185 1000 1.0411 192.595939

185 2000 1.0567 195.498081
185 3000 1.0728 198.464949
185 4000 1.0892 201.498459
185 5000 1.1059 204.600601
185 10000 1.1958 221.215810
210 1000 1.0411 218.622417

210 2000 1.0567 221.916741
210 3000 1.0728 225.284536
210 4000 1.0892 228.727980
210 5000 1.1059 232.249331
210 10000 1.1958 251.109838
230 1000 1.0411 239.443599

230 2000 1.0567 243.051669
230 3000 1.0728 246.740206
230 4000 1.0892 250.511597
230 5000 1.1059 254.368314
230 10000 1.1958 275.025061
240 1000 1.0411 249.854190

240 2000 1.0567 253.619133
240 3000 1.0728 257.468042
240 4000 1.0892 261.403406
240 5000 1.1059 265.427806
240 10000 1.1958 286.982672
250 1000 1.0411 260.264782

250 2000 1.0567 264.186596
250 3000 1.0728 268.195877
250 4000 1.0892 272.295214
250 5000 1.1059 276.487298
250 10000 1.1958 298.940283
Note.— Where PANS-OPS specifies the use of mach number in place of TAS for holding area construction
(i.e. specific case of holding at high altitude), a holding area designed using TAS without considering this part of the
criteria will be overprotective, and the function may be acceptable although the design is not totally consistent with
PANS-OPS criteria.
D-3. Nominal track construction
The following table describes the formulas used to compute the nominal track (Doc 8168, Volume II).
Formulas for the nominal track construction
Segment Formula
3
4
3
1 π
t
a V
n
α
R=
Rate of turn R (°/sec) Where:
α = bank angle (°)
V = TAS (kt)
W = 12 h + 87
Where:
W = wind speed in km
h = altitude in thousands of metres
or
Wind velocity calculation formula
W = 2 h + 47
Where:
W = wind speed in Kt
h = altitude in thousands of feet
w 0
R
4
Wind effect during turn. E= km (NM)
For a 90° heading change
W = wind speed km/h or (Kt)
3t
6
φ= for TAS less than or equal to 170 kt

T
A
S
0
.
2
1
5t
Divergence between the inbound and ⋅

φ= for TAS exceeding 170 kt
the outbound leg of a base turn
Where:
t is the time in minutes specified for the outbound leg
TAS is the maximum IAS specified for the procedure
Wind effect in the area construction for w = (2h + 47) kt
reversal procedures Where h is in thousands of feet
Y = r × tan (0.5 × α)
Where:
Turn anticipation in fly-by turns Y = turn anticipation distance
r = radius of turn
α = track angle change (degrees) 120° ≥ α.
V 6
D
N
M
1
0
1
5
0
=( + . ) + .
Radius of the protection area for the DF turn

Where:
t = outbound time in minutes
V = aircraft speed in kt
D = radius in NM
Appendix D App D-5
D-4. Obstacle evaluation in departure procedures
This section deals with the formulas to compute the obstructions for the departure procedures.
Formulas for the obstacle’s evaluation in departures procedures
Computation Formula
Turning departures:
The obstacles must be less than 90 m (295 ft) in height
Obstructions located in the turn area
PDG (dr + d0) + H – MOC
where:
dr = shortest distance from obstacle to K-K line (m or ft)
Turn departures: d0 = horizontal distance from DER to line K-K (m or ft)
Obstacle clearance in the turn area PDG = promulgated procedure design gradient
H = as mentioned in para. 6.1.2
MOC = 0.008 (dr + d0) or 90 m (295 ft) (CAT H 80 m
(265 ft)), whichever higher.
The obstacle’s elevation/altitude has to be less than:
Omnidirectional departures TNA / H + 0.033d0 – MOC
CAT H: 90mt + 0.05 d0 – MOC
D-5. ILS/MLS surfaces construction
This section deals with the formulas to construct the OAS surfaces.
Formulas for the ILS/MLS approaches procedures
Computation Formula
Z= Ax + By + C
Surfaces construction Where:
A, B, C are referring to Doc 8168 Att. I to Part III
W surface = Cw – (t – 6)
W* surface = Cw* – (t – 6)
X surface = Cx – Bx ⋅ P
Y surface = Cy – By ⋅ P
Adjustment of constants in case of Where:
t Bx
t
3
o
r
s
non standard conditions −

Bx
P= + whichever is the maximum
Where:
S = semi-span (m)
t = vertical distance between paths of the GP antenna and
the lowest part of the wheels (m)
Ccorr = C + (RDH - 15)
Where:
Ccorr = corrected value of the coefficient C for the appropriate
Adjustment of the reference datum
surface
C = tabulated value
RDH (m)
D-6. Obstacle evaluation in ILS/MLS approaches
This section deals with the formulas to evaluate the obstructions in case of ILS/MLS approaches.
Formulas for the obstacle’s evaluation in ILS/MLS approaches
Computation Formula
hm
ZZ
x
9
0
0
ha
cot +( + )
a
=
cot + cot θ
Where:
ha = height of the equivalent approach obstacle
hma = height of the missed approach obstacle
Equivalent height of the
θ = glide path angle
obstructions in the MA area
Z = angle of the missed approach surface
x = range of obstacle relative to THR
Note:
For CAT H the formula is
hm
ZZ
x
7
0
0
ha
cot + ( + )
a
=
cot + cot θ
Obstacle altitude/height <
(OCA/Hps – HL) + d0 tan Z
Where:
OCA/Hps and HL are referring to Doc 8168,
Maximum altitude/height of the
Table II-1-3-2 and are related to the same aircraft
obstacle in the straight precision
category.
missed approach
d0 is measured from the SOC parallel to the straight
missed approach track
Z is the angle of the missed approach surface with the
horizontal plane
D-7. Obstacle evaluation in RADAR approaches
This paragraph deals with the RADAR approaches as described in PANS-OPS.
Formulas for the RADAR procedures
Computation Formula
H n
9 n
8 0
D
t
a
.
6
t
a
= −
θ θ
Intersection of the obstacle’s Where:

clearance surface and the D = distance before the THR
horizontal surface H = height of the nominal descent path over the
THR (m)
θ = nominal glide path angle (°)
0.6 θ = worst assumed glide path angle
22/2/11
Corr.
Appendix D App D-7
D-8. Straight-in approach
If the software is providing assistance to determine if the selected final axis is a straight-in approach axis, one must
check if the criteria used by the software are compliant with the regulation as it is described in Doc 8168, Volume II,
Part I, Section 4, Chapter 5.
D-9. OCH adjustment
If the software is providing the designer with a level of information sufficient to identify straight-in approach, then one
must check if the software takes into account a minimum value of OCH per category of aircraft.
If so, one must check if this minimum value is compliant with the table included in Doc 8168, Volume II, Part I, Section 4,
Chapter 5.
If the software fulfills the previous hypothesis, and if it takes into account by computation or by input the nominal slope of
the final segment, then one must check if the software warns the designer in case of the high slope and/or computes a
minimum OCH value due to high final slope according to the criteria expressed in Doc 8168, Volume II, Part I, Section 4,
Chapter 5.
The value of the proper minimum OCH must be compared by the software to the OCH obtained by the survey of the
obstacles in the final segment. One must check that the resulting OCH associated to the segment by the software is the
highest one.
D-10. Slope and rate of descent
If the software is providing the user with a slope computation, one must check that this slope is actually computed
between two fixes along the designed trajectory. This slope must be computed between each nominal position of the
fixes.
If the segment concerned by the computation is the final segment then the slope is computed between the nominal
position of the FAF and the runway threshold assuming that the trajectory is passing 15 m (50 ft) above the threshold
location.
If the software is computing rate of descent it must be computed using nominal flight time for identified IAS.
_____________________
Appendix E
SAMPLE VALIDATION DOCUMENTATION

Software Name Instrument Procedure Design System Version 1.0
Name of Tester John Q. Public Organization/State Federal Aviation Administration/United States of

America
Signature John Q Public Date 16 May 2007
Test # 1 Title Circling Objective Validate construction and obstacle assessment of

circling area
Reference Doc. PANS-OPS, Volume II [Part I, Section 4, Chapter 7]
Related Test # Tests # 7 and 8
Initial Conditions
Application is open, and populated with database set “A1”. Procedure titled VOR/DME straight-in final Test #8 has been created
and saved.
Step Required Action Expected Results Pass Fail
1 CAT A area Application correctly constructs area x
2 CAT A obstacle assessment Application correctly assesses obstacles x
3 CAT B area Application correctly constructs area x
4 CAT B obstacle assessment Application correctly assesses obstacles x
Comments
None
_____________________
App E-1
QUALITY ASSURANCE
Feedback Form
Please submit any written comments, feedback or recommendations to improve this document, or suggestions for new
items/additional subjects.
Subject : Quality Assurance Manual for Flight Procedure Design

Volume 3 — Flight Procedure Design Software Validation
To: ICAO
Air Traffic Management Section
Air Navigation Bureau
999 University Street
Montréal, Quebec H3C 5H7
CANADA
Please check appropriate line items and duplicate the form as required.
An error (procedural or typographical) has been noted in paragraph on page .
Recommend paragraph on page be changed as follows:

(attach separate sheet if necessary)
In a future amendment to this document, please include coverage on the following subject:
(briefly describe the suggested subject and, possibly, recommended text)
Other comments:
ATTACHMENT LIST [please mention all attachments to this form].
I would like to discuss the above. Please contact me.
Submitted by (name, organization and address): ________________________________________________________
_______________________________________________________________________________________________
Date: ___________________
Telephone number: _______________________
Email address: ___________________________
— END —
Q-1

9906 - Vol III - Flight Procedure Design Software Validation (1) 2010

Uploaded by

Copyright:

Available Formats

9906 - Vol III - Flight Procedure Design Software Validation (1) 2010

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9906 - Vol III - Flight Procedure Design Software Validation (1) 2010

Uploaded by

Copyright:

Available Formats

What is the purpose of this manual?

What is the purpose of this manual?

What are the different volumes of the manual?

What are the different volumes of the manual?

Doc 9906

Quality Assurance Manual

Approved by the Secretary General

First Edition — 2010

International Civil Aviation Organization

Quality Assurance Manual

Approved by the Secretary General

First Edition — 2010

International Civil Aviation Organization

For ordering information and for a complete listing of sales agents

First edition 2010

All rights reserved. No part of this publication may be reproduced, stored in a

Amendments are announced in the supplements to the Catalogue of ICAO

RECORD OF AMENDMENTS AND CORRIGENDA

No. Date Entered by No. Date Entered by

1 8/8/13 ICAO 1 22/2/11 ICAO

Volume 1 — Flight Procedure Design Quality Assurance System;

Volume 3 — Flight Procedure Design Software Validation;

Volume 4 — Flight Procedures Design Construction (to be developed);

Volume 5 — Validation of Instrument Flight Procedures; and

Volume 4 — Flight Procedures Design Construction (to be incorporated later).

PREFACE ......................................................................................................................................................... (v)

TABLE OF CONTENTS .................................................................................................................................... (vii)

DEFINITIONS .................................................................................................................................................... (xi)

FOREWORD ..................................................................................................................................................... (xiii)

STRUCTURE OF THE MANUAL ..................................................................................................................... (xv)

Chapter 1. Introduction ................................................................................................................................ 1-1

1.1 Automation in the procedure design domain..................................................................................... 1-1

Chapter 2. Scope .......................................................................................................................................... 2-1

2.1 Goal of the manual ........................................................................................................................... 2-1

Chapter 3. Overview of procedure design tools ........................................................................................ 3-1

3.1 Main functions of procedure design tools.......................................................................................... 3-1

Chapter 4. Implementing a validation programme .................................................................................... 4-1

4.1 Preparation ....................................................................................................................................... 4-1

Chapter 5. Environment of procedure design ............................................................................................ 5-1

5.1 Tool documentation .......................................................................................................................... 5-1

Chapter 6. Tool inputs .................................................................................................................................. 6-1

6.1 Aeronautical data integration and updates........................................................................................ 6-1

Chapter 7. Procedure design functions ...................................................................................................... 7-1

7.1 Considerations about units and rounding processes ........................................................................ 7-1

Appendix A. Geographical transformations/conversions......................................................................... App A-1

Appendix B. WGS-84 calculations .............................................................................................................. App B-1

Appendix C. Basic data and parameters .................................................................................................... App C-1

Appendix D. Basic element validation ........................................................................................................ App D-1

D-1 Fixes and waypoints construction ..................................................................................................... App D-1

Appendix E. Sample validation documentation ......................................................................................... App E-1

Quality Assurance Feedback Form................................................................................................................ Q-1

AIXM Aeronautical information exchange model

Acceptance. The act of accepting with formal approval (favourable reception).

Automation. The automatic operation or control of equipment, a process, or a system.

• result of checks for consistency of input with the applicable regulation;

Test. A basis for critical evaluation.

The Secretary General

This manual is organized as follows :

The following drafting conventions are used in this manual: