rtca sc-189/eurocae wg-53 position paper · 2020. 12. 31. · c:\mes...

$: RTCA SC-189/EUROCAE WG-53 Position Paper · 2020. 12. 31. · C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page 2, Save date, 14-Oct-00 RTCA S RTCA SC-189/EUROCAE$
C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page 1, Save date, 14-Oct-00 RTCA S

RTCA SC-189/EUROCAE WG-53 Position PaperAir Traffic Services Safety and Interoperability Requirements

General InformationPosition Paper Number:

P-PUB-22Revision: e.g. A

FinalDate: e.g. 11 Nov 94 23-Jun-00

Comments Due:

Author/Fax/Internet:Tom MillerInternet: [email protected]: 202-484-1510

Send Comments to (Include Name/Address/Fax/Voice/Internet):Author

Position Paper Title:Guidelines for Approval of the Provision and Use of Air Traffic Services Supported by Data CommunicationsAbstract:This position paper is used to develop and track the changes of ED/DO-GUID publication, Guidelines forApproval of the Provision and Use of Air Traffic Services Supported by Data Communications. This publicationwill contain the guidance material being produced by the sub-groups.It is the intent of PUB to combine all guidance material into one document. As a result, ED/DO-METH, currently in P-Pub-20-C2, has been incorporated into ED/DO-GUID, which is contained in thisposition paper. Therefore, P-Pub-20-C2 is considered obsolete and will no longer be maintained.Also, subgroups will no longer maintain position papers containing guidance material and all newguidance material provided by subgroups should be developed as a comment paper to this positionpaper and provided to the name shown above.

Action taken:This version contains the results of the work conducted after the Plenary meeting held inMontreal Jun 5-Jun 9, 2000, to the date of this version's publication. This document isprepared for ballot process.

Resolution Required By:

Key words (Optional):

Status Individual Proposal Sub-Group Agreement Pub document

Internal Use Only Closed

DistributionName Org Internet Fax189/53 participantsSerge Bagieu Aerospatiale

[email protected] +33-5-61-93-80-90

Tom Kraft FAA [email protected] +01-425-227-2725Rob Mead SG-1 Eurocontrol [email protected] +32-2-729-9087Tony Martin SG-1 AJM Cnslt [email protected] +01-425-868-7297John Vincent SG-2 CAA SRG [email protected] +44-1293-573975Mark Joseph SG-2 MITRE [email protected] +01-703-883-1330Roy Oishi – SG-3 ARINC [email protected] +01-410-573-3106Marc Barrere - SG-3 Aerospatiale [email protected] +33-5-61-93-07-29Gregg Anderson – SG-4

FAA [email protected] +01-202-366-1806

Danny Bharj – SG-4 Eurocontrol [email protected] +32-2-729-3587

mailto:[email protected]




C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page 2, Save date, 14-Oct-00 RTCA S

RTCA SC-189/EUROCAE WG-53 CommentPosition Paper Information

(To be completed by Position Paper Author and attached to position paper)Position Paper Number:

P-PUB-22Revision: e.g. A

FinalDate: e.g. 11 Nov 94

23-Jun-00Comments Due:

Author/Fax/Internet:Tom MillerInternet: [email protected]: 202-484-1510

Send Comments to (Include Name/Address/Fax/Voice/Internet):Author

Position Paper Title:Guidelines for Approval of the Provision and Use of Air Traffic Services Supported by Data Communications

Comment Information(To be completed by Comment Author)

Comment Author (Include Name/Address/Voice/Fax/Internet): Comment Date:e.g., 3 Apr 96

Type of Comment (Check all that apply): Response Requested Disagreement Clarification Additional Material

Comment (Attach pages as necessary):

Proposed Solution (Attach pages as necessary)

Status of Comment/Action Taken(To be completed by position paper author or delegate)

Assigned to: SG-1 SG-2 SG-3 Staff CAG Other Comment Number:

C-Status/Action Taken:

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page i, Save date, 14-Oct-00 RTCA S

EUROCAE17 Rue Hamelin

75783 PARIS Cedex 16FRANCE

Guidelines for Approval of the Provision and Use ofAir Traffic Services

Supported by Data Communications

DOCUMENT NO.EUROCAE/ED-XXX

Save date:Prepared by: WG-53/SC-189

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page ii, Save date, 14-Oct-00 RTCA S

Copies of this document may be obtained from

EUROCAE17 Rue Hamelin

75783 PARIS Cedex 16FRANCE

Telephone: 33-(0)1 45 05 71 88Facsimile: 33-(0)1 45 05 72 30

Internet: [email protected]

Please contact EUROCAE for price and ordering information.

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page iii, Save date, 14-Oct-00 RTCA S

FOREWORD

1. The development of these guidelines was jointly accomplished by RTCA SC-189 and the EuropeanOrganisation for Civil Aviation Equipment (EUROCAE) WG-53 through a consensus process. It wasaccepted by the Council of EUROCAE on (TBD) and RTCA Program Management Committee on(TBD).

2. RTCA, Incorporated and EUROCAE are respectively a US and an international not-for-profit makingorganizations, formed to advance the art and science of aviation and aviation electronic systems forthe benefit of the public.

2.1 EUROCAE Membership is open to European users and manufacturers of equipment for aeronautics,trade associations, national civil aviation administrations and, under certain conditions, non-Europeanorganizations. Its work programme is principally directed to the preparation of performancespecifications and guidance documents for civil aviation equipment, for adoption and use at Europeanand worldwide levels.

The findings of EUROCAE are resolved after discussion among its members and in cooperation withRTCA Inc., Washington DC, USA and/or the Society of Automotive Engineers (SAE), WarrendalePA, USA through their appropriate committees.

2.2 RTCA functions as a Federal Advisory Committee and develops consensus based onrecommendations on contemporary aviation issues. RTCA’s objectives include, but are not limitedto:• coalescing aviation system user and provider technical requirements in a manner that helps States

and industry meet their mutual objectives and responsibilities;• analyzing and recommending solutions to the system technical issues that aviation faces as it

continues to pursue increased safety, system capacity and efficiency;• developing consensus on the application of pertinent technology to fulfill user and provider

requirements, including development of minimum operational performance standards forelectronic systems and equipment that support aviation, and

• assisting in developing the appropriate technical material upon which positions for theInternational Civil Aviation Organization and the International Telecommunications Union andother appropriate international organizations can be based.

The organization’s recommendations are often used as the basis for State and private sector decisionsas well as the foundation for many Federal Aviation Administration Technical Standard Orders.

3. Since RTCA or EUROCAE are not official agencies of any US or European State, theirrecommendations may not be regarded as statements of official State policy unless so enunciated bythe appropriate State organization, conference of States; or agency having statutory jurisdiction overany matters to which the recommendations relate.

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page iv, Save date, 14-Oct-00 RTCA S

This page intentionally left blank

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page i, Save date, 14-Oct-00 RTCA S

RTCA, Incorporated1140 Connecticut Avenue, N. W., Suite 1020

Washington, DC 20036

Guidelines for Approval of the Provision and Use ofAir Traffic Services

Supported by Data Communications

DOCUMENT NO. RTCA/DO-XXXSave date:

Prepared by: SC-189/WG-53

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page ii, Save date, 14-Oct-00 RTCA S

Copies of this document may be obtained from

RTCA, Incorporated1140 Connecticut Avenue, Northwest, Suite 1020

Washington, D.C. 20036-4001 U.S.A.

Telephone: 202-833-9339Facsimile: 202-833-9434Internet: www.rtca.org

Please contact RTCA for price and ordering information.

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page iii, Save date, 14-Oct-00 RTCA S

FOREWORD

This guidance document was jointly prepared by Special Committee 189 (SC-189) and theEuropean Organisation for Civil Aviation Equipment (EUROCAE) Working Group 53 (WG-53) and approved by the RTCA Program Management Committee (PMC) on _________.

RTCA, Incorporated is a not-for-profit corporation formed to advance the art and science ofaviation and aviation electronic systems for the benefit of the public. The organizationfunctions as a Federal Advisory Committee and develops consensus based onrecommendations on contemporary aviation issues. RTCA’s objectives include, but are notlimited to:

• coalescing aviation system user and provider technical requirements in a mannerthat helps government and industry meet their mutual objectives andresponsibilities;

• analyzing and recommending solutions to the system technical issues thataviation faces as it continues to pursue increased safety, system capacity andefficiency;

• developing consensus on the application of pertinent technology to fulfill userand provider requirements, including development of minimum operationalperformance standards for electronic systems and equipment that supportaviation, and

• assisting in developing the appropriate technical material upon which positionsfor the International Civil Aviation Organization and the InternationalTelecommunications Union and other appropriate international organizations canbe based.

The organization’s recommendations are often used as the basis for government and privatesector decisions as well as the foundation for many Federal Aviation AdministrationTechnical Standard Orders.

Since RTCA is not an official agency of the United States Government, its recommendationsmay not be regarded as statements of official government policy unless so enunciated by theU. S. government organization or agency having statutory jurisdiction over any matters towhich the recommendations relate.

C:\Mes documents\pdf-prepare\EUROCAE\Pu-22-Fina.docPu-22-Fina.Doc, Page iv, Save date, 14-Oct-00 RTCA S

This page intentionally left blank

Pu-22-Fina.Doc, Page v, Save date, 14-Oct-00 RTCA SC-189 / EUROCAE WG-53

TABLE OF CONTENTS

1.0 Introduction 11.1 Purpose ............................................................................................................................... 11.2 Scope................................................................................................................................... 2

1.2.1 Assessments that are Not Within the Scope of this Document.............................. 31.3 How to Use the Guidance Material and Standards ............................................................. 3

1.3.1 Guidance Material ................................................................................................. 31.3.1.1 Document Structure .................................................................................. 41.3.1.2 Additional Considerations Using the Guidance Material ......................... 5

1.3.2 Operational Services and Environment Definition (OSED) and Standards .......... 61.3.2.1 Operational Services and Environment Definition (OSED)..................... 61.3.2.2 Operational, Safety, and Performance Requirements (SPR)

Standard .................................................................................................... 61.3.2.3 Interoperability Requirements (INTEROP) Standard............................... 61.3.2.4 MOPS and MASPS................................................................................... 7

1.3.3 Relationships of Guidance Material to Standards and Evidence ........................... 7

2.0 Description of Processes 82.1 Approval Planning .............................................................................................................. 92.2 Coordinated Requirements Determination ....................................................................... 10

2.2.1 Operational Services and Environment Information Capture (OSEIC)............... 122.2.2 Operational Safety Assessment (OSA)................................................................ 122.2.3 Operational Performance Assessment (OPA)...................................................... 132.2.4 Interoperability Assessment (IA)......................................................................... 132.2.5 Evidence for Coordinated Requirements Determination ..................................... 14

2.3 Development and Qualification of a System Element ...................................................... 142.3.1 Development........................................................................................................ 152.3.2 Qualification ........................................................................................................ 16

2.4 Entry into Service ............................................................................................................. 172.5 Operations......................................................................................................................... 18

3.0 Approval Planning 203.1 Objectives for Approval Planning .................................................................................... 203.2 Evidence for Approval Planning....................................................................................... 21

4.0 Coordinated Requirements Determination 224.1 Objectives for Coordinated Requirements Determination................................................ 22

4.1.1 Operational Services and Environment Information Capture (OSEIC)............... 224.1.2 Operational Safety Assessment (OSA)................................................................ 23

4.1.2.1 Operational Hazard Assessment (OHA)................................................ 234.1.2.2 Allocating Safety Objectives and Requirements (ASOR) ...................... 27

4.1.3 Operational Performance Assessment (OPA)...................................................... 274.1.3.1 Determination of RCP Type ................................................................... 274.1.3.2 Allocation of RCP Type ......................................................................... 28

4.1.4 Interoperability Assessment (IA)......................................................................... 294.2 Evidence for Coordinated Requirements Determination .................................................. 30

5.0 Development and Qualification of a System Element 30

Pu-22-Fina.Doc, Page vi, Save date, 14-Oct-00 RTCA SC-189 / EUROCAE WG-53

5.1 Development..................................................................................................................... 305.1.1 Objectives for Development ................................................................................ 305.1.2 Evidence for Development .................................................................................. 32

5.2 Qualification ..................................................................................................................... 325.2.1 Objectives for Qualification................................................................................. 32

5.2.1.1 Validation Objectives ............................................................................. 335.2.1.2 Verification Objectives ........................................................................... 335.2.1.3 Process Assurance Objectives ................................................................ 355.2.1.4 Configuration Management Objectives .................................................. 35

5.2.2 Evidence for Qualification................................................................................... 36

6.0 Entry into Service 366.1 Objectives for Entry into Service...................................................................................... 366.2 Evidence for Entry into Service........................................................................................ 37

7.0 Operations 377.1 Objectives for Operations ................................................................................................. 37

7.1.1 Continued Operations .......................................................................................... 377.1.2 Development and Qualification of Follow-on Modification ............................... 38

7.2 Evidence during Operations.............................................................................................. 397.2.1 Continued Operations .......................................................................................... 397.2.2 Follow-on Modification....................................................................................... 39

Annex A: Compliance Matrix 40

Annex B: Acronyms & Glossary of Terms and Definitions 51

Annex C: OSED Guidance 62

Annex D: SPR Guidance 81

Annex E: OSA Guidance 85

Annex F: OPA Guidance 100

Annex G: INTEROP Guidance 117

Appendices

Appendix A Committee Membership

Pu-22-Fina.Doc, Page vii, Save date, 14-Oct-00 RTCA SC-189 / EUROCAE WG-53

List of Figures and Tables

Figures

Figure 1-1: Generic Regulatory Framework for Approvals ........................................................................ 2

Figure 1-2: Guidance Material Structure .................................................................................................... 5

Figure 1-3: Relationship of Guidance Material to Standards and Evidence ............................................... 8

Figure 2-1: Process for ATS Supported by Data Communications.............................................................. 9

Figure 2-2: Approval Planning .................................................................................................................. 10

Figure 2-3: Overview of Coordinated Requirements Determination ......................................................... 12

Figure 2-4: Development and qualification of a system element .............................................................. 15

Figure 2-5: RCP/ICP/ACP Development Phases 1..................................................................................... 16

Figure 2-6: Entry into Service.................................................................................................................... 18

Figure 2-7: Operations............................................................................................................................... 20

Figure 4-1: Operational Safety Assessment Hazard Classification Matrix ............................................... 25

Figure 4-2: Hazard Classification and Safety Objectives Relationship..................................................... 26

Figure C.1-1: ATS Supported by Data Communication Operational Environment.................................... 62

Figure C.2.1-1: Clearance Request/Response Operational Service .......................................................... 65

Figure C.3.1.5.1-1: Achieved Transaction Distribution............................................................................. 69

Figure C.3.1.5.2-1: Single Transaction Scenario...................................................................................... 70

Figure C.3.1.5.3-1: Two Overlapping Transactions Scenario ................................................................... 70

Figure C.3.1.5.4-1: Two Non-Overlapping Transactions Scenario ........................................................... 71

Figure E.1.3-1: Concept Model of Operational Environment, the Relationships Among Faults, Failures,Procedural Errors, and Airspace Characteristics, and the Risk Mitigation Strategy ........................ 86

Figure E.3.1-1: Operational Safety Assessment Hazard Classification Matrix .......................................... 90

Figure E.3.1-2: Hazard Classification and Safety Objectives Relationship ............................................... 91

Figure F.5.2.1-1: Transaction Time ......................................................................................................... 108

Figure F.6.1.2.2.5-1: Sample Weibull Plot............................................................................................... 112

Pu-22-Fina.Doc, Page viii, Save date, 14-Oct-00 RTCA SC-189 / EUROCAE WG-53

TablesTable C.3.1.6-1: Information Exchange Requirements.............................................................................. 73

Table F.4.1-1: RCP Set of Parameters..................................................................................................... 101

Table F.4.1.2: Example RCP Type Values Table ..................................................................................... 102

1

Pu-22-Fina.Doc, Page 1, Save date, 14-Oct-00 RTCA SC-189 / EUROCAE WG-53

1.0 Introduction

The International Civil Aviation Organization (ICAO) has introduced the concept of theCommunication, Navigation, and Surveillance/Air Traffic Management System (CNS/ATM).This concept will enable improvements in ATM worldwide through the application of moderntechnologies to new air traffic services (ATS). These ATS include the use of datacommunications between the operators and the ATS providers and will require an allocation ofoperational, functional, technical, and performance requirements to the different elements thatcomprise the system. The system elements when fully integrated into a CNS/ATM system willneed to be qualified for approval to ensure that the system performs as intended and is acceptablysafe.

Because ATS supported by data communications require a high degree of coordination among thestakeholders and approval authorities to ensure compatibility between operator use and ATSprovision, there is a need for State/industry-accepted guidance material on the processes forcoordinating implementation requirements and qualification for different types of approvals.

This guidance material was developed considering the provision and use of ATS supported bydata communications. The term “ATS” is used throughout this document to refer to “ATSsupported by data communications”.

This guidance material is intended for stakeholders and approval authorities involved in theoperational implementation of the provision and use of ATS supported by data communications.Stakeholders are those organizations that have a financial investment in the provision and use ofATS. Stakeholders also include ATS providers, ATS equipment manufacturers, supportingservice providers, such as those that provide communication and weather services, aircraft andequipment manufacturers, and operators; these stakeholders may be identified as applicants in thecontext of this document. Approval authorities are those organizations in control of orresponsible for issuing approvals to any element of the CNS/ATM system.

This guidance material comprises criteria in clear and concise format to enable consistent resultsin its application throughout the world. The guidance material was developed jointly by RTCA,Inc. and the European Organisation for Civil Aviation Equipment (EUROCAE) in considerationof the International Civil Aviation Organization (ICAO) activities and in cooperation with Statesworldwide.

1.1 Purpose

This guidance material provides minimum acceptable criteria for approving the provision and useof an ATS supported by data communications when approvals are required to show compliance tocivil regulations. The criteria are in the form of process objectives and guidance for evidence. Asused throughout this document, evidence is data produced during the accomplishment of theprocess objectives. Evidence can be inspected to show that the objectives have been satisfied.For example, evidence may take the form of standards such as the SPR and INTEROP standards,or plans such as the Approval Plan, or results of verification activities such as test results. Theformulation of related standards and the means to qualify related systems to those standards arediscussed. “Approval” denotes those activities related to ATS provider operational approval,operator operational approval, and aircraft type design approval. These separate and distincttypes of approvals collectively define the conceptual “CNS/ATM system approval.” In cases forwhich there is no regulatory basis for approval of an element of the CNS/ATM system,

2


“approval” denotes the activities that take place to show compliance with the requirementsallocated to that element. See Figure 1-1.

Figure 1-1: Generic Regulatory Framework for Approvals

• operator operational approval is the authorization granted to an operator to use the ATS,aircraft equipage, communication services procured by the operator, and related inter-networks with the ATS provider’s communication services. It is supported by informationprovided by the aircraft type design approval and ATS provider operational approval;

• aircraft type design approval is the approval granted to an aircraft manufacturer or modifier toindicate that the type design of the aircraft equipage complies with applicable airworthinessrequirements. It includes information to support operator operational approval; and

• ATS provider operational approval includes approval of the technical system and thecommunication services procured by the ATS provider. It is granted to an ATS provider forthe provision of ATS within an airspace and includes information to support the operatoroperational approval.

1.2 ScopeThis document provides means to establish the operational, safety, performance, andinteroperability requirements for ATS supported by data communications, to assess their validity,and to qualify the related CNS/ATM system. It is a single source document that provides

Aircraft typedesign approval

ATSprovider

operationalapproval

Operatoroperational

approval

Guidelines forapproval & use of ATS

supported by datacommunications

Generic approvalframework

Standards

3


guidance for approval of the CNS/ATM system and its operation where coordination is necessaryacross organizations. The guidance material considers the allocations of the operational, safety,performance, and interoperability requirements to the elements of the CNS/ATM system. Theseinclude ground-based elements, operational procedures, including human elements, and aircraftequipage.

Other RTCA special committees and EUROCAE working groups may provide guidance materialrelated to human factors, development assurance, and security. This document is intended tosupport such future guidance material.

1.2.1 Assessments that are Not Within the Scope of this DocumentExamples of assessments that are out of the scope for this document include:

• safety assessments related to the disposal of hazardous materials used in test and evaluation,or in technical system development;

• performance assessments related to establishing requirements for optimizing efficiency forATM;

• interoperability assessments related to data communications between two ATS units (ATSU)or between ATSUs and Aircraft Operational Control (AOC) units; and

• occupational health and safety assessments for ATS facility workers.

However, States and organizations that perform such assessments can conduct them in concertwith the activities related to the operational assessments to which this guidance material relates.

1.3 How to Use the Guidance Material and StandardsThis sub-section provides an overview of the guidance material, and how it can be used toproduce standards and other evidence for approval of the provision and use of operationalimplementations of ATS and aircraft equipage. The guidance material and standards are intendedfor use by the aviation community when ATS providers, operators or aircraftmanufacturers/modifiers intend to:

• provide or use new or modified ATS supported by data communications;

• use an existing ATS supported by data communications differently from its original intent; or

• add new functions or technologies, or modify existing functions or technologies to support anexisting ATS.

1.3.1 Guidance MaterialThe guidance material minimizes references to specific national regulations and procedures;instead, generic terms are used. The guidance material is not mandated by law, but represents aconsensus of the aviation community. It also recognizes that alternative means may be availableto the applicant to obtain approval. To aid the use of alternative means, the guidance materialuses the word “should”. However, if an applicant declares this guidance material as means ofcompliance for one of the approval types and it is accepted by the approval authority, then“objectives” are provided in Sections 3 to 7. Guidance on the applicability of the “objectives” to

4


each of the approval types is provided in Annex A. The guidance material may be revised asexperience is gained in using the document.

1.3.1.1 Document Structure

Section 1 describes the purpose and scope of the document, and provides guidance on the use ofthis document and the standards and evidence resulting from its use.

Section 2 describes the processes for approval of the provision and use of ATS supported by datacommunications to which this guidance material applies. These processes are: approval planning,coordinated requirements determination, development and qualification of a system element,entry into service, and operations.

Section 3 provides objectives for approval planning. The evidence for approval planning is theapproval plan and the acceptance of the plan by the approval authority.

Section 4 provides objectives for coordinated requirements determination. The evidence forcoordinated requirements determination is a description of operational services and their intendedoperating environments in an operational services and environment description (OSED) and theoperational, safety, and performance requirements (SPR) standard and interoperabilityrequirements (INTEROP) standard.

Section 5 provides objectives for development and qualification of a system element. Theevidence for development and qualification is data produced by the stakeholder in control of orresponsible for a system element to show that it complies with the requirements allocated to it bythe standards and is capable of operating within an operational CNS/ATM system.

Section 6 provides objectives for entry into service. The evidence for entry into service iscoordinated data that shows one or more system elements integrated into an operationalCNS/ATM system or a complete system will operate as intended.

Section 7 provides objectives for operations. The evidence for operations is the analysis andresolution of in-service problems to ensure that the standards requirements continue to be met.Evidence for operations also includes the analysis for follow-on modification for technical andoperational changes that are made after entry into service to show that the standards requirementscontinue to be met or that the guidelines process needs to be repeated in part or in full.

In addition, sections that provide process objectives (Sections 3 through 7) include guidance forthe evidence that is required to show compliance to the objectives provided within each of thesections.

Annex A provides a summary of the process objectives and related evidence, and indicatesapplicability of each objective to the approval type.

Annex B provides a glossary of terms and acronyms.

Annex C provides guidance and templates for the operational services and environment definition(OSED).

5


Annex D provides guidance and templates for the operational safety and performancerequirements (SPR) standard.

Annex E provides guidance and templates for the operational safety assessment (OSA).

Annex F provides guidance and templates for the operational performance assessment (OPA).

Annex G provides guidance and templates for the interoperability requirements (INTEROP)standard.

Figure 1-2 provides an overview of the structure of the guidance material.

• A cronym s and g lossary te rm s are con ta ined in A nnex B .• G uidance and tem plates fo r coord ina ted requirem ents dete rm ina tion a re prov ided in

rem ain ing annexes.

C oord inatedR equ irem entsD eterm ination

S ec. 4

D evelopm ent &Q ualification

(O rgan izational)S ec. 5 .1& S ec. 5.2

O perationsS ec. 7

A pprovalP lann ing

S ec. 3

E ntry in toserv iceS ec. 6

X .1 D eta ils o f objectives

O bjectives and g u idelines fo r ev idence (M ain bod y)

O b jective

S ectionR eference

fo ro b jective

E vidence

A pproval type

A ircraft typed esign

approval

A TSp rovider

o perationalapproval

O peratoro perational

approval

C om pliance m atrix (A nnex A )

G uidelines fo r app licabilityto approva l types

S ectionR eference

fo rev idence

R eference to de ta ils o f objectives& ev idence w ith sum m ary

In tro duction &D escrip tion o f

P rocessesS ec. 1 & Sec. 2

N arrative

X .2 D eta ils o f ev idence

Figure 1-2: Guidance Material Structure

1.3.1.2 Additional Considerations Using the Guidance MaterialThe following should be noted when using this guidance material:

• each process objective or guideline for evidence provided in this document is assigned aparagraph and sub-paragraph number to facilitate compliance assessment during approval.Annexes are normative parts of this document and include guidance material;

• explanatory text is included to aid the reader in understanding the topic under discussion.Sections 1 and 2 and notes provide explanatory text that does not contain guidance material;

6


• in cases where examples are used to indicate how the guidance material might be applied,either graphically or through narrative, the examples are not to be interpreted as the preferredmethod or best practice; and

• a list of items does not imply the list is all-inclusive.

1.3.2 Operational Services and Environment Definition (OSED) and StandardsOperational descriptions and standards facilitate coordination and allocation of requirements tostakeholders in control of or responsible for elements of the CNS/ATM system. The descriptionsand standards are:

• operational services and environment definition (OSED);

• operational, safety, and performance requirements (SPR) standard;

• interoperability requirements (INTEROP) standard; and

• MOPS/MASPS.

1.3.2.1 Operational Services and Environment Definition (OSED)The OSED is used as the basis for assessing and establishing operational, safety, performance,and interoperability requirements for the related CNS/ATM system. It is developed based on anoperational services and environment information capture process (OSEIC) that coordinates theinformation among stakeholders. The OSEIC captures elements related to a defined CNS/ATMsystem, including aircraft equipage, ATS provider technical system, and communication serviceprovider system. The OSED identifies the ATS supported by data communications and theirintended operational environments and includes the operational performance expectations,functions, and selected technologies of the related CNS/ATM system. The OSED facilitates theformulation of technical and procedural requirements based on operational expectations andneeds and is updated as necessary throughout the coordinated requirements determinationprocess.

1.3.2.2 Operational, Safety, and Performance Requirements (SPR) Standard

An SPR standard is used to coordinate the operational, safety, and performance objectives andallocate requirements for the different approval types. It is developed based on an operationalsafety assessment (OSA) and an operational performance assessment (OPA) of the functions,performance expectations, and characteristics of operational environments needed to support theATS identified in the OSED. The SPR standard identifies the objectives and allocatedrequirements, including the substantiation, for a specific operation. The SPR providestraceability from each requirement to its source, the services, and operating environmentsdescribed in the OSED, and captures the results of the OSA and OPA. An SPR standard can betailored to meet the needs of a particular operational implementation.

1.3.2.3 Interoperability Requirements (INTEROP) StandardAn INTEROP standard is used to provide sufficient information to enable different stakeholdersto develop system elements that are compatible for an operational implementation. It isdeveloped based on an interoperability assessment (IA) of selected functions and technologiesneeded to support the ATS identified in the OSED. An INTEROP standard identifies the

7


technical, interface, and related functional requirements for a specific technology or a mix oftechnologies. The INTEROP provides traceability from each requirement to the functions itsupports, the services, and the operating environments in the OSED. Similar to an SPR standard,an INTEROP standard can be tailored to meet the needs of a particular operationalimplementation.

1.3.2.4 MOPS and MASPS

In most cases, Minimum Operational Performance Standards (MOPS) and Minimum AviationSystem Performance Standards (MASPS) provide performance requirements tailored tocharacteristics of a specific technology. These standards can be used to assess the feasibility of aspecific technology to meet the minimum operational, safety, and performance requirementsdefined in an SPR. These standards do not provide an operational performance basis. Theproduction of MOPS and MASPs are not a part of this guidance material.

1.3.3 Relationships of Guidance Material to Standards and Evidence

The guidance material provides process objectives and guidelines for evidence as they relate toeach of the approval types. It includes templates for the formulation of the OSED, the SPRstandard, and the INTEROP standard. MASPS/MOPS that exist may facilitate the selection oftechnologies during the OSEIC process when information is captured in the OSED.

The OSED, the SPR standard, and the INTEROP standard are the products of coordinatedrequirements determination. They may be applicable to different operational implementationsthroughout the world provided the operational implementations are shown to meet therequirements provided by the standards in the context of the OSED under consideration.However, multiple OSEDs, SPR standards, and INTEROP standards may be developed overtime. The OSED, SPR standard, and INTEROP standard can be tailored to an ATS provider’s, anoperator’s, or an aircraft manufacturer’s/modifier’s specific requirements. They can:

• Select from the OSED the ATS and operating environments appropriate for a particularoperational implementation. Implementers need to qualify only to those requirements thattrace to the ATS selected for the operational implementation;

• use the SPR and INTEROP source traceability to assess the impact in the event the ATS,aircraft equipage, and procedures selected for the operational implementation do not meet theoperational, safety, performance, and interoperability requirements contained in the SPR andINTEROP standards;

• negotiate with approval authorities any deviations, additions, modifications, or clarificationsof the SPR and INTEROP standards via the approval plan and operational specification data;and

• use the SPR standard to determine the basis for safety and performance monitoring duringoperations.

The SPR and INTEROP standards provide the basis for development, qualification, and entry intoservice of one or more elements of the CNS/ATM system, or a complete CNS/ATM system.Evidence is produced as part of development, qualification, and entry into service of a systemelement to support coordination and the approval of the system element and the CNS/ATMsystem. This evidence includes the approval plan, development and qualification data, including

8


the accomplishment summary, and entry into service data. The evidence is used to showcompliance to the SPR and INTEROP standards prior to approval. Additional evidence isproduced during operations and it is used to show that the operational CNS/ATM systemcontinues to comply with the standards and to maintain operational approvals for the ATSprovider and operator.

Figure 1-3 shows the relationships among the guidance material, the OSED, the SPR standard,the INTEROP standard, MOPS/MASPS, and other evidence under control of an applicantresponsible for one of the approval types.

Figure 1-3: Relationship of Guidance Material to Standards and Evidence

2.0 Description of ProcessesThis section describes processes for approval planning, coordination of requirementsdetermination across organizations, development and qualification of CNS/ATM systems at theorganizational level, entry into service, and operations using ATS supported by datacommunications. The processes are shown in Figure 2-1, which also shows the relationshipsamong the guidance material, the OSED, the SPR standard, the INTEROP standard, and otherevidence under control of an applicant responsible for one of the approval types.

Operations

Coordinated Requirements Determination

Operationsdata

SPRstandard

INTEROPstandard

OSED

MOPS &MASPS

GuidanceMaterial

Objectives &guidelines

for evidence

SelectedTechnology

OperationsDescription

Operational, Safety, &Performance Requirements

InteroperabilityRequirements

ATS provider operational approval

Aircraft type design approval

Operator operational approvalPlanning, Development & Qualification

Developmentdata

Qualificationdata

Approval Plan AccomplishmentSummary

Planningdata &

Feedback

Entry into service(Coordinated)

Entry intoservice data

Approved systemelement

(incl. Procedures) &integration test data

Integrationqualification

data

Requirements

Integrationqualification

data

NOTAM

Feedback

Feasibilitydata

9


Figure 2-1: Process for ATS Supported by Data Communications

2.1 Approval Planning

Approval planning is the process of describing the system, establishing the approval basis,proposing the means of compliance, and identifying tasks and schedules for the approval of a newor modified element of the CNS/ATM system related to ATS supported by data communications.Approval planning provides early involvement and commitment of the applicant and the approvalauthorities to agree on the approach for meeting the approval basis. It is intended to formalize theagreements among those provisioning for the ATS, the operators who will use the ATS, theaircraft manufacturers and modifiers, and the approval authorities.

Follow-on implementations of the same or similar ATS in a different area or region of the worldmay consider the work that was previously done in order to reduce the development and approvaleffort. In these cases, the SPR and INTEROP standards, and the evidence for completion fromprevious implementations can provide the basis for approval of the follow-on implementations.Evidence for approval planning includes approval plans and acceptance of the plans from theapproval authorities. When accepted, the approval plan provides the agreed approach betweenthe applicant and the approval authority.

Guidancematerial

ATS provision,aircraft equipage,

& useOperations(Section 7)

CNS/ATM systemEntry into Service

(Section 6)

System ElementDevelopment &

Qualification(Section 5)

Area/regionalCoordinated

RequirementsDetermination

(Section 4)

In-servicedata

Area/RegionalApproval Planning

(Section 3)

Follow-on & Cross-area/regional

Approval Planning(Section 3)

Approvalplans

Acceptanceof plans

Dev & Qualdata

Approval•ATS provision•Aircraft equipage•Operator Operations

Coo

rdin

atio

n fo

r Coo

rdin

ated

Req

uire

men

ts D

eter

min

atio

n &

Ent

ry in

to S

ervi

ce


INTEROPstandard

SPRstandard OSED

Evidence ofapprovalplanninvg

AccomplishmentSummary

FeedbackEvidence

Changes to plan& summary of

completion

Modificationdata

Notificationdata

Standardsdiscrepancies& impact data

10


Figure 2-2 depicts the approval planning process.

Refer to Section 3 for objectives and guidance on evidence for approval planning.

ApprovalPlanning

Evidence of Approval Planning

Approval Plan•Description of system element•Approval basis•Means to coordinate requirements•Means to develop element of the system•Means to qualify element of the system•Means for entry into service•Means for continued operations

Guidelines for provisionand use of ATS

supported by datacommunications

State RegulatoryRequirements

Legend

ProcessEvidence

Externalinputs Feed

forwardflow

Feedbackwardflow

Internaldata flow

Figure 2-2: Approval PlanningNote: The legend in Figure 2-2 also applies to Figures 2-3, 2-4, 2-6 and 2-7.

2.2 Coordinated Requirements DeterminationCoordinated requirements determination establishes requirements that require coordinationamong organizations involved in the development, qualification, operation, and approval of theCNS/ATM system. It consists of the OSEIC, OSA, OPA, and the IA. The OSEIC produces theOSED, which captures service descriptions, operational performance expectations, selectedtechnologies, and characteristics of the intended operational environments. The OSA, OPA, andIA identify, coordinate, allocate, and validate the operational, safety, performance andinteroperability requirements, and update the OSED, as necessary. The operational, safety, andperformance requirements provide the operational basis for the operational implementation andare captured in the SPR standard. The interoperability requirements provide the technologicaland functional basis for the operational implementation and are captured in the INTEROPstandard. The requirements in the standards are allocated to each of the stakeholders in control ofor responsible for an element of the CNS/ATM system.

The OSA, OPA, and IA include the following generic activities in addition to the specific tasksidentified in subsequent guidance.

• Identification of requirements. This activity involves the capture of requirements, whichidentify the operational, safety, performance, and interoperability attributes from the initialOSED;

11


• Coordination of requirements. This activity involves coordination among the stakeholderswhile they perform the appropriate assessments, in order to ensure that requirements thataffect operational, safety, performance, and interoperability are addressed and correctlyintegrated into the OSED, SPR, and INTEROP. Coordination facilitates the validation of theoperational, safety, performance, and interoperability requirements;

• Allocation of requirements. This activity takes the operational, safety, performance, andinteroperability requirements and allocates them to the different stakeholders in control of orresponsible for qualifying an element of the CNS/ATM system; and

• Validation of requirements. This activity ensures that requirements are necessary andsufficient for operational implementation. It may include analysis, simulation evaluations,prototype testing, and operational trials. The requirements provided in the SPR andINTEROP standards are validated during the development of the standards. The validationincludes a consistency check between the requirements specified in the INTEROP standardand the SPR standard and consistency and completeness with the OSED. To support thisvalidation, these standards are typically developed the first time an ATS or technology isimplemented for operations, trials, or prototype development. The SPR and INTEROPstandards are used to establish the basis for developing and evaluating evidence produced insupport of an operational implementation.

The outputs of the coordinated requirements determination process are an OSED, a SPR standard,and an INTEROP standard.

Coordinated requirements determination may be subject to external influences which are beyondthe scope of this document to describe but which are indicated for completeness.

Figure 2-3 provides an overview of the overall coordinated requirements determination process.

Refer to Section 4 for objectives and guidance on evidence for coordinated requirementsdetermination.

12


Figure 2-3: Overview of Coordinated Requirements Determination

Each sub-process of coordinated requirements determination is described below.

2.2.1 Operational Services and Environment Information Capture (OSEIC)

The OSEIC captures, in a systematic and formal way, the operational objectives of the airspaceusers and the ATS providers, in terms of the implementation of ATS supported by datacommunications. All potential applicants including the operators, aircraft modifiers, systemintegrators, equipment designers, ATS providers, communication service providers and approvalauthorities are involved in the OSEIC process. Cost benefit analyses may influence thecoordination process to decide what will be included in the OSED. The information capturedduring the OSEIC process is assessed and validated by the OSA, OPA and IA and may have to bemodified as a result of those assessments to produce an updated OSED.

2.2.2 Operational Safety Assessment (OSA)

The OSA includes an operational hazard assessment (OHA) and an allocation of safety objectivesand requirements (ASOR). The inputs to the OSA are derived from the OSED.

• Operational Hazard Assessment (OHA): The OHA is a qualitative assessment of theoperational hazards associated with the OSED. For the OHA, operational functions areexamined to identify and classify hazards that could adversely effect those functions. Hazardsare classified according to a standardized classification scheme based on hazard severity andtaking into account human factors. Overall safety objectives are assigned to the identifiedhazards.

• Allocation of Safety Objectives and Requirements (ASOR): Based on the OHA results, theASOR allocates safety objectives to organizations, develops and validates risk mitigation

Evidence ofCoordinated


Evidence ofApprovalPlanning

Coordinated RequirementsDetermination

OSED(Updated)

OSA•Identification•Coordination•Allocation•Validation

OSEIC• Captureinformation

• Coordination

IA•Identification•Coordination•Allocation•Validation

OPA•Identification•Coordination•Allocation•Validation

SPR

AllocatedAircraft

Requirements

AllocatedATS ProviderRequirements

AllocatedOperator

OperationalRequirements

Evidence ofAnalysis,

Coordination,& Validation

INTEROP

ExternalInfluences

Approval Plan

Evidence ofOther Processes

(Feedback)

Development& qualification

data

MASPS& MOPS

OSED(Initial)

13


strategies that are shared by multiple organizations, and allocates safety requirements to thoseorganizations. Requirements are allocated over the CNS/ATM system elements that providethe functional capability to perform the service and the stakeholders that develop the variouselements of the CNS/ATM system. Understanding the interactions of the ATS, procedures,and airspace characteristics will assist in the identification of failures, errors, and/orcombinations thereof that contribute significantly to the hazards identified in the OHA. Theallocation may require updating based on feedback from other processes.

• during the OSA planning process agreement on quantitative goals may be set. This may takethe form of agreement on the acceptable likelihood of occurrence for hazards of each severitylevel. This will enable safety objectives and requirements described in the ASOR to be givenquantitative meaning.

2.2.3 Operational Performance Assessment (OPA)The OPA provides methods: to derive or validate Required Communication Performance type(RCP type) from the OSED; to allocate the performance requirements specified by the RCPbetween the technical communications (i.e. Required Communication Technical Performances orRCTP) and human element; and to allocate the RCTP to the organizations. The OPA includes theallocation of transaction performance between the aircraft and ATS provider combined with thecontroller/pilot human factors transaction time to receive/transmit and process message requests.The OPA includes the allocation of performance requirements between the ATS provider andaircraft, which are derived from the OSED.

• Required Communication Performance (RCP) RCP type is a statement of thecommunication performance necessary for operation within a defined airspace. RCTP type isallocated between the human element and the technical element.

- Required Communication Technical Performance (RCTP). The Required CommunicationTechnical Performance (RCTP) is the framework to express the two-way technicalperformance of the communication path proposed to meet an RCP type. RCTP is used toseparate the technical performance of the communication path from the humanperformances. The RCTP is expressed as a set of performance parameters, which reflectsfrom a technical standpoint, the capability of the communication path required to satisfyan RCP type. The RCTP is defined for an entire transaction excluding the human factorwith the same parameters as the RCP type. The RCTP will be allocated to theorganizational domains.

- Human performance. Human performance is a framework to express the humancontribution to the required communication performance. Human performance isexpressed as a set of parameters which reflects the capability of the human performanceof the communication path to satisfy an RCP type. Human performance is defined for aentire transaction excluding the technical contribution with the same parameters as theRCP type.

2.2.4 Interoperability Assessment (IA)The IA reviews the technical, functional, and interface requirements for the defined technologiesand allocates the requirements to different stakeholders and subsequent approval processes. Theallocation is based on the selected technologies and functions defined in the OSED. Thedefinition of interoperability requirements in the scope of the IA is as follows:

14


Interoperability requirements are the minimum technical and functional requirements that providethe basis for ensuring compatibility among the various elements of the CNS/ATM system usingspecific technologies.

Some differences in implementations that can be accommodated by operational procedures maybe acceptable and still be considered interoperable, however there may be limits in the number ofsuch procedures due to operational or safety considerations.

2.2.5 Evidence for Coordinated Requirements DeterminationEvidence for coordinated requirements determination includes the OSED, the SPR standard, andthe INTEROP standard. The evidence for coordinated requirements determination provides thestandards for development and qualification by stakeholders that are building the system elementsthat comprise the CNS/ATM system.

Refer to Section 4 for guidance on evidence for coordinated requirements determination.

Refer to Annex C for guidance and templates on developing an OSED.

Refer to Annex D for guidance on developing an SPR standard.

Refer to Annex E and F for guidance and templates on the OSA and OPA respectively.

Refer to Annex G for guidance on developing an INTEROP standard.

2.3 Development and Qualification of a System ElementDevelopment and qualification of a system element are processes that are performed by eachstakeholder to ensure that their element of the CNS/ATM system is produced with assurance thatoperational, safety, performance, and interoperability objectives and requirements from the SPRand INTEROP standards are met. Considerations include the impact on schedule, effect of theresult on safety, performance, or interoperability, and potential operating constraints.

Figure 2-4 provides an overview of development and qualification of a system element.

Refer to Section 5 for objectives and guidance on evidence for development and qualification.

15


Figure 2-4: Development and qualification of a system element

The following paragraphs describe development and qualification of a system element.

2.3.1 Development

Development produces elements of the CNS/ATM system that meet the requirements of thecoordinated requirements determination process. Elements may take the form of a technicalsystem, which includes only the hardware and software components, or it may take the form ofoperational specification data, which provides the ATS provider and operator information neededto enter into service, provide, and use the ATS. Human factors considerations are involved inboth the technical system and operational specification elements of the CNS/ATM system.

Development also includes system integration of the CNS/ATM elements. Development canresult in feedback to the appropriate coordination process (i.e., coordinated requirementsdetermination or entry into service) of issues that are found to have a multi-organization impact.The acceptability of the element of the CNS/ATM system produced is based on the results ofqualification.

Evidence for development includes system element specifications, design data, the technicalsystem, and operational specifications.

Refer to sub-section 5.1 for objectives and guidance on evidence for development.

Evidence ofQualification

Evidence ofDevelopment



Qualification

Valida-tion

Verifica-tion

Config-urationManage

ment

ProcessAssur-ance

Development

RqmtsCapture

Design Integra-tion

OSED(Updated)

SPR

INTEROP

Systemelement

specification

Design Data

System element(technicalsystem or

procedures) &manuals

Qualificationdata


ApprovalPlan

Evidence ofEntry into

Service(Feedback)


16


2.3.2 Qualification

Qualification ensures that the element of the CNS/ATM system meets the operational, safety,performance, and interoperability requirements. Qualification activities, which addressvalidation, verification, configuration management, and process assurance, include:

• System Element Safety Assessment. This assessment ensures that the element of theCNS/ATM system, which a stakeholder is in control of or responsible for, satisfies the safetyobjectives identified and requirements that have been allocated by the OSA. The assessmenttakes human factors into consideration. The system element safety assessment allowsapplicants flexibility in allocating lower level requirements to satisfy the safety objectivesidentified and requirements allocated by the OSA. An applicant’s safety assessment mayaddress or define safety requirements that are beyond the scope of the OSA.

• System Element Performance Qualification. Qualification of performance takes into accountthe relationship between RCP, RTCP, ICP, ACP, and human performance as follows.

Figure 2-5 graphically shows the RCP, ICP and ACP framework development phases.

Figure 2-5: RCP/ICP/ACP Development Phases 1

Qualification of performance takes into account the relationship between RCP, RTCP, ICP, ACP,and human performance as follows:

• Installed Communication Performance (ICP). ICP is a statement of performance for a givencommunication path which addresses the specific technology used. The ICP excludeshuman factor time and is used to qualify against a given RCTP. For operational approval atotal ICP is qualified against a total RCTP. For qualification or approval of an element of theCNS/ATM system, the ICP component determined or measured for each functional domain isqualified against its respective allocated RCTP. The ICP is expressed in the same parametersas those of the RCTP. The total ICP that is achievable could vary, depending on the aircraft

HumanPerformance

Beginning ofTransaction

ExpirationTime

RCP

RCP Framework

StandardTransaction

OperationalNeeds

RCTP

ICP * Framework

OrganizationalDomains

Design

ICPICPAirborne

ICPComm

ICPATS

Comm ATS

Type DesignApproval

ACP Framework

CurrentOperation

OperationalApproval

HumanACP

Beginning ofTransaction

ExpirationTime

Current

Airborne

*Note: ICP does not include human performance

95% Time 95% Time

Performance

95% Time

Development Phases

ExpirationTime

ICPCombination

17


equipage and ATS provider technical system, including the network and selectedtechnologies.

• Achieved Communication Performance (ACP). ACP is the dynamic measure of theoperational performance of the communication path, with human factors included in themeasure. The ACP is expressed in the same terms and parameters as the RCP, but at anyinstant may vary, depending on environmental, communication, and CNS/ATM systemfailures, and human performance variability. The ACP is compared and evaluated against theRCP. The ACP is a transaction measurement and cannot be allocated. In the case where ACPdoes not meet a specified RCP level, an annunciation may be required.

• System Element Interoperability Qualification. Qualification for interoperability includessystem element conformance to standards, interoperability testing at the functional level,interoperability testing between the aircraft equipage and ATS provider, and systemintegration and interface testing among the elements of the CNS/ATM system.

Evidence for qualification includes validation data, verification data at the system element andsystem integration levels, configuration management data, process and process assurance data.

Refer to sub-section 5.2 for objectives and guidance on evidence for qualification.

2.4 Entry into ServiceEntry into service is the process whereby stakeholders coordinate the results of the developmentand qualification activities performed at the organizational and system integration levels andprepare for operations. In particular, coordinated qualification activity includes assessment of thetotal ICP against RCTP. Each ATS provider and operator provides the operational specificationand procedures data to coordinate and prepare for operation of the CNS/ATM system includingconfiguration management and in-service monitoring. The operational specification data includesoperational qualification requirements that ensure the element of the CNS/ATM system functionsas intended when integrated as part of an operational implementation. These requirements aremet during qualification of the operator to support the operational approval.

The operator is responsible for the integration of the aircraft equipage and its use with the ATSsupported by data communications. The operator provides assurance that, as a minimum, therequirements in the SPR and INTEROP standards are being met for an operationalimplementation.

Evidence for entry into service includes the approval of the technical system elements, approvedoperational specifications, qualification of the CNS/ATM system and promulgation in theAeronautical Information Publication (AIP) and/or NOTAM.

Figure 2-6 depicts the entry into service process.

Refer to Section 6 for objectives and guidance on evidence for coordinating entry into service.

18


Figure 2-6: Entry into Service

2.5 OperationsOperations include the process of ensuring that the operational, safety, performance, andinteroperability objectives and requirements for the ATS and operating environment aremaintained throughout operations. Operations include:

• continued operations, which include:

– analysis and resolution of in-service operational issues reported by the ATS providersand operators. This item includes change management, continued verification,configuration management. Where changes are proposed beyond the originaloperational approval, an impact analysis is conducted to determine the extent to whichthe processes described in this document will be applied.

– addition of new organizations, ATS providers and operators, to the operationalCNS/ATM system.

– maintenance, which ensures that the CNS/ATM system is maintained in accordancewith any maintenance requirements allocated by the SPR and INTEROP standards asnegotiated prior to entry into service.

Entry intoService

(Coordinated)

Evidence of Entryinto Service

Notification ofATS data



procedures)



SPR

INTEROP Evidence ofOperations(Feedback)Operations

data


ApprovalPlan

Integrationqualification datafor CoordinatedRequirementsDetermination

Integrationqualification datafor Development

IntegrationQualification

Prepare forNotification

of ATS

19


– monitoring, which provides creditable operational data to determine that requirementsfor the CNS/ATM system and monitoring as defined in the SPR and INTEROPcontinue to be met. The ACP provides a means to monitor and measure theperformance of the operational system to support operational approvals. The ACP iscompared and evaluated against the RCP. The ACP is a transaction measurement andcannot be allocated. In the case where ACP does not meet a specified RCP level, anannunciation may be required. Monitoring includes data collection on a routine basisand as problems or abnormalities arise. System monitoring is performed byorganizations which provide or use an ATS or are in control of or responsible for anelement of the CNS/ATM system in operation and a data collection point resides withinthat element.

• development and qualification of follow-on modification, includes re-qualification when anyof the operational, safety, performance, and interoperability requirements of the approvedATS are changed or system components are modified. Changes to the CNS/ATM system caninclude changes in procedures, changes to the operational environment, and changes to,including decommissioning of, elements of the CNS/ATM system. Follow-on modificationsmay take various forms, including: Introducing a new ATS (initial or different region). NewATS can be introduced into an airspace by modification of an existing CNS/ATM systempreviously installed or by installing a new system;

– replacing the system or procedures, or parts thereof, with another of similar or differenttechnology or operation to perform the same ATS. The replacement system may beinstalled for a number of reasons including: replacement of obsolescent equipment,improvement of reliability or integrity, in compliance with a regulatory change, or tocorrect problems or abnormalities encountered in operations or to enhance;

– adapting an existing system or procedure to a different ATS; and

– modifying an existing ATS or element thereof. An alteration may result from a changein requirements or desired performance, correction of an implementation error, or anenhancement to equipment reliability.

– introducing organizational changes.

Once the system has passed entry into service, approval of follow-on modification may be neededif the kinds of operation, services, and equipment have changed and the change affects the SPR orINTEROP standards. However, when a change in the operating environment, kind of operation,services, or communications equipment occurs, re-qualification and/or revalidation is performedto the extent that the change impacts the analysis supporting the SPR and INTEROP standards.

Since most highly integrated or complex systems implement multiple functions, it is likely that aspecific modification for such a system would involve more than one of these forms. Suchmodifications would imply a change to the OSED, which, in turn, implies revision or revalidationof the SPR and INTEROP standards. Each stakeholder ensures that it satisfies any newrequirements. When it is necessary, the applicant submits new approval plans.

Evidence for continued operations includes the NOTAMs, monitoring data, configurationmanagement data, and in-service problem analysis and resolution data. The purpose of evidencefor continued operations is to provide information to the approval authority to substantiate thatthe objectives for continued operation are met.

20


Evidence for development and qualification of follow on modifications includes analysis todetermine if any of the operational, safety, performance or interoperability requirements havebeen affected such that re-qualification is necessary. The purpose for evidence for follow-onmodification is to show that the modification does not impact the operation, safety, performance,or interoperability of the initial implementation and that the modification performs as intended.

Figure 2-7 depicts the Operations process.

Refer to Section 7 for objectives and guidance on evidence for operations.



procedures)

Operations

ContinuedOperations

Follow-onmodification

Evidence of Operations

In-service data•Monitoring data•Configuration data•Notification data

Modification data•Modification description•Modification impact data

Evidence of Entryinto Service

Notification ofATS data

Figure 2-7: Operations

3.0 Approval PlanningThis section provides objectives for approval planning and guidelines for related evidence.Approval planning enables applicants (i.e., ATS providers, operators, and aircraft and equipmentmanufacturers/modifiers) to resolve issues early rather than at entry into service and reachagreement on the approval approach with the approval authority.

3.1 Objectives for Approval PlanningFor approval planning, the following objectives should be met:

a) Description of system element. The ATS, related CNS/ATM system, performanceexpectations, selected technologies, and intended operating environments are identified;

1) The element of the CNS/ATM system and its operating environment are identified;

2) The operational functions, system architecture, human/machine interface, includingphysical layout, and relevant operating assumptions are identified; and

21


3) The interface and interactions with other systems are identified;

b) Approval basis. Applicable approval processes and related regulatory requirements andmeans of compliance, including the approval basis, applicable regulatory requirements, otherrelated regulatory material, industry guidelines, standards, or other documents, are identified;

Note: In cases where there is no regulatory basis for a particular element of the CNS/ATMsystem, the regulatory requirements refer to those requirements established by thestakeholder responsible for development and qualification of the element.

c) Related approval plans and their relationship to this approval are identified;

d) Planning for coordinated requirements determination. The means to identify, coordinate,allocate, and validate the operational, safety, performance, and interoperability requirementsare described. Refer to Section 4 for guidance on completing the SPR, INTEROP and relatedOSED;

e) Planning for development. The means to develop the implementation are described. Refer toSub-section 5.1 for guidance on developing an element of the CNS/ATM system andoperational integration and transition;

f) Planning for qualification. The means to qualify the implementation to the requirements aredescribed. Refer to Sub-section 5.2 and section 6 for guidance on qualifying an element ofthe CNS/ATM system for operational integration and transition;

g) Planning for continued operations. The means of monitoring for operational, safety,performance, and interoperability as well as managing the configuration of the system duringoperations are described. Refer to Section 7 for guidance on criteria for establishing andmaintaining a monitoring system for the provision and use of the ATS;

h) Schedule. The schedule for operational implementation is identified and indicates theinteraction between the applicant and the approval authority, including milestones forreviews, evaluations, and data submittals; and

i) Proposal acceptance. Agreements with the approval authorities on the approval plans areobtained:

1) The means for providing evidence showing that the element of the CNS/ATM Systemcomplies with approval requirements are defined, including how approval data will bepackaged, in what form, and how approval data are made available to the approvalauthority. (e.g., Manual for ATS (MATS) supplements, Airplane Flight Manual (AFM),and Operator’s Operational Specifications); and

2) The involvement of the approval authority is defined, including proposals for delegatedauthority.

3.2 Evidence for Approval Planning

The evidence for the approval planning process is the:

22


a) Approval plan. The approval plan provides information to show that the objectives forapproval planning are satisfied; and

b) Acceptance of the plan from the approval authority.

4.0 Coordinated Requirements DeterminationThis section provides objectives for approval coordinated requirements determination andguidelines for related evidence. The coordinated requirements determination process includes theinter-related processes that are coordinated by the stakeholders. These are:

• the OSEIC;

• the OSA, including the OHA and ASOR;

• the OPA, including RCP type determination or evaluation (when directly provided in theOSED), RCTP and human performance determination, and RCTP system elementsallocation; and

• the IA.

4.1 Objectives for Coordinated Requirements DeterminationFor coordinated requirements determination, which includes the OSEIC, OSA, OPA, and IA, thefollowing objectives should be met.

4.1.1 Operational Services and Environment Information Capture (OSEIC)For the OSEIC, the following objectives should be met:

a) Stakeholder identification. Applicants, approval authorities, and stakeholders needed toestablish requirements for the ATS provision, its use, and related CNS/ATM system areidentified;

b) Operational objectives, intentions, and capabilities. The airspace users operational objectivesare defined, ATS providers intentions are defined, and intended operational capabilities aredefined;

c) Air traffic services description. The air traffic services provided by the CNS/ATM systemare defined.

1) The performance expectations of the service are defined;

2) The technologies providing the CNS/ATM system are defined, including technicalchoices and functional characteristics;

3) Dependencies on aircraft equipage are identified;

4) Dependencies on ATS provider technical system automation are identified;

5) Accommodation criteria for legacy systems are identified;

23


6) Operations are described, including:

i) ATS descriptions, including;

ii) procedural requirements;

iii) operational scenarios; and

iv) human factors requirements;

d) Operational environment description. The operational environment for which the services areintended are defined, including;

1) separation minima;

2) route configuration and complexity;

3) type of ATM services;

4) airspace class;

5) traffic characteristic description;

6) traffic rates; and

7) aircraft mix;

e) OSED updates. The OSED is updated from information input from the OSA, OPA, and IA.

4.1.2 Operational Safety Assessment (OSA)

The OSA includes the OHA and ASOR. Objectives for the OSA are provided in terms ofobjectives for the OHA and ASOR respectively.

4.1.2.1 Operational Hazard Assessment (OHA)For the OHA, the following objectives should be met:

a) Operational air traffic services identification. Air traffic services, including functions, asprovided in the OSED are copied into the OHA to serve as its basis;

b) Operational hazard identification. The operational hazards are identified as the loss ormalfunction of the service, including misleading or delayed information.

c) Operational hazard effects identification. The effects of each operational hazard are identifiedby evaluating the services in the environment, including legacy system considerations, for theintended operational capabilities as defined in the OSED. (see Figure 4-1);

d) Operational hazard classification. Each operational hazard is classified according to theseverity of its identified effects using a hazard classification matrix, Figure 4-1. Todetermine hazard severity:

1) assess the effects of the hazard ultimately on the aircraft occupants;

24


2) if the hazard is identified at the service level, then environmental mitigation can be usedto lower the hazard class. The requirements that define the environmental mitigationstrategy should be defined in the SPR; and

3) mitigations within the ATS provided by the CNS/ATM system should not be used tolower the hazard class at the service level.

e) Traceability of operational hazards and effects. The operational hazards and their effects aretraceable to services and environment as defined in the OSED;

f) Safety objectives identification. Overall safety objectives (either qualitative or quantitative)based on the operational hazard classifications are established, Figure 4-2;

g) Candidate safety requirements identification. Candidate requirements established fromenvironmental mitigation strategies are identified. Candidate requirements includeprocedural requirements, as well as aircraft and ATS provider technical system requirementsnot related to the new or modified CNS/ATM system.

25


Hazard Class 1 (most severe) 2 3 4 5 (least severe)Effect onOperations

Normally with hullloss. Total loss offlight control, mid-aircollision, flight intoterrain or high speedsurface movementcollision.

Large reduction insafety margins oraircraft functionalcapabilities.

Significant reductionin safety margins oraircraft functionalcapabilities.

Slight reduction insafety margins oraircraft functionalcapabilities.

No effect onoperationalcapabilities or safety

Effect on Occupants Multiple fatalities. Serious or fatal injuryto a small number ofpassengers or cabincrew.

Physical distress,possibly includinginjuries.

Physical discomfort. Inconvenience.

Effect on Air crew Fatalities orincapacitation.

Physical distress orexcessive workloadimpairs ability toperform tasks.

Physical discomfort,possibly includinginjuries or significantincrease in workload.

Slight increase inworkload.

No effect on flightcrew.

Effect on Air TrafficService

Total loss ofseparation.

Large reduction inseparation or a totalloss of air trafficcontrol for asignificant period oftime.

Significant reductionin separation orsignificant reductionin air traffic controlcapability.

Slight reduction inseparation or slightreduction in air trafficcontrol capability.Significant increasein air trafficcontroller workload.

Slight increase in airtraffic controllerworkload.

Figure 4-1: Operational Safety Assessment Hazard Classification Matrix

26


HazardClass

SafetyObjectives

Extremely ExtremelyProbable Remote Remote Improbable

1

2

3

4

5

Risk Acceptance Cases

Unacceptable Acceptable with Review Acceptable

Acceptable with Review - Unacceptable withSingle Point Failures and Common-Cause Failures

Figure 4-2: Hazard Classification and Safety Objectives Relationship

Figure 4-2 contains three possible safety analysis choices representing different levels ofrisk associated with the operational environment as a whole. These are; Unacceptable(shaded), Acceptable with Review (black), and Acceptable (white). The term‘Acceptable with Review’ merely means that there is an increased level of risk associatedwith this choice which requires an extra measure of review before it can be accepted. Inthis case, parties in the OSA make an informed decision to accept the increased level ofrisk. This choice constitutes a gray area between a level of risk that is clearly‘Acceptable’ and clearly ‘Unacceptable’. For example, consider Hazard Class 3.Reading along the row against Hazard class 3, it can be seen that the Probable category ofsafety objective is Unacceptable while the Extremely Remote and Extremely Improbablecategories of safety objective are Acceptable. The Remote category is Acceptable withReview. The safety goal of Remote may be chosen for this Hazard Category after acareful review of the factors affecting the hazard to which the category 3 designationapplies and making an informed decision regarding the acceptable level of risk.

27


4.1.2.2 Allocating Safety Objectives and Requirements (ASOR)

For the ASOR, the following objectives should be met:

a) Identification of system failure relationships. Identify the relationships of CNS/ATM systemfailures, procedural errors, and the effects on air traffic services to the hazard. Includeidentification of common cause failures or errors occurring among elements of the system.

b) Identification of shared risk mitigation strategy. Identify risk mitigation strategies that areshared by multiple elements of the CNS/ATM system, including mitigation from effects ofcommon cause failures or errors occurring across system elements. CNS/ATM systemmitigation includes architectural and procedural aspects of the system and environmentalmitigation and related candidate safety requirements identified in the OHA.

c) Identification of safety requirements. Determine safety requirements from the shared riskmitigation strategies that satisfy the safety objectives.

d) Allocation of safety objectives and requirements. Allocate the safety objectives andrequirements, including requirements from environmental mitigation, to elements of theCNS/ATM system.

e) Traceability of ASOR results to OHA. Trace the ASOR results to each safety objectiveidentified in the OHA.

f) Shared safety objective and requirement coordination. Coordinate the ASOR results:

1) The impact of the ASOR on the OSEIC and other operational assessments are identifiedand reported to the appropriate process.

2) The impact of the ASOR on development and qualification of system elements areidentified and reported to the appropriate organizations. This impact includes criteria fordetermining development assurance requirements, considering architecture includingdesign features, for reducing the effects of generic design and implementation errors.Criteria for validating the effectiveness of procedural requirements are also provided.

g) Validation of OSA results. Ensure the correctness and completeness of the safety objectivesand requirements, including candidate safety requirements identified during the OHA.

4.1.3 Operational Performance Assessment (OPA)

The OPA includes determination of Required Communication Performance (RCP) type,allocation of RCP type to human (human performance) and technical elements of the system(RCTP), and allocation of RCTP to technical elements of the CNS/ATM system.

Note: The OPA does not provide methods to allocate human performance to the human elementsof the system. However, it is necessary to qualify a human element for approval, and criteria forallocation are negotiated with the approval authority during approval planning.

4.1.3.1 Determination of RCP TypeTo determine RCP type, the following objectives should be met:

28


a) Selection of operational scenarios. Select from the OSED operational communicationtransactions for determining the RCP type for the intended application.

b) RCP type determination. If not defined in the OSED, RCP type is specified according to thefollowing parameters:

1) Transaction expiration time. The maximum time to complete a transaction, after whichpeer parties revert to an alternative procedure;

2) 95% transaction time. The time before which 95% of the transactions is completed;

3) Continuity. The probability that the transaction will be completed before the transactionexpiration time, assuming that the communication system is available when thetransaction is initiated;

4) Availability. The probability that the communication system between the two parties isin service when it is needed; and

5) Integrity. The risk of non-detection of message corruption, or the probability that thetransaction is completed with an undetected error;

c) RCP type evaluation. RCP type is evaluated for the air traffic services in the environments,including legacy systems, as defined in the OSED.

4.1.3.2 Allocation of RCP TypeTo allocate RCP type between human and technical elements of the system, the followingobjectives should be met:

a) Allocation of RCP type to human and technical elements. RCP type parameters are allocatedbetween technical and human performance. The RCTP determines the performancerequirement in order to qualify the technical system elements. The Human Performancecomponent determines a performance level for pilot and controller.

b) Allocation of RCTP to technical elements. RCTP is allocated to the airborne and ATSprovider technical system.

Note: Allocation of RCTP to technical elements supports the different approval types for theelements. Further allocations may be necessary for the network, when provided by adifferent stakeholder than the applicant, and would be qualified for operator operationalapproval or ATS provider operational approval, as appropriate.

c) Evaluation of RCP type allocations. Ensure the correctness and completeness of theperformance allocations based on the RCP type.

d) Traceability of RCP type to operational services. The allocations of RCP type are traceableto the operational services defined in the OSED.

e) Coordination of RCP type allocations. The allocated performance parameters arecoordinated.

29


1) The impact of the OPA on the OSEIC and other operational assessments are identifiedand reported to the appropriate process.

2) The impact of the OPA on development and qualification of system elements areidentified and reported to the appropriate organizations. This impact includes criteria forqualification and monitoring and configuration management for performance of systemelement and the CNS/ATM system.

4.1.4 Interoperability Assessment (IA)The IA defines the interoperability requirements and their allocation across organizationalboundaries.

For the IA, the following objectives should be met:

a) Requirements, rules, constraints. The requirements, basic rules and constraints that arenecessary for interoperability are identified. For new ATS implementations, it should bedetermined whether one or more existing INTEROP standard(s) should be used as a baseline.

b) Compatibility/interface technical requirements. The technical requirements for CNS/ATMsystem compatibility and organization interfaces are identified, including legacy systemconsiderations;

c) Standards references and additional requirements. International and industry standards arereferenced whenever available, and any additional requirements are defined, including:

1) message subsets;

2) changes or deviations from existing standards;

3) selected options;

4) dynamic behavior, and;

5) limitations necessary to achieve interoperability of the system in the operationalenvironment defined in the OSED;

d) Requirements coordination/allocation. The interoperability requirements are coordinated andallocated to the applicable applicant or stakeholder; and

e) Requirements validation and documentation. The interoperability requirements are validatedand documented in INTEROPs (the Interoperability Requirements template in Annex Gprovides an example format).

f) Traceability of interoperability to operational services. The interoperability requirements aretraceable to the operational services defined in the OSED.

g) Coordination of interoperability requirements. The interoperability requirements arecoordinated.

30


1) The impact of the IA on the OSEIC and other operational assessments are identified andreported to the appropriate process.

2) The impact of the IA on development and qualification of system elements are identifiedand reported to the appropriate organizations. This impact includes criteria forqualification and monitoring and configuration management for interoperability ofsystem element and the CNS/ATM system.

4.2 Evidence for Coordinated Requirements DeterminationThe output of the coordinated requirements determination process consists of three data items:

a) OSED;

b) SPR; and

c) INTEROP.

The OSED, the SPR, and the INTEROP provide the evidence that the objectives of thecoordinated requirements process have been met.

5.0 Development and Qualification of a System ElementThis section provides guidance on how to meet objectives and provide the related evidencerequired for the development and qualification processes at the organizational level.Development and qualification of a system element indicates that an applicant is developing orqualifying their own particular element of the CNS/ATM system.

5.1 DevelopmentDevelopment is the process used to produce an element of a CNS/ATM system that meets therequirements of the coordinated requirements determination process. The inputs to thedevelopment process are the OSED, SPR, and INTEROP. Development includes the following:

• requirements capture;

• design; and

• integration.

5.1.1 Objectives for Development For development at the organizational level, the following objectives should be met:

a) System element requirements. System element requirements are captured from the SPR andINTEROP in accordance with the following criteria:

1) requirements allocated to the organizations by the coordinated requirementsdetermination process;

2) safety requirements are highlighted;

3) human/machine interface requirements;

31


4) human qualification requirements (e.g., flight crew, maintenance crew, and air trafficcontrollers); and

5) operational requirements issues, including:

i) the aircraft flight manual and flight manual supplements;

ii) training and maintenance programs;

iii) identification of procedures, highlighting those that are safety related, andnormal/abnormal/emergency checklists;

iv) a means to monitor ACP and compare to RCP and the associated procedures forcorrective action if ACP does not meet RCP; and

v) configuration management of the operational CNS/ATM system;

b) Requirements consistency. Requirements are modified to eliminate ambiguities,inconsistencies, and undefined conditions;

c) Requirements discrepancies. Inadequate or discrepant coordinated requirements, ordeviations from the coordinated requirements, together with their impact on the operationalsafety, performance, and interoperability of the CNS/ATM system are reported back to theappropriate coordination body;

d) Development assurance. Development assurance level assignments for isolated componentsare determined and assigned.

e) Development environment. The development environment is defined, including developmentstandards and tools;

f) Design. Design data are determined from the requirements, and consider:

1) operational, performance, interoperability, and safety-related design;

2) definition of the interface to the CNS/ATM system for which it is intended; and

3) human interface design, including controls, displays, alerts/annunciation, and otherhuman factors design data related to system functionality, performance, andworkstation/flight deck integration, training, maintenance;

4) monitoring provisions; and

5) procedures;

g) Traceability of requirements and design. Requirements and design data are:

1) produced in accordance with development standards and plans;

2) traceable, verifiable, and consistent; and

32


3) provided as input to the appropriate qualification process;

h) Component Integration. The components of the system element are integrated and the systemelement is produced;

i) Training and maintenance. The training and maintenance programs are developed;

j) Transition criteria identification. Transition criteria are defined, including procedures,airspace requirements, and NOTAM;

k) Specify RCP types, safety, and interoperability requirements in operational data. RCP typesand RCTP for the system element are specified in operational specification data, includingreferences to guidance material, SPR, and INTEROP standards; and

l) Operations. The activities and their interrelationships with other activities within theapproval process are defined.

5.1.2 Evidence for Development

Evidence for development should include the following.

a) the system element specification, which provides the results of requirements capture,including development plans, procedures, and standards;

b) the design data, including plans, procedures, and standards;

c) the technical system; and

d) the operational data, including training, operating, and maintenance procedures and manuals.

5.2 QualificationQualification is the process that provides an acceptable level of confidence that the developmentprocess has produced an element of the CNS/ATM system that meets the requirements of thecoordinated requirements determination process.

5.2.1 Objectives for Qualification

For qualification of a system element, the following general objectives should be met:

a) Qualification plans and procedures. Qualification plans and procedures are produced, andqualification is carried out in accordance with the plans and procedures;

b) Approval. Approval is obtained;

c) Approval promulgation. Organizational approvals are promulgated in the AIP withreferences to the applicable OSED, SPR, and INTEROP;

In addition, the following sections provide qualification objectives related to validation,verification, process assurance, and configuration management.

33


5.2.1.1 Validation Objectives

For qualification of a system element, the following validation objectives should be met:

a) Requirements validation. The requirements produced at the organizational level arevalidated;

b) Risk mitigation strategy validation. Risk mitigation strategies which are not shared, andrelated architecture and design for the element of the CNS/ATM system are validated; and

c) Human/machine interface requirements validation. Human/machine interface requirementsare validated. Issues to be considered include:

1) ease of operation;

2) mode confusion;

3) task sharing and distribution of workload within an ATSU or flight deck;

4) adequacy of feedback;

5) the methods used for consideration of realistic human performance, including the effectof error, are defined; and

6) system integration to ensure that the human/machine interface is consistent with theinterface and design of the particular aircraft or ATS provider system in which theelement of the CNS/ATM system is installed.

5.2.1.2 Verification Objectives

For qualification of a system element, the following verification objectives should be met:

a) Verification flight and ground tests. Verification flight and ground tests are performed,including verification of aircraft flight deck interface acceptability;

b) Element verification. The results of the development process are verified against theobjectives and requirements allocated by the coordinated requirements determination process,including the following:

1) the objectives and requirements for the intended operation;

2) the safety objectives and requirements that support shared risk mitigation strategies;

3) operational and technical interoperability requirements for the selected technologies andintended operation are verified;

4) the CNS/ATM system element is verified to have no adverse affect on the operation,safety, and performance aspects of the existing ATS or existing aircraft equipage inwhich it is integrated;

5) development assurance aspects are verified;

34


6) implementation of monitoring requirements is verified;

7) It is verified that ICP has no adverse effect on the operation, safety, and performanceaspects of the existing ATS or existing aircraft equipage in which it is integrated; and

8) ICP meets its requirements;

c) System element safety assessment. The safety assessment activities and theirinterrelationships with other activities within the approval process are defined; this includesthe means to verify allocated requirements and risk mitigation strategies specific to thesystem element, and considers the following:

1) operational hazards being addressed by the applicant, with associated safety objectivesand requirements;

2) verification that these safety objectives and requirements have been met (with referenceto appropriate standards or codes of practices if appropriate);

3) objectives within the system element safety assessment that cannot be met by thatapplicant;

4) assumptions made in the OSA, about the system elements;

5) the list of system element safety assessment specific hazards with associated safetyobjectives and requirements, which have been identified by the applicant, andverification that these safety requirements have been met; and

6) deviations from standards;

d) Installed communication performance (ICP). The performance assessment activities and theirinterrelationships with other activities within the approval process are defined;

e) Verification of operational, performance, and interoperability implementation. The means toverify operation, performance, interoperability implementation of the element of theCNS/ATM system at system integration and its interrelationships with other activities withinthe approval process are defined. The element is verified, considering the following:

1) test organizations (i.e., which participants participate with personnel, test equipment,development systems, or operational systems);

2) test tools (e.g., operationally equivalent, independently developed tools);

3) test schedules;

4) test plans and procedures, including success criteria;

5) objectives within the SPR and INTEROP that cannot be met by those organizations;

6) assumptions made in the SPR and INTEROP about elements of those organizations thathave been identified as being incorrect;

35


7) operating conditions within elements of those organizations that can change and affectthe assumptions made in the SPR and INTEROP about the achievement of theoperational, performance, and interoperability objectives;

8) new assumptions which are made about the other organizations;

9) identified functions allocated to the wrong organizations;

10) identification of OSED, SPR, or INTEROP characteristics and information, orrequirements that need to be monitored before and/or at entry into service;

11) results of monitoring exercises;

12) capability of interoperating with a characteristic ATS provider technical system;

13) capability of ICP to meet applicable RCP and capability that the operator cansatisfactorily operate the technical system in the intended environment; and

14) interoperability is demonstrated through exhaustive, multi-leveled interoperabilitytesting at the component, organizational interface, and CNS/ATM system levels; and

f) Element Integration and transition tests. The objectives and acceptance criteria for flight,ATS provider technical system, and laboratory tests are defined. These tests include meansto validate the element of the CNS/ATM system in the context of the operational, safety,performance and interoperability requirements and to check for adverse effects on othersystem elements and operations;

Note: Refer to Section 6 for qualification objectives for integrating a system element into theoverall CNS/ATM system.

5.2.1.3 Process Assurance ObjectivesFor qualification of a system element, the following process assurance objectives should be met:

a) Adherence to plans. Qualification is performed in accordance with plans and procedures;

b) Feedback from entry into service. The results fed back from the entry into service process areaccounted for; and

c) Discrepancies. Organizational requirements and design are assessed to ensure that theysatisfy the operational, safety, performance, and interoperability aspects of the CNS/ATMsystem, and discrepancies are indicated to the development process;

5.2.1.4 Configuration Management Objectives

For qualification of a system element, the following configuration management objectives shouldbe met:

a) Configuration management. The configuration of the system element is managed throughoutthe development and qualification process; and

36


5.2.2 Evidence for Qualification

Evidence provides proof that the compliance objectives for qualification have been met and thatthe system is suitable for its intended use. This section provides guidance on how to produceevidence to show compliance and to ensure the objectives for development and qualification havebeen met.

Evidence for qualification should include the following.

a) validation plans, procedures, and results;

b) verification plans, procedures, and results;

c) process assurance plans, procedures, and results;

d) configuration management plans, procedures, and results;

e) accomplishment summary

f) approval; and

g) AIP.

6.0 Entry into Service

This section provides objectives and related evidence for entry into service. Entry into service isa coordinated process that:

• Accepts the development and qualification data produced by the stakeholders; and

• Ensures that the elements of the CNS/ATM system have been implemented in accordancewith approved plans, except in cases where deviations, clarifications, or additions have beenidentified and accepted in each of the approvals.

6.1 Objectives for Entry into Service

The operator’s operational approval provides the basis for the use of the CNS/ATM system. Theoperational approval requires the applicant, approval authority and other stakeholders to workcollaboratively. For entry into service, the following objectives should be met:

a) System element demonstration. It is demonstrated that the system element performs asintended and meets the requirements allocated by the SPR and INTEROP, includingdemonstration that ACP meets the RCP types being sought, when operated in the CNS/ATMsystem environment;

b) Issues/deficiencies. Issues or deficiencies, which manifest at operational integration, areidentified;

c) Corrective actions. Corrective action(s) for each issue or deficiency are agreed upon andimplemented; and

37


d) Operation against specifications. The operational CNS/ATM system operates in accordancewith operational specifications.

6.2 Evidence for Entry into Service

The purpose of evidence for entry into service is to show that integration of the elements of theCNS/ATM system operate as defined by the operational specifications. For entry into service, thefollowing evidence should be produced:

a) Element integration verification plans, procedures, and results, including configuration data;

b) Corrective actions agreed upon for issues/deficiencies identified during entry into service;and

c) Accordance verification data

7.0 Operations

This section provides objectives and guidance on evidence required for operations. Theoperations process ensures that system operations continue to satisfy operational, safety,performance, and interoperability requirements while in service. For each applicant, this processconsists of:

• continued operations, including system monitoring and iterative operational safety,performance, and interoperability assessments as internal or external changes are made foradjustments and problem resolution; and

• the development and qualification of follow-on modifications.

7.1 Objectives for Operations

This section provides guidance on the objectives for operations.

7.1.1 Continued Operations

Organizations continually monitor to detect any deviations beyond the granted operationalapproval and coordinate timely and effective corrective action. Where changes are proposedbeyond the original operational approval, an impact analysis is conducted to determine the extentto which the processes described in this document should be applied.

For continued operations, the following objectives should be met:

a) Evaluation. Operations and procedures are continually evaluated;

b) Problem identification. Potential problems are identified early;

c) Problem management. Information concerning identified problems is disseminated tooperators and ATS providers to raise awareness and facilitate problem resolution;

1) status reports are generated on a periodic basis by each applicant; and

38


2) status reports and problem reports are based on data collected and analyzed, including thereason problems or abnormal events occurred.

d) Problem resolution tracking. Problem resolution is tracked;

1) problem resolution is identified, including interim operational procedures andoperating constraints, which mitigate the effects of problems until such time a longerterm solution is implemented;

2) problem resolution is monitored to assure implementation;

3) problem resolution are traceable to the point at which the problem was encountered,their operational implications, and their resolution and are identified and traceable;

4) system performance is assessed; and

5) system testing is authorized and coordinated.

e) Problem resolution. Problems affecting safety or flight operations are resolved in timeframeacceptable to the approval authority. Problem resolution may require:

1) re-training of system operators, revision of training procedures to ensure compliance withexisting procedures, or operational constraints;

2) changes to operational specifications; and

3) changes to systems including design, performance and interoperability.

f) ACP. ACP is monitored and the data is analyzed in regard to the RCP.

g) Configuration changes. Changes to the configuration of the system that impact the SPR andINTEROP requirements are managed per the configuration management procedures definedin operational specification data.

7.1.2 Development and Qualification of Follow-on ModificationFor follow-on modification, the following objectives should be met:

a) Assessment. The modification is assessed as to its impact on the SPR and INTEROPstandards, development and qualification, and the integration into the operationalenvironment;

b) Standards revision. SPR and/or INTEROP standards are revised in accordance with Section4;

c) Development. The modification is developed and qualified in accordance with Section 5; and

d) Integration. The modification is integrated into the operational environment in accordancewith Section 6.

39


7.2 Evidence during Operations

This section provides guidance for evidence produced during operations to support the operator’sand ATS provider’s operational approvals.

7.2.1 Continued OperationsFor continued operations, the following evidence should be produced:

a) Notice to airmen;

b) Monitoring data; and

c) Configuration management data.

7.2.2 Follow-on ModificationFor follow-on modification, the following evidence should be produced:

a) Modification impact assessment, including applicable service data;

b) Data from the development process defining the requirements, design data, and operationalspecification data;

c) Data from the qualification process that shows the change has been implemented correctlyand does not affect existing elements of the CNS/ATM system; and

d) Notification to operators and ATS providers that the modification is operational.

40


Annex A: Compliance Matrix

ObjectiveReference

Objective EvidenceReference

Evidence Approval types

Aircraft type designapproval

ATS provider operationalapproval

Operator operationalapproval

Section 3, Approval Planning3.1.a) Description of

systemelement

3.2.a Approval plan The system element is theaircraft equipage andincludes interactions with theATS provision and intendeduse.

The system element is ATSprovision and includesrelevant third partycommunication services andinternet working capability.

The system element is theATS use and includesrelevant third partycommunication services andinternetworking capability.

3.1.b) Approval basis 3.2.a Approval plan Aircraft use ATS provision ATS use3.1.c) Related

approval plans3.2.a Approval plan Not applicable Not applicable Related to ATS provision

and aircraft equipage3.1.d) Planning for

coordinatedrequirementsdetermination

3.2.a Approval plan ATS provision, aircraftequipage, ATS use.

ATS provision, aircraftequipage, ATS use.

ATS provision, aircraftequipage, ATS use.

3.1.e) Planning fordevelopment

3.2.a Approval plan Aircraft equipage andoperational specification data(e.g., Airplane, FlightManual and supportingreferences)

ATS provision includestechnical system andoperational specifications(e.g., Manual of ATSsupplement

Operational specificationsand supporting material (e.g.,training material)

3.1.f) Planning forqualification

3.2.a Approval plan Aircraft equipage ATS provision ATS provision / aircraftequipage integration andATS use

3.1.g) Planning forcontinuedoperations

3.2.a) Approval plan Aircraft equipage provisionsand operational specificationdata to support operationalmonitoring and configurationmanagement

ATS provision, operationalspecification data

ATS use, operationalspecification data

3.1.h) Schedule 3.2.a) Approval plan Aircraft equipage ATS provision ATS use

41


ObjectiveReference






3.1.i) Proposalacceptance

3.2.b) Acceptance ofthe plan fromthe approvalauthority

Aircraft equipage ATS provision ATS use

Section 4, Coordinated Requirements DeterminationOperational Services and Environment Capture (OSEIC)4.1.1.a)AnnexC.1.2

Stakeholderidentification

4.2.a)AnnexC.3D.2.3D.2.4

OSED Coordinated Coordinated Coordinated

4.1.1.b)Annex C.2

Operationalobjectives,intentions, andcapabilities

4.2.a)AnnexC.3D.2.4


4.1.1.c)Annex C.2C.2

Air trafficservicesdescription

4.2.a)AnnexC.3D.2.4


4.1.1.d)Annex C.2

Operationalenvironmentdescription

4.2.a)AnnexC.3D.2.4


4.1.1.e)Annex C.2

OSED updates 4.2.a)AnnexC.3D.2.4


42


ObjectiveReference






Operational Safety Assessment (OSA)Operational Hazard Assessment (OHA)4.1.2.1.a)AnnexE.3.1

Operational airtraffic services

4.2.b)Annex D.2

SPR Coordinated Coordinated Coordinated

4.1.2.1.b)AnnexE.3.1

Operationalhazardidentification

4.2.b)Annex D.2


4.1.2.1.c)AnnexE.3.1

Operationalhazard effectsidentification

4.2.b)Annex D.2


4.1.2.1.d)AnnexE.3.1

Operationalhazardclassification

4.2.b)Annex D.2


4.1.2.1.e)AnnexE.3.1

Traceability ofoperationalhazards andeffects

4.2.b)Annex D.2


4.1.2.1.f)AnnexE.3.1

Safetyobjectiveidentification

4.2.b)Annex D.2


4.1.2.1.g)AnnexE.3.1

Candidatesafetyrequirementsidentification

4.2.bAnnex D.2


4.1.2.1.hAnnexE.3.1

Traceability ofoperationalhazards effects

4.2.bAnnex D.2


4.1.2.1.iAnnexE.3.1

Safetyobjectivesidentification

4.2.bAnnex D.2


43


ObjectiveReference






4.1.2.1.jE.3.1

Candidatesafetyrequirementsidentification

4.2.bAnnex D.2


Allocating Safety Objectives and Requirements (ASOR)4.1.2.2.AnnexE.3.2.a

Identificationof systemfailurerelationships

4.2.bAnnex D.2


4.1.2.2.AnnexE.3.2.a

Identificationof shared riskmitigationstrategy

4.2.bAnnex D.2


4.1.2.2.cAnnex E.3.2

Identificationof safetyrequirements

4.2.bAnnex D.2


4.1.2.2.dAnnexE.3.2

Allocation ofsafetyobjectives andrequirements

4.2.bAnnex D.2


4.1.2.2.eAnnexE.3.2

Traceability ofASOR resultsto OHA

4.2.bAnnex D.2


4.1.2.2.fAnnexE.3.2

Shared safetyobjective andrequirementcoordination

4.2.bAnnex D.2


4.1.2.2.gAnnexE.3.2

Validation ofOSA results

4.2.bAnnex D.2


44


ObjectiveReference






Operational Performance Assessment (OPA)Determination of RCP Type4.1.3.1.a)Annex F.3

Selection ofoperationalscenarios

4.2.bAnnex D.2


4.1.3.1.b)Annex F.4

RCP TypeDetermination

4.2.bAnnex D.2


4.1.3.1.c)Annex F.4.

RCP typeevaluation

4.2.bAnnex D.2


Allocation of RCP Type4.1.3.2.a)Annex F.5

Allocation ofRCP Type tohuman andtechnicalelements

4.2.bAnnex D.2


4.1.3.2.b)Annex F.6

Allocation ofRCTP totechnicalelements

4.2.bAnnex D.2


4.1.3.2.cAnnex F.6

Evaluation ofRCP typeallocations

4.2.bAnnex D.2


4.1.3.2.dAnnex F.7

Traceability ofRCP type tooperationalservices

4.2.bAnnex D.2


4.1.3.2.eAnnex F.7

Coordinationof RCP typeallocations

4.2.bAnnex D.2


Interoperability Assessment (IA)4.1.4.a) Requirements,

rules,constraints

4.2.cAnnex G

INTEROP Coordinated Coordinated Coordinated

45


ObjectiveReference






4.1.4.b) Compatibility/interfacetechnicalrequirements

4.2.cAnnex G


4.1.4.c) Standards,references andadditionalrequirements

4.2.cAnnex G


4.1.4.d) Requirementscoordination/allocation

4.2.cAnnex G


4.1.4.e) Requirementsvalidation anddefinition

4.2.cAnnex G


4.1.4.f) Traceability ofinteroperability tooperationalservices

4.2.cAnnex G


4.1.4 g) Coordinationofinteroperability requirements

4.2.cAnnex G


Section 5, Development and qualification of a system elementDevelopment5.1.1.a) System

ElementRequirements

5.1.2 a) Systemelementspecification

aircraft equipage ATS provider technicalsystem and procedures

Procedures and network asappropriate

5.1.1.b) Requirementsconsistency

5.1.2 a) Systemelementspecification



46


ObjectiveReference






5.1.1.c) Requirementsdiscrepancies

5.1.2.a) Systemelementspecification



5.1.1.d) Developmentassurance




5.1.1.e) Developmentenvironment




5.1.1.f) Design 5.1.2.b) Design data aircraft equipage ATS provider technicalsystem and procedures


5.1.1.g) Traceability ofrequirementsand designdata

5.1.2.a)5.1.2.b)

Systemelementspecificationand designdata



5.1.1.h) ComponentIntegration

5.1.2.c) Technicalsystem

aircraft equipage ATS provider technicalsystem

network, as appropriate

5.1.1.i) Training andmaintenance

5.1.2.d) Operationaldata

operational specification datato support operator trainingand maintenance

ATS provision, operationalspecification data

ATS use, operationalspecification data

5.1.1.j) Transitioncriteriaidentification


N/A Provide transition criteria Provide supporting data

5.1.1.k) Specify RCPtypes, safety,andinteroperabilityin operationaldata


AFM ATS operating manuals Operational specifications

5.1.1.l) Operations 5.1.2.a)5.1.2.b)

Plans andprocedures



47


ObjectiveReference






Qualification5.2.1.a) Qualification

plans andprocedures

5.2.2 a)5.2.2.b)5.2.2.c)5.2.2.d)5.2.2.e)

plans andprocedures forvalidation,verification,processassurance andconfigurationmanagementAccomplish-ment summary



5.2.1.b) Approval 5.2.2 f) From approvalauthority

Type design ATS provider Operations Operator Operations

5.2.1.c) Approvalpromulgation

5.2.2 g) From approvalauthority

Not required Provide supporting data Provide supporting data

Validation5.2.1.1 a) Requirements

validation5.2.2 a) Validation

resultsaircraft equipage ATS provider technical

system and proceduresProcedures and network asappropriate

5.2.1.1.b) Riskmitigationstrategyvalidation

5.2.2 a) Validationresults



5.2.1.1 c) Human/machine interfacerequirementsvalidation

5.2.2 a) Validationresults


N/A

Verification5.2.1.2 a) Verification

flight andground tests

5.2.2 b) Verificationresults



5.2.1.2 b) Elementverification

5.2.2.b Verificationresults



48


ObjectiveReference






5.2.1.2 c) Systemelement safetyassessment




5.2.1.2 d) Installedcommunicationperformance




5.2.1.2 e) Verification ofoperational,performanceandinteroperabilityimplementation




5.2.1.2 f) Elementintegration andtransition tests

5.2.2.b Verificationplans,procedures andresults



Process Assurance5.2.1.3 a) Adherence to

plans5.2.2.c)5.2.2.e)

ProcessassuranceresultsAccomplish-ment summary



5.2.1.3 b) Feedback fromentry intoservice

5.2.2 evidence forqualification

aircraft equipage andsupporting operational data

ATS provider technicalsystem and procedures


5.2.1.3 c) Discrepancies 5.2.2 Evidence forqualification



Configuration Management5.2.1.4 a) Configuration

Management5.2.2.d) Configuration

managementresults



49


ObjectiveReference






Entry into service6.1.a) System

elementdemonstration

6.2.a) Elementintegrationverificationplans,procedures,results

demonstrated in arepresentative environment(i.e., an environment that isindependently developed andoperationally equivalent) andthat operator operationalelements are demonstrated inthe actual environment

demonstrated in arepresentative environment(i.e., an environment that isindependently developed andoperationally equivalent) andthat operator operationalelements are demonstrated inthe actual environment

Demonstrated in theenvironment as defined bythe operational specification

6.1.b) Issues/Deficiencies

6.2.a) Elementintegrationverificationresults


ATS provision, includingoperational data and networkas appropriate

ATS use, includingoperational specifications,network, andinternetworking, asappropriate

6.1.c) CorrectiveActions

6.2.b) Correctiveactions


ATS provision, includingoperational data and networkas appropriate


6.1.d) Operationagainstspecifications

6.2.c) Accordanceverificationdata

Not applicable ATS provision, includingoperational data and networkas appropriate


Operations - Continued OperationsSystem Monitoring7.1.1 a) Evaluation 7.2.1.a) Notice to

airmenNot applicable ATS provision ATS use

7.1.1.b) Problemidentification

7.2.1.a) Notice toairmen

Not applicable ATS provision ATS use

7.1.1.c) Problemmanagement

7.2.1.b) Monitoringdata

Not applicable ATS provision ATS use

50


ObjectiveReference






7.1.1.d) Problemresolutiontracking

7.2.1.c) Configurationmanagement

Not applicable ATS provision, includingnetworking

ATS use, including networkand internetworking asappropriate

7.1.1.e) Problemresolution

7.2.1.c) Configurationmanagementdata

When problem resolutionaffects aircraft equipage

ATS provision, includingnetworking


7.1.1.f) ACP 7.2.1.b) Monitoringdata



7.1.1.g) Configurationchanges

7.2.1.c) Configurationmanagement



Operations - Development and Qualification of Follow-on Modification7.1.2.a) Assessment 7.2.2.a) Modification

impactassessment

CNS/ATM system, includingATS provision and use

CNS/ATM system, includingaircraft equipage and use

CNS/ATM system, includingaircraft equipage, provision,and use

7.1.2.b) Standardsrevision

7.2.2.b) Developmentprocess data

CNS/ATM system, includingATS provision and use

CNS/ATM system, includingaircraft equipage and use

CNS/ATM system, includingaircraft equipage, provision,and use

7.1.2.c) Development 7.2.2.b)7.2.2.c)

Developmentandqualificationprocess data

Aircraft equipage ATS provision, includingnetwork

ATS use, including networkand internetworking

7.1.2.d) Integration 7.2.2.d) Notification ofmodificationoperational

Representative ATSprovision and use

Representative aircraftequipage

Actual use as defined by theoperational specification

51


Annex B: Acronyms & Glossary of Terms and Definitions

ACRONYMS

ACAS Airborne Collision Avoidance SystemACL ATC ClearancesACM ATC Communications ManagementACP Achieved Communication PerformanceADS Automatic Dependent SurveillanceADS Automatic Dependent SurveillanceADS-B Automatic Dependent Surveillance-BroadcastAFM Aircraft Flight ManualAFTN Aeronautical Fixed Telecommunications NetworkAIDC Air Traffic Services Interfacility Data CommunicationAIP Aeronautical Information PublicationALRS Alerting ServiceAMC ATC Microphone CheckAMSS Aeronautical Mobile Satellite SystemAOC Aircraft Operational ControlASOR Allocation of Safety Objectives and RequirementsATC Air Traffic ControlATM Air Traffic ManagementATN Aeronautical Telecommunication NetworkATS Air Traffic Services.ATSC Air Traffic Services CommunicationATSU Air Traffic Service UnitCAP Controller Access Parameters serviceCMA Context Management ApplicationCNS/ATM Communication, Navigation, Surveillance/Air Traffic ManagementCPC Controller Pilot CommunicationsCPDLC Controller Pilot Data Link Communication applicationDLIC Data Link Initiation CapabilityFIR Flight Information RegionFIS Flight Information Service.FRC Flight Plan (Route) ConformanceGNSS Global Navigation Satellite SystemIA Interoperability AssessmentICAO International Civil Aviation OrganisationICP Installed Communication PerformanceISO International Organization for StandardizationMASPS Minimum Aviation System Performance StandardsMOPS Minimum Operational Performance StandardsOHA Operational Hazard AssessmentOICS Operational Implementation Conformance StatementsOPA Operational Performance AssessmentOSA Operational Safety AssessmentOSED Operational Services and Environment DefinitionOSEIC Operational Service Environment Information Capture process

52


PICS Protocol Implementation Conformance StatementsPIRG Planning and Implementation Regional GroupRCP Required Communication PerformanceRCTP Required Communication Technical PerformanceRNP Required Navigation PerformanceRSP Required Surveillance PerformanceSESA System Element Safety AssessmentsSPR Safety and Performance Requirements

GLOSSARY

Term Definition / Description

AAchievedCommunicationPerformance(ACP)

A dynamic measure of the operational performance of the communicationpatch, with human factor included in the measure and is used to qualifyagainst an RCP.

Air NavigationSystem

The aggregate of organizations, people, infrastructure, equipment,procedures, rules and information used to provide to Airspace Users AirNavigation Services in order to unsure the safety, regularity and efficiencyof air navigation.

Air TrafficControl (ATC)

A service provided for the purposes of: a) preventing collisions: 1)betweenaircraft, and 2)on the maneuvering area between aircraft and obstructions;and b)expediting and maintaining an orderly flow of traffic.

Air TrafficManagement(ATM)

The aggregation of functions, comprising variously those of Air TrafficServices, Airspace Management, Air Traffic Flow Management includingtheir interacting airborne functional capabilities, required to ensure the safeand efficient movement of aircraft during all phases of operations.

Air Traffic ServiceUnit (ATSU)

A generic term meaning variously, air traffic control unit, flightinformation center or air traffic services reporting office.

Air TrafficServices (ATS)

A generic term meaning variously, flight information service, alertingservice, air traffic advisory service, air traffic control service (area controlservice, approach control service or aerodrome control service) and airtraffic management.

Aircraft equipage The aircraft technical system comprising the hardware and software.AircraftOperationalControl (AOC)

AOC applications provide safety related services for routine operationalcontrol which includes weather information, flight plans, companyoperational communications, and connecting flight information; emergencywhich includes in-flight emergency communications and special medicalrequests; and aircraft maintenance which includes the delivery of engine,avionics, and airframe information to expedite maintenance services.

AircraftOperationalControl Unit(AOCU)

A facility that provides services required for the exercise of authority overthe initiation, continuation, diversion or termination of a flight in theinterest of the safety of the aircraft and the regularity and efficiency offlight.

53


Term Definition / DescriptionAirspace Any portion of the atmosphere sustaining aircraft flight and which has

defined boundaries and specified dimensions. Airspace may be classifiedas to the specific types of flight allowed, rules of operation, and restrictionsin accordance with ICAO standards or State regulation (also see ATSairspace.)

AirspaceCharacteristic

Airspace attribute that is strategic in nature and may contribute toproviding a mitigation strategy. Usually constrained by airspace structure,traffic density, separation minima and other factors affecting theapplication of tactical procedures.

Allocation ofSafety Objectivesand Requirements(ASOR)

Process (and corresponding document) which allocates the safetyobjectives and related requirements, and identifies and validates the riskmitigation strategies that are shared.

Applicant An organization applying for regulatory approval.Approval A document by which an authorized body, acting within a legislative

framework, gives formal recognition that a product, process orservice/operation conforms to applicable requirements

ApprovalAuthority

The relevant and competent body designated by a State, responsible for thesafety regulation of civil aviation (or of element of it) and concerned withthe verification of compliance with applicable requirements.

Approval Plan A document submitted by the applicant to the approval authority thatdefines the means by which the element of the CNS/ATM system beingconsidered complies with the applicable requirements and can bedemonstrated to function as intended. In some cases, this Plan will need tobe submitted to multiple Approval Authorities.

Approval Process A process by which an authorized body, acting within a legislativeframework, gives formal recognition that a product, process orservice/operation conforms to applicable regulatory requirements.

ATSCommunication(ATSC)

Communication related to air traffic services including voice and data..This communication involves one or more air traffic service providers.This term is used for purposes of address administration.

ATS facilities The engineered systems and sub-systems the functions of which directlysupport the provision of the ATS services.

ATS FacilitiesNotification (AFN)

A data link application used by FANS 1/A for the establishment of datacommunications.

ATS Provider An Appropriate ATS Authority in a given airspace.ATS ProviderSystem

The total ATS provider system including the technical system andoperational procedures.

ATS supported bydatacommunications

Air Traffic Services that are supported by elements of the data linkapplications.

AutomaticDependentSurveillance (ADS)

A technique in which aircraft automatically provide, via a data link, dataderived from on-board navigation and flight management, includingaircraft identification, four-dimensional position, intent predictions andadditional data as appropriate.

54


Term Definition / DescriptionAutomaticDependentSurveillance-Broadcast (ADS-B)

ADS-B is a surveillance function transmitting parameters, such as position,track and ground speed, via a broadcast mode data link, and at specifiedintervals, for utilization by any air and/or ground users requiring it.

Availability Availability criteria refer to the criteria associated with loss of the function,system, and equipment. For example, the effects of indefinite loss of anelement of an ATS data link application are classified during the safetyassessment. Depending on design constraints and assumptions made aboutthe operational environment, loss of an element of an ATS data linkapplication for more than a specified period of time (e.g., 30 minutes) maybe the failure condition considered.

BCCapacity Number of aircraft allowed to enter into a specified portion of the airspace

or to proceed to specified aerodromes within a given period of time.Certification Certification means the legal recognition that a product, service,

organization, or person complies with the applicable requirements. Suchcertification comprises the activity of technically checking the product,service, organization or person, and formal recognition of compliance withthe applicable requirements by issue of a certificate, license, approval, orother documents as required by national laws and procedures.

CNS/ATM System The hardware and software that make up the communication, navigationsurveillance and associated air traffic management functions, services andprocedures.

Common CauseFailure

Event or failure which bypasses or invalidates redundancy orindependence.

CommunicationService Provider

Organization, which provides service in delivery of data and/or voicecommunication.

Compliance The methodology for determining that requirements have been satisfied.ContextManagement

An ATN application that provides a service allowing initial aircraft logonto the ATN. The logon service allows indication of all data linkapplications on the aircraft including CM itself. CM also allows the groundsystem to identify its data link capability, to update this information, torequest an aircraft to logon to a specified ground system and includesfunctionality to forward addresses between ATS units.

Continuity The probability of a system to perform its required function withoutunscheduled interruptions during the intended period of operations.

Controller PilotCommunications(CPC)

In a controlled airspace, continuous listening watch on the appropriateradio frequency (either manual or automatic with signaling devices) andestablishment of two-way communication with the appropriate air trafficcontrol (ATC) unit.

Controller PilotData LinkCommunications(CPDLC)

A data link application that provides a means of communication betweencontroller and pilot, using data link messages and responses for ATCcommunications.

55


Term Definition / DescriptionCoordination Inter- and intra organizational communications to:

- achieve mutual understanding on safety-related issues and common work- build confidence and consistency in hypotheses and assumptions- ensure the adequate level of safety assessment activity

CoordinatedRequirementsDetermination(CRD)

The process of identification, coordination, allocation and validation theoperational, safety, performance and interoperability requirements.

DData Authority A ground system that provides for the establishment and maintenance of a

CPDLC transport connection with an aircraft. The transfer ofcommunication from the current data authority to the next data authority isprepared prior to the actual data link switch by designating a next dataauthority in a specific CPDLC message.

Data LinkApplication

A data link application is the implementation of data link technology toachieve specific CNS/ATM operational functionality. For example, in thiscontext of addressed data link the current applications include, ADS,CMA/DLIC, CPDLC, DFIS, and AIDC.

Data link Messageor report

A unit of user-data which is conveyed from an originator of the data to oneor more recipients of the data.

Data Link System The data link system comprises the aircraft data link system, one or moreof the air/ground sub-networks, and the ground data link system includingone or more communication service providers and ATS providers. Thedata link system includes peer data link applications in the air and groundend systems.

DevelopmentAssurance

All those planned and systematic actions performed to minimize genericerrors during development and implementation, and provide confidencethat the system is suitable for its intended use.

DLIC Data Link Initiation Capability is part of the CMA data link application.Domain A bounded system or an operational area boundary within a specified

environment. Operational domains include surface, terminal area, en-routeand oceanic.

EElement of theCNS/ATM System

An element of the CNS/ATM System is represented by any of theconstituent part of the CNS/ATM System, including any part of theexternal and internal interface.

End System (ES) A system that contains the OSI seven layers and contains one or more enduser application processes.

End to End Pertaining or relating to an entire communication path, typically from (1)the interface between the information source and the communicationsystem at the transmitting end to (2) the interface between thecommunication system and the information user or processor or applicationat the receiving end.

End-to-EndTransfer Delay

The period elapsed from the time at which the originating user initiates thetriggering event until the time the transmitted information has beenreceived by the intended end user.

56


Term Definition / DescriptionEnvironment The conditions, circumstances, and influences surrounding and affecting

the air traffic services. The environment excludes the new air trafficservices being introduced and assessed.

Estimated Time ofArrival (ETA)

The time at which it is estimated that the aircraft will arrive over adesignated point or at a destination.

Event An occurrence whose origin is distinct from the aircraft, such asatmospheric conditions, runway conditions, cabin and baggage fires. Theterm is not intended to cover sabotage. [ref: ARP 4761, AMJ 25.1309]

Event Report. An ADS report that is triggered by exceeding a defined parameter.Evidence A set of proof used to demonstrate completion of a process or compliance

with applicable requirements. As used throughout this document, evidenceis data produced during the accomplishment of the process objectives.Evidence can be inspected to show that the objectives have been satisfied.Evidence may take the form of standards such as the SPR and INTEROPstandards, or plans such as the Approval Plan, or results of verificationactivities such as test results. Evidence will need to provided in a logicalordered manner, preferably with a summary of what is included.

FFailure A loss of function, or malfunction, of a system or part thereof resulting in

the inability of an item to perform its intended function. Analysis thatfocuses on functions and their failure modes is a valuable tool. However,fatal accidents can and have been caused by a unit functioning as designedwithout failing to meet its design requirements.

Figure of Merit(FOM)

An indication of the level of accuracy of positional information given in anADS report.

Flight Plan Specified information relative to an intended flight or portion of a flight ofan aircraft. Note: Specifications for flight plans are contained in ICAOAnnex 2.

FunctionalCapability

An attribute of a system such as communications, navigation orsurveillance

GGround EarthStation (GES)

An earth station in the fixed satellite service, or, in some cases, in theaeronautical mobile-satellite service, located at a specified fixed point onland to provide a feeder link for the aeronautical mobile-satellite service.Note: This definition is used in the ITU’s Radio Regulations under the term“aeronautical earth station.” The definition herein as “GES” for use in theSARPs is to clearly distinguish it from an aircraft earth station (AES),which is a mobile station on an aircraft.

Ground/SpaceSystemCommissioning

Ground/space system commissioning describes the process(es) that serviceproviders and certification authorities use to commission an air/ground sub-network, ground data link system, or ground application for operationalservice in accordance with established requirements (e.g., FAA Orders andDirectives, 14 CFR parts 170 through 191, international and federaltelecommunication regulations, and other requirements, if the certificationauthority comprises the air traffic services, the airways facilities services,system development services, and other participating services of the FAA).

57


Term Definition / DescriptionGround-groundApplication

A data link application that has both of its peer applications on the groundsuch as AIDC.

HHazard A situation which has the potential to lead to harm.HazardClassification

Hazard class gradation ranging from 1 (most severe) to 5 (least severe),which takes into account the hazard’s effects on operations.

IInstalledCommunicationPerformance

A statement of performance for a given communication path which reflectsthe technology used. ICP excludes human factor time and is used to qualifyagainst a total RCTP.

Integrity Integrity describes the characteristics of a function indicating a level ofconfidence that the function will perform as intended under all operatingscenarios. For example, validating the safety requirements for the systemdesign and ensuring that the implementation satisfies those requirementsprovide integrity for the system.

Internetwork A set of interconnected, logically independent heterogeneous sub-networks. The constituent sub-networks may be administrated separatelyand may employ different transmission media.

Interoperability Compatible operation of all the elements of an integrated system.InteroperabilityAssessment

The basis for defining interoperability requirements and their allocationacross the organizations involved in the implementation of the distributedCNS/ATM system in a particular operational environment as defined in theOSED.

InteroperabilityRequirements

Interoperability requirements are the minimum technical and functionalrequirements that provide the basis for ensuring compatibility among thevarious elements of the CNS/ATM system using specific technologies.

JKLMMessage Basic unit of user information exchanged between an airborne application

and its ground counterpart or between two ground applications. Messagesare passed in one or more data blocks from one end user to another throughthe data link.

Mitigation The means by which risk can be lowered to an acceptable level asdetermined by the safety objective.

NNOTAM A notice containing information concerning the establishment, condition or

change in any aeronautical facility, service, procedure or hazard, the timelyknowledge of which is essential to personnel concerned with flightoperations.

OOperationalApproval

Process by which an authorization is given to an applicant to operate asystem, sub-system or component approved for an operational ATSsupported by data link. Approval may also grant the ability for thatapplicant to carry out modifications to the approved system, sub-system orcomponent within regulatory guidelines.

58


Term Definition / DescriptionOperationalCapability

Defines the needs of airspace users and service providers, usuallyaccording to cost/benefit, schedule, technological feasibility, and safety.Its scope is such that the requirements to attain the operational capabilitycan be analyzed. Used interchangeably with operational objective.

OperationalEnvironment

The operational environment consists of the airspace characteristics, trafficcharacteristics, air traffic services, and technical characteristics includingair/ground sub-network, the ground data link system, and the air/groundapplications for a particular operational implementation.

OperationalHazardAssessment

A qualitative assessment of the operational hazards associated with theOSED.

OperationalObjectives

Goals defined by the airspace planners and operators relating to the safeand efficient use of the airspace. Operational objectives are realizedthrough a set of operational requirements to enable the objectives to bemet.

OperationalPerformanceAssessment (OPA)

A framework for assessing the necessary co-ordination to establish,validate and allocate performance objectives and high level requirementsneeded to attain a particular operational capability in a defined OperationalEnvironment.

OperationalProcedures

Written procedures and instructions used by ATC personnel and pilots inthe pursuance of their duties directly in connection with the provision anduse of the ATS services.

OperationalRequirements

A statement of the operational attributes of a system needed for theeffective and/or efficient provision/use of ATS to meet the operationalobjectives.

Operational SafetyAssessment (OSA)

A framework for assessing the necessary co-ordination to establish,validate and allocate safety objectives and requirements among the variouselements of the CNS/ATM system and operational environment.

OperationalServices andEnvironmentDefinition (OSED)

Document that defines the characteristics that form the descriptive basis ofoperations relevant for assessing the safety of operations for currentconditions or conditions under which the system will be used. Theenvironment definition is used in conjunction with the Operational Safety,Performance and Interoperability Assessment Methodology in the processof developing objectives.

OperationalServices andEnvironmentInformationCapture (OSEIC)

The process of capturing the operational objectives of the operators and theATS providers.

Operations Phase of the life cycle which includes operating, maintaining, monitoringand changing the system after its entry into service till it is phased out.

Operator An airspace user.Organization In the context of this document an organization is any party involved in the

development, qualification or approval of ATS supported by datacommunications.

59


Term Definition / DescriptionOrganizationalBoundary

Delineates span of control of each State/organization within a CNS/ATMsystem, and identifies the elements of the operational environment toprovide an operational capability and any other aspect necessary tocommission and/or certify an air traffic service.

PPerformance Describes the characteristics of the data link system and applications

associated with the functionality and capabilities of the data link system orapplication, regardless of its availability and integrity. For example,message length, time to process a data link message, memory capacity, andoperational features are measures of performance.

PerformanceRequirements

Set of requirements that define a function’ s performance, and expressed bya set of characteristics/attributes associated to all or part of a system. Thoseinclude transaction and expiration times, continuity, availability andintegrity risk characteristics.

Priority (P) The relative importance of a particular message/protocol data unit (PDU)relative to other message/PDUs in transit and used to allocate resourceswhich become scarce during the transfer process.

Procedural Error Occurrence arising as a result of incorrect action by a human associatedwith the CNS/ATM system.

Profile (Data link) Defines implementation conformance constraints on a set of referencespecifications.

Profile (FlightPlan)

The four dimensional definition of an aircraft’s intended trajectoryincluding horizontal positions, altitudes, speeds and times.

Protocol A set of rules and formats (semantic and syntactic) which determines thecommunication behavior between peer entities in the performance of a datacommunication transaction.

QQualification Process through which a State/approval authority/applicant ensures that a

specific implementation satisfies applicable requirements with a level ofconfidence.

RReliability The probability that the system will deliver a particular message without

one or more errors. Note: Definitions of other terms are provided in theGlossary of Acronyms and in the Data Glossaries for data link applications.

RequiredCommunicationPerformance(RCP)

RCP is a statement of the communication performance necessary foroperation within a defined airspace.

RequiredCommunicationTechnicalPerformance(RCTP)

RCTP is determined for a specific RCP, where the human performanceprobabilities have been assessed in order to establish the RCTP, i.e.,performance requirements bearing on the underlying infrastructure.

Requirement An identifiable element of a specification that can be validated and againstwhich an implementation can be verified.

Risk The combination of the probability, or frequency of occurrence of a definedhazard and the severity/magnitude of the consequences of the occurrence.

60


Term Definition / DescriptionRisk MitigationStrategy

The set of requirements that, when correctly implemented, providesadequate protection from a specific failure, error, or change to airspacecharacteristic contributing to the hazard. The risk mitigation strategy isconstrained by the safety objective.

SSafety Freedom from unacceptable risk of harm.

Safety Assessment Safety Assessment stands for a systematic and comprehensive processconducted during system development to establish safety requirements andto demonstrate that these requirements are met.

Safety Assurance All planned and systematic actions necessary to provide adequateconfidence that a product, a service or a system satisfies given safetyrequirements

Safety Objective A safety objective is a statement that defines the maximum frequency orprobability at which a hazard can be tolerated to occur.

SafetyRequirement

Safety requirements are risk mitigation means. A safety requirement is arequirement that when implemented, will help the system meet the safetyobjective. Safety requirements may take various forms, includingorganizational, operational, procedural, functional, performance, andinteroperability requirements or environment characteristics.

Stakeholders Organizations that have a financial investment in the provision and use ofATS.

Standard A recognized international or industry defined specification or guidelinedocument.

Surveillance Surveillance applications include the delivery of position and intent data(e.g., position waypoint passage and next waypoint) and other conformancemonitoring data to permit ATS and other aircraft to monitor for safe andefficient separation. Surveillance applications include air-groundtransmissions and air-air transmissions intended to supplementground-based surveillance. Surveillance applications include automaticdependent surveillance (ADS).

System A combination of inter-related items arranged to perform a specificfunction.

System ElementSafety Assessment

Safety Assessment process followed by one organization for an element ofthe CNS/ATM system.

TTransactionAvailability

Or ‘Availability risk’:Availability is represented by the ratio of the total outages during theduration of the expected flight time.

TransactionContinuity

Continuity is represented as the availability with an exposure time of themaximum transaction time.

TransactionIntegrity

Or ‘Integrity risk’Integrity risk is represented as the probability of undetected failures perflight hour

61


Term Definition / DescriptionTransaction Time Transaction time is the time in which a specified probability of delivery

success can be met.UVValidation Confirmation by examination and provision of objective evidence that the

particular operational requirements for a specific use are correct.Verification Confirmation by examination of evidence such as test results that a

product, process or service/operations, fulfills specified requirements.Verification Plan A plan encompassing all stages of definition, development and operations

aiming at demonstrating compliance to the requirements.WXYZ

** Alternative definition - Decision to be made as to which definition will be used.

62


Annex C: OSED Guidance

This annex provides guidance on how to define the service description and operational environmentcharacteristics of any Air Traffic Services supported by data communication. It also provides a templateof the document which would result from the Operational Service Environment Initial Capture (OSEIC)process.

A typical OSED would consist of the following documentation.

C.1 Introduction

C.1.1 OSED Guidance and Template

Airspace planners and airspace users are the primary users of the template to capture characteristics of theoperational environment needed by system qualifiers to assess the operational, safety, interoperability,and performance aspects of air traffic services supported by data communications. The OperationalServices and Environment Definition (OSED) is the result of the OSEIC process. It provides the basis foran assessment of the safety and performance system, procedures, and airspace characteristics from whichto determine elements to perform the safety and performance methodologies.

ATSU

AOCU

ATSU ATSsupport

Aircraft

Airspace characteristics➫ Separation minima➫ Traffic density➫ Traffic complexity

Operationalboundary

ATSboundary

Air Traffic ServicesATS Procedures

CNS/ATM System

Systemboundary

Figure C.1-1: ATS Supported by Data Communication Operational Environment

Figure C.1-1 shows a conceptual model of the operational environment. The model is not intended toimply a specific operational environment. Organizational configurations may differ. For example, theremay be more than two air traffic service units, there may not be an Aeronautical Operational ControlUnit, there may be more than one air traffic service within an environment, and an air traffic service may

63


be supported by more than one CNS/ATM system. The conceptual model is intended to provide therationale for the knowledge about the operational environment needed to perform the ATS supported bydata communication safety and performance assessments.

The elements of the operational environment span organizational boundaries. Dashed lines denote thedifferent organizations that are in control of the planning, development, implementation, maintenance, oroperation of these different elements. The CNS/ATM system comprises elements within air traffic serviceunits, aeronautical operational control units, one or more communication service provider(s), and theaircraft.

The operational environment and resulting required assessment of a given air space includes a mix ofaircraft with different system characteristics, including functional and performance, a variety of air trafficservices, and modification of any other elements of the operational environment.

C.1.2 Identification of participants

Several types of organizations are involved in the OSEIC, OSA, OPA, and IA. The different types oforganizations act in various fields of responsibility. The list hereafter does not intend to be specific of anyexisting organization. In some countries a unique organization may be responsible for several fields ofresponsibility. However, the functional roles within this organization are distinct and well defined. Thevarious fields of responsibility that may be involved are:

a. The airspace planners in charge of the definition of the airspace. The States are responsible for theirown domestic airspace. When coordination on an international basis is necessary, this airspaceplanning is coordinated within the International Civil Aviation Organization (ICAO) RegionalPlanning Groups (PIRG);

b. CNS/ATM system developers encompass ground CNS/ATM systems developers and airborneCNS/ATM systems developers:

(1) Ground CNS/ATM developers encompass designers / developers / manufacturers /installers / maintainers of CNS-ATM systems, telecommunication networks andcommunication systems (including ground and satellite equipment); and

(2) Airborne CNS/ATM systems developers encompass aircraft manufacturers, aircraftequipment manufacturers and airlines in the design of aircraft systems;

c. Air traffic service providers including:

(1) Air traffic control service providers including:

(a) Area control service providers;

(b) Approach control service providers; and

(b) Aerodrome control service providers;

(2) Flight information service providers; and

(3) Alerting service providers;

64


d. Those organizations providing support to ATS providers including:

(1) Telecommunication service providers;

(2) Weather forecast service providers;

(2) Airport service providers (excluding Aerodrome control services);

(4) Commercial power providers; and

(5) Plant and plant system providers;

e. Flight crews and aeronautical operational control; and

f. State authorities having statutory authority and responsibility for regulation, certification, and/orcommissioning of any element of the CNS/ATM system, procedures, or airspace.

C.2 Operational Data Communication Services

Operational flight services that employ communications could be used for the purpose of both tactical andprocedural air traffic management. These operational services are achieved by exchanging informationthrough communication systems between a pilot and a controller.

The data link applications could be described as operational data services. An operational data service isa set of ATM related transactions. These transaction sets for communication, navigation or surveillanceuse data link communications, and are made up of a sequence of messages.

This subsection is provided to show how to break down an operational data service into a singletransaction in order to facilitate the identification of the required performance characteristics at theoperational level.

A typical operational data service is a request by the flight crew for clearance, followed by the delivery ofclearance. The flight crew needs to know if the request for clearance was received, or if they should usealternate communications procedures to deliver the request. The controller needs to know if the clearancewas received, and what actions the flight crew has taken subsequent to the clearance delivery. Thisoperational data service should be thought of as two separate transactions.

The majority of pilot – controller data link communications is interactive. The timely delivery of amessage is closely monitored to determine the applicability of recovery procedures before safety marginsare degraded.

The first transaction is the delivery of the request for clearance, followed by the delivery of the clearance.

The second Transaction is the delivery of the clearance, followed by delivery of the flight crew responseto the clearance.

The flight crew initiates the first transaction, and the flight crew must become aware when to abandon thetransaction and utilize alternate procedures.

65


Transaction 1 begins when the flight crew initiates a data link message requesting a clearance and endswhen the message containing the clearance response is received. Transaction 2 begins with the data linkmessage containing the clearance and ends when the response to the clearance is received. There isoverlap between these processes.

The flight crew may be alerted when transaction 1 fails. This may be the result of slow message delivery,or even slow controller response to the request. Typically, a timer will start when the request is initiated,and the timer stops when the clearance response is received.

Note: pilot and controller procedure and back up procedure specific to an operation determine theannunciation requirement.

The controller may be alerted when transaction 2 fails. This may be the result of slow message delivery,or even slow flight crew response to the clearance. Typically, a timer starts when the request is initiated,and the timer stops when the clearance response is received.

ReceivingApplication

InitiatingApplication

Networking

Time todeliverMessage


HumanResponseTime


HumanResponseTime

Transaction1

Transaction2

Figure C.2.1-1: Clearance Request/Response Operational Service

66


For transaction 1, if the timer expires, the flight crew re-initiates the clearance request using otherprocedures. For transaction 2, if the timer expires, the controller initiates alternate procedures to contactthe flight crew and then take appropriate action regarding the clearance.

It should be noted that if the flight crew receives a clearance in a timely manner, it is considered valid andthey can accept it and comply with it immediately. If the controller fails to receive the response to theclearance, the controller cannot necessarily assume that either the clearance was not delivered or that theresponse was not delivered; it is indeterminate.

C.3 OSED Template

This sub-section of the annex provides a detailed template of the information that should be gathered inthe OSED. Paragraph C.2.1 defines the service description for the capability. Paragraph C.2.2 definesthe operating environment for the capability.

C.3.1 Operations Service Description

Adapted from ICAO Document 9694This section of the OSED is a vehicle for the description of the Air Traffic Service descriptions and theoperational context for their use. These should be documented in accordance with this service descriptiontemplate.

Operational scenarios may be used to describe how the air traffic services based on data communicationsare used.

This paragraph describes data link applications as services. Each data link service is a description of itsrecommended use from an operational point of view.

Services are defined in gradually increasing detail, using the following sub-paragraphs:

C.3.1.1 Scope and Objective

Provides a brief, two-to-three sentence description of what the service does from an operationalperspective.

C.3.1.2 Expected Benefits, Anticipated Constraints, and Associated Human Factors

Expected benefits provides a non-exhaustive list of benefits expected from implementation of the service.

Anticipated constraints describes the constraints which could result from implementation of the service.

Human Factors provides the Human Factors aspects considered essential for the safe and coherentoperation of the service, particularly in reference to partial implementations, mixed equipage, etc.

C.3.1.3 Operating Method Without Data Link

Describes how the controller, pilot, or support system(s) perform the service in today’s non-data linkenvironment. As this heading describes controller and pilot actions, it also covers procedures.

67


C.3.1.4 Operating Method With Data Link

Normal mode describes how the service would normally be conducted via the following:• Service description describes how the controller, pilot, or support system(s) perform the service

with data link assistance. As this heading describes controller and pilot actions, it also coversprocedures and should identify optional features in addition to the standard features of theservice. This heading also describes how the data link service is carried out, stating whatmessages are sent by the data link partners involved, and what operational events trigger thetransmittal of the messages;

• Initiation conditions describes what conditions are met prior to initiation of the data link service,to include association with operational events and manual action;

• Sequence of services states what other data link services precede the data link service, if any; and

• Additional guidelines provide any additional features for the data link service, to includeamplification of the preceding elements and any recommended enhancements that could beachieved through advanced airborne or ground equipment.

C.3.1.5 Capturing Service Time Constraints

By their very nature, two-way transactions are dependent on message delivery time in each direction,flight crew human response time, and controller human response time. For the transaction example of arequest for clearance followed by clearance delivery, there are two transactions involved, each with theirown transaction expiration time.

For transaction 1, request for clearance followed by clearance delivery, expiration time allows time todownlink the request, time for the controller to respond with a clearance, and time to uplink the clearance.

For transaction 2, clearance delivery followed by response to clearance, expiration time allows time touplink the clearance, time for the flight crew to respond, and time to downlink the flight crew’s intentions.

The following example scenarios show how the service time constraints may be established. It isincumbent upon the writer of the OSED to develop a complete description of the transactions that makeup the service.

C.3.1.5.1 Capturing Communication Time Constraints

The aim of the time characteristic form is to capture operational time characteristics that are needed forATS communication in order to complete a specific procedure.The pilot controller communication as a whole could be grouped into various types of exchanges that canhave different operational goals such as planning, tactical, strategic or emergency in accordance with thecontext of operation. The ATS communication could be grouped as follow:

General information: PlanningClearances - request and delivery: Tactical & strategicFlight monitoring: Tactical, Strategic or PlanningNegotiation: Tactical, Strategic or PlanningSystem management: Strategic

68


Emergency situations: EmergencyAccording to the operational goal of pilot controller exchanges, the constraint could differ in time. Forexample, a transaction used for planning is less time-critical than a tactical message.

Planning: long-termStrategic: intermediate-termTactical: short-termEmergency: immediate

For each type of communication: planning, strategic, tactical, and emergency, a form is provided in theOSED template to identify time constraints.

In a first stage, a procedure, which has the more stringent operational constraint, should be chosen and theATS communication scenario between pilot and controller established.

Different cases of ATS exchange are suggested hereafter and could be considered in order to capture thetime constraints.

The Transaction Time is the time needed by a pilot and a controller to exchange a pair of messages. Thistime represents the sum of the delivery time of incoming and outgoing messages and the controller orpilot response time.

The transaction time distribution is characterized by two main parameters:

• Transaction Expiration Time: represents the moment after which, when expired, even if amessage is received, it is not considered as applicable, and may be treated either by specificpilot/controller procedures, such as a "revert to voice procedure" or specific functions of thesystem are applied; and

• 95% Transaction Time: represents the time that it takes to complete 95% of the transactions.

A transaction that cannot be completed before the expiration time is considered as a failure, consequentlythe outage effect is classified following the result of the safety analyses.

The following figure represents the typical distribution of the completion time of transaction. In this chartthe "95% Transaction Time" and "Transaction Expiration Time" are also shown.

69


Distribution ofExchanged

Transaction

Transaction available

95% of theTransactions

Transaction Failed

TransactionExpiration

Time

Time

∞

Lost messages

95%Transaction

Time

2σ

Figure C.3.1.5.1-1: Achieved Transaction Distribution

Similarly, the 95% Human Response Time represents the time that a human needs to perform a response95% of the time.

C.3.1.5.2 Single Transaction Scenario

The following figure could be applied to a simple demand and response exchange between a pilot and acontroller. In this case, only one transaction is necessary to achieve the ATS communication. Thefollowing figure could be applied to a simple paired exchange between a pilot and a controller. In thiscase only one transaction is necessary to achieve the ATS communication. Examples of such CPDLCtransactions include but are not limited to:

• a controller issuing a clearance and the compliance indication response from the pilot; or

• a pilot requesting a clearance and the controller responding negatively.

70


TRANSACTION

Initiator Responder

Sec95% HumanResponseTime

SecTransaction

ExpirationTime

Sec95%

TransactionTime

OperationalData link serviceInitiation

OperationalData link serviceCompletion

REQUEST

RESPONSE

Figure C.3.1.5.2-1: Single Transaction Scenario

C.3.1.5.3 OverlappingTransactions Scenario The following figure could be applied when two transactions are required to complete the ATScommunication and the transactions overlap in time. An example of such a CPDLC scenario might be arequest for clearance, which results in a clearance being issued. In this scenario, the clearance messageinitiates the second transaction when it is transmitted and completes the first transaction when it isreceived.

TRANSACTION1

TRANSACTION2

Initiator


SecTransaction#1

ExpirationTime

Sec95%

Transaction#1Time

Sec95% Human

ResponseTime

SecTransaction#2ExpirationTime

Sec95%Transaction#2Time

OperationalData link service

Completion


Responder

REQUEST

CLEARANCE

ACKNOWLEDGE

Figure C.3.1.5.3-1: Two Overlapping Transactions Scenario

71


C.3.1.5.4 Non-Overlapping Transactions Scenario The following figure could be applied when two transactions are required to complete the ATScommunication and the transactions do NOT overlap in time. Examples of such CPDLC transactionsinclude but are not limited to:

• a request for clearance that results in both a STANDBY message and a clearance being issued;

• a clearance issued by the controller, that results in both a STANDBY and the pilot’s compliancewith the clearance; and

• a request by the controller for the pilot to indicate a future event, the pilot indicating positivecompliance, and a subsequent message indicating the event requested (e.g. report reachingrequests).

In these examples the first response closes the first transaction. The second response may be a two-orone-way transaction. Note that in the third case the pilot responded with a STANDBY to the request toindicate a future event 3 transactions could be required to complete the ATS communication. (3 ifpositive compliance, 2 if negative).

TRANSACTION2

TRANSACTION1

Initiator Responder


SecTransaction

ExpirationTime

Sec95%

TransactionTime

Sec95% Human

ResponseTime

SecTransactionExpirationTime

Sec95%TransactionTime


Completion


REQUEST

STANDBY

CLEARANCE

ACKNOWLEDGE

Figure C.3.1.5.4-1: Two Non-Overlapping Transactions Scenario

72


C.3.1.6 Information Exchanges

This sub-paragraph provides further operational requirements for each message described in the aboveparagraph. This sub-paragraph is set out in a table with the following entries:

a) Message: states the name of the specific message within the exchange;

b) Information required: includes a plain text description of the data to be transferred in themessage. Descriptions should clearly separate and identify the mandatory and optionalcontents;

b) Event trigger: briefly describes the operational event that initiates the message;

d) Source/destination: gives the operational source and destination of the message. These canbe aircraft or one of several air traffic services unit (ATSU) designators, as defined in theglossary;

e) Alerting requirements: describes the need for pilot and controller alerting for the data linkservice. Alerting can be one of four categories:

1) H: High;

2) M: Medium;

2) L: Low; and

4) N: No alerting required;

f) Response: indicates whether a response is or is not required for the message (“Y” and “N”respectively);

g) Urgency: delineates the relative relationship among messages when placed in a queue foroperator access. It relates to the handling of the information by the receiving system. Itdictates the order of display, processing (including deletion, modification, and shelf life), orother action in accordance with the sequencing of essential, routine and time-expired data.Urgency does not influence communication processing, which is defined bycommunications priority; it applies to the end user processing application only. Valid entriesare:

1) Distress, indicating grave and imminent danger;

2) Urgent, comprising movement and control messages and meteorological or other adviceof immediate concern to an aircraft in flight or about to depart, or of immediate concernto units involved in the operational control of an aircraft in flight or about to depart;

3) Normal, comprising routine operational messages such as routine surveillance ornavigation, meteorological messages not of an urgent nature, etc.; and

4) Low, indicating any message with a lesser urgency than the above.

73


Table C.3.1.6-1 is an example table of information exchange requirements.

Message Information required(Mandatory/Optional)

Event/trigger Source/destination

Alert Response(Controller/Pilot)

Urgency

Table C.3.1.6-1: Information Exchange Requirements

In addition, applicable information security requirements (e.g., authentication, access control, etc) for theinformation exchange are specified. This document does not provide any guidance on how theseinformation security requirements should be developed and specified.

C.3.1.7 Exception handling

Describes what should happen if the service fails, to include error reporting, recovery needs, proceduresand alternative message exchange.

C.3.2 Operational Environment

This section of the OSED is a vehicle for the description of the operational environment for the AirTraffic Services described above.

C.3.2.1 Capturing Environment Constraints

The aim of the communication environment characteristics form, provided in the OSED template is to getknowledge of the fundamental operational and technical characteristics that govern communicationperformance and safety.

From the operational standpoint, communication performance changes according to the scope of ATScommunication. In the same way, the performance applied to voice or data channels differs according towhich means is used as primary.

The goal of the technical part of this form is mostly to capture or identify the technical limitations. Thisinformation is necessary in order to be used in the methodology to determine the communicationperformance in the technical path. For example, the loss of communication with one aircraft does nothave the same consequences as the loss of communication with all aircraft within the area of control.

Similarly, the volume of ATS communication expected is considered, as it could have an impact on thetransaction time and on the transaction continuity when there is network congestion.

C.3.2.2 Operational Environment Template Forms

This template provides performance information to be used as an input by the methodology to developtechnical performance requirements for the end to end data link path in any communication environmentsupporting the operational concept.

This template focuses on information, which needs to be captured in the early stages of the definition, andimplementation of any operational enhancement based on air ground data communication in a region or a

74


state. It helps to initiate the operational safety assessment, operational performance assessment and initialdevelopment of performance requirement.

75


COMMUNICATION ENVIRONMENT CHARACTERISTICS

OPERATIONAL CHARACTERISTICSPrimary Supplemental

ATC Data Link means:ATC Voice means:

Flight Phases: Yes NoOceanic/Remote:

Offshore:En route/Domestic:

Terminal: Takeoff:

Approach: Landing:

Airport Surface:

Air Traffic Complexity: Yes NoAltitude transition:

Crossing traffic: Speed management:

Route Configuration: Yes NoFixed Tracks:

Flexible Tracks:

Type of Control: Yes NoProcedural:

Tactical:

Other: Yes No => If yes, qualify constraintsMultiple Sectorization:Special Use Airspace:

Topographic Constraints:Weather Constraints:

Separation MinimaLateral Nautical Miles

Longitudinal Nautical MilesVertical Feet

TRAFFIC CHARACTERISTICS (Anticipated for traffic growth over capability life cycle)

Aircraft Throughput Aircraft per Sector per HourTrack Occupancy Aircraft on Same Track per Controller

Sector Traffic Density Aircraft per Sector

For each type of aircraft, provide the following information:CNS equipment of aircraft:

Aircraft performance:Speed:

Altitude:Climb/descent:

76


TECHNICAL CHARACTERISTICS

Network Data Architecture: Yes NoACARS Based:

ATN Based:

Sub-network Coverage: Totally Partially / NoneVHF Data:

SATCOM data: HF data: Mode S:

HF Voice: VHF Voice: UHF Voice:

SATCOM Voice: Other:

AVAILABILITY CHARACTERISTICS

Acceptable link communication shutdown:(When the link is down between one pilot and one controller)

Maximum Aircraft Operating Time: hours (Maximum time needed to transit over the longest direct path of a given area)

Total duration of the acceptable link shutdown per operation: minutes

Acceptable area communication outage:(When the links are down between all pilots and controllers)

ATS Operating Time: Hours per dayTotal duration of the acceptable outage: Minutes per day

VOLUME CHARACTERISTICS

Maximum volume of ATC transaction exchanged: per Hour per AircraftMaximum number of aircraft: per AreaMaximum message traffic density: per Hour per Area

(The traffic density should reflect the expected total number of AOC, APC or ATC messages transmitted using airground data link path)

77


ATS supported by Data/Voice Communication Type: EMERGENCYNote: the exercise should be performed on the more stringent Emergency procedure in terms of operational constraint

Service Sequence ChartSingle msg element Multiple msg element Route clearance type msgs

Typical Message Size:(Single, multiple or route clearance like)

TRANSACTION

Initiator Responder

Sec95% HumanResponseTime (HT)

SecTransaction

ExpirationTime(ET)

Sec95%

TransactionTime (TT)



REQUEST

RESPONSE

CONTINUITY CHARACTERISTIC

Volume of acceptable failed transactions: Transaction(s) per 103 transactions(When the maximum time allowed is expired for the transaction)

INTEGRITY CHARACTERISTIC

Volume of acceptable undetected corrupted transaction: Transaction(s) per 103 transactions(When messages for this type of transaction and received by controller or pilot are corrupted)

78


ATS supported by Data/Voice Communication Type: TACTICAL

Note: the exercise should be performed on the more stringent tactical procedure in terms of operational constraint



TRANSACTION1

TRANSACTION2

Initiator

Sec95% HumanResponseTime (HT1)

SecTransaction#1

ExpirationTime (ET1)

Sec95%

Transaction#1Time (TT1)

Sec95% Human

ResponseTime (HT2)

SecTransaction#2ExpirationTime (ET2)

Sec95%Transaction#2Time (TT2)


Completion


Responder

REQUEST

CLEARANCE

ACKNOWLEDGE





79


ATS supported by Data/Voice Communication Type: STRATEGICNote: the exercise should be performed on the more stringent strategic procedure in terms of operational constraint



TRANSACTION2

TRANSACTION1

Initiator Responder


SecTransaction

ExpirationTime (ET1)

Sec95%

TransactionTime (TT1)

Sec95% Human

ResponseTime (HT2)

SecTransactionExpirationTime (ET2)

Sec95%TransactionTime (TT2)


Completion


REQUEST

STANDBY

CLEARANCE

ACKNOWLEDGE





80


ATS supported by Data/Voice Communication Type: PLANNINGNote: the exercise should be performed on the more stringent information procedure in terms of operational constraint



TRANSACTION2

TRANSACTION1

Initiator Responder


SecTransactionExpiration

Time (ET1)

Sec95%

TransactionTime (TT1)

Sec95% Human

ResponseTime (HT2)

SecTransactionExpirationTime (ET2)

Sec95%TransactionTime (TT2)


Completion


REQUEST

STANDBY

CLEARANCE

ACKNOWLEDGE





81


Annex D: SPR Guidance

This annex provides guidance on how to define the operational safety and performance requirements ofany Air Traffic Services supported by data communication. It also provides a template of the documentthat would result from the Operational Safety Assessment (OSA) process and the OperationalPerformance Assessment (OPA) process.

A typical SPR would consist of the following documentation.

D.1 SPR Guidance

D.1.1 Purpose

During a project development, the relevant stakeholders should jointly develop the SPR; it should be usedto provide the basis for ensuring that systems meet applicable requirements during initial implementationand continued operation.

It should include:

• the allocation of these requirements to the stakeholders developing the ATS supported by datacommunication, procedures and airspace characteristics;

• identification of approval authority; and

• identifies source of requirements.

The SPR is for use by all organizations. Organizations include those States and stakeholders that are incontrol of establishing requirements or insuring that systems meet those requirements. The SPR shouldrecognize existing requirements and systems that mitigate identified hazards.

D.1.2 Scope

The Safety and Performance Requirements (SPR) document should identify the operational, safety andperformance requirements for air traffic services supported by data communications in airspace describedin the OSED.

The SPR provides the basis for ensuring systems meet applicable requirements for initial implementationand continued operation. This document should include:

• requirements identification;

• Allocation of requirements to the stakeholders in control of requirements implementation;

• Identification of the approval authority responsible for ensuring that initial implementation andcontinued operation meet the allocated requirement; and

• Identification of the source of each requirement.

D.1.3 How to Use the SPR

82


The SPR should be developed as an industry standard and can be used to provide the requirements basisfor qualification activities throughout the life cycle of the implementation. The operational, safety andperformance requirements should be associated with service descriptions and operating contexts andshould include a source trace from each requirement through the operational safety assessment,operational performance assessment, through the OSED and to each service/operating context listed. Theapproval plan for the project should provide the vehicle for negotiating the requirements basis and themeans of compliance amongst the applicant, approval authority and other stakeholders. The SPR templateis designed to enable stakeholders to tailor the SPR to the needs for the project in the following ways :

• stakeholders could choose the services and operating contexts appropriate for the project fromservice descriptions and the operating contexts, so only those requirements that trace to thespecific services for the project need to be satisfied;

• stakeholders could use this trace to assess the impact in the event their specific serviceimplementation or operating context can not be shown to meet the operational, safety andperformance requirements contained in the SPR;

• the applicant would negotiate with approval authority any deviations, additions, or clarificationsof the SPR via the approval plan. These items would be provided as project specific data; and

• stakeholders would use the SPR to provide the basis for monitoring requirements duringoperations.

D.2 SPR Template

D.2.1 Purpose

This SPR Document provides the operational, safety and performance requirements for air traffic servicessupported by data communications as defined in the OSED (Annex C). The SPR is used to provide thebasis for ensuring that systems meet applicable requirements during initial implementation and continuedoperation.

D.2.2 Scope

This Safety and Performance Requirements (SPR) document supports the air traffic services identified inthe OSED (Annex C) within the xxx FIR (or sector or airspace designation). These services are expectedto be under trial or to be operational in the 2xxx-2yyy time frame.

Note: This section identifies scope of applicability of the SPR document to include the geographiccoverage of the services, the expected schedule of implementation, etc.

D.2.3 Contributors to This Document

This Safety and Performance Requirements (SPR) document was prepared by Group Identifier with thefollowing membership:

Name Organization

83


Note: This section identifies the contributors who have developed the OSED, OSA, and OPA for thespecific air traffic services covered by this SPR.

D.2.4 Summary of the OSED

D.2.4.1 Description of Services

This section provides a brief description of the air traffic services supported by data communications.These service descriptions were developed using the template defined by ICAO. For a more detaileddescription of the message transactions and technical functions, refer to the OSED.

D.2.4.2 Description of Operational Context

This section provides a brief description of the service operational contexts for each of the services. For amore comprehensive description of the operational context, refer to the OSED.

D.2.5 Summary of the OSA

This section should present a summary of the highlights of the OSA.

D.2.5.1 Summary of the OHA

This section should present a summary of the highlights of the OHA.

D.2.5.2 Summary of the ASOR

This section should present a summary of the highlights of the ASOR.

D.2.6 Summary of the OPA

This section should present a summary of the highlights of the OPA.

D.2.7 Allocation of Safety and Performance Requirements

This section should present the result of the operational safety and performance assessment up to theallocation of requirements at the organizational level.

D.2.7.1 Methodology for Requirements Determination This section should provide the methodology to gather:

• all requirements allocated by the ASOR; and

• all requirements allocated by the OPA.

D.2.7.2 Table of Allocated Safety and Performance Requirements

84


The requirements could be presented in a matrix containing the following information:

• requirements reference;

• requirements;

• organization;• approval; and

• source trace ! OSED, OSA, OPA.

RequirementsReference

Requirements Organization Approval Source Trace(OSED,OSA,OPA)

Appendix A – Operational Safety Assessment (OSA)

Refer to Annex E

Appendix B – Operational Performance Assessment (OPA)

Refer to Annex F

85


Annex E: OSA Guidance

This annex provides guidance on how to define the safety requirements of any Air Traffic Servicessupported by data communication.

E.1 Introduction

E.1.1 Purpose

This section provides the framework to describe the operational safety assessment (OSA) for CNS/ATMsystems that are planned, built, and operated by different stakeholders.

E.1.2 Scope

The OSA described here is an assessment of the safety of air traffic services supported by datacommunications, within the context of the entire airspace system. Safety assessment methods are used toestablish safety objectives or high level requirements needed to attain a particular operational capability ina defined operational environment. Such requirements are allocated to parts of the system, procedures, orairspace characteristics. Qualification means are then applied to development activities to ensure thatspecific implementations satisfy these requirements with acceptable levels of confidence. In consideringa multi-organizational system, the allocated requirements go beyond the control of any one State ororganization.

E.2 Operational Safety Assessment (OSA)

Based on the conceptual model of the operational services and environment, Figure E.1.3-1 shows therelationships among faults, system failures, procedural errors, airspace characteristics, and the riskmitigation strategy.

86


ATSU

AOCU

ATSUSupporting

ATS

Aircraft

Airspace characteristics➫ Separation minima➫ Traffic density➫ Traffic complexity

Operationalboundary

ATSboundary

✕✕✕✕

✕✕✕✕

Failure

Effect on ATS

Procedural error✕✕✕✕

✕✕✕✕

Hazard

Denotes institutional boundaries

ATS Procedures

OperationalEnvironment

CNS/ATM System

Systemboundary

✕✕✕✕

✕✕✕✕

Fault

✕✕✕✕Fault

Riskmitigation

strategy

Figure E.1.3-1: Concept Model of Operational Environment, the Relationships AmongFaults, Failures, Procedural Errors, and Airspace Characteristics, and the Risk MitigationStrategy

The OSA process should be useful for both strategic and tactical changes in the airspace system. As anexample of strategic use, the OSA process could be used in conjunction with strategic planning, providingsafety input to the evaluation of a planned operational capability. This process might begin by definingthe concept of operations, which in turn would influence the OSED. The resulting OSA would developsafety goals to be considered with other factors such as cost and performance. As an example of tacticaluse, consider the prospective implementation of a technological opportunity rather than requirement. Inthis case the OSA methodology could be used to assess the potential safety effects of using the newtechnology. These effects in turn could result in the specification of new requirements for inclusion in theOSED, or alternatively, could result in the revision or even elimination of specified requirements from theOSED.

An OSA establishes, validates, and allocates the safety objectives and requirements through a cooperativeeffort from the stakeholders that control each of the elements of the operational environment. The OSAprovides the basis for the safety assessment activities conducted by each of the stakeholders that controlthe development of the elements of the operational environment. The OSA is separate from each of theorganizational safety assessments in order to define the common safety objectives and requirements thatrequire multi-organizational coordination.

87


a. The approval authority endorses an OSA as part of an element approval. The OSED determines thescope of the OSA. The OSA provides the mechanism for the coordination necessary to establish,validate, and allocate across organizations the safety objectives and requirements to the elements ofthe operational environment;

b. The OSA includes an operational hazard assessment (OHA) and allocation of safety objectives andrequirements;

c. The OHA is separate from the allocation of safety objectives and requirements to standardize thesafety objectives and requirements for an operational capability with similar airspace characteristicsthroughout the world. The risk mitigation strategies, however, may be different in various regions ofthe world, depending on the CNS/ATM system architecture and procedures; and

d. The Operational Hazard Assessment should begin with the services documented in the OSED.Operational hazards should be identified and assessed against those services; therefore, each servicefrom the OSED should be reflected in the OHA.

The Operational Services and Environment Definition (OSED) provides the basis for an assessment ofsystem failures, procedural errors, and airspace characteristics from which to determine risk mitigationstrategies that protect against hazards for a defined operational capability.

E.3 Performing the Operational Safety Assessment

The OSA includes two interrelated processes:

a. Operational Hazard Analysis OHA; and

b. The allocation of safety objectives and requirements (ASOR).

E.3.1 Operational Hazard Assessment (OHA)

The OHA is developed early in the airspace planning process and is updated as functions are modified oroperational hazards are identified. Guidance for performing the OHA is as follows:

a. All characteristics of the operational environment as defined by the OSED that may cause a hazard orto which a hazard is related should be identified. The accuracy and completeness of the OHA isdependent upon the accuracy and completeness of the OSED. The operational environment,including the functional capabilities necessary to achieve the defined operational capabilities, shouldbe specified before commencing an OHA. However, it should be noted that the OHA developmentprocess may be iterative. The results of the initial OHA may, in fact, result in modifications toOSED. The OHA process should be initiated early in the air traffic system requirements specificationprocess;

b. Determination of all operational hazards should be identified:

(1) Hazards can be identified by first determining the functional characteristics supplied bythe system. However, it is recognized that on occasion, a restricted view of thesefunctional characteristics will not identify all of the potential operational hazards.

88


Therefore, procedural error, such as that involving transactions between the pilot and theATC, should also be considered when identifying operational hazards;

(2) Identification of operational hazards should be supported by considerations including:

(a) Functional failure;

(b) Human failure to respond appropriately to functional failure;

(c) Human error or omission during normal use;

(d) Transitional hazards (those that may result by changing over from an existingoperation to a new operation); and

(e) External factors (e.g., outages, weather);

(3) It should be remembered that the OSA is focused on functions that involve multipleorganizations; any functional characteristics within an organization are organizationalsafety assessment issues except where they affect the results of the OSA. Organizationalsafety assessment issues affecting the OSA results should be fed back to the OSA processfor reassessment;

c. The effects of each operational hazard should be identified:

(1) When considering ATS systems incorporating data link, these effects arise from systemfailures or procedural errors associated with the operational concept. Operational eventeffect types include:

(a) Collision or loss of margin of safety with respect to collision between airborneaircraft:

- Loss of vertical separation between aircraft;- Loss of lateral separation between aircraft;- Loss of longitudinal separation between aircraft; and- Loss of separation with special use airspace;

(b) Collision or loss of margin of safety with respect to collision with terrain or lossof separation with terrain;

(c) Loss of separation or loss of margin of safety with respect to loss of separationwith significant weather or atmospheric contamination effects (e.g., volcanic ash,birds); and

(d) Collision or loss of margin of safety with respect to collision between aircraft andother aircraft or vehicles on the ground;

(2) When assessing the effects of system failures or operational errors on the margin ofsafety it is important to consider contributory factors such as:

89


(a) Is the effect dependent on outage time?

(b) Is the effect only associated with initial operations?

(c) Does the effect only exist during the transition when two operational capabilitiesare in service?

(d) Is more than one aircraft effected?

(d) Is more than one sector effected?

(f) Is the effect dependent on the time the hazard occurs or on the hazard’sduration?

(g) Is the effect dependent on the phase of flight? and

(h) Is the effect related to a specific workload or skill issue?

(3) The purpose of this phase of the analysis is to establish the extent that the identified failuresand procedural errors can lead to a reduction of safety margins in the operationalenvironment. This reduction of safety margins can be described by a type of effect onoperations as defined in the Hazard Classification Matrix. The Hazard Classification Matrix(HCM) is a tool that assists in assigning the proper hazard effect and severity to each of theidentified operational hazards. Figure E.3.1-1 shows the HCM.

90


Hazard Class 1 (most severe) 2 3 4 5 (least severe)Effect onOperations

Normally with hullloss. Total loss offlight control, mid-aircollision, flight intoterrain or high speedsurface movementcollision.

Large reduction insafety margins oraircraft functionalcapabilities.

Significant reductionin safety margins oraircraft functionalcapabilities.

Slight reduction insafety margins oraircraft functionalcapabilities.

No effect onoperationalcapabilities or safety

Effect on Occupants Multiple fatalities. Serious or fatal injuryto a small number ofpassengers or cabincrew.

Physical distress,possibly includinginjuries.

Physical discomfort. Inconvenience.

Effect on Air crew Fatalities orincapacitation.

Physical distress orexcessive workloadimpairs ability toperform tasks.

Physical discomfort,possibly includinginjuries or significantincrease in workload.

Slight increase inworkload.

No effect on flightcrew.

Effect on Air TrafficService

Total loss ofseparation.

Large reduction inseparation or a totalloss of air trafficcontrol for asignificant period oftime.

Significant reductionin separation orsignificant reductionin air traffic controlcapability.

Slight reduction inseparation or slightreduction in air trafficcontrol capability.Significant increasein air trafficcontroller workload.

Slight increase in airtraffic controllerworkload.

Figure E.3.1-1: Operational Safety Assessment Hazard Classification Matrix

91


HazardClass

SafetyObjectives

Extremely ExtremelyProbable Remote Remote Improbable

1

2

3

4

5

Risk Acceptance Cases

Unacceptable Acceptable with Review Acceptable

Acceptable with Review - Unacceptable withSingle Point Failures and Common-Cause Failures

Figure E.3.1-2: Hazard Classification and Safety Objectives Relationship

Figure E.3.1-2 contains three possible safety analysis choices representing different levelsof risk associated with the operational environment as a whole. These are; Unacceptable(shaded), Acceptable with Review (black), and Acceptable (white). The term‘Acceptable with Review’ merely means that there is an increased level of risk associatedwith this choice which requires an extra measure of review before it can be accepted. Inthis case, all parties in the OSA must make an informed decision to accept the increasedlevel of risk. This choice constitutes a gray area between a level of risk that is clearly‘Acceptable’ and clearly ‘Unacceptable’. For example, consider Hazard Class 3.Reading along the row against Hazard class 3, it can be seen that the Probable category ofsafety objective is Unacceptable while the Extremely Remote and Extremely Improbablecategories of safety objective are Acceptable. The Remote category is Acceptable withReview. The safety goal of Remote may be chosen for this Hazard Category after acareful review of all factors affecting the hazard to which the category 3 designationapplies and making an informed decision regarding the acceptable level of risk.

92


(a) How a hazard effects aircraft operations is the primary concern when assessing theappropriate hazard level to assign to a hazard. Therefore when using the HCM it is importantto focus on the top row of the matrix. The lower rows in the HCM are provided to guide theOHA developer in determining the effect on operations but should not be relied upon as thesole means of assessing hazard level. For example, simply because a hazard may causephysical distress to the aircrew does not mean that the hazard level should automatically beassigned as Hazard Level 2. After determining that a hazard may cause physical distress onthe air crew the OHA developer is now alerted that a Hazard Level 2 may exist but still needsto assess whether a “large reduction in safety margins or aircraft functional capabilities”exists before finally assigning the hazard level. Such an assessment should includeconsultation with flight crew, flight operations experts and other specialists in aircraft safetyas required to arrive at an appropriate hazard classification.

(b) The OSA team agrees on a description that relates the organizational effects to the Effect onOperations. To achieve this, the effects of each failure are assessed across the boundaries ofeach stakeholder, taking into account the inter-relationships between them and the operationalenvironment characteristics. The HCM may help in this association between the two distinctkinds of descriptors;

(c) This phase in the OSA process requires a discussion between all of the organizations in orderto agree on a single hazard classification. This agreement is based on shared engineeringjudgment, empirical data and professional experience; and

(d) Another use of the HCM is as a record of the rationale for the hazard classification, firstly interms of the effects on the air traffic service, aircrew and occupants and secondly for theeffect on operations. If changes occur, it might be easier to identify their impact on the OSAvia the modified effects within the organizations rather than evaluate globally the effect of themodification on operations;

d. Hazard classification and the assignment of safety objectives that affect the required assurance levelsfor system design can be done using two different methods. Most real hazard assessments include acombination of the two;

The first way entails:

• Identifying the hazard in the context of the OSED;

• Identifying specific environmental mitigation factors from the OSED that reduce its severityshould the undesired event(s) occur;

• Assign hazard severity in the context of the OSED; and

• Identifying the safety objective.

The second approach entails:

• Identifying the hazard in the context of the OSED;• Assigning a severity without consideration of potential mitigation;

93


• Identifying the safety objective;

• Identifying mitigation means that reduce the probability of occurrence of the hazard or reduceits severity should the undesired event(s) occur; and

• Assigning a safety objective taking mitigation measures into account.

e. The effects and classifications of operational hazards should be traced to the environment definition;

(1) It is important to maintain traceability between the effects and classification ofoperational hazards and the operational environment. If environmental characteristics areused to constrain a particular hazard then it needs to be recorded in the OSED. Thistraceability is necessary because should safety objective and safety requirementssubsequently fail to be met then it is likely that some constraints will be imposed uponthe operational capability or additional mitigation is provided;

f. Safety objectives based on the operational hazard classifications should be established:

(1) Figure E.2.1-2 is a Hazard Classification/safety objective relationship matrix. Itassociates a Hazard Class with an acceptable safety objective to show that the moresevere the effect of the hazard, the less desirable it is that the hazard occurs. Therefore,for any required hazard classification, the matrix defines the safety objective;

(2) Figure E.2.1-2 illustrates that for any given Hazard Class (severity) there are fourpossible safety objectives. However, only particular ranges of safety objectives, for anygiven hazard, are acceptable. For example, consider Hazard Class 3. Reading along therow against Hazard Class 3 it can be seen that the Probable category of safety objective isUnacceptable; the Remote, Extremely Remote and Extremely Improbable categories ofsafety objective are ‘Acceptable’;

(3) The safety objectives are defined such that a rate of Probable occurs more often thanRemote, a safety objective defined as Remote occurs more often than Extremely Remoteand a safety objective defined as Extremely Remote occurs more often than ExtremelyImprobable. From this table it is therefore possible to identify that:

(a) Hazard Class 5 has no minimum safety objective;

(b) Hazard Class 4 is shown to be no more likely than Probable;

(b) Hazard Class 3 is shown to be no more likely than Remote;

(d) Hazard Class 2 is shown to be no more likely than Extremely Remote; and

(e) Hazard Class 1 is shown to be no more likely than Extremely Improbable (and is alsosubject to the no single failure condition);

(4) The safety requirement should be expressed by combining the hazard effect with thesafety objective. As an example, if the total loss of flight level information has an effect

94


such that the hazard classification is 3 then the safety objective could be expressed asfollows:

“The likelihood that the loss of flight level information will occur, for greater than 10seconds, is no greater than Remote.";

(5) Safety objectives should be considered in relation to other available OSA results. Inother words, for similar operational concepts the safety objectives between OSAs oughtto be similar and consistent if both are done properly. Turning this argument around, it isalso expected that some systems will be expected to operate in different operationalenvironments and meet the safety objectives associated with the worst case environment;and

(6) Note that the Hazard Class is not used in the safety requirement. It is the means ofderiving the safety objective;

g. All considerations and assumptions that were made when evaluating each operational hazard,including interdependencies, should be identified. Assumptions should be substantiated within thecontext of the operational environment; and

h. In the case where manual procedures are automated, the change should be assessed for effects on thesafety of the system.

E.3.1.1 Hazard Description Modifiers

a. When the functional characteristics are identified, a set of descriptors should be applied to the hazardsrelated to those functional characteristics so that the effect of various failure modes can beconsidered. Typical descriptors are identified below:

(1) Total Loss or Unavailability of Information: The information is lost or the function isunavailable (e.g. an ATC controller’s workstation is inoperative);

(2) Misleading Information, including:

(a) Partial loss: Part of the information is lost or the function is only partially completed;

(b) Corruption: The information is altered from what was intended to be transmitted;

(c) Misdirection: The data has come from the wrong source or received by the wrongdestination;

(d) Delay: The data received is out of date or the function is carried out late in relationto succeeding processes;

(e) Out of sequence: When transmitted data is received in a time sequence other than thesequence intended by the transmitting party; and

(f) Inconsistency. Where diverse information paths convey different information;

95


b. Any of the above might be either detected or undetected. This consideration may result in twodifferent hazards for a given descriptor from the list above, where one hazard is more severe than theother.

E.3.1.2 Guidance on Quantitative Safety Performance Levels

Where more than one stakeholder is involved it may be necessary to derive and maintain a set ofquantitative safety objectives associated with the qualitative safety objectives. In addition, whenOrganizational Safety Assessments are undertaken they adhere to a common framework that ensures thatwhen the stakeholder contain similar categories of effect, the qualitative safety objectives, while probablymeasured in different units as appropriate to the stakeholder, are consistent. This means that theacceptable rate of occurrence of these hazards should be equivalent as seen from the perspective of theaircraft occupant.

E.3.2 Allocation of Safety Objectives and Requirements (ASOR)

This process allocates the safety objectives and related requirements, and identifies and validates the riskmitigation strategies that are shared by multiple stakeholders. Guidance for allocating safety objectivesand requirements is as follows:

a. Identify and assess the relationships of system failures, procedural errors, combinations thereof, andthe effects on air traffic services based on the CNS/ATM architecture and the proceduralrequirements provided in the OSED:

(1) Safety Objectives derived from the OHA level relate to the operational environment andthe required operational functionality and are generally independent of implementation.The ASOR process increases the detail of the risk mitigation strategy to includeconsideration of how the defined safety functions and objectives can be allocated tovarious stakeholders;

(2) It should be noted that the skill mix to accomplish the production of this risk mitigationstrategy should be similar to that needed for the OHA;

(3) Through the ASOR process, Safety Objectives can be allocated and /or apportioned andbecome safety requirements and are now associated with safety performancerequirements, not hazard severity;

(4) Consideration should be given as to the reasonableness and practicability of theconsiderations and assumptions (be they procedural, functional, performance,environmental etc.). In particular is the human component being unduly relied upon. Areasonableness check could be to relate the intended system architecture with the existingarchitecture, for example data-link replacing voice communication path to ensure that thesafety objectives of the new technology are not significantly different from the existingtechnology, given similar mitigation and similar hazard category. As another example, itis possible that one piece of mitigation is used to mitigate more than one fault orprocedural error considered in the ASOR. In such a case, the reliance on such mitigationis increased and therefore the reasonableness of this assumption and its reuse in manyplaces needs checking;

96


(5) The participants of the ASOR should determine the existence of applicable ICAOstandards. ICAO standards already exist for certain aspects considered in the ASOR (i.e.separation standards, RCP etc.). In many cases, these standards can be applied withoutfurther safety analysis, as the appropriate analysis would have been conducted duringtheir formulation. Additional safety justification of these standards therefore needs to bedetermined on a case by case basis;

(6) Consideration should be given to how a high-level system architecture as recorded in theOSED defines the allocation of function to the stakeholders. This high level descriptionwould describe how the concept of operations, the ATS procedures etc. build to a riskmitigation strategy, particularly where this description requires actions in differentstakeholders to describe a safe operation;

(7) Within particular stakeholders, there are many candidate risk mitigation strategies thatcan be used at the ASOR level. These may include but are not limited to:

97


(a) Remove the risk by removing the function;

(b) Remove the risk by changing the operational mode in which the function is mostcritical;

(c) Achieve the risk mitigation through verified risk mitigation strategies;

(d) Functional diversity;

(e) Zonal diversity;

(f) Design diversity;

(g) Isolation;

(h) Proven reliability;

(i) Failure warning or indication;

(j) Check procedures, flight crew/controller;

(k) Removal of common cause;

(l) Checkability - the capability to check a system capability;

(m) Designed failure effect limits;

(n) Designed failure path;

(o) Margins or factors of safety;

(p) Error tolerance; and

(q) Error avoidance, reduction, or transfer;

(8) The concept of the ASOR is to start with the Safety Objective derived from the OHA anddevelop an agreed strategy to implement these objectives, taking into account proceduraland architectural mitigation to derive a set of safety requirements. These safetyrequirements are generally composed of a function to be carried out, together with asafety objective. The purpose of the ASOR is to fulfill the safety objective with a set ofsafety requirements that are identified with specific stakeholders; and

(9) The decomposition of the risk mitigation stops when an event is fully dependent on oneapplicant only. Further decomposition of the risk mitigation within one applicant is theresponsibility of the applicant itself and should not be included within the OSA.

b. All operational safety objectives and requirements should be allocated to stakeholders and elementsof the CNS ATM System.

98


(1) A safety objective may be directly allocated to an applicant in its entirety or it may beapportioned across several stakeholders either wholly or by decomposing the safetyobjective into safety requirements and allocating the safety requirements to thestakeholders. Such apportionment can take two forms. Firstly, where the fault orprocedural error leading to the hazard can occur in more than one stakeholder, the safetyobjective is more stringent in each stakeholder than the original safety objective.Secondly, where the failure or procedural error leading to the hazard in one stakeholder ismitigated by functionality in another stakeholder, the safety objective may be lower thanthe original safety objective. For example, if a ground based system is relying onairborne avionics to detect any corruption of data that the ground system might cause,there is a requirement placed on the airborne system to perform the detection function.As a result, the ground system may have little or no safety requirements relative todetection of corrupted data being transmitted to the airborne system.

The level to which allocated safety requirements can be derived from the safetyobjectives is dependent on the degree to which the operational concept has beendeveloped. However, it is clearly necessary to be able to develop the OSA and ASOR toa stage that allows each stakeholder to identify the required functionality and theassociated safety performance required from this function; and

(2) Whatever risk mitigation strategy is adopted, the resultant allocation/apportionmentshould be documented.

c. Shared safety objectives and requirements should be coordinated across organizational boundaries:

(1) One of the principal reasons for conducting the OSA process is to allow for the fact thatthe various stakeholders implement systems to mitigate a risk that arises from anotherstakeholder. As such, it is necessary to ensure that safety requirements falling on onestakeholder as a result of a fault or procedural error leading to a hazard arising fromanother stakeholder are in fact met;

(2) If it is not possible to validate the safety requirement placed on one stakeholder, it isnecessary to review the safety requirement in the other stakeholder to determine if thesafety objective can still be met; and

(3) In some circumstances it may be necessary to retain the safety objective and itsassociated risk mitigation strategy for each stakeholder.

99


OPERATIONAL SERVICE :N° Operational hazard Specific mitigation or environmental factors Operational effects Operational

hazardclassification

Safety objectives and Environment requirements

OHA Template

100


Annex F: OPA Guidance

This annex provides guidance on how to define the performance requirements of any Air Traffic Servicessupported by data communication.

F.1 Introduction

F.1.1 Purpose

This paper provides the method for performing a CNS/ATM Operational Performance Assessment(OPA).

The structure of the document reflects the cycle inherent in the OPA process. It also sets the mathematicalprincipals and tools to be used.

F.1.2 Scope

The CNS/ATM OPA described here is an assessment of the performance of air traffic services supportedby data communications, within the context of the entire airspace system. The OPA envisages somecombined work groups and some assessments by individual stakeholders. The CNS/ATM OPAdocument was developed while considering air traffic services supported by data communications. OPAmethods are used to establish performance objectives or high level requirements needed to attain aparticular operational capability in a defined operational environment. Such requirements are allocated toparts of the system, procedures, or airspace characteristics. Qualification means are then applied todevelopment activities to ensure that specific implementations satisfy these requirements with acceptablelevels of confidence. In considering a multi-organizational system, the allocated requirements go beyondthe control of any one State or organization.

F.2 OPA Process

The steps undertaken in the OPA are:

• determine the Required Communication Performance Type (RCP Type);

• determine the Required Communication Technical Performance (RCTP) and HumanPerformance; and

• allocate RCTP to organizational domains.

F.3 Define the Scenario

Based on the work done in the Operational Service and Environment Definition (OSED), the varioustransactions should be analyzed and provide the appropriate input for the RCP determination.

F.4 Determine RCP Type

The objective of this sub-section is to provide a methodology to determine the Required CommunicationPerformance once captured, which identifies high level data link performance characteristics expected byusers and guarantee ATM safety and efficiency.

Before going through this methodology, data should be gathered from different sources of information(such as pilots, controllers, etc.), and inserted in the OSED template.

101


F.4.1 Required Communication Performance

Required Communication Performance, published for a given airspace or for an intended service,provides a quantitative requirement of the communication portion of the CNS concept. ATS serviceproviders specify RCP types in order to qualify a system to gain specific operational benefits. RCP typesare technology independent and include Human Factors. RCTP is used to quantify technical systemperformance requirements. Installed Communication Performance (ICP) is the qualified technicalperformance level and is compared to RCTP. Achieved Communication Performance (ACP) is themeasured operational performance level, in order to determine operational approval and monitorperformance, and is compared to RCP.

Aeronautical communication services may be considered as two-way transactions becausecommunication involves a dialog between two parties. For example, a transaction involving a request forclearance and subsequent clearance delivery can be thought of as a transaction containing a collection oftwo-way communications, with each two-way communication having its own process.From a technical standpoint, considering communication as two-way transactions avoids any problemsdue to asymmetry of the path and allows the direct comparison between voice and data communication tobe made.

The RCP is the operational framework to express the communication performance necessary foroperation within a defined airspace or to perform a specified operation.When determining airspace requirements, an RCP is determined according to safety analysis andoperational needs and is specified for ATS operational service for a given region that is deemed necessaryfor safe and efficient operation of the airspace. The RCP is independent of the technology used andapplicable to voice and data communication.

The RCP type is specified in terms of a set of parameters needed to quantify the performance of thecommunications transaction. The denomination of RCP type is provided by one of its parameters: thetransaction expiration time.The RCP type is further defined by a set of parameters listed in the following table.

Parameters Value DescriptionTransaction ExpirationTime (ETRCP)

Time Maximum time for completion of a transaction after whichpeer parties should revert to an alternative procedure

95% Transaction Time(TTRCP)

Time95%

Time before which 95% of the transactions are completed

Continuity (CRCP) Probability That the transaction will be completed before thetransaction expiration time, assuming that thecommunication system is available when the transaction isinitiated

Availability (ARCP) Probability That the communication system between the two parties isin service when it is needed

Integrity Risk (IRCP) Probability That the transaction is completed with undetected error.

Table F.4.1-1: RCP Set of Parameters

In principle each data link transaction would have an RCP Type, however, given the number of possibletransactions, the process has to be simplified. The simplification consists in grouping transactions into

102


broad categories and publishing a global RCP type for a type of airspace, based on the most stringenttransaction to be provided.

The RCP types are expressed in a table that gathers the performance characteristics. An RCP typeidentifies each column.

The values, which appear in this table, are provided as an example.

RCP

Performance Parameters

Planning Strategic Tactical Emergency

RCP Type 900 500 500-1 60

95% Transaction Time 750 Sec 300 Sec 150 Sec 50 Sec

Transaction Expiration Time 900 Sec 500 Sec 500 Sec 60 Sec

Continuity .99 .99 .999 .9999

Availability 0.99 0.99 0.99 0.999

Integrity 10E-5 10E-5 10E-5 10E-6

Table F.4.1.2: Example RCP Type Values Table

F.4.2 Determination of RCP Parameters

The objective of this paragraph is to help to complete table F.4.1-2 of the preceding paragraph. Themethodology developed here could be applied for both voice and data communication.

F.4.2.1 Determining RCP Type

The RCP Type is a parameter created in order to differentiate the different types of RCP. Thedenomination of RCP type is provided by the transaction expiration time:

• The first number of RCP type is elaborated by the Transaction Expiration Time value expressed inseconds; and

• The second number indicates a version number, and is incremented each time a new set of RCP typeis created with the same Transaction Expiration Time.

This method is used for each category of message: planning, strategic, tactical, or emergency.

F.4.2.2 Determining 95%Transaction Time and Transaction Expiration Time

1) Single Transaction Scenario

In a single transaction scenario, which is the case, for example, of an emergency type message, the 95%

103


Transaction Time equals the value TT, in seconds, determined by PIRGs in the OSED template.The Transaction Expiration Time equals the value ET, in seconds.

2) Two Linked Transactions Scenario

In a two linked transactions scenario, which is the case of a tactical type message, the 95% TransactionTime of the whole message could be the minimum of both transaction times TT1 and TT2; theTransaction Expiration Time should be the minimum of both transaction expiration times ET1 and ET2.

TT = min (TT1; TT2)ET = min (ET1; ET2)

3) Two Independent Transactions Scenario

In a two independent transactions scenario, which is the case of both planning and strategic typemessages, the 95% Transaction Time of the whole message could be the minimum of both transactiontimes TT1 and TT2. The Transaction Expiration Time should be the minimum of both transactionexpiration times ET1 and ET2.

TT = min (TT1; TT2)ET = min (ET1; ET2)

F.4.2.3 Determining Availability

1) Link availability

PIRGs determine, in the OSED communication environment characteristics template - availabilitycharacteristics paragraph, the acceptable link communication shutdown (when the link is down betweenone pilot and one controller), considering that it applies to every type of message. Assuming that anoperation is a flight over the longest path of a given area, the determination of the link availability needsto capture the maximum aircraft operating time (MAOT), and the total duration of the acceptable linkshutdown per operation (TDALSO).

The link availability is determined using the following formula:

ALink =1-[TDALSO (in minutes)/(60*MAOT (in hours))]

2) Area availability

PIRGs determine, in the OSED communication environment characteristics template - availabilitycharacteristics paragraph, the acceptable area communication outage (when the links are down betweenall pilots and controllers). Assuming that an operation is a flight over the longest path of a given area, thedetermination of the area availability needs to capture the ATS operating time (AOT), and the totalduration of the acceptable outage (TDAO).

The area availability is determined using the following formula:

AArea =1-[TDAO (in minutes per day)/(60*AOT (in hours per day))]

The total Availability to determine for RCP parameters is the link availability.

F.4.2.4 Determining Continuity

104


The determination of the continuity depends on the type of message that has to be transmitted, becausethe consequences of a transaction failure are different depending on whether the message, a tacticalmessage, a strategic message, or an emergency message.

For each type of message, PIRGs determine, in the OSED communication environment characteristicstemplate - continuity characteristic paragraph, the volume of acceptable transactions failed (VATF),which is the number of failed transactions (when the maximum time allowed for a transaction has beenexpired) out of 1000 transactions.

The continuity is determined using the following formula:

CONT= 1-[VAFT (transactions per 10E3 transactions)/10E3]

F.4.2.5 Determining Integrity

The determination of the integrity depends on the type of message which has to be transmitted, becausethe consequences of a corrupted message passing through the communication path are differentdepending on whether the message is a planning message, a tactical message, a strategic message, or anemergency message. When determining integrity safety objectives and requirements should beconsidered.

For each type of message, PIRGs determine, in the OSED communication environment characteristicstemplate - integrity characteristic paragraph, the volume of acceptable undetected corrupted transactions(VAUCT), which is the number of corrupted transactions received by a pilot or a controller out of 1000transactions.

The integrity risk is determined using the following formula:

INTRisk =VAUCT (transactions per 10E3 transactions)/10E3

F.5 Determine RCTP and Human Performance

The RCP for an ATS communication system includes the human interaction required to respond to areceived request and the technical performance of the ATS equipment in each domain of the system. Todetermine the RCTP of a system, the human performance is determined for each performance parameter.The human performance is then allocated from the system requirements to determine the resultingtechnical requirements for the system.

For the performance requirements of RCP that are specified as distributions and probabilities, a statisticalanalysis is accomplished to properly allocate the RCP performance parameters between the human andtechnical aspects. For a given system, the analysis is performed to determine the independence of thehuman performance probabilities and technical performance probabilities. If independence can bedetermined and if it is valid to assume a normal distribution, then simplified statistical mathematics maybe used to derive RCTP from RCP.

To declare independence of the human and system probabilities, the events must be mutually exclusive.The occurrence of a given event must not affect the probability any other event occurring.

If independence between the human performance and technical performance can be proven, the followingtheories can be utilized to perform the analysis. This allows for the performance parameters to beallocated between the human and system technology without having to solve complex mathematics.

1. The mean of each distribution may be summed to determine a total system mean.

105


µ1 + µ2 = µT

2. The variance of each independent distribution may be summed to determine a total system variance.(Variance is the square of the standard deviation δ)

δ12 + δ2

2 = δT2

3. The probability of an event is the product of the individual parts.

F.5.1 RCTP Determination

This paragraph provides the methods and guidelines for determining the Required CommunicationTechnical Requirement (RCTP) from a given Required Communication Requirement (RCP) of the airtraffic services (ATS) system. The performance parameters associated with determining RCTP addressedin this chapter are integrity, continuity, availability and transaction time.

The following sub-paragraphs describe the allocation of each performance parameter utilizing asimplified means of allocating. The concept allows the human performance to be subtracted from RCP toallow RCTP to be determined. These guidelines are analyzed to determine if they are valid for eachunique application.

F.5.1.1 Integrity

The Integrity component of RCP is a performance parameter that the ATS system meets end-to-end. Theprobability of undetected or incorrect data must meet the system requirements from the hardware,software, and human factors perspective.

In a transaction, the integrity of the system is composed of two messages and the human performance.The three events are independent, so the sum of the integrity probabilities is better than the integrityrequired by RCP.

The integrity of the human performance may be determined by any qualified and accepted human factorsstudy.

Integrity is represented as the probability of undetected failures per flight hour, or “Integrity Risk”.Therefore Integrity Risk (I) for RCTP can be determined as follows.

I RCP / I human = I RCTP

F.5.1.2 Availability

The Availability of RCP is determined by the link availability and human availability. The Availability isdetermined by the service to be provided, and is represented as the ratio of the total outages time over theexpected flight time, or Availability Risk. For an ATS system, the human availability may beapproximated to be always available. The link availability may be driven by either the equipment failurerates or by the networks operational coverage.

The RCTP availability is obtained by dividing the RCP availability over the controller or flight crewavailability.

A RCP / A human = A RCTP

If the controller or flight crew is assumed to be always available,

106


A RCP = A RCTP

F.5.1.3 Continuity

The link and human availability determine the Continuity of RCP over the duration of the transaction.Therefore, Continuity is represented as availability with an exposure time of the maximum transactiontime. For this performance parameter, the system is assumed available at the initiation of the firstmessage of the transaction.

The RCTP continuity is obtained by dividing the RCP continuity over the human continuity.

C RCP / C human = C RCTP

F.5.1.4 95% Transaction Time

The RCP Transaction Time is represented in units of time, typically seconds. It represents a time inwhich 95% probability of delivery success can be met. To determine the RCTP Transaction Timerequirement, the human performance transaction time is determined for 95% probability of deliverysuccess. The time can then be subtracted from the RCP Transaction Time requirement to determine theRCTP Transaction Time requirement.

The time component of human performance Transaction Time can then be subtracted from the RCPrequirement to determine the RCTP Transaction Time requirement. This simplified method may becalculated as follows and provides a stringent value for TTRCP:

TT RCP - TT human = TT RCTP

If an analysis of a higher fidelity is required, this can be accomplished based on the Satterthwaiteapproximation. The basis of the approximation assumes that the three distributions can be models asGamma distribution with a mean and 95% value. The mean and 95% values allow an accurateapproximation to be simply calculated.

µµµµ RCTP + µµµµ human + 1.666 δδδδ RCP = TT RCPwhere:δδδδ RCP = (∑∑∑∑ µµµµi2 (TTi / µµµµi) 2 / 2.776) 1/2

F.5.1.5 Expiration Time

The RCP Expiration Time is represented in units of time, typically seconds. To determine the RCTPExpiration Time requirement, the human performance Expiration Time is determined as a direct ratio ofRCP Transaction Time and Expiration Time.

ET human = ET RCP * (TT human / TT RCP)

The human Expiration Time can then be subtracted from the RCP Expiration Time requirement todetermine the RCTP Expiration Time requirement. This simplified method may be calculated as followsand provides a stringent value for ETRCP:

ET RCP - ET human = ET RCTP

107


F.5.2 Analysis of Human Performance

The human performance component of the ATS system has a determined starting point and ending pointin the exchange of ATS communications. There are three human contributions to the performance:

- at the initiation of the transaction when the initiator prepares the message;

- when the responder receives and formulate the response, the starting point is at the instancewhen the controller or flight crew has received and displayed an ATS message. The endpoint is at the instance when the same controller or flight crew sends the response back to theinitiator; and

- when the initiator accesses the response.

In this process, the main factor of human performance that has a dependence on the systems technologicalperformance is the human-machine user interface.

The human-machine user interface is designed to support the human activity and is considered as part ofthe RCTP since improving on the technology may improve the performance of the interface.

Making an association of the human factor issues with the transaction delay, availability, continuity andintegrity performance parameters of the RCP concept may summarize the contribution of the human tothe communication performance.

The following guidance for human factor credit has been developed to determine the human contributionto the communication performance including hazard identification, conflict resolution or crisismanagement.

F.5.2.1 95% Transaction Time

The human contribution to the 95% RCP transaction time could be assumed to be modeled by a normaldistribution and includes the contribution of the HMI.

The human machine interface is taken into account in the transaction time for the responder.For the initiator, as the HMI contribution cannot be measured easily, some assumptions are made basedon HMI access time budget that should be demonstrated by ergonomic analysis and measure.

108


Initiator Responder

95% HumanResponse Time

TransactionExpiration

Time


REQUEST

RESPONSE

95%Transaction

Time

HMI access Time

HMI access TimeHMI access Time

HMI access Time

Figure F.5.2.1-1: Transaction Time


It is possible to make an assumption that the availability of the humans is essentially 1, meaning there arenever any ‘outages’. This position is supported because both in the cockpit and at the controller positionthere is immediate backup and constant vigilance of the communications. If we assume that availabilityis equal to1, the inclusion of the human performance for these parameters is completely consistent withcharacterization of the remainder of the communications system.

F.5.2.3 Continuity

The continuity reflects the probability to exceeding the transaction expiration time. While the assumptionis that the human is always available, the human may introduce delays in the communication process dueto reasons such as workload. When the delay is long enough to cause the transaction to fail, the humancauses a loss of continuity. It is necessary to determine how often this situation is likely to occur in orderto establish the human contribution to the transaction continuity.

F.5.2.4 Integrity

Humans contribute to the integrity in two ways: first, the human knows the situation and could be able toidentify corrupted received information, second, the human could introduce errors when transmitting orreceiving messages.The integrity parameter might be related to the probability of detection and introduction of errors.

Data SourcesThe magnitude of the human contribution in respect to workload, human reaction time and proceduresshould be established by the appropriate PIRG. Other sources of data, such as that for pilots, should beconsistent with existing regulatory requirements.

F.6 RCTP Allocation to Domains

This sub-section provides the methods and guidelines for allocating ATS performance parameterrequirements to each domain of the ATS system (airborne domain, network domain, and ATS domain).In addition, it provides the methods and guidelines for consolidation of the installed performance

109


parameters from each domain of the ATS system. The relevant performance factors are integrity,continuity, availability and transaction time.

One objective of the OPA is to provide a method of specifying performance requirements to assure thatthe ATS service to be provided are supported by the equipment and technologies expected to be used inthe system.

This sub-section does not provide requirements, but is intended to provide guidance to how allocation andconsolidation of requirements may be done. It also provides information on aspects that need to beconsidered when determining allocations to the system performance requirement.

Section F.6.1 of this annex addresses factors that are taken into consideration when allocating ATSperformance requirements. Section F.6.2 presents a simplified means of determining ATS performanceparameter allocations, and consolidation of these requirements.

F.6.1 System Analysis

The ATS system allows for each domain to be independently developed. Therefore, the systemperformance requirements are allocated to enable the organizational domain developer to be aware of theperformance requirements that are levied on the sub-system being produced. Conversely, installedperformances are mathematically consolidated to determine if a total ICP meets the system requirements(RCTP).

A domain is developed to accomplish the specified system level requirements. The requirement may beimplemented with unique means. For example, the Network Domain may be based on the ACARSsystem, or it may be based on ATN. The ACARS system may be composed of VHF datalink, Satcomdatalink, HF datalink, or any combination thereof. In addition, each domain may be further divided intoproducts of individual sub-systems. For the purposes of this analysis, each domain is specified aperformance budget, and it is up to the stakeholder responsible for the domain to allocate performancebudgets to the lower level. The concepts described in this chapter may be used to allocate budgets to sub-systems of a domain.

Various methods were considered to obtain the performance requirements for each domain. Based on thestatistical nature of the top-level requirements, the logical allocation of time would be a statisticaldistribution. A statistical requirement would allow for a domain to occasionally fail its allocated timerequirements but allow the system to be operationally acceptable by taking advantage of the allowedprobability of failure.

The information in this section is primarily focused on the Transaction time requirement. TheTransaction time presents some challenging aspects that need to be properly addressed if a validTransaction time allocation or consolidation is to be made. The Integrity, Availability, and Continuityallocations and consolidations are more straightforward. These performance parameters can be allocatedor consolidated using more conventional mathematical methods and is described in paragraph F.6.2.

F.6.1.1 Assumptions

To perform a mathematical analysis of the system, a few initial assumptions are made. The assumptionsare required such that limits may be set to make the problem reasonably solvable. Although someassumptions can be made which would introduce minimal or no errors, many of the assumptions requiredto create a simplified mathematical analysis of the system will cause errors in the results. Eachassumption is carefully assessed to assure a valid analysis.

The assumptions that can be reasonably made are:

110


1. For Transaction time, the analysis pertains to the time during which the entire system is considered“available”. The system may become “unavailable” after initiation of the message, but must beperceived as “available” prior to initiation;

2. The maximum message size is determined by the interoperability methodology;

3. The actual Domain transit times will not exhibit a normal distribution. This is due to the documentedsystem design with respect to retry timers and counters;

4. The end time is when the message is available for the flight crew or controller to view. It does notaccount for human actions required to view the message. Reference the definition of RCTP; and

5. The maximum length of the message used to determine RCP may differ from the maximum messagelength for the service. The sizes of the messages are identified to determine the ICP for each domain.

The Ideal ModelThe three domains in the ATS system operate as one end-to-end system. All boundaries between thedomains have logical protocols that create a dependency link between the neighboring domains.Therefore, since the specified domains are not truly independent, the ideal solution for transaction delaywould require a Markov analysis on the entire system to determine the mean value of processing rate for asingle message such that Xn messages are delivered with a specified requirement. The Markov analysiswould also account for the random “entry” of messages into the system over an infinite time. Thissolution would take into account the fact that the three domains are dependent no matter where theboundaries are set. This analysis becomes complex when three domains are considered together, andsince there is a dependency between each domain, a complete system analysis would be the only means ofan accurate performance requirement.

To avoid a Markov analysis over three domains, the domains must be determined to be independent. Inaddition, the analysis is limited to the probability of delivery of a single message.

F.6.1.2 Determining A Simplified Model

An alternative method to analyze the entire network is to make some assumptions that would create threedomains whose distributions are independent. If these can be substantiated, the distributions of eachdomain can be summed. This would also open the possibility of summing variances (square of standarddeviation) of each individual distribution. This along with the fact that means may always be summedleads to interesting possibilities of simple probability analysis.

To declare independence of two probabilities, the events must be mutually exclusive. The occurrence of agiven event occurring must not affect the probability of any other event occurring.

If independence between the domains can be proven, the following theories can be utilized to perform theanalysis.

1. The mean of each distribution may be summed to determine a total system mean;µ1 + µ2 + µ3 = µT

2. The variance of each independent distribution may be summed to determine a total system variance.(Variance is the square of the standard deviation δ);

δ12 + δ2

2 + δ32 = δT

2

3. The mathematical sum for three normal distributions can be derived by summing the distributions, ordirectly from the individual means and variances; and

111


4. The mathematical sum of the three distributions where all probabilities are not normally distributed, isthe convolution of the three distributions.

If independence cannot be determined, a complex end-to-end system analysis is modeled, which is moresuited for analysis by software programs such as ReliaSoft, IRAP, or BONeS.

F.6.1.2.1 Single Message Analysis

In addition to the independence criteria, a complete system analysis would require the system to beanalyzed with a random entry of messages from both ends. The analysis can be simplified if anassumption can be made that only one ATS message is in the system at a time. If analysis is performedwith only a single message in the system, many of the queuing issues, which cause non-independence,can be resolved.

It must be understood that if a second message is introduced to the system prior to the completion of thetransmission of the first, the system's performance will be affected. This is taken into account by thesystem designer. In operations with low datalink activity, one message at a time may be a validassumption and the analysis can proceed with a single message model. In operations with high datalinkactivity, this assumption may not be valid.

For the boundaries between each Domain, if a single message is assumed to be in the system at a time, theaspect of queued messages in one Domain affecting the other is resolved, which may lead toindependence of the domains.

F.6.1.2.2 Independent Domain Analysis For a Single Message

To make the assumption of independence in the ATS system, the boundaries of the domains are properlyselected to minimize the influence of the neighboring domain.

F.6.1.2.2.1 Airborne/Network Boundary - Downlinks

This boundary initially fails independence because the state of the previous downlink message affects thedelivery of a new message from the Airborne domain to the Network domain. In the case of theFMC/ACARS MU interface, the ACARS MU may reply to the FMC with a Williamsburg BUSY if it isstill in the process of downlinking a message.

If the assumption is made that only a single message is in the system during the transaction, this boundaryin the downlink direction can be considered independent.

F.6.1.2.2.2 Network/ATS Boundary - Downlinks

If it can be determined that ATS processing is faster than the maximum reception time of a message fromthe modem (via X25 etc), this boundary can be considered independent.

F.6.1.2.2.3 Airborne/Network Boundary - Uplinks

This boundary initially fails independence because of the buffering capability of the airborne end systemthat hosts the ATS applications is less than the rate in which messages can be uplinked. Although thebuffer may be deep, there is dependence.

Again, if the assumption is made that only a single message is in the system during the transaction, thisboundary in the uplink direction can be considered independent.

112


F.6.1.2.2.4 Network/ATS Boundary - Uplinks

If it can be determined that the speed in which the controller generates a message is significantly slowerthan the rate which a message is transmitted to the modem, this boundary can be considered independent.In addition, if only a single message is allowed to be in the system during the transaction for the analysis,the boundary can be considered independent.

Therefore, based on the specified boundaries, sufficient independence can be declared when theassumption for a single message is made.

F.6.1.2.2.5 Modeling a Domain

Assuming a mathematical function of each domain can be determined, where only a single domain is non-normal, the mathematics may become complex. For a system with a non-normal distribution, theindividual domain distributions are first determined, then they are convoluted to obtain the systemcharacteristics. If a second domain is determined to be a non-normal distribution, the mathematicsbecomes even more complex.

Assuming the sum of the three distributions can be obtained, a Weibull analysis may be performed todetermine if the system meets its specified timing requirement. A Weibull plot shows the probabilityversus time relationship for the system. Computer programs such as Weibull++ can be utilized toautomate this task.

Figure F.6.1.2.2.5-1: Sample Weibull Plot

The assumption above is that a mathematical function for each distribution can be determined. For theAirborne and ATS Domain, this may be a determinable task. Based on the boundaries, the distributionsof the Airborne and ATS Domains may be so close to normal that it can be modeled as a normaldistribution without inducing a significant error into the total (assuming independence). This would makeit easy to allocate a mean and variance to each of these domains.

113


The Network Domain is much more challenging. Simplistically, it resembles a series of overlappingnormal distributions with varying means and standard deviations. The computer programs listed insection F6.1.2 can be utilized to generate a theoretical distribution for this domain. From the distribution,a mean and variance can be allocated to the Domain as a requirement. For existing systems, computerprograms are also available which allow sampled data to be entered and a distribution could be generated.

Analysis of the Network Domain can be done to prove that if enough randomness of the various processrates within the Network Domain exists, then the distribution can be approximated as normal, the solutionwould become easier.

F.6.2 Performance Allocations and Consolidation

The mathematical analysis presented in Section F.6.1 relies on complex mathematics to analyze thesystem and allocate performance budgets. If the methods present a challenge to the resolution of theperformance allocations, a simplified method can be established. The following sub-paragraphs describethe allocation of each performance parameter, and a simplified means of allocating budgets. In addition,the methods and equations presented may be used for the consolidation of an individual performanceparameter.

F.6.2.1 Integrity

Integrity is a performance parameter that the ATS system must meet end-to-end. The end system is builtto ensure that the probability of corrupted data meets the system requirements from the hardware andsoftware perspective. A means is provided to detect corruption of messages communicated end-to-end toa level equal to or better than the integrity requirements of the system.

If a high integrity sub-network is used, the message integrity is a function of the integrity of the sub-networks used and the end systems. In this case, an end-to-end means of integrity assurance for such sub-networks may not be required.

Sub-networks and sub-systems within the system comply with appropriate international or industrystandards, and should be consistent with the end-to-end integrity requirement. It is up to the responsiblestakeholder of the domain to assure the sum of contributing parts meet the system requirement.

A hazard analysis of each system should be performed to determine the integrity of the system.Manufacturer data or mathematical models may be used to determine failure rates. A failure analysisshould then be performed to determine that undetectable system faults would not contribute to ahazardous condition. The exposure time should be chosen appropriately based on the capability of asystem or operation to detect a failure. Integrity should be represented as the risk of non-detection ofmessage corruption, or “Integrity Risk”.


The systems availability is defined by the link Availability. For an ATS system, the individual domainavailability may be driven by either the equipment failure rates or by the networks operational coverage.The link Availability is the total system availability, based on system failure rates and network coverage.

The Availability is determined by the service to be provided. The product of the individual domainavailabilities is greater than the required system Availability. The Availability should be represented as aratio of “up-time” to the total required operating time.

For a specific system, the Availability may be manipulated to allocate more or less availability as long asthe product of the three Availability values exceeds the system requirement.

114


A airborne * A network * A ATS > A RCTP

As an example for equal allocation, the individual domain Availability values can be determined bytaking the cube root of the system Availability value. This assures that the product of the individualavailability values meets the system requirement. This provides an equal share of the availabilityrequirement to each domain.

A airborne > (A RCTP) 1/3

A network > (A RCTP) 1/3

A ATS > (A RCTP) 1/3

Note that equal allocation may not be practical in a real system. In a real system, it may be determinedthat the network have a higher availability than the aircraft or ATS because the network supportscommunications between multiple aircraft and ATSs. In this case, the high availability requirement islevied onto the network, and the remainder of the RCTP Availability may be divided between theairborne system and ATS.

F.6.2.3 Continuity

Continuity is defined as the link availability over the duration of the transaction. Therefore, Continuity isrepresented as an availability value with an exposure time of the maximum transaction time. For thisperformance parameter, the system is assumed available at the initiation of the first message of thetransaction.

For a specific system, the Continuities may be manipulated to allocate more or less availability values aslong as the product of the three Continuities exceeds the system requirement.

C airborne * C network * C ATS > C RCTP

As an example for equal allocation, the individual domain Continuity can be determined by taking thecube root of the system Continuity. This assures the product of the individual continuities meet thesystem requirement. This provides an equal share of the continuity requirement to each domain.

C airborne > (C RCTP) 1/3

C network > (C RCTP) 1/3

C ATS > (C RCTP) 1/3

Note that equal allocation may not be practical in a real system. The allocation to Continuity should bedone with the same ratios used in determining availability.

F.6.2.4 Transaction Time

Based on the assumption that reasonable independence can be declared between each domain in theuplink and downlink directions, a discrete allocation of time can be made to each domain. Theallocations of the Transaction Time are best made by understanding the technology available to supportthe intended operation. Experience with existing systems provides a benchmark for the allocation of themessage delivery requirement.

Transaction Time is represented in units of time, typically seconds. It represents a time in which aspecified probability of delivery can be met. This simplified method may be calculated as follows andprovides a stringent value for allocated TT to domains:

115


TT airborne + TT network + TT ATS = TT RCTP

Since RCTP is for a transaction, the Time and Probability allocated in each domain is related to thenumber of times that a message traverses the domain for the specified operation. For a two-waycommunication, the Transaction Time reflects the request and response messages traversing the domain.

If an analysis of a higher fidelity is required, this can be accomplished based on the Satterthwaiteapproximation. The basis of the approximation assumes that the three distributions can be models asGamma distribution with a mean and 95% value. The mean and 95% values allow an accurateapproximation to be simply calculated.

µµµµ airborne + µµµµ network + µµµµ ATS + 1.666 δδδδ RCTP = TT RCTP

where:δδδδ RCTP = (∑∑∑∑ µµµµi2 (TTi / µµµµi)2 / 2.776) ½

F.6.2.5 Expiration Time

Based on the assumption that reasonable independence can be declared between each domain in theuplink and downlink directions, a discrete allocation of time can be made to each domain. Theallocations of the Expiration Time are best made by understanding the technology available to support theintended operation. Experience with existing systems provides a benchmark for the allocation of themessage delivery requirement.

Expiration Time is represented in units of time, typically seconds. It represents a time in which a specifiedprobability of delivery can be met. This simplified method may be calculated as follows and provides astringent value for allocated ET to domains:

ET airborne + ET network + ET ATS = ET RCTP

F.7 OPA TEMPLATE

F.7.1 Introduction

F.7.1.1 Purpose

This document provides a template to capture the results of the OPA process.

F.7.1.2 Scope

The results gathered in this document come from the analysis performed through the OPA process fromthe OSED filled in template.

F.7.1.3 Contributors to This Document

This operational performance assessment (OPA) was performed by Group Identifier with the followingmembership:

Name Organization

F.7.2. Results of the RCP Determination

116


This section should at least contain a description of the RCP type that is needed.

F.7.3 Results of the RCTP and Human Factor Determination

F.7.4 Results of the RCTP Allocation to Domains

117


Annex G: INTEROP Guidance

This annex provides guidance on how to define the interoperability requirements of any Air TrafficServices supported by data communication. It also provides a template of the document, which wouldresult from the Interoperability Assessment (IA) process.

A typical INTEROP Standard would consist of the following documentation.

G.1 Introduction

G.1.1 Purpose

The purpose of this document is to provide interoperability requirements for air traffic services (ATS)supported by data communications. Interoperability requirements are the minimum technical andfunctional requirements that provide the basis for ensuring compatibility among the various elements ofthe CNS/ATM system using a specific technology. These elements comprise the distributedcommunication services and ATS applications in the aircraft system, the communication serviceproviders' system and the ATS provider system. This document should:

• Define interoperability requirements for the communication services;

• Define interoperability requirements for the ATS applications; and

• Allocate the interoperability requirements to stakeholders.

G.1.2 Scope

This paragraph of the document identifies the ATS, ATS applications and data communicationtechnology which are addressed in the document. This paragraph should point out areas which may be related to the interoperability requirements, but arenot covered by this set of interoperabilty requirements (e.g., ground-ground data communicationsbetween ATS providers or between an ATS provider and an Airline Operational Control (AOC) facility,air-ground data communications between an aircraft and an AOC facility, other).

G.1.3 Relationships to other Documents This paragraph of the document should show how this document relates or not to OSED and SPR in orderto provide traceability.

G.1.4 How to use this Document

G.1.4.1 Mandating and Recommendation Phrases

This document should contain "shall" and "should" statements with the following meanings:The use of the word "shall" indicates a mandated criterion; i.e. compliance with the particular procedureor specification is mandatory and no alternative may be applied.

The use of the word "should" (and phrases such as "It is recommended that…", etc.) indicate that thoughthe procedure or criterion is regarded as the preferred option, alternative procedures, specifications orcriteria may be applied to elements of the CNS/ATM system that impact interoperability, provided thatthe applicant can provide information or data to adequately support and justify the alternative.

118


G.1.4.2 Document Organization This sub-paragraph of the document should contain a brief overview of the major sections of thedocument, and their intended use. This sub-paragraph of the document should also include any guidance on the use or interpretation ofmajor sections of the document, such as specialized forms and requirements representation formats (e.g.Protocol Implementation Conformance Statements and Operational Implementation ConformanceStatements (PICS/OICS)).

G.1.4.3 Acronyms and Abbreviations

This sub-paragraph of the document should include only key acronyms and abbreviations used in theINTEROP document. The document “Guidelines for Approval of the Provision and Use of ATSsupported by Data Communications” includes the primary Acronyms and Abbreviations list and theGlossary of Terms.

G.1.5 References This paragraph of the document should include a specific list of documents, and the relevant versionnumbers, which are used as the basis for the interoperability requirements. Documents such as ICAOSARPS, OSEDs, SPRs, ISO standards, ARINC specifications, other RTCA/EUROCAE standards, etc.,should be listed here. If a document must be adhered to as part of the interoperability solutions (e.g. ICAO SARPS), this shouldbe explicitly stated. Formally published deviations or changes to the above standards should also be listed, e.g. ICAO SARPS Proposed Defect Reports (PDR).

G.2 System Description

This sub-section should provide a high level description of the ATS supported by data communicationsand the selected data communication technology derived from the OSED. The data link applications andthe aircraft and ATS ground system functions required to support the ATS should be identified. If onlysubsets of the data link applications are to be implemented, the subsets should be defined. Ifinteroperability is dependant upon any assumptions about the operational environment or technical andfunctional capabilities, the assumptions should be included.

G.3 Requirements For Communication Services This sub-section of the document should provide a general description of, and the major interoperabilityissues for, the communications technologies applied to this implementation. This sub-section of the document should define any interoperability requirements for the communicationschain, to include such things as addressing, routing, interface specification issues, communicationsmanagement, overall transfer delay requirements, partitioning of transfer delay time allocations on thevarious end-end system components, and security. In addition to the specific communications systems involved, this section should identify interoperabilityrequirements for the use of those communications systems which are levied on the user ATS provider oravionics systems, if applicable (e.g. address usage, interface specifications, etc.).

119


Formal methods for requirements representation and analysis (e.g. PICS/OICS) are encouraged wherethey can convey additional clarity to textual requirements statements. In keeping with the general principle of the interoperability requirements, only requirements further tothose already stated in reference documents should be stated. The aim is not to duplicate material alreadypresent in the reference documents, only to clarify, add to, or identify non-compliancies to such material. Note: The above items are provided as examples only and are not exhaustive. Not all elements describedabove need to be provided, only those relevant to interoperability for the target communicationstechnologies.

G.4 Requirements for ATS Applications This sub-section of the document should state any interoperability requirements for the communicationsapplications used by this implementation. For ATN and 1st generation FANS these include ContextManagement ATS Facilities Notification, Controller Pilot Data Link Communication, and AutomaticDependant Surveillance. ATN also includes the Flight Information Service (FIS) and ATS InterfacilityData-link Communication (AIDC) applications. The sub-section should be divided into one paragraph foreach application, e.g.G.4.1 CMA, G.4.2 ADS, G.4.3 CPDLC, etc: • the use or non-use of available data elements and message types and reports;

• the computation or manipulation of data for the generation of such messages and reports which mayaffect the interpretation and treatment of those message types by recipients;

• required responses to received messages (message pairs) and permitted or prohibited combinations ofdifferent message elements;

• the handling of transition between airspaces which use or do not use unique parts of the applications;

• functions that are required to generate the data used by the applications. These include groundautomation functions, navigation, aircraft performance predictions and flight management; and

• abnormal event handling and recovery, and interoperability requirements associated with recoveryfrom those modes.

Formal methods for requirements representation and analysis (e.g. PICS/OICS) are encouraged wherethey can convey additional clarity to textual requirements statements. In keeping with the general principle of the interoperability requirements, only requirements further tothose already stated in reference documents should be defined. The aim is not to duplicate materialalready present in the reference documents, only to clarify, add to, or identify non-compliancies. Note: The above items are provided as examples only and are not exhaustive. Not all elements in theabove list need to be provided, only those relevant to interoperability for the target communicationstechnologies and applications.

G.5 Dynamic Functions / Operations This sub-section of the document should state any interoperability requirements and constraints for thedynamic aspects of using the applications described in the preceding sub-section.

120


This sub-section should provide the technical detail for the operational air traffic service descriptions inthe OSED, and should include the interoperability requirements associated with setting up, tearing down,and transferring communications connections at the applications level. Interoperability requirementsshould include the timing and specific exchange sequences for logging on and establishing technicalconnectivity, and conducting operational message exchanges, as well as other dynamic aspects of usingand managing the applications used. In keeping with the general principle of the interoperability requirements, only requirements further tothose already stated in reference documents are stated. The aim is not to duplicate material alreadypresent in the reference documents, only to clarify, add to, or identify non-compliancies. Note: The above items are provided as examples only and are not exhaustive. Not all elements in theabove list need to be provided, only those relevant to interoperability for the target communicationstechnologies, applications and the air traffic services they support.

G.6 Allocation of Interoperability Requirements

This sub-section should allocate the requirements from sub-sections 3, 4 and 5 among the variousstakeholders. The purpose of this section can be fulfilled by PICS/OICS for ATN.

G.7 Unique Characteristics

The intent of the INTEROP standard is to harmonize technical and functional implementations so that allaircraft and ground system elements of the CNS/ATM system that contribute to ATS supported by datacommunications can interoperate. Nevertheless, some elements of the CNS/ATM system may haveunique characteristics for a variety of reasons. These may include procedural constraints, legacy systemfeature, lack of standards for supporting functions and the need to accommodate mixes of technology andtechnical capability. These characteristics may impact interoperability and require operational proceduresto accommodate the unique characteristics.

This sub-section should identify such unique characteristics and identify the means to accommodate themto maintain interoperability.

It is intended that this sub-section provide guidance to specification writers and designers of otherelements of the CNS/ATM system.

Note: when PICS/OICS are included in the INTEROP standard, they contain unique characteristics. ThisAppendix will not be required.