GPS

System and Message Overviews

Document Version: 5.9

Date: October 2, 2019

Document Revision History

The following revision history table reflects all substantive changes to this document since the previous release.

Table Of Contents

1  Introduction

This document defines the interfaces which govern the interchange of data between a GPS system and other systems within an Airline Operation Center (AOC).  Each AOC interface is represented by a message described in an associated XSD (XML Schema Definition). The XSD defines and enforces the required, optional, and conditional data that can be included in a message.

1.1  Audience

The intended audience for this document includes existing and potential Jeppesen customers, integration partners, and personnel with roles associated with application architecture, application development, system testing, implementation, and application support within GPS.

1.2  Scope

This document discusses the GPS messages currently supported by the Jeppesen Solution Integrator. Each message description includes the following:

• Overview for common message uses within an AOC
• Message Version Summary listing all available versions of each message
• Links to the message specifications including direct links to XSD documentation, where you can explore the XSD hierarchy and interface specifications in a navigable HTML format
• Links to the XSD source code
• Links to sample XML messages for each AOC message

Other data interfaces or formats not included in this document will be considered custom and not supported.

1.3  XML Schema/XSD

The XML schema for this ICD is published in the following file: GPS.xsd

2  Message Summary

Table 2-1 lists the messages that can be sent or handled by the application. The messages originated by this application (messages that begin with “GP”) are further discussed in Section 3 AOC Interface Messages.

Table 2-1 Message Summary

3 AOC Interface Messages

The following messages are processed by the GPS system.

3.1 GP001 - GPS RAIM Prediction

3.1.1  Message Overview

RAIM (Receiver Autonomous Integrity Monitoring) is a technology that assesses the integrity of Global Positioning System (GPS) signals in a GPS receiver system.

The RAIM Prediction report is used by a dispatcher or crew member to determine coverage of GPS systems for a given flight plan. FAA AC-90-100 dictates that all operators using RNAV as their primary navigation method must have a RAIM prediction report before departing. 

GPS devices utilize one of two algorithms for the RAIM prediction report. The GP001 message requires this algorithm be specified. 

• Fault Detection (FD): Used by traditional RAIM to detect faults (differences between a satellite’s pseudorange measurement and its expected value).
• Fault Detection and Exclusion (FDE):  Used by newer GPS receivers to allow continued operation in the presence of a GPS failure.

In addition to these algorithms, the ability to use barometric features is defined by the GPS receiver used within the aircraft.

3.1.1.1 Typical Message Usage

The GPS RAIM Prediction Report is typically requested by the dispatcher to validate GPS coverage for a specific flight plan. If there is acceptable coverage for a selected flight plan, then the dispatcher can file the flight plan; if the GPS coverage is unacceptable—either per the airline’s parameters or FAA requirements—then the dispatcher must select a different flight plan and then run the RAIM Prediction Report for that newly selected flight plan.

Figure 1 shows the typical use of GP001 message in an AOC.

Figure 1 . Typical GP001 Use in an AOC

3.1.1.2 Sample Periods and Minimum Duration Outages

The RAIM Prediction Report calculates GPS coverage for points along the flight path according to the specified sample period. The sample period is the duration (in minutes) between each RAIM calculation. For example, if the sample period is set to one minute, then RAIM will calculate the GPS coverage for the expected location of the plane (position including altitude) along its flight path once every minute. Therefore, if the flight plan calls for a 60 minute flight, RAIM will perform 60 calculations for the plane’s position along that flight path.

Reduce the sample period for a more precise analysis of the GPS coverage for a flight plan.

Each airline can also specify their acceptable minimum duration outage. This number (in minutes) specifies the acceptable duration that an aircraft can be without GPS coverage. If a predicted outage has a duration of less than the minimum duration it is not included in the result set, if an outage has a duration equal to or longer than the minimum duration it is included in the result set.  The purpose is to filter the results to contain only those outages of interest to the user [typical value would be 5 minutes].

For example, Jeppesen Airlines sets their minimum duration outage to five minutes for all flights. A flight plan is run for Flight 1234 from SFO to DEN, and then a RAIM Prediction Report is run against that flight plan. The RAIM calculates that there are two four-minute periods of GPS outage and one six-minute outage. The report ignores the two four-minute outages (because they are below the minimum duration outage threshold) and returns only the one six-minute outage. In this case, another flight plan is calculated for Flight 1234 to find a route without any outages greater than five minutes.

3.1.1.3 GPS RAIM Prediction Report Outputs

The dispatcher can select one or both of the following RAIM Prediction Reports with a single GP001 message:

• Terminal Report: Report that calculates GPS coverage for specific airports (POA, POD and any relevant alternates) for a specific time. This report instructs the dispatcher that the aircraft will have required GPS coverage for all planned takeoff and landing scenarios.
• Route: Report that calculates GPS coverage for an entire route along a series of checkpoints.

Both of the above can be output as a graphical report (chart showing the GPS outages), a text report (detailed descriptions of GPS outages based on discrete fields) or both. The GP001 message provides maximum flexibility to allow Dispatch systems to request different RAIM Prediction Report parameters and output formats.

As a rule – The mask angle to use for routeRequest (GP001 msg) shall be the aircraft mask angle, and the mask angle to use for terminalRequest (GP001 msg) shall be airport mask angle.

3.1.2  Message System Flow

This message interacts with the systems as shown in Figure 2.

Figure 2. GP001 message system flow

3.1.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.2 GP002 - Station Group Discovery

3.2.1  Message Overview

This message is used to determine if there are any changes to RNP (Required Navigational Performance) station approach calculations for airports in the database. One system sends a GP002 (request) asking if there are any changes to the second system containing the RNP data. The second system then replies with the GP002 (response), indicating whether or not there are any changes. This message is typically sent at a regular period (for example, every three minutes) to identify changes soon after they appear in the RNP system.

RELATED MESSAGES: If GP002 indicates RNP changes, then the GP003 message is used to gather the actual updates.

3.2.2  Message System Flow

This message interacts with the systems as shown in Figure 3.

Figure 3. GP002 message system flow

3.2.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.3 GP003 - RNP Station Reports

3.3.1  Message Overview

When the GP002 message identifies updates to the RNP stations approaches calculations, GP003 is sent to retrieve the actual updates. Similar to GP002, the requesting system sends the GP003 (request) message to the RNP system, who then responds with the GP003 (response) containing the actual RNP data.

3.3.2  Message System Flow

This message interacts with the systems as shown in Figure 4.

Figure 4. GP003 message system flow

3.3.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.4 GP004 - Region Discovery

3.4.1  Message Overview

This message is used to determine if there are any changes to RNP (Required Navigational Performance) coverage within a certain region (defined as a polygon). One system sends a GP004 (request) to the second system containing the RNP data asking if there are any changes . The second system then replies with the GP004 (response), indicating whether or not there are any changes. This message is typically sent at a regular period (for example, every three minutes) to identify changes soon after they appear in the RNP system.

3.4.2  Message System Flow

This message interacts with the systems as shown in Figure 5.

Figure 5. GP004 message system flow

3.4.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.5 GP005 - RNP Region Reports

3.5.1  Message Overview

When the GP004 message identifies updates to the RNP coverage, GP005 is sent to retrieve the actual updates. Similar to GP004, the requesting system sends the GP005 (request) message to the RNP system, who then responds with the GP005 (response) containing the actual RNP data.

3.5.2  Message System Flow

This message interacts with the systems as shown in Figure 6.

Figure 6. GP005 message system flow

3.5.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.