Attachment_2_Govt_Spec_for_FMF_SW_App_Rev_A_29_June_2017_w_signatures.pdf

Government Specification (GS) for

Flight Management Function (FMF) Software Application

FMF Software Application

NAVAIR PMA209

DISTRIBUTION STATEMENT D - Distribution authorized to Department of Defense and DOD contractors only, Critical Technology, 3 April 2017. Other requests for this document SHALL be referred to the United States Navy, Program Executive Officer, (PMA209), NAS Patuxent River MD 20670

DESTRUCTION NOTICE - Destroy by any method that will prevent disclosure of contents or reconstruction of document. Local reproduction authorized.

Rev A, 28 June 2017

REVISION HISTORY

REV / DATE APPROVED

Rev – / April 07, 2017

Rev A / 28 June 2017

Revision Record

Revision Date Description Affected Sections

Rev - 07 Apr

Initial Release All

Rev A 28 Jun

Correct table references for RTCA DO-283 (from x.y to x-y)

Throughout document

Corrected figure references to match numbering of the actual figure located in the document.

Throughout document

Corrected figure references. 3.2.2.1.2.6.2 Notes 4, 5, 6, 7, &

Added two requirements (9th and 10th shall). 3.2.2.1.2.6.4

Added one requirement (2nd shall). 3.2.2.1.2.6.4.1.1

Added one requirement (2nd shall). 3.2.2.1.2.6.4.1.2

Added one requirement (2nd shall). 3.2.2.1.2.6.4.1.3

Added word “automatically” to the 27th shall statement.

3.2.2.1.2.7

Added paragraph spacing to the note. No word changes.

3.2.2.1.2.12.3

Broke current requirement into two shall statements.

3.2.2.1.4.9

Removed “displays or” from 3rd shall statement.

3.2.2.1.4.12

Changed “listed previously” to “in section 3.2.2.2.2.6”

3.2.2.2.2.6.1.1

Removed third sentence (it was not a requirement statement).

3.2.2.2.2.6.1.3

Added subscript to “delta H” in Note 2. 3.2.2.2.2.6.1.3

Added “if” to the ‘should” statement. 3.2.2.2.3

Changed first “shall” to a “should”. 3.2.2.2.3.1

Deleted all after “defined path” in first sentence and added note.

3.2.2.2.4.2

Changed “not less” to “not more” 3.2.2.2.4.2.1.2

Reworded requirement to be in line with DO- 283.

3.2.2.2.4.5

Reworded requirement into one “shall” and one “should” to be in line with DO-283.

3.2.2.2.4.6

Added second “shall” to be in line with DO- 283.

3.2.2.2.4.7

Added “and output” to the second requirement.

3.2.2.2.4.8

Added “provide an output to” for both the “shall” statement and the “should” statement.

3.2.2.2.4.9

Deleted first note, it was redundant with another note earlier in the document.

3.2.2.5

Table of Contents

1. Scope

1.1 Identification

1.2 System Architecture and Overview

1.2.1 Notional aircraft Software Architecture

1.3 RNP RNAV Operations

1.3.1 RNP Operations

1.3.2 RNAV Operations

1.3.3 RNAV Instrument Approach Procedures (IAP)

1.4 Document Overview

1.4.1 Terminology

1.4.2 Document Structure

2. Referenced Documents

2.1 Government Documents

2.2 Non-Government Documents

3. Requirements Section

3.1 FACE Application Requirements

3.2 SOFTWARE REQUIREMENTS

3.2.1 General Requirements

3.2.2 Software Performance - Standard Conditions

3.2.2.1 2D (RNAV) Function and Performance

3.2.2.1.1 Position Estimation

Estimate of Present Position

3.2.2.1.1.2 Estimate of Position Uncertainty (EPU)

3.2.2.1.1.3 Containment Radius

3.2.2.1.1.4 Position Initialization

Navigation Aid Selection

3.2.2.1.1.5.1 Equipment

3.2.2.1.1.6 Navigation Sensors

3.2.2.1.2 Path Definition

Leg Types

Flight Planning

Direct-To Function

Entry of User-Defined Fixes

User-Defined Course-to-a-Fix

RNP Holding (Objective)

Parallel Offsets

Magnetic Variation

Transitions Between Legs

Data Resolution

Navigation Database

RNP

3.2.2.1.3 Path Steering

Fix/Leg Sequencing

Continuous Lateral Path Steering

Nearest Airport Function (Objective)

3.2.2.1.4 Outputs and System Alerting

Cross Track Deviation Display

Fix Distance Display

TO-FROM Indication

Bearing and Distance to Fix

Display of Fix Identifier

Display of Fix Latitude/Longitude

Desired Track

Groundspeed

Track Angle and Track Angle Error

Selection of RNP

Navigation Sensor Indication

Failure/Status Indications and Alerting

3.2.2.1.5 Reserved

3.2.2.1.6 Lateral Control Performance

3.2.2.1.7 Speed Control Performance

Speed Restrictions

3.2.2.2 Vertical Navigation (VNAV) Functional and Performance Requirements

3.2.2.2.1 Vertical Position Estimation

3.2.2.2.2 Vertical Path Definition

General

Altitude Constraints

Speed Restrictions

Vertical Direct-To

Reserved

3.2.2.2.3 Vertical Path Steering

Transition to Missed Approach

3.2.2.2.4 VNAV Displays and Alerting

General

Vertical Deviation

Altitude and Speed Predictions

Level Flight Transition

Altitude Constraints

Speed Restrictions

Flight Path Angles

Vertical Navigation Operations

Vertical Alerting

3.2.2.2.5 Temperature Compensation

3.2.2.3 Estimated Time of Arrival

3.2.2.3.1 ETA Accuracy

3.2.2.3.2 ETA Response Time

3.2.2.4 Reserved

3.2.2.5 Localizer Performance (LP) and Localizer Performance with Vertical Guidance (LPV) Function and Performance

3.2.2.5.1 Reserved

3.2.2.5.2 Path Selection

Five (5)-Digit Channel Selection

Approach Name Selection

Missed Approach Sequencing

Selection of the Approach Type

3.2.2.5.3 Path Definition

Approach Path Definition

Missed Approach Path Definition

Navigation Center Offset

3.2.2.5.4 Navigation Displays

Primary Navigation Displays

Non-Numeric Lateral Cross-Track Deviation

Numeric Lateral Cross-Track Deviation

Non-Numeric Vertical Deviation

Missed Approach Waypoint/LTP/FTP Distance Display

Missed Approach Waypoint/LTP/FTP Bearing Display

Displayed Data Update Rate

Reserved

Display of Vertical Accuracy

3.2.2.5.5 Database Requirements

Reserved

Data Integrity

3.2.2.5.6 Alerts

Alert Limits

Caution Associated with Loss of Integrity Monitoring

Caution Associated with Loss of Navigation

Low Altitude Alert

Alerting Scheme

3.2.2.5.7 Approach/Departure Mode Switching Requirements

Entry Criteria

Exit Criteria

Display Transition

Advisory Approach Mode Availability

3.3 Software Quality

3.3.1 Defect Reporting

3.3.2 Software Reliability

3.3.3 Software Maintainability

3.3.4 Software Security

3.4 General Requirements

3.4.1 Platform Performance Data

3.4.2 Single and Dual FMF Environments

3.4.3 Multiple Approaches in a Single Flight Plan (Objective)

3.4.4 External Database

3.4.5 Operational Program Configuration

4. Verification

5. Acronyms and Abbreviations

6. Notes

List of Tables

Table 1: 3.2-2 Maximum Holding Airspeeds (KIAS) Table 2: 3.2-8 Operational Applicability of Speed Restrictions Table 3: 3.2-9 Example of Height Loss for Vertical Fly-By Table 4: 3.2-10 VNAV Output/Entry Resolution Table 5: 3.2-10 Non-Numeric Display Requirements Table 6: 3.2-11 Definition of Default Navigation Modes Table 7: 3.2-12 Summary of Typical Mode Switching Transitions Table 8: 3.2-13 Summary of Changes in Cross-Track Full Scale Deflection for Mode Switching

List of Figures

Figure 1: Notional Aircraft Single FMF Software Environment Software Architecture Figure 2: Notional Aircraft Dual FMF Software Environments Architecture Figure 3: 3.2-0 Single Waypoint Serving Multiple RNP Procedures Figure 4: 3.2-1 Holding Pattern Definition Figure 5: 3.2.2.1-4 Entry Sectors Figure 6: 3.2.2.1-5 Sector 1 Entry Procedure Figure 7:3.2.2.1-6 Sector 2 Entry Procedure Figure 8: 3.2.2.1-7 Sector 3 Entry Procedures Figure 9: 3.2.2.1-8 Sector 4 Entry Procedures Figure 10: 3.2-2 Offset Path Definition Figure 11: 3.2-3 Typical Fly-by Transitions at Offset Start Point Figure 12: 3.2-4 Fly-By Theoretical Transition Area Figure 13: 3.2-4.1 Fly-Over Theoretical Transition Area Figure 14: 3.2-5 Fixed-Radius Transition Figure 15: 3.2-6 Descent Path Permitted by Two "WINDOW" Constraints, Two "AT" Constraints and Cruise Altitude Figure 16: 3.2-7 Descent Path defined by AT constraints and a Cruise Altitude Figure 17: 3.2-8 Waypoint with Vertical Constraint Figure 18: 3.2-9 Fly-By Transition Figure 19: 3.2-14 Final Approach Segment Definition Figure 20: 3.2-11 Full-Scale Deflection and Defined Path for Normal LNAV Approach (not VTF approach) Figure 21: 3.2-12 Full Scale Deflection and Define path for LNAV VTF Approach Figure 22: 3.2-13 Missed Approach Scenarios Figure 23: 3.2-15 VTF Final Approach Segment Lateral Deviations with FAS Data Block Figure 24: 3.2-16 Final Approach Segment Vertical Deviations Figure 25: 3.2-10 Default Navigation Modes

1. Scope

1.1 Identification

The United States Navy (USN) has identified a need to upgrade the existing fleet of aircraft to provide enhanced operational capabilities to meet Required Navigation Performance (RNP) Area Navigation (RNAV) requirements. Aircraft must operate worldwide and fly in civilian controlled airspace. This document identifies the requirements for a RNP RNAV Flight Management Function (FMF) software application developed in accordance with the Technical Standard for Future Airborne Capability Environment (FACETM). The FACE Conformant FMF application specified herein comprises only the subset of RNP RNAV system requirements which allocate to Flight Management System (FMS) software. The FACE-conformant FMF software application developed under this effort will support the integration of an RNP RNAV capability into multiple USN aircraft.

1.2 System Architecture and Overview

The open system architecture of the software supports a range of airframe types with different equipment combinations that produce a set of unique aircraft configurations. This solution provides FMS software functions to facilitate the integration of an RNP RNAV capability for Navy and other Department of Defense aircraft. This FMF software application is to be designed as a Portable Component Segment (PCS) component or components. The PCS component(s) will be provided to each platform as Government Furnished Information (GFI). Each platform will be responsible for integration of this component(s) and implementing the supporting FACE Architecture.

1.2.1 Notional aircraft Software Architecture

The following figure is a notional aircraft avionics block diagram.

Figure 1: Notional Aircraft Single FMF Software Environment Software Architecture

Figure 2: Notional Aircraft Dual FMF Software Environments Architecture

1.3 RNP RNAV Operations

In order to ensure safe separation of military and civil air traffic and adherence to air traffic control clearances, the aircraft must be capable of performing the following Federal Acquisition Regulation (FAR) Part 91 operational capabilities:

1.3.1 RNP Operations

Class II Navigation

Multiple and Single Long-Range Navigation Systems (M-LRNS)/(S-LRNS) / North Atlantic Minimum Navigation Performance Specification (NAT MNPS)

Operations in Areas of Magnetic Unreliability

RNP 10 (RNAV 10)

Oceanic and Remote Continental Operations

RNP 4

Oceanic and Remote Continental Operations

RNP 2

En route Domestic Offshore Oceanic Remote Continental Operations

RNP 1

Terminal (Arrival & Departure) Approach (Initial, Intermediate, Missed) Operations Departure Procedures (DPs) (Standard Instrument Departure (SID) & Operational

Departure (ODP)) & Standard Terminal Arrival Route (STAR)

RNP 0.3

Helicopter Operations En Route Domestic Terminal (Arrival & Departure) Approach (Initial, Intermediate, Missed)

Area RNP (ARNP) Oceanic & Remote Continental Ops (RNP 2) En route Domestic (RNP 2 or 1) Terminal - Arrivals & Departures (RNP 1-0.3) Approach - Initial, Intermediate, Missed (RNP 1-0.3)

RNP Approach (APCH) - Initial, Intermediate, Missed (RNP 1) Final (RNP 0.3)

1.3.2 RNAV Operations

Instrument Flight Rules (IFR) Class I Terminal & En route Navigation (Europe)

B-RNAV (RNAV 5)

P-RNAV (RNAV 1)

Class I Navigation in U.S. Class A Airspace / Long-Range Navigation Systems RNAV 2 - En-route / Q-Route

US Terminal and En Route Area Navigation (RNAV) Operations RNAV 2 En route/ Q-Route & T-Route RNAV 1 - DPs (SID & ODP) & STAR

1.3.3 RNAV Instrument Approach Procedures (IAP)

Non-Precision Approach (NPA)

Lateral Navigation (LNAV) LNAV/Vertical Navigation (VNAV) LNAV w/Advisory Barometric (Baro) VNAV Localizer Performance (LP) & LP w/Advisory Baro or w/Advisory Global Positioning

System (GPS)/Satellite-Based Augmentation System (SBAS) Vertical Approaches with Vertical Guidance (APV)

LNAV/VNAV w/Baro-VNAV) *** With Temperature Compensation*** LNAV/VNAV w/Wide Area Augmentation System (WAAS) based VNAV Localizer Performance w/Vertical (LPV)

1.4 Document Overview

This Government Specification (GS) details the tailored requirements from RTCA DO-283 (Class A Equipment), RTCA DO-229, FAA TSO-C115 and the FACE Technical Standard. The GS documents the requirements and verification provisions for the RNP RNAV FMF software application.

1.4.1 Terminology

Throughout this document, the following terminology applies to the use of the words SHALL, MUST, WILL, SHOULD, MAY:

SHALL: Indicates a requirement. An approved design should comply with every requirement, which can be assured by inspection, test, analysis or demonstration. All requirements are considered “Threshold” requirements unless the individual requirement is specifically labeled as “Objective”. For purposes of this specification, “Objective” means the requirement is optional.

MUST: Identifies items which are important, but are duplicated somewhere else in the document as a “SHALL”.

WILL: Denotes a capability that is a surety or a fact.

SHOULD: Denotes a recommendation that would improve the equipment, but does not constitute a requirement.

MAY: Denotes a recommendation that is optional.

1.4.2 Document Structure

This document is organized with the following sections:

Section 1: Scope - Discusses the scope of the specification.

Section 2: Referenced Documents - Contains references to the documents cited in this specification.

Section 3: System Requirements - Contains the requirements of this specification.

Section 4: Verification - Discusses the verification methods that will be used to validate that the software meets the requirements of this specification.

Section 5: Acronyms and Abbreviations - Lists the acronyms and abbreviations in this specification.

Section 6: Notes

2. Referenced Documents The following lists of documents of the exact issue shown form a part of this specification to the extent specified herein. In the event of conflict between the document referenced herein and the contents of this specification, the contents of this specification will be considered a superseding requirement. However, any discrepancies found between this document and RTCA DO-283, RTCA DO-229, and TSO-C115 that do not appear consistent with derivation for a software application SHOULD be brought to the attention of the Government.

The exact document versions listed in Section 2 will take precedence throughout this specification, unless specifically noted otherwise.

The FACE Technical Standard is the version listed in Section 2, or a later released version. All FACE Conformance tools and documentation SHOULD match the version of the FACE Technical Standard selected for development of the FMF Application.

2.1 Government Documents

Document Number Document Title Date

Statement of Work (SOW) for Flight Management Function (FMF) Software Application 10 April 2017

TSO-C115d Required Navigation Performance (RNP) Equipment using Multi-Sensor Inputs 7 March 2016

MIL-STD-882E

System Safety 11 May 2012

US/UK World Magnetic Model (WMM) 2015

Joint Software System Safety Handbook (JSSSEH) Version 1.0 27 August 2010

NAVAIR Software System Safety Level of Rigor (LOR) Tasks 20 Oct 2016

NGA Product Specification for the Digital Aeronautical Flight Information File (DAFIF) Edition 8.1 Version 3.4a March 2014

2.2 Non-Government Documents

Document Number Document Title Date

Technical Standard for Future Airborne Capability Environment (FACETM) Edition 2.1 May 2014

The Open Group Future Airborne Capabilities (FACETM) Conformance Authorities Plan Version 1.2 Sept 2016

The Open Group Future Airborne Capabilities (FACETM) Conformance Policy Version 2.0 Sept 2016

Technical Standard for Future Airborne Capability Environment (FACE™) Conformance Verification Matrix Edition 2.1 Dec 2014

The FACE Shared Data Model Edition 2.1

The Open Group Future Airborne Capabilities (FACETM) Shared Data Model Governance Plan Edition 2.1

RTCA DO-178C

Software Considerations in Airborne Systems and Equipment Certification 13 December 2011

RTCA DO-200B

Standards for Processing Aeronautical Data 18 June 2015

EUROCAE ED-76A

Standard for Processing Aeronautical Data June 2015

RTCA DO-201A

Standards for Aeronautical Information 19 April 2000

EUROCAE ED-77

Standards for Aeronautical Information April 2000

RTCA DO-229D (Change 1) Minimum Operational Performance Standards for Global Positioning System/Satellite-Based Augmentation System Airborne Equipment 01 Feb 2013

RTCA DO-283B

Minimum Operational Performance Standards for Required Navigation Performance for Area Navigation 15 December 2015

RTCA DO-297

Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations 8 Nov 2005

ICAO Doc 8168 (PANS-OPS) Procedures for Air Navigation Services Aircraft Operations Volume II Construction of Visual and Instrument Flight Procedures

IEEE/EIA 12207-1997 Annex J April 1998

ARINC 424-18

Navigation Systems Data Base 23 November 2005

ARINC 424-20

Navigation Systems Data Base December 2011

ARINC 743

Airborne Global Positioning System Receiver March 1990

ARINC 755-4

Multi-Mode Receiver (MMR) June 2010

3. Requirements Section

This section discusses the software requirements.

Each requirement is designated by a 'SHALL' statement.

This procurement is for the “FMF application software” hereafter called “the software”.

3.1 FACE Application Requirements

The software SHALL conform to the Safety-Base Profile for operating system segments defined by the FACE Technical Standard. The software SHALL limit usage to a Safety Profile for language interfaces defined by the FACE Technical Standard.

The software SHALL conform to the Portable Component Segment (PCS) defined by the FACE Technical Standard.

The software SHALL conform to the FACE Technical Standard Edition 2.1 or later.

All input to and output from PCS component(s) developed under this effort SHALL pass through either the Operating System Interface (OSI) or the Transport Service Interface (TSI) as described by the FACE Technical Standard. These inputs and outputs include any resource requests including those requests to an external file system.

3.2 SOFTWARE REQUIREMENTS

Note: Section 3.2 is derived from RTCA DO-283, RTCA DO-229, and TSO-C115. The intent is this specification contains all the requirements from RTCA DO-283, RTCA DO-229, and TSO- C115 that allocate to the software.

The paragraph numbers from RTCA DO-283 are the same as this document when the leading “3” is removed. For example, paragraph number 3.2.1.3 in this document is from paragraph

2.1.3 in RTCA DO-283.

Section 3.2.2.5 is taken from Section 2.2.5 of RTCA DO-229. Section numbers are identical to RTCA DO-229 when the leading ‘3’ is removed. The content of Section 3.2.2.5 has been modified for a software application, and requirements already captured earlier in the document have not been repeated.

Not all the notes from RTCA DO-283, RTCA DO-229, and TSO-C115 are included in this specification. See those documents for additional notes. The included notes are for clarification only.

Any discrepancies found between this document and RTCA DO-283, RTCA DO-229, and TSO-C115 that do not appear consistent with derivation for a software application SHOULD be brought to the attention of the Government.

3.2.1 General Requirements

3.2.1.1 Reserved

3.2.1.2 General Performance

Note: Manufacturers may choose to include additional functions within the software that are not specifically addressed in this specification. To facilitate approval of the software, the manufacturer should consider defining the intended function of each additional function in the operational context of its use.

3.2.1.3 Reserved

3.2.1.4 Reserved

3.2.1.5 Accessibility of Functions Not Intended for Use in Flight

The software SHALL not allow access during normal flight operations to software functions that are intended for use only on the ground.

3.2.1.6 Reserved

3.2.1.7 Reserved

3.2.1.8 Reserved

3.2.1.9 Development Assurance

The output of misleading lateral or vertical information (non-LP/LPV) is defined to be a Major failure condition.

Output of misleading lateral information (non-LP/LPV) SHALL be Improbable (less than or equal to 1x10-5 per flight hour).

Output of misleading vertical information (non-LP/LPV) SHALL be Improbable (less than or equal to 1x10-5 per flight hour).

The output of misleading information for LP/LPV operations is defined to be a Hazardous failure condition.

Output of misleading information for LP/LPV operations SHALL be Extremely Remote (less than or equal to 1x10-7 per 150-second approach).

3.2.1.9.1 Reserved

3.2.1.9.2 Software Compliance

3.2.1.9.2.1 Software Safety

The software system safety program SHALL comply with MIL-STD-882 and NAVAIR Software System Safety Level of Rigor (LOR) Requirements Tasks Table.

The JSSSEH SHOULD be used as a guide for the software system safety program.

All software that affects navigation and integrity functions for LP/LPV SHALL comply with Software Criticality Index (SwCI) 2.

Any FMF capabilities that are required to reside within the same software partition SHALL be developed to the highest SwCI level contained in that partition.

The software SHALL be developed to SwCI 3 at a minimum, commensurate with the software criticality identified by the MIL-STD-882/JSSSEH software safety process.

3.2.1.9.2.2 Software Development Processes

The software development processes SHALL comply with RTCA DO-178.

All software that affects navigation and integrity functions for LP/LPV capability SHALL be developed to Design Assurance Level (DAL) B.

Any FMF capabilities that are required to reside within the same software partition SHALL be developed to the highest DAL level contained in that partition.

The software SHALL be developed to DAL C at a minimum, commensurate with the software criticality identified by the RTCA DO-178 software development process.

3.2.2 Software Performance - Standard Conditions

3.2.2.1 2D (RNAV) Function and Performance

3.2.2.1.1 Position Estimation

Estimate of Present Position The software SHALL estimate the present position of the aircraft in latitude and longitude.

The software SHALL output estimated latitude with a resolution of 0.1 min or better.

The software SHALL output estimated longitude with a resolution of 0.1 min or better.

Note: The value originated in Table 2-3 in RTCA DO-283.

3.2.2.1.1.2 Estimate of Position Uncertainty (EPU)

The software SHALL output its current Estimate of Position Uncertainty (EPU), in nautical miles.

The software SHALL output EPU with a resolution of 0.01NM or better.

Note: The value originated in Table 2-3 in RTCA DO-283.

The software SHALL scale the EPU such that the containment alert occurs no later than when the EPU value exceeds the RNP in effect.

Note: The intended use of EPU is to provide the flight crew a measure of confidence of the system’s current navigation performance. EPU can be related to the required RNP for the following information:

• If the EPU is less than the RNP, there should be a high level of confidence the system can meet the requirements of a given RNP.

• The margin between EPU and the RNP should be an indication of the flight technical error margin available. If the margin is low, the flight crew may decide or be required to couple the autopilot system.

3.2.2.1.1.3 Containment Radius

The software SHALL determine the current containment radius under the prevailing conditions of flight.

Note: Prevailing conditions include airborne equipment condition, airborne equipment in use, and external signals in use. The containment radius is the radius of a circle, centered on the estimated position, such that the probability of the true position lying outside the circle without being detected is not greater than 10-5/hour.

3.2.2.1.1.4 Position Initialization

The software SHALL accept input of position initialization parameters to a resolution of 0.1min.

Note: The value originated in Table 2-3 in RTCA DO-283.

Navigation Aid Selection

3.2.2.1.1.5.1 Equipment

The software SHALL be capable of identifying and outputting navaid tuning commands to obtain the data necessary for position estimation or navigation. The navaids may be ground-based or space-based.

3.2.2.1.1.5.2 Ground-Based Navaids

If the FMF software provides for the ability to incorporate ground-based navaid data, then the software SHALL accept inputs for manually selecting and de-selecting the station frequencies of navaids where RNP 2 or less airspace operations are intended.

If the FMF software provides for the ability to incorporate ground-based navaid data, then the software SHALL accept inputs for automatically selecting and de-selecting the station frequencies of navaids where RNP 2 or less airspace operations are intended.

If the FMF software is able to automatically select ground-based navaid data, then the software SHALL accept inputs to inhibit the selection of individual navaids from the automatic selection process.

If the FMF software provides for the ability to incorporate ground-based navaid data, then the software SHALL perform reasonableness and integrity checks of the ground-based navaid data.

Note: For additional information, see Section 2.4.3.4 of RTCA DO-283.

If the FMF software provides for the ability to incorporate ground-based navaid data, then the software SHALL output frequencies and/or identifiers associated with a ground-based navaid selected for navigation.

3.2.2.1.1.6 Navigation Sensors

The software SHALL estimate the position using a Precise Positioning Service GPS as the primary sensor input.

Note: This requirement does not preclude use of other navigation sensors or combinations of sensors to supplement the PPS GPS. It is the software manufacturer’s responsibility to demonstrate that the performance of the other sensors or sensor combinations meets the requirements of this document.

Note: The software is to provide the GPS position with all the correct advisories and cautions as long as the GPS is providing any type of position data.

The software SHALL accept input to inhibit the use of any supported sensors not authorized for a particular RNP operation.

The software SHALL accept input that allows one or more supported sensors to be inhibited.

3.2.2.1.2 Path Definition

Leg Types The software SHALL be capable of utilizing the ARINC 424 leg type CF, Course to Fix leg.

The software SHALL be capable of utilizing the ARINC 424 leg type DF, Direct to Fix leg.

The software SHALL be capable of utilizing the ARINC 424 leg type FA, Fix to Altitude leg.

The software SHALL be capable of utilizing the ARINC 424 leg type HA, Hold to an Altitude leg.

The software SHALL be capable of utilizing the ARINC 424 leg type HM, Hold to Manual Termination leg.

The software SHALL be capable of utilizing the ARINC 424 leg type HF, Hold to Fix leg.

The software SHALL be capable of utilizing the ARINC 424 leg type IF, Initial Fix leg.

The software SHALL be capable of utilizing the ARINC 424 leg type RF, Radius to Fix leg.

The software SHALL be capable of utilizing the ARINC 424 leg type TF, Track to Fix leg.

The software SHALL be capable of utilizing the ARINC 424 leg type FM, Fix to Manual Termination leg.

The software SHALL be capable of utilizing the ARINC 424 leg type VA, Heading to Altitude leg.

The software SHALL be capable of utilizing the ARINC 424 leg type VI, Heading to Intercept leg.

The software SHALL be capable of utilizing the ARINC 424 leg type VM, Heading to Manual Termination leg.

The software SHALL be capable of utilizing the ARINC 424 leg type CA, Course to Altitude leg.

Note: FM, VA, VI, VM, and CA are from TSO-C115.

The software SHALL be capable of utilizing an IF that is a fly-by waypoint, fly-over waypoint, or the initial fix defining an RF leg segment.

Additionally, the software SHALL have the ability to proceed “direct to” an IF.

Note: This requirement is needed to support RNP departure procedures, particularly those with an RF leg as the first leg segment, where the IF defines the beginning of the RF leg.

With LNAV available immediately after takeoff, the software should provide guidance direct to the IF and sequence the next leg; particularly when the IF is the initial fix of an RF leg)

The VA leg defines a specified heading to a specific altitude termination at an unspecified position and no correction SHALL be made for wind.

The VI leg defines a specified heading to intercept a subsequent leg at an unspecified position and no correction SHALL be made for wind.

The VM leg defines a specified heading until a manual termination of the leg and no correction SHALL be made for wind.

The CA leg defines a specified course to a specific altitude termination at an unspecified position and the course flown SHALL make corrections for the wind.

The software SHALL construct the flight path associated with airways contained within the navigation database as though each fix segment is defined as a TF leg.

Note: This is because ARINC 424 defines airways as a series of fixes, and not as specific leg types.

In the case where all or part of a route is created through the manual entry of fixes, from the navigation database or user-defined fixes, a TF leg type SHALL be used to define the path between a manually entered fix and the preceding and following fixes.

Flight Planning The software SHALL accept inputs to create a flight plan.

The software SHALL accept inputs to cause the output of a flight plan.

The software SHALL accept inputs to allow the activation a flight plan.

The software SHALL provide the capability to contain a minimum of 200 waypoints in the flight plan.

The software SHALL accept requests to modify (e.g., deletion and addition of fixes and creation of along-track fixes) the flight plan.

The software SHALL accept requests to review the flight plan and output the draft flight plan.

When flight plan modification is exercised, the software SHALL prohibit guidance modifications until an input(s) is/are received to execute the modification.

Activation of any flight plan modification SHALL require input to the software showing acceptance of the modification prior to acceptance.

The software may provide for insertion of along-track reference points into an existing flight plan.

If implemented:

1. The along-track reference points SHALL not modify the desired track of the original flight path on which they are inserted.

2. The along-track reference points SHOULD only be entered on CF, DF, RF, or TF legs.

Note: Examples of along-track reference points are along-track fixes, abeam fixes, and lat/long crossing points.

The software SHALL have the capability to create flight plans by selection of individual fixes, by identifier, from the database.

A minimum 5-character field for input and display of database fix identifiers SHALL be required.

The software SHALL provide the means to extract from the database and review, for incorporation into a flight plan, flight departure procedures, including SIDS/DPs, and flight arrival procedures, including STARs and arrival transitions, for the appropriate/selected airport runway.

The software SHALL have the capability of creating flight plans by joining routes or route segments from the navigation database and by the use of ATS route identifiers.

The software SHALL indicate any flight plan discontinuities.

Note: A flight plan discontinuity is a point in the flight plan after which no desired path is defined.

The software SHALL provide the means to extract approach procedures from the database for review and incorporation into the flight plan.

These approach procedures SHALL include approach transitions and missed approach procedures for the selected airport runway.

The software SHALL have the ability to use a single waypoint supporting multiple RNP terminal procedures (SID, DP, STAR) and multiple approach procedures using different tracks.

When a single waypoint supports an arrival and an RNP instrument approach using different tracks, the software SHALL continue following the arrival procedure to the procedure’s termination fix.

Note: Some waypoints may serve as: a transition fix for an instrument approach; an initial approach fix (IAF) for an instrument approach; the first fix in a terminal arrival procedure;

and an intermediate waypoint on a terminal RNP procedure (SID, DP or STAR) (see Figure 1 below). This requirement ensures the software completes RNP procedures as assigned by ATC, and loaded by the flight crew into the active flight plan from the onboard navigation database.

Figure 3: 3.2-0 Single Waypoint Serving Multiple RNP Procedures

Additional methods of flight plan entry may consist of the insertion of individual fixes and related data, the selection of individual fixes from the database, the extraction of routes or portions of routes from the database or via datalink uplink.

Modifying the final approach segment SHALL disable the approach mode.

Note: Original requirement is from RTCA DO-229 paragraph 2.2.1.2.2.

Direct-To Function The software SHALL provide the capability of establishing a direct leg to any fix from the aircraft’s present position.

The software SHALL be capable of generating a geodesic path to the designated TO fix.

The software SHALL provide guidance and/or cues such that the aircraft is capable of capturing this path without "S-turning" and without undue delay.

Note: The purpose of the Direct-To function is to navigate the aircraft expeditiously from the aircraft’s present position to the crew designated TO fix.

Entry of User-Defined Fixes The software SHALL provide the capability to accept input of the coordinates of a fix in terms of latitude and longitude.

The software SHALL provide the capability to accept input of a fix as a range and magnetic bearing from another fix (place/bearing/distance).

The software SHALL provide the capability to accept input of a fix as a magnetic bearing from two fixes (place/bearing-place/bearing).

The range and bearing resolution SHALL be 0.1 NM and one degree.

Note: The value originated in Table 2-3 in RTCA DO-283.

Note 1: Consideration should be given to allow entry of true bearing for RNP equipment that will be approved for use at higher latitudes.

Note 2: The type of user-defined fix capability of the software should be commensurate with its intended operational use. For RNP-1 or less, user-defined fixes should not be used for systematic route creation and are only intended for use in tactical situations and temporary route diversions.

It is not intended that user-defined fixes be inserted into approach or missed approach procedures once drawn from the database, and the ramifications of doing so should be clearly understood by the flight crew.

Note 3: The software that allows storage of user-defined fixes should provide a means for automatic deletion of these temporary fixes prior to the next flight. This does not preclude the capability to store temporary user-defined fixes by deliberate crew action.

User-Defined Course-to-a-Fix The software SHALL provide the capability to intercept a user-defined course to a fix.

The resolution of the defined course SHALL be 1 degree.

Note: The value originated in Table 2-3 in RTCA DO-283.

RNP Holding (Objective) The software SHALL provide the capability to establish a flight path, with associated guidance and/or cues, to a selected fix and to provide a fly-by of the fix for entry into a hold from any direction, while maintaining the aircraft within the holding area. (Objective)

Once established in the hold, the software SHALL provide guidance and/or cues for tracking the holding pattern path. (Objective)

Once established in the hold, the software SHALL provide guidance and/or cues to ensure flight over the hold fix along the defined inbound track. (Objective)

For HF holding patterns within RNP airspace, the software SHALL determine the boundaries of the holding area as defined in this section. (Objective)

For HA holding patterns within RNP airspace, the software SHALL determine the boundaries of the holding area as defined in this section. (Objective)

For HM holding patterns within RNP airspace, the software SHALL determine the boundaries of the holding area as defined in this section. (Objective)

This boundary of the holding area defines the maximum size of an RNP holding pattern.

The software SHALL have the ability to establish containment consistent with the boundaries of the holding area defined in this section. (Objective)

3.2.2.1.2.6.1 RNP Holding Area Dimensions (Objective)

For airspace planning purposes, an RNP holding area will be derived from the assumption that the software will execute a racetrack pattern whose position and dimensions are defined by:

a. A holding fix;

b. A holding altitude, in feet, relative to mean sea level;

c. An inbound track to the holding fix, in degrees relative to true north;

d. The maximum length of the inbound track to the holding fix (d1), in nautical miles;

e. An assigned RNP;

f. The maximum IAS in knots;

g. An allowance for the maximum wind expected to be encountered.

The software is not required to fly the actual racetrack to ensure compatibility with such a holding area.

The software SHALL establish an entry that maintains the aircraft within the defined holding area during the entry procedure and subject to the actual airspeed being at or below the maximum IAS for the hold AND the actual wind speed being at or below the maximum wind speed used in the holding area airspace calculation. (Objective)

The software SHALL establish a holding pattern path that maintains the aircraft within the defined holding area for hold execution subject to the actual airspeed being at or below the maximum IAS for the hold AND the actual wind speed being at or below the maximum wind speed used in the holding area airspace calculation. (Objective)

The values associated with a. through e. above are typically provided by the navigation database.

The software SHALL accommodate pilot entry of these parameters. (Objective)

The maximum holding airspeed is normally dependent upon altitude.

Where maximum holding speed is not provided in the database, the maximum indicated airspeed values for flight level up to and including 6,000 ft. based on altimeter setting in use SHALL be 100 kt for cat H aircraft only. (Objective)

Where maximum holding speed is not provided in the database, the maximum indicated airspeed values for flight level up to and including 14,000 ft. based on altimeter setting in use SHALL be 230 kt for cat other than cat A & B aircraft. (Objective)

Where maximum holding speed is not provided in the database, the maximum indicated airspeed values for flight level up to and including 14,000 ft. based on altimeter setting in use SHALL be 170 kt for cat A & B aircraft only. (Objective)

Where maximum holding speed is not provided in the database, the maximum indicated airspeed values for flight level above 14,000 ft. up to and including 20,000 ft. based on altimeter setting in use SHALL be 240 kt. (Objective)

Where maximum holding speed is not provided in the database, the maximum indicated airspeed values for flight level above 20,000 ft. up to and including 34,000 ft. based on altimeter setting in use SHALL be 265 kt. (Objective)

Where maximum holding speed is not provided in the database, the maximum indicated airspeed values for flight level above 34,000 ft. based on altimeter setting in use SHALL be 0.83 M. (Objective)

Note: The value originated in Table 2-2 in RTCA DO-283.

The maximum wind speed used in airspace planning will not normally be known to the software.

The software SHALL use the actual wind measured by the system, subject to a maximum of the ICAO accountable wind speed (defined below) for the altitude flown. (Objective)

In cases where the holding altitude is not provided to the navigation system, the current altitude upon initiating the hold and at each recomputation of the hold dimensions at the inbound to the hold fix, the current altitude SHALL be used to define the holding altitude. (Objective)

When performing an entry into the holding pattern, the software is permitted to use an inbound leg length (d1) that is equal to the holding pattern width (d2) instead of the length defined in the database or from pilot entry.

Note 1: The inbound track may be published in degrees relative to magnetic north; in this case, true reference systems are expected to apply the magnetic variation in order to calculate the holding area.

A plan-view of the holding area so defined is shown in Figure 4: 3.2-1 along with the path definition terms.

Note 2: Value d4 in Figure4: 3.2-1 represents an allowance of airspace added to the holding fix-end to prevent aircraft from having to fly away from the hold fix before initiating a turn to the hold fix during entries from the holding side which have high intercept angles relative to the inbound track (S turning). See 3.2.2.1.2.6.2 RNP Holding Area Entry Procedures.

Figure 4: 3.2-1 Holding Pattern Definition

The holding area parameters defining the maximum holding track width (d2) and protected area (d4) are calculated as follows.

The maximum holding track width d2 is defined as:

d2 = (TAS + w)2/ (34313 tan φ) (NM) where, TAS is the lower of:

1. The true airspeed at the entry to the hold and at each inbound to the hold fix or

2. the true airspeed at the holding altitude for the maximum holding IAS at International Standard Atmosphere (ISA) +15° (kts) or Mach, including the effects of compressibility w is the lower of:

1. the measured wind at the entry to the hold and at each inbound to the hold fix or

2. the ICAO accountable omnidirectional wind speed for the given hold altitude (kts);

φ is the maximum bank angle.

The distance d2 defined by the above formula is conservative with respect to aircraft turn performance in that the accountable wind speed is assumed to be a tailwind throughout the entire turn, and the bank angle achievable by the aircraft will generally exceed the maximum value assumed in the computation.

Note: The maximum indicated airspeeds or Mach to be used in defining d2 are presented in Table 1: 3.2-2, and are derived from PANS-OPS Volume II, Part II — Section 4, Chapter 1, Table II- 4- 1-2. The corresponding true airspeed to be used in the calculation of d is presented in the PANS- OPS Volume II, Part II — Section 4, Chapter 1, Appendix A, Table II-4-1-App A-2. Alternatively, the formula of paragraph 6.1 of the same Attachment A can be used to calculate the required

TAS.

Table 1: 3.2-2 Maximum Holding Airspeeds (KIAS)

Levels 1 Indicated Airspeed up to 6,000 ft. (inclusive) 100 kt (cat H aircraft only) up to 14,000 ft. (inclusive) 230 kt 170 kt (cat A & B aircraft only) above 14,000 ft. to 20,000 ft. (inclusive)

240 kt above 20,000 ft. to 34,000 ft. (inclusive)

265 kt above 34,000 ft. 0.83 M

1 The levels tabulated represent altitudes or corresponding flight levels depending upon the altimeter setting in use.

The ICAO accountable omnidirectional wind speed [PANS OPS Volume II, Part II — Section 4, Chapter 1, Appendix A] to be used in defining d2 is defined as follows:

w = (2h + 47) kts where, w is the wind speed in knots, limited to 120 kts and h is the hold altitude in thousands of feet.

The bank angle to be used in the calculation of d2 is defined as:

φ = 23° for FL<245 φ = 15° for FL≥245

The distance d4 is the protection area for Sector 4 entries (See 3.2.2.1.2.6.2 RNP Holding Area Entry Procedures) and is calculated using the formula:

d4 = d2 (1 - sin20°)/ (2 cos20°) (NM)

3.2.2.1.2.6.2 RNP Holding Area Entry Procedures (Objective)

The software SHALL calculate entry the procedure from any direction and maintain the aircraft within the holding area after penetration into the holding area. (Objective)

The software SHALL output the entry procedure from any direction and maintain the aircraft within the holding area after penetration into the holding area. (Objective)

Note 1: The following notes describes acceptable fixed path hold entries used to establish an aircraft within an RNP hold.

Note 2: Introduction

Conventional holding pattern entry procedures are based on overflying the station or fix upon which the holding pattern is based. A consequence is the need for additional protection for entry procedures, particularly on the non-holding side of the holding pattern. With the advent of more capable RNAV systems, it is no longer necessary to overfly the station or holding waypoint and less space consuming holding patterns can be developed.

Note 3: Entry Procedures

There is no required entry pattern, however the entry procedures described below can be considered as acceptable. These examples of entry procedures satisfy the characteristic that the flight plan leg preceding the hold fix is maintained until the aircraft is within the holding area.

Note 4: Entry Sectors

The holding pattern is composed of two half circles and two straight segments as shown in Figure 5:3.2.2.1-4. The example shown includes the requirement that, for entry, the inbound leg length is greater than or equal to the width of the holding pattern. Using the center of the two half circles, complete C1 and C2. The center of C1 is located on a line perpendicular to the inbound holding course and passing through the holding waypoint (point A in Figure 5:3.2.2.1-4). The straight segments are drawn tangent to the two circles. Entry sectors are constructed by drawing a line making an angle of 70° with the inbound leg passing through the holding waypoint. The holding pattern is now divided into four sectors labeled 1, 2, 3 and 4 (see Figure5: 3.2.2.1-4.)

Figure 5: 3.2.2.1-4 Entry Sectors

Note 5: Sector 1 Entry Procedure

Turn along the arc of the circle centered on the line between the centers (line BC in Figure 6:3.2.2.1-5), to intercept the reverse of the inbound course of the holding pattern. Intercept and follow circle C2 until reaching the tangent between C2 and C1. Intercept and follow circle C1 until reaching the holding waypoint (point A in Figure 6: 3.2.2.1-5).

Figure 6: 3.2.2.1-5 Sector 1 Entry Procedure

Note 6: Sector 2 Entry Procedure

After overflying the holding waypoint (point A in Figure 7:3.2.2.1-6), tangentially intercept circle C2. Follow C2 until intercepting the inbound holding course.

Figure 7:3.2.2.1-6 Sector 2 Entry Procedure

Note 7: Sector 3 Entry Procedure

Overfly the holding waypoint and continue on the same course as was used to approach the holding waypoint. Intercept C1 or a circle centered on the line between the centers of C1 and C2.

Follow this circle until intercepting the outbound straight segment. (see Figure 8:3.2.2.1-7).

Figure 8: 3.2.2.1-7 Sector 3 Entry Procedures

Note 8: Sector 4 Entry Procedure

Continue on the course flown to the holding waypoint. Tangentially intercept a circle centered on the extended line between the centers of C1 and C2. Follow this circle until intercepting the outbound straight segment. (see Figure 9:3.2.2.1-8).

Figure 9: 3.2.2.1-8 Sector 4 Entry Procedures

The aircraft is not required to fly over the hold waypoint during entry. The aircraft is required to fly over the hold waypoint along the defined inbound track once established in the hold.

Note 9: Software not performing a fixed path entry may require complex alerting algorithms to ensure containment continuity is maintained (i.e. avoiding false alarms).

3.2.2.1.2.6.3 RNP Holding Area Exit Procedures (Objective)

The protected area for a hold exit SHOULD be the composite of the hold pattern, and the associated transition at the hold fix.

The transition at the hold fix for hold exit SHALL be a fly-by unless otherwise specified. (Objective)

The fly-by transition SHOULD use the inbound course to the hold fix and the track to the following leg.

3.2.2.1.2.6.4 RNAV Holding

The software SHALL provide the capability to establish a flight path, with associated guidance and/or cues, to a selected fix and to provide a fly-by of the fix for entry into a hold from any direction, while maintaining the aircraft within the holding area.

Once established in the hold, the software SHALL provide guidance and/or cues for tracking the holding pattern path.

Once established in the hold, the software SHALL provide guidance and/or cues to ensure flight over the hold fix along the defined inbound track.

The software SHALL provide the capability to fly on a specified inbound course to the holding waypoint (WP) with repeated crossing of the selected WP.

The software SHALL provide the capability to proceed to a selected WP, enter and accomplish published holding patterns as a leg of a coded procedure or route as defined by the navigational database.

The software SHALL provide the capability to proceed to and execute ATC directed holding at user defined points or WPs selected from the navigational database.

The software SHALL output steering guidance on the inbound course based on the RNP or RNAV value for the holding WP as defined by the navigational database.

If no RNP or RNAV value is present, then the software SHALL assign the RNP or RNAV in the following order of precedence:

a) Use the input RNP or RNAV type, if defined;

b) Use the RNP or RNAV type coded in the navigation database for the current leg or route, if defined; or

c) Use the RNP or RNAV type coded in the navigation database for the area if defined.

If the original leg is divided into multiple legs, the software SHALL apply the RNP or RNAV type of the original leg to each newly created leg.

When a parallel offset is active, the software SHALL apply the RNP or RNAV value applicable to the host route in the active flight plan.

The software SHALL use the magnetic variation of record for the designated holding WP or NAVAID if selected from the database.

The software SHALL use the local magnetic variation when holding at a user defined fix.

The software SHALL output turn direction or stick map representation output of the holding pattern.

The software SHALL calculate and output the distance from the aircraft to the holding WP once it becomes the active WP and while the aircraft is established in the holding leg.

Additional Information: This is intended to give the pilot an indication of when the aircraft has reached the holding pattern leg length distance from the holding WP.

The software SHALL use the WP type (fly-over or fly-by) from the navigational database for entry and hold logic.

Additional Information: The normal holding pattern entry procedures are based on overflying the station or fix upon which the holding pattern is based.