GPS

System and Message Overviews

Document Version: 5.9

Date: October 2, 2019


Copyright © 2009-2021 Jeppesen. All rights reserved. Your use of the AIM Bookshelf and all supporting documentation is subject to a separate license agreement between you and Jeppesen, a copy of which is included in the zip file or can be obtained from Jeppesen. The AIM Bookshelf is delivered "AS IS" without warranty of any kind and is not guaranteed to be free from errors or defects. You rely on the AIM Bookshelf at your own risk. No support for the AIM Bookshelf is implied through its publication. The AIM Bookshelf is intended solely for use as a reference and examples of interfaces to Jeppesen systems. Jeppesen may revise, update or cease publication at any time, without notice. Building to the specifications set forth in the AIM Bookshelf does not mean that your intended integration needs will be met or that an interface will function as documented. We recommend contacting Jeppesen directly to discuss professional services options with respect to production application integration and validation efforts.

 


Document Revision History

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

Date

Description of Updates Made

04-August-08

Created new version of GP001.  Added capability for precision terminal and route calculations.  Replaced NPA calculation with Terminal calculation. Added RNP value to the Terminal request as well as the Terminal text response.  Added RNP value to route for each checkpoint.  Added choice of location to be either an airport, a geographic point, or both.  Changed rnp value from integer to float.

01-July-09 Updated GP001 to version 3.
01-February-10

Added new messages GP002, GP003, GP004, and GP005.
Major restructuring of GP001 in new version (v4).

31-July-10 Updated GP002, GP003, GP004 and GP005 from DRAFT to version 1.
30-August-10 Updated links for new Bookshelf directory structure.
7-October-10 Updated XSD. Updated sample message GP001.
14-December-10 Updated XSD. The integrityLevel tag in the route portion of the message (containing either the level or the rnpArValue) was set to mandatory in v4. However, in previous versions the rnp value was optional at each point in the route, so there was no good way to transform the prior version to v4. Therefore the integrityLevel was set to optional in v4 to more closely correspond to the previous message convention.
11-January-11 Updated XSD. The integrityLevel tag in the route portion of the message (containing either the level or the rnpArValue) was set to mandatory in v4.  However, in previous versions the rnp value was optional at each point in the route, so there was no good way to transform the prior version to v4.  Therefore the integrityLevel was set to optional in v4 to more closely correspond to the previous message convention.
15-November-12 New sample messages GP002, GP003, GP004, GP005.
26-February-13 Updated XSD. GP001 V4 updated. Added <isBaroAided>true</isBaroAided>.
23-July-13 New XSD.
19-March-14 New XSD. Updated the version numbering for: GP001 GPS Raim Pred Request; GP001 GPS Raim Pred Response; GP003 RNP Pred Report by Station App Response; GP005 RNP Pred Region Update Response.
GP001 Response -Outages are to be reported back from DWI, related to the checkpoints along the route from within the request. DWI will assume that each request requires a response that indicates the waypoints and coordinates where an outage occurs along that route of flight. i.e. no indicator will be added to the request to allow choice between including waypoints, or not.
The OutageType will be modified. OutageType is used in the TerminalTextResponseGroup, as well as in the RouteTextResponseType. DWI will not populate the TerminalTextResponseGroup. This change adds a repeatable, optional, checkpoint structure that optionally provides the name of the waypoint, and requires the coordinates of any checkpoint that are crossed during the range of time that the outage is occurring.
It is assumed that the checkpoints within the request are in sequential order.
It is assumed that if checkpoints have the same name, and are provided in the request in sequential order, that their lat/long coordinates are different, and that their timeToCheckpoint, and also their toa (time of arrival to the checkpoint) are different. i.e. repeating checkpoints are OK, but may not contain the same coordinates and must either contain a timeToCheckpoint of greater than one minute, and a different toa. The outageType is also a part of GP003and GP005 responses.
18-September-14 New XSD.
Deprecated GP003 and GP005 version 1.
2-October-19 etd Removed GP002Response.xml sample


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

ID

Message

Publish

Request

Response

GP001

GPS RAIM Prediction

 

X

X

GP002

Station Group Discovery

 

X

X

GP003

RNP Station Reports

 

X

X

GP004

Region Discovery

 

X

X

GP005

RNP Region Reports

 

X

X

 

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.

Typical GP001 use in 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.

NOTE: Although airlines can specify their own minimum duration outage, they must comply with current FAA regulations.

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.

GP001 message system flow

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.

Message Version

GP001 v5

Message Header Details (REQUEST/RESPONSE)

msgName: GP001
msgClass: REQUEST/RESPONSE
version: 5

Message Specification

GP001 GpsRaimPredictionRequestType
GP001 GpsRaimPredictionResponseType

Defined in XSD

GPS.xsd

Sample Messages

Samples not yet available for this message version.

Message Version History

Version 1
* Added aircraft registration number. Added additional description for minDurationOutage and CheckpointTimeType.

Version 2
* Created new version 2 of GP001. Added capability for precision terminal and route calculations.
* Replaced NPA calculation with Terminal calculation.
* Added RNP value to the Terminal request as well as the Terminal text response.
* Added RNP value to route for each checkpoint.
* Added choice of location to be either an airport, a geographic point, or both. Changed rnp value from integer to float.

Version 3
* Edited the duration type from minExclusive to minInclusive.
* Added AirportCoordinatesElevationType.

Version 4
* (02-01-10) Major restructuring and enhanced functionality of message. Added <isBaroAided>true</isBaroAided>.

Version 5
* (03-03-14) GP001 Response - Outages are to be reported back from DWI, related to the checkpoints along the route from within the request. DWI will assume that each request requires a response that indicates the waypoints and coordinates where an outage occurs along that route of flight. i.e. no indicator will be added to the request to allow choice between including waypoints, or not.
* The OutageType is modified. OutageType is used in the TerminalTextResponseGroup, as well as in the RouteTextResponseType. DWI will not populate the TerminalTextResponseGroup. This adds a repeatable, optional, checkpoint structure that optionally provides the name of the waypoint, and requires the coordinates of any checkpoints crossed during the range of time that the outage is occurring.
* It is assumed that the checkpoints within the request are in sequential order, and that if checkpoints have the same name, and are provided in the request in sequential order, that their lat/long coordinates are different, and their timeToCheckpoint, and also their toa (time of arrival to the checkpoint) are different. i.e. repeating checkpoints are OK, but may not contain the same coordinates and must either contain a timeToCheckpoint of greater than one minute, and a different toa. The outageType is also a part of GP003 and GP005 responses.

 

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.

GP002 Message Flow

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.

Message Version

GP002 v1

Message Header Details (REQUEST/RESPONSE)

msgName: GP002
msgClass: REQUEST/RESPONSE
version: 1

Message Specification

GP002 StationGroupDiscoveryRequestType
GP002 StationGroupDiscoveryResponseType

Defined in XSD

GPS.xsd

Sample Messages

GP002v1StationGroupDiscoveryRequest.xml>

Message Version History No changes.

*** 10-2-19 edit: No Version Change: Removed GP002Response.xml sample

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.

GP003 Message System Flow

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.

Message Version

GP003 v2

Message Header Details (REQUEST/RESPONSE)

msgName: GP003
msgClass: REQUEST/RESPONSE
version: 2

Message Specification

GP003 RnpStationReportsRequestType
GP003 RnpStationReportsResponseType

Defined in XSD

GPS.xsd

Sample Messages

Samples not yet available for this message version.

Message Version History

Version 1
* Updated XSD, no changes in sample message.

Version 2
* (03-03-14) The OutageType is modified. OutageType is used in the TerminalTextResponseGroup, as well as in the RouteTextResponseType. DWI will not populate the TerminalTextResponseGroup. This adds a repeatable, optional, checkpoint structure that optionally provides the name of the waypoint, and requires the coordinates of any checkpoints crossed during the range of time that the outage is occurring.
* It is assumed that the checkpoints within the request are in sequential order, and that if checkpoints have the same name, and are provided in the request in sequential order, that their lat/long coordinates are different, and their timeToCheckpoint, and also their toa (time of arrival to the checkpoint) are different. i.e. repeating checkpoints are OK, but may not contain the same coordinates and must either contain a timeToCheckpoint of greater than one minute, and a different toa. The outageType is also a part of GP001 and GP005 responses.

Note (18 September 2014): GP003 Version 1 - Deprecated

 

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.

GP004 message flow

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.

Message Version

GP004 v1

Message Header Details (REQUEST/RESPONSE)

msgName: GP004
msgClass: REQUEST/RESPONSE
version: 1

Message Specification

GP004 RegionDiscoveryRequestType
GP004 RegionDiscoveryResponseType

Defined in XSD

GPS.xsd

Sample Messages

GP004v1RegionDiscoveryRequest.xml
GP004v1RegionDiscoveryResponse.xml

Message Version History No changes.

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.

GP005 message flow

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.

Message Version

GP005 v2

Message Header Details (REQUEST/RESPONSE)

msgName: GP005
msgClass: REQUEST/RESPONSE
version: 2

Message Specification

GP005 RnpRegionReportsRequestType
GP005 RnpRegionReportsResponseType

Defined in XSD

GPS.xsd

Sample Messages

Samples not yet available for this message version.

Message Version History Version 1
* No changes.

Version 2
* (03-03-14) The OutageType is modified. OutageType is used in the TerminalTextResponseGroup, as well as in the RouteTextResponseType. DWI will not populate the TerminalTextResponseGroup. This adds a repeatable, optional, checkpoint structure that optionally provides the name of the waypoint, and requires the coordinates of any checkpoints crossed during the range of time that the outage is occurring.
* It is assumed that the checkpoints within the request are in sequential order, and that if checkpoints have the same name, and are provided in the request in sequential order, that their lat/long coordinates are different, and their timeToCheckpoint, and also their toa (time of arrival to the checkpoint) are different. i.e. repeating checkpoints are OK, but may not contain the same coordinates and must either contain a timeToCheckpoint of greater than one minute, and a different toa. The outageType is also a part of GP001 and GP003 responses.

Note (18 September 2014): GP005 Version 1 - Deprecated