Operations Control

System and Message Overviews

Document Version: 6.2

Date: November 1, 2017


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 original publication.

Date

Description of Updates Made

04-August-08

Created a new version (version 2) of the ContinueLegType by adding the callSign field.
Created a new version (version 3) of OC001. Added callSign (CallSignType) field.
Created a new version (version 3) of OC005. Updated continueLeg to use ContinueLegType version 2.  
Created a new version (version 3) of OC009. Added callSign (CallSignType) field.
Created a new version (version 3) of OC018. Added callSign (CallSignType) field.
Created a new version (version 4) of OC020. Updated continueLeg to use ContinueLegType version 2.
Created a new version (version 4) of OC021. Updated continueLeg to use ContinueLegType version 2.
Changed the field order in OC005 to match the XSD. Note that this is a documentation change and does not represent a technical change to OC005. 
Updated Message Summary table.

15-September-08 Added OC025 message overview.
01-July-09

Added messages OC025, OC026, OC027, OC028, and OC029. Updated OC002 and OC013.

15-July-09 Updated element 'dispatcherRemarks' in the OperationsControl.xsd from a mandatory to an optional element to correct issue with message OC002.
01-October-09 Updates to the following messages: OC002, OC003, OC004, OC008, OC009, OC021, OC025, and OC029.
31-March-10 Updated messages OC002, OC003, OC009, OC011, OC013, and OC025.
31-July-10 Added new message OC030. Updated the following messages to the following versions: OC010 v3, OC012 v3, OC025 v1, OC029 v1. In OC012, added clearance and changeoverReceived types.
30-August-10 Updated links for new Bookshelf directory structure. Updated OC028 to vC. Updated OC010 to correct version 2.
15-September-10 Updated messages: OC026, OC027, and OC028 to version 1.
07-October-10 Updated XSD. Updated sample message OC028. Reworded message OC008.
24-February-11 New XSD.
8-June-11 New XSD. Added new sample message OC031, OC032.
14-September-11 New XSD. Added new message OC033 to support flight locking functionality. Added OC034 to support aircraft locking functionality. Updated message OC001 and OC032 to add new enumeration to :irregularOperationType" of Gate Return.
15-November-11 New XSD. Updated OC030 - Added optional attribute UOM to OC030 fuel on board. Updated OC033 - New work for request/response. Updated OC034 - Added airlineCode as mandatory element. New OC035 - Added Tankering Advice record. New OC036 / OC037 - Publish Message where external system has partial flight key data, and the system finds and completes the flight key data.
17-February-12 New XSD. New OC036 and OC037 - Add unique ID, optional, nillable. The purpose of this new element is to allow receiving systems to identify proper post-processing upon receipt of these messages (Version numbers will revert to a draft).
15-November-12 New XSD. Updated sample message OC033, OC036.
23-July-13 New XSD. Updated OC012 Estimated Times Annotations. Clarified annotations for ETD, ETO, EON, ETA, EIN
8-November-13 New XSD. Updated OC012, Fixed sample
3-March-14 New XSD.
26-May-15 New XSD. Common.xsd added flightKey which had a trickle-down effect causing this xsd to be updated.
1-November-17 New XSD.
* Deprecated OC013 v1 from messageCatalogTemplate, cross-versioning: v1 to v2, v1 to v3, v1 to v4, v2 to v1, v3 to v1, v4 to v1
* Deprecated OC014 v1 from messageCatalogTemplate, cross-versioning: v1 to v2, v2 to v1.
* Deprecated OC016 v1 Arrival, publish message from messageCatalogTemplate and cross-versioning folder and files (mfd, xsl): v1 to v2, v2 to v1


Table Of Contents

 

 


1 Introduction

This document defines the interfaces which govern the interchange of data between an Operations Control 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.

Operations control systems are used to manage airlines’ operational schedules. This includes such activities as creating flight legs, managing cancellations, deletions and diversions, and communicating flight status. Operations control systems are typically concerned with flight legs, as opposed to complete flights, which are managed by scheduling systems.

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 Operations Control.

1.2  Scope

This document discusses the Operations Control 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: OperationsControl.xsd

 

2  Message Summary

Table 2-1 lists the messages that can be sent or handled by the application.

Table 2-1 Message Summary

ID

Message

Publish

Subscribe

Request

Response

OC001

Create Flight Leg

X

 

 

 

OC002

Cancel Flight Leg

X

 

 

 

OC003

Delete Flight Leg

X

 

 

 

OC004

Reinstate Flight Leg

X

 

 

 

OC005

Divert Flight Leg

X

 

 

 

OC008

New Origin Flight Leg

X

 

 

 

OC009

Update Flight Leg

X

 

 

 

OC010

Reschedule Flight Leg

X

 

 

 

OC011

Aircraft Assignment

X

 

 

 

OC012

Estimate Times

X

 

 

 

OC013

Next Information

X

 

 

 

OC014

Arrival

X

 

 

 

OC015

Off

X

 

 

 

OC016

On

X

 

 

 

OC017

Departure

X

 

 

 

OC018

Change Flight Leg Identifier

X

 

 

 

OC020

Air Return

X

 

 

 

OC021

Ground Return

X

 

 

 

OC022

Delay

X

 

 

 

OC023

Out

X

 

 

 

OC024

In

X

 

 

 

OC025

Flight Lock

X

 

 

 

OC026

Flight Assignment Data

X

 

 

 

OC027

Post Flight Actuals

X

 

 

 

OC028

Post Flight Summary Report

X

 

 

 

OC029

Request Diversion

X

 

 

 

OC030

Fuel On Board at Enroute Positions

X

 

 

 

OC031

Gate Assignment

X

 

 

 

OC032

Ad Hoc Create Flight Leg

 

 

 

X

OC033

Dispatcher Lock

 

 

X

X

OC034

Aircraft Lock

X

 

 

 

OC035

Fuel Tankering Advice

X

 

 

 

OC036

Request Complete Flight Key

X

 

 

 

OC037

Completed Flight Key

X

 

 

 

 

3 AOC Interface Messages

The following messages are processed by the Operations Control system.

3.1 OC001 - Create Flight Leg

3.1.1  Message Overview

The Create Flight Leg message is used to create scheduled flight legs. Multiple flight legs can be created in a single message. This message deals with scheduled fields such as scheduled departure time and scheduled arrival time; it is not concerned with actual data, which is handled by other Operations Control messages.

3.1.1.1 Creating a new flight leg

The Create Flight Leg message can be used to create a single flight leg between two cities. Note that the OC001 message fields only contain information related to the scheduled flight. Flight actuals will be included in other messages such as Delay and Divert Flight Leg. Note also that although an equipment type is required, the specific aircraft identification is not required. Actual tail numbers can be assigned to a leg later using the Aircraft Assignment message.

3.1.1.2 Creating a multi-leg flight

When creating multiple legs using a single message, the same fields are required for each leg as when creating a single leg. This message includes a repeating group, which allows the create flight information to be repeated for as many legs as necessary.

3.1.1.3 Creating an irregular operation flight

The Create Flight Leg message can also be used to create irregular operations legs. Irregular operation legs are any flights other than planned revenue-generating flights. There are three common types of irregular operations:

  • Continue
  • Ferry
  • Position
3.1.1.3.1 Continue

When a flight is diverted to another airport, due to weather or mechanical issues, scheduling systems typically generate a “continuation” leg from the diversion point to the leg’s original point of arrival (poa). In the case where a continuation leg is not automatically created, a new flight leg needs to be created. This new flight leg must set the Irregular Operations field to continue.

Step four in Figure 1 shows when the irregular operation of type “continue” should be used.

Sample create continue leg scenario

Figure 1. Sample create continue leg scenario.

3.1.1.3.2 Ferry

Ferry flights are non-revenue generating flights used to move an aircraft from one location to another, usually for purposes related to maintenance. Ferry flights can be scheduled or unplanned as a result of mechanical issues. Figure 2 shows an example situation for a ferry flight.

Sample create flight ferry scenario

Figure 2. Sample create flight ferry scenario.

3.1.1.3.3 Position

Position flights are used to move an aircraft from one location to another in order to enable a revenue flight. Position flights are most common for charter and cargo flights.

For example, Jeppesen Airlines has a contract with the NBA to fly the Denver Nuggets to their game locations. Jeppesen Airlines flies the Nuggets from Denver to Los Angeles, where the Nuggets plan to remain for two days. In the meantime, JP uses the aircraft to fly a business party one-way from Los Angeles to San Francisco. The plane is then flown (as a Position flight) from San Francisco to Los Angeles in time to return the Nuggets to Denver. Figure 3 shows an example situation for a positioning flight.

Sample create flight position scenario

Figure 3. Sample create flight position scenario.

3.1.1.4 Additional Notes

The following notes should be considered when using this message:

  • The equipmentCode field can include either ICAO or IATA codes. 
  • This message is used to specify the schedule, not the actuals.

Related Messages:
The Create Flight Leg message is used to schedule a new flight and does not include any estimate or actual information. The following messages are related to creating a new flight leg.

OC002 Cancel Flight

Cancel an existing flight.

OC003 Delete Flight

Delete an existing flight.

OC004 Reinstate Flight

Reinstate a previously canceled or deleted flight.

OC005 Divert Flight Leg

Changes the flight’s actual point of arrival and automatically creates a new “continuation” flight to the original point of arrival. Therefore, when diverting, you do not need to send the Create Flight Leg message to create the continue leg.

OC010 Reschedule Flight

Update the scheduled times for a flight.

OC011 Aircraft Assignment

Assign or update the aircraft or equipment type for a flight.

OC018 Change Flight Leg

Change the flight key for a flight leg, rather than rescheduling or canceling and recreating a flight.

 

3.1.2  Message System Flow

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

OC001 message system flow

Figure 4. OC001 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

OC001 v3

Message Header Details

msgName: OC001
msgClass: PUBLISH
version: 3

Message Specification

OC001 CreateFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC001v3CreateScheduledFlight.xml
OC001v3CreateMultiLegFlight.xml
OC001v3CreateIrregularFlight.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Version 3
* Created a new version (version 3) of OC001. Added callSign (CallSignType)
field.
* Added new enumeration to "irregularOperationType" of Gate Return.

 

3.2 OC002 - Cancel Flight Leg

3.2.1  Message Overview

This message is used to cancel an existing flight leg.

When a particular flight leg is no longer needed or no longer possible for reasons related to under-bookings, severe weather, and mechanical issues, it can be deleted or canceled. Deletion and cancellation records can be used by the carrier to fine-tune their schedules.

Flight legs must be canceled if they are within a certain number of days of the scheduled departure date. US carriers must cancel flights within seven days of the scheduled departure. Canceled flights must be reported to the Department of Transportation.

Tip: Using a Cancel Indicator Flag
Scheduling systems should place a cancel indicator flag on the canceled flight legs rather than performing a hard delete from their system. Maintaining these records allows carriers to report on their own cancellation statistics. Using a cancel indicator also enables carriers to reinstate a canceled flight; if the record is removed from the system, then a new flight leg must be created, rather than simply reinstated.

3.2.1.1 Canceling a single flight leg

Carriers may decide to cancel a flight for reasons related to weather, under-bookings, and mechanical issues. For example, Jeppesen Airlines has two scheduled flights from LAX to SFO, departing ten minutes from each other. The first flight is not completely booked and there are very few bookings on the second flight. Jeppesen Airlines moves passengers from the second to first flight and then cancels the second flight.

3.2.1.2 Additional Notes

The following notes should be considered when using this message:

  • To cancel a flight leg, only the flight key is required.
  • Although the <reason> field is optional in this message, carriers are encouraged to capture the cancellation reason for reporting purposes.
  • Deletes can be used instead of cancels when the flight is removed a certain number of days before the scheduled departure. This can be advantageous to carriers because deletes do not have to be reported to the Department of Transportation.

Related Messages:
The Cancel Flight Leg message is used to cancel an existing flight. The following messages are related to canceling a new flight leg.

OC001 Create Flight Leg

Create a new flight. Use this in the case where you want to recreate a previously canceled flight that was “hard deleted” from your system.

OC003 Delete Flight

Delete an existing flight. Flights can be deleted up to seven days before the flight. Anything closer to the date of departure must be canceled.

OC004 Reinstate Flight

Reinstate a previously canceled or deleted flight. This message can only be used if a cancel/delete indicator flag was used during the cancel/delete operation. If the record was removed from the system using a hard delete, then this message is not an option and a new flight leg must be created.

3.2.2  Message System Flow

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

OC002 message system flow

Figure 5. OC002 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

OC002 v4

Message Header Details

msgName: OC002
msgClass: PUBLISH
version: 4

Message Specification

OC002 CancelFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC002v4CancelFlightLeg.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.
* Added element dispatcherRemarks.

Version 3
* Changed dispatcherRemarks from required to optional. 

Version 4
* Added aircraftID.

 

3.3 OC003 - Delete Flight Leg

3.3.1  Message Overview

This message is used to delete an existing flight leg.

When a particular flight leg is no longer needed or no longer possible for reasons related to under-bookings, severe weather, and mechanical issues, it can be deleted or canceled. Deletion and cancellation records can be used by the carrier to fine-tune their schedules.

If an airline determines a future flight leg is not need, they can delete the flight. US carriers can delete a flight up to seven days before departure. Anything closer to the scheduled departure date must be canceled, rather than deleted. Deletions remove flights from the scheduling system and are not reported to the Department of Transportation.

Tip: Using a Delete Indicator Flag
Scheduling systems should place a delete indicator flag on the deleted flight legs rather than performing a hard delete from their system. Maintaining these records allows carriers to report on their own deletion statistics. Using an indicator also enables carriers to reinstate a deleted flight; if the record is removed from the system, then a new flight leg must be created, rather than simply reinstated.

3.3.1.1 Deleting a single flight leg

Carriers may decide to delete a flight if they anticipate a future flight will be under-booked or if they plan to perform maintenance on a number of aircraft, thus reducing their capacity. 

For example, historical data shows that Flight 2245 from LAX to SFO never fully books on December 25 (Christmas day). The carrier sends a delete message for that specific flight leg.

3.3.1.2 Additional Notes

  • To delete a flight leg, only the flight key is required.
  • Although the reason field is optional, carriers are encouraged to capture the deletion reason for reporting purposes. The actual reason in the message will consist of a four-character code and optional text explanation.
  • Use deletes instead of cancels when the flight is removed a certain number of days before the scheduled departure. This can be advantageous to carriers because deleted flights do not have to be reported to the Department of transportation.

Related Messages:
The Delete Flight Leg message is used to delete an existing flight. The following messages are related to deleting a new flight leg.

OC001 Create Flight Leg

Create a new flight. Use this in the case where you want to recreate a previously deleted flight that was “hard deleted” from your system.

OC002 Cancel Flight Leg

Cancel an existing flight. Flights can be deleted up to seven days before the flight. Anything closer to the date of departure must be canceled.

OC004 Reinstate Flight

Reinstate a previously canceled or deleted flight. This message can only be used if a cancel/delete indicator flag was used during the cancel/delete operation. If the record was removed from the system using a hard delete, then this message is not an option and a new flight leg must be created.

3.3.2  Message System Flow

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

OC003 message system flow

Figure 6. OC003 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

OC003 v4

Message Header Details

msgName: OC003
msgClass: PUBLISH
version: 4

Message Specification

OC003 DeleteFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC003v4DeleteFlight.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Version 3
* Created version 3 of message to use new userInfo element.

Version 4
* Added aircraftID.

 

3.4 OC004 - Reinstate Flight Leg

3.4.1  Message Overview

This message is used to reinstate a flight leg that has been deleted or canceled.
In order to reinstate a flight leg, the scheduling systems must have placed a cancel or delete indicator flag on the flight legs during the cancel/delete operation. If the record was removed from the system using a hard delete, then the reinstate is not an option and a new flight leg must be created.

3.4.1.1 Reinstating a deleted or canceled flight leg

If a carrier cancels or deletes a flight, but then decides that they, in fact, want that flight to occur, then they can simply reinstate it. For example, Flight 1234 from LAX to SFO is canceled due to aircraft mechanical issues. A quicker-than-anticipated repair puts the aircraft back into service. Flight 1234 is reinstated.

3.4.1.2 Additional Notes

The following notes should be considered when using this message:

  • Although the <reason> field is optional in this message, carriers are encouraged to capture the reason for reinstating the canceled or deleted flight for reporting purposes.

Related Messages:
The Reinstate Flight Leg message is used to reinstate a flight leg that has been deleted or canceled. The following messages are related to reinstating a flight leg.

OC001 Create Flight Leg

Create a new flight. Use this in the case where you want to recreate a previously deleted flight that was “hard deleted” from your system and therefore cannot be reinstated.

OC002 Cancel Flight Leg

Cancel an existing flight. Flights can be deleted up to seven days before the flight. Anything closer to the date of departure must be canceled.

OC003 Delete Flight Leg

Delete an existing flight. Flights can be deleted up to seven days before the flight. Anything closer to the date of departure must be canceled.

 

3.4.2  Message System Flow

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

OC004 message system flow

Figure 7. OC004 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

OC004 v3

Message Header Details

msgName: OC004
msgClass: PUBLISH
version: 3

Message Specification

OC004 ReinstateFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC004v3ReinstateFlightLeg.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Version 3
* Created version 3 of message to use new userInfo element.

 

3.5 OC005 - Divert Flight Leg

3.5.1  Message Overview

This message is used to divert a flight leg. This message can also be used to create a continuation leg.  This message changes the actual point of arrival.

A diversion is a flight that is required to land at a location other than the original destination for reasons beyond the control of the pilot/company. Diversions may be caused by such things as severe weather or equipment issues.
There are two types of diversions:

  • Unplanned Diversion – diversion that occurs after takeoff.
    Example: A flight from LAX to SFO receives a report of bad weather in San Francisco while en route, and the flight is diverted to Sacramento. 
  • Planned Diversion – diversion that occurs before takeoff.
    Example: A flight plan is calculated for LGA to LAX, accounting for a strong headwind. The flight plan calls for a stop (or diversion) midway for refueling.

The divert message is used in the following situations:

  • Divert – point of diversion becomes the new POA.
  • Divert and continue – flight automatically created from point of diversion to the original destination.
  • Divert and hold – flight is held at the diversion point; a continue leg is not built.
  • Planned diversion – a “divert-and-continue” diversion planned before takeoff.

3.5.1.1 Divert

Sometimes when a flight leg is diverted, a continue leg is automatically generated from the diversion point to the originally scheduled destination (poa). However, sometimes the diversion point becomes the new POA, as is illustrated in the following scenario. Note that this scenario applies to both en route and pre-departure diversions.

  1. Flight leg diverted from original destination to new destination, changing the diversion point to the new POA.

Figure 8 shows a typical divert scenario.

Figure 8. Divert

3.5.1.2 Divert and Continue

Typically, when a flight leg is diverted, a continue leg is automatically generated from the diversion point to the originally scheduled destination (poa). A divert-and-continue uses the following process:

  1. Flight leg diverted from original destination to new destination, changing the Actual POA of the leg.
  2. A “continuation leg” is created from the diversion point to the original Point of Arrival (POA).

Figure 9 shows a typical divert and continue scenario.

Divert and continue

Figure 9. Divert and Continue

Note that this message (OC005) contains information related to the continuation leg. The continue leg only requires that you send the new scheduled time of departure (std) and scheduled time of arrival (sta) for the leg from MCI to ORD. You do NOT need to send a “create flight leg” message (OC001) when using this message.

3.5.1.3 Divert and Hold

An airline might divert a flight to a new POA and then hold the flight at that location. In this case, a new leg is NOT automatically built from the diversion point to the final destination. Passengers would then be moved to different flights traveling to their desired destination, or a new flight leg would be created later with the Irregular Operation field set to “continue.”

Note: Divert-and-holds are less common than divert-and-continues. Continue legs to the final destination are typically built automatically with any diversion.

Figure 10 shows a Divert and Hold scenario.

Divert and Hold

Figure 10. Divert and Hold


Note: When using this approach, you will either need to send a “create flight leg” message (OC001) to build the flight leg to the originally planned destination, or arrange for through-passengers to get their destination by other means.

3.5.1.4 Planned Diversions

Diversions can happen before an aircraft leaves the ground. For example, a long flight from LGA to LAX is calculated the morning of the flight. When factoring in a strong headwind, the flight plan requires a refueling stop mid-flight. In this example, the flight diverts to DEN and then continues to LAX.
Figure 11 shows a planned diversion scenario.

Planning divert

Figure 11. Planned Diversion

Note that this message includes scheduling information (scheduledTimeDeparture and scheduledTimeArrival) for the continuation leg. Note also that the POA is not included in the continue leg information because the flight is still bound for LAX.

3.5.1.5 Additional Notes

  • Most carriers will perform a “divert and continue” or “planned diversion” as explained above, automatically building the continuation legs. In the case where the flight cannot move from the diversion to the final destination along the “continue” flight leg (due to weather or mechanical issues), then the continue leg is canceled.

Related Messages:
The Divert Flight Leg message is used to divert a flight and create a continuation leg to the original point of arrival (poa). This message changes the actual poa. The following messages are related to diverting a flight leg.

OC001 Create Flight Leg

Create a new flight. Use this to create a continuation leg in the “divert and hold” scenario—flight has been diverted and a continuation leg has not been automatically built. The continuation leg should be marked as a “continue” irregular operation.

OC002 Cancel Flight Leg

Cancel an existing flight. Use this message to manually cancel a continuation leg which has been automatically built following a diversion.

OC020 Air Return

Perform an air return, which is a special type of diversion where the aircraft returns to the point of departure. 

OC021 Ground Return

Perform a ground return, which is a special type of diversion where the aircraft returns to the point of departure without leaving the ground. 

 

3.5.2  Message System Flow

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

OC005 message system flow

Figure 12. OC005 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

OC005 v3

Message Header Details

msgName: OC005
msgClass: PUBLISH
version: 3

Message Specification

OC005 DivertFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC005v3DivertFlightLeg.xml
OC005v3DivertContinueFlightLeg.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

version 3
* Created a new version (version 3) of OC005. Updated continueLeg to use ContinueLegType version 2.
* Changed the field order in OC005 to match the XSD. Note that this is a documentation change and does not represent a technical change to OC005.

 

3.6 OC008 - New Origin Flight Leg

3.6.1  Message Overview

This message is used to change the actual point of departure of a flight leg. This message is used to change the actual point of departure (pod) from one airport to another airport in close proximity.

3.6.1.1 New Origin Flight Leg

This message is used to change the actual point of departure from one airport to another airport in close proximity.
For example, after taking off from Los Angeles, Flight 1234 (LAX to SFO to DEN) is notified of heavy fog in San Francisco and is diverted to Oakland, using the Divert Flight Leg message. A continuation-leg is created, changing the actual point of departure from SFO to OAK. The second leg of flight 1234 is now OAK to DEN.

3.6.1.2 Additional Notes

Related Messages:
The New Origin Flight Leg message is used to change the actual point of departure (pod) of a flight leg from one airport to another airport in close proximity. The following messages are related to updating a flight’s origin.

OC002 Cancel Flight Leg

Cancel an existing flight. Use this message to manually cancel a continuation leg which has been automatically built following a diversion.

OC005 Divert Flight Leg

Changes the flight’s actual point of arrival. If planning to use the New Origin Flight Leg message, do not automatically create a new “continuation” flight to the original point of arrival. If the continuation leg is automatically built, send the Cancel Flight Leg message for that leg.

 

3.6.2  Message System Flow

This message inteOC008 message system flowracts with the systems as shown in Figure 13.

 

Figure 13. OC008 message system flow

 

3.6.3   Message Details

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

Message Version

OC008 v3

Message Header Details

msgName: OC008
msgClass: PUBLISH
version: 3

Message Specification

OC008 NewOriginFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC008v3NewOriginFlightLeg.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Version 3
* Created version 3 of message to change the actualPodOperationalSuffix to optional.

 

3.7 OC009 - Update Flight Leg

3.7.1  Message Overview

This message is used to update flight attributes that cannot be updated via the other leg management messages. This includes assigning or updating the Service Type and Route. The service type codes in this message are taken from the IATA manual.

Note:    This message is not used to update estimate or actual flight times, departure, or arrival data. See Related Messages box below for additional information.

Related Messages:
The Update Flight Leg message is not used to update estimate or actual flight times, departure, or arrival data. Instead, use one of the following messages:

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg

OC014 Arrival  

Update both the actual On and In times of a flight leg at the same time.

OC017 Departure Update both the actual Out and Off times of a flight leg at the same time. While the ETA is not required, it is highly encouraged this is sent with a departure message.
Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

This message interacts with the

3.7.2  Message System Flow

systems as shown in Figure 14.

OC009 message system flow

Figure 14. OC009 message system flow

 

3.7.3   Message Details

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

Message Version

OC009 v5

Message Header Details

msgName: OC009
msgClass: PUBLISH
version: 5

Message Specification

OC009 UpdateFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC009v5UpdateFlightLeg.xml

Changes from Previous Version

Version 2
* Created version 2 of message to use the version 2 FlightKeyType. Updated note for “route” in OC009 v2’s Update Flight Leg Data table.
* Added a new sample XML for OC009 (OC009v2UpdateFlightLegServiceType) and renamed OC009v2UpdateFlightLeg to OC009v2UpdateFlightLegRoute.

Version 3
* Created a new version (version 3) of OC009. Added callSign (CallSignType) field.

Version 4
* Added POA.

Version 5
* Added "isFuelBonded" optional, boolean element.

 

3.8 OC010 - Reschedule Flight Leg

3.8.1  Message Overview

This message is used to change the schedule times for a flight leg. This message changes the scheduled time of departure (std) and scheduled time of arrival (sta).

Note: This message can NOT be used to reschedule the first leg of a flight if it changes the date of departure. This would change the flight key. Instead, you must send a Change Flight Identifier message for the first leg and all down-leg flights. Then, after changing the flight identifier, you can send this message to reschedule one or more flight legs.

3.8.1.1 Changing the scheduled departure by a few minutes

This message can be used to change the STD and STA of flights. Carriers will typically send this message a few days or weeks before a flight to move its departure forward or back a few minutes.
For example, JEP Airlines consistently experiences slower than anticipated turn times when flying through DEN. They decide to push the scheduled time of departure back fifteen minutes for Flight 1234’s DEN to ORD leg. They send a Reschedule Flight Leg message to reschedule the STD and STA of the leg.

3.8.1.2 Special Case: Changing the scheduled departure to a new day

This message can NOT be used to reschedule the first leg of a flight if it changes the date of departure. This would change the flight key. Instead, you must send a Change Flight Identifier message (OC018) for the first leg and all down-leg flights. Then, after changing the flight identifier, you can send this message to reschedule one or more flight legs.
For example, the first leg of flight 1234 departs from LAX at 2330. A maintenance issue moves the departure time to 0005 the next day. The Reschedule Flight Leg message can NOT yet be sent because it would change the flight’s flight key. Instead, the airline sends the OC018 (Change Flight Identifier) message to change the flight identifier for this leg and all down-leg flights. Only then can the OC010 (Reschedule Flight Leg) message be sent to alter the flight times.  

3.8.1.3 Additional Notes

Related Messages:
The Reschedule Flight Leg message changes the scheduled time of departure (std) and scheduled time of arrival (sta) for a flight leg. Note that this message does not update estimate or actual times. Instead use one of the following messages:

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

OC014 Arrival

Update both the actual On and In times of a flight leg at the same time.

OC017 Departure

Update both the actual Out and Off times of a flight leg at the same time. While the ETA is not required, it is highly encouraged this is sent with a departure message.

OC018 Change Flight Leg Identifier

Updates the flight key. Use this message when rescheduling a flight changes that flight’s departure date. See message OC018 for details.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

3.8.2  Message System Flow

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

OC010 message system flow

Figure 15. OC010 message system flow

 

3.8.3   Message Details

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

Message Version

OC010 v2

Message Header Details

msgName: OC010
msgClass: PUBLISH
version: 2

Message Specification

OC010 RescheduleFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC010v2RescheduleFlightLeg.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

 

3.9 OC011 - Aircraft Assignment

3.9.1  Message Overview

This message is used to assign aircraft and/or equipment type to a flight leg.

When creating a flight leg, you are required to specify the type of aircraft (equipment type) for that flight. You do not, however, need to identify the specific aircraft until the day of the flight’s departure. This enables carriers to create schedules while retaining flexibility with actual fleet assignments and maintenance cycles.

Note: If the Aircraft ID is not included in this message, the receiving application will remove any previously assigned aircraft ID. 

Assign a specific aircraft to a flight

This message can be used to assign a specific aircraft to a flight. For example, JEP Airlines created Flight 1234 using a Boeing 777 equipment type. The morning of the flight, the dispatcher assigns aircraft ID “JP100A.”

Change the equipment type for a flight

This message can be used to change the equipment type for a single flight leg. For example, the Boeing 777 scheduled for Flight 1234 is grounded for mechanical reasons just before completing the last leg of its flight.  There is no other Boeing 777 available for the flight. JEP Airlines sends an Aircraft Assignment message to change the equipment type from 777 to 787, and uses an available 787 to fly the final leg.

Change the equipment type for multiple flight legs

This message can be used to change the equipment type for multiple flight legs. For example, JEP Airlines anticipates a low passenger volume on Christmas Day for all legs of Flight 1234. They decide to use a Boeing 767 rather than the 777. They send a single Aircraft Assignment message, and utilize the message’s repeating group to change the equipment type for each leg of the flight.

Figure 16 shows an equipment type swap for two multi-legged flights. A separate Aircraft Assignment message would be sent for each of the planes being swapped.

Equipment type change for multi-leg flight

Figure 16. Equipment type change (swap) for multi-leg flight.

NOTE:
Schedule planning (or fleet planning) software applications are available which allow users to graphically assign and swap aircraft equipment. For each aircraft assignment and swap performed in the GUI, the Aircraft Assignment message would communicate the appropriate changes. 

Change equipment type and assign an aircraft ID

This message can also be used to both change the equipment type and assign an aircraft ID. For example, the Boeing 777 (tail number JP100A) is grounded due to mechanical issues and there is not another 777 available for the flight. JEP Airlines sends the Aircraft Assignment message to:

  1. Change the equipment type to an available 787.
  2. Assign a specific aircraft identification number to the flight (example, JP230A).

Additional Notes

Related Messages:
The Aircraft Assignment message assigns aircraft and/or equipment type to a flight leg. The following message is related to assigning an aircraft.

OC001 Create Flight Leg

Creates a new flight. The aircraft and equipment type can be specified during the initial flight creation.

 

3.9.2  Message System Flow

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

OC011 message system flow

Figure 17. OC011 message system flow

 

3.9.3   Message Details

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

Message Version

OC011 v3

Message Header Details

msgName: OC011
msgClass: PUBLISH
version: 3

Message Specification

OC005 AircraftAssignmentType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC011v3AircraftAssignment.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.
* Added repeating group (aircraftAssignment) to 0C011 v2.

Version 3
* Added "isFuelBonded" optional, boolean element.

 

3.10 OC012 - Estimate Times

3.10.1  Message Overview

This message allows for update of any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg. It is highly recommended that if an estimated departure time (ETD/ETO) is updated, that at a minimum a new estimated time of arrival (ETA) also be provided.

This message is used to update the estimate times related to a flight leg. Though the reasons for sending this message vary, the message itself contains the same information: flight key, any updates to the estimate times, delay reasons, and additional textual information.

3.10.1.1 Update estimates due to delay

This message can be used to update the estimated time of departure or arrival resulting from any sort of delay. For example, Flight 1234 from LAX to SFO is delayed due to a mechanical issue, which requires 25 minutes of maintenance. JEP Airlines sends an Estimate Times message to update the estimated time of departure (etd). They also include a new estimated time of arrival (eta) within the message.

3.10.1.2 Update estimates from new flight plan calculation

This message can also be triggered from a change in the flight plan calculation. For example, a strong headwind for a flight leg between LGA and LAX changes the estimated time en route for the flight. A new flight plan is published using message DP001 which adds one hour to the original flight plan. JEP Airlines sends an Estimate Times message to update the estimate time of arrival for the flight.

3.10.1.3 Update estimates from departure data

This message can also be used to update estimates based on when the aircraft actually departs (Out or Off). For example, Flight 1234 from DEN to ORD leaves the gate (Out) ten minutes late due to weight and balance issues. The new Out time is then used to calculate a new ETA. JEP Airlines then sends the Estimate Times message to publish the new ETA.

3.10.1.4 Update estimates due to airborne delay

This message can be used to update estimates due to airborne delays. For example, severe weather has caused a number of flights to divert from nearby airports to SFO. When nearing SFO, Flight 1234 from LAX is told to engage in a holding pattern from twenty minutes. The pilot reports this to JEP Airlines, who then sends an Estimate Times message to update the ETA.

3.10.1.5 Additional Notes

  • Some carriers calculate all of their flight plans first thing in the morning. As weather and airport conditions change through the day, the Estimate Times message can be sent to fine tune the estimated schedules.
  • The etd, eto, eon, and eta fields are listed as Optional because different systems utilize different metrics (out versus off, and on versus in). Note, however, that most systems do not display the ETO and EON data.

Related Messages:
The Estimate Times message changes the estimate times related to a flight. Note that this message does not update scheduled or actual times. Instead use one of the following messages:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC014 Arrival

Update both the actual On and In times of a flight leg at the same time.

OC017 Departure

Update both the actual Out and Off times of a flight leg at the same time. While the ETA is not required, it is highly encouraged this is sent with a departure message.

OC022 Delay

Communicate the duration and reason for any delay. Note that this message does not directly update any scheduled, estimated, or actual values associated with the flight times.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.10.2  Message System Flow

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

OC012 message system flow

Figure 18. OC012 message system flow

 

3.10.3   Message Details

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

Message Version

OC012 v3

Message Header Details

msgName: OC012
msgClass: PUBLISH
version: 3

Message Specification

OC012 EstimateTimesType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC012v3EstimateAll.xml

Message Version History

Version 2
Created version 2 of message to use the version 2 FlightKeyType.
Updated OC012v2 to allow it to repeat. Updated OC012 from estimatedTimesDataGroup to estimatedTimesGroup.

Version 3
Created version 3 of message. Added clearance and changeoverReceived types.

 

3.11 OC013 - Next Information

3.11.1  Message Overview

This message is used to indicate a time when additional information about delays or flight statuses are expected to be communicated. This message may also contain a delay reason code.

3.11.1.1 Mechanical delays

This message can be used to communicate delays related to mechanical issues.

For example, a fluid is found leaking from the aircraft assigned to Flight 1234 from Denver to Chicago. The maintenance crew determines that it will take 30 minutes to diagnose the problem. They send a Next Info message for 30 minutes, at which time they expect to have a more detailed estimate for the required work. At the end of the thirty minutes, they have a diagnosis and additional estimate for the required work. They send another Next Info message for another hour. At the end of that hour, the maintenance issue is resolved and the flight can proceed to its next destination.

3.11.1.2 Next info for next departure

This message can also be used to communicate the Next Info point for a down-leg flight.

For example, Flight 1234 enters a holding pattern outside of Chicago due to severe winter weather. Because the pilots do not know when they will land, they call down to JEP Airlines and discuss the situation. JEP Airlines decides to send a Next Info message for the next flight leg’s departure time (ORD to LGA).

Note: This case is not common. Typically, carriers will simply send an Estimate Times message under these circumstances.

3.11.1.3 Additional Notes

Related Messages:
The Next Info message communicates when additional information related to delays or flight statuses will be posted. Note that this message does not directly update any scheduled, estimated, or actual values associated with the flight times. The following messages are related to the Next Info message:

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

OC022 Delay

Communicate the duration and reason for any delay. Note that this message does not directly update any scheduled, estimated, or actual values associated with the flight times. Also note that delay messages are posted AFTER the departure or arrival, so that they can accurately report actuals.

 

3.11.2  Message System Flow

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

OC013 message system flow

Figure 19. OC013 message system flow

 

3.11.3   Message Details

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

Message Version

OC013 v4

Message Header Details

msgName: OC013
msgClass: PUBLISH
version: 4

Message Specification

OC013 NextInformationType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC013v4NextInformation.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Version 3
* Added element dCNTime.

Version 4
* Deleted element dCNTime.

Note:
* 1 November 2017 - Deprecated OC013 v1 from messageCatalogTemplate, cross-versioning: v1 to v2, v1 to v3, v1 to v4, v2 to v1, v3 to v1, v4 to v1

 

3.12 OC014 - Arrival

3.12.1  Message Overview

This message is used when updating both the actual On and In times of a flight leg at the same time.

Although ACARS sends distinct messages for On and In events, both On and In are sent in one message when manually communicating this information using the Arrival message. Use the “Is ACARS” field in the case where the ACARS system logs the event, but the official record is entered manually.

3.12.1.1 Additional Notes

  • Some airlines may post the On when landing in airports with long taxi times. This communicates that the passenger has landed, but has not yet arrived at the gate.

Related Messages:
The Arrival message updates the actual On and In times for a flight. The following messages are related to the arrival message:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.12.2  Message System Flow

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

OC014 message system flow

Figure 20. OC014 message system flow

 

3.12.3   Message Details

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

Message Version

OC014 v2

Message Header Details

msgName: OC014
msgClass: PUBLISH
version: 2

Message Specification

OC014 ArrivalType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC014v2Arrival.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Note:
* 1 November 2017 - Deprecated OC014 v1 from messageCatalogTemplate, cross-versioning: v1 to v2, v2 to v1.

 

3.13 OC015 - Off

3.13.1  Message Overview

This message is used when updating the Off time of a flight leg. Off is the “wheels up” time, or actual takeoff time. If the message is an ACARS generated message, the actual trigger event is often the weight coming off the wheels. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user. While the ETA is not required, it is highly encouraged this is sent with an Off message.

Related Messages:
The Off message updates the actual Off time for a flight. This message can also communicate the flight’s estimated On time and estimated time of arrival. The following messages are related to the Off message:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.13.2  Message System Flow

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

OC015 message system flow

Figure 21. OC015 message system flow

 

3.13.3   Message Details

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

Message Version

OC015 v2

Message Header Details

msgName: OC015
msgClass: PUBLISH
version: 2

Message Specification

OC015 OffType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC015v2Off.xml

Message Version History

Version 2
Created version 2 of message to use the version 2 FlightKeyType.

 

3.14 OC016 - On

3.14.1  Message Overview

This message is used when updating the On time of a flight leg. On is the “wheels on” time, or actual landing time. If the message is an ACARS generated message, the actual trigger event is often the weight coming on the wheels. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user. While the ETA is not required, it is generally encouraged this be sent with an On message.

Related Messages:
The On  message updates the actual On time for a flight. This message can also communicate the flight’s estimated On time and estimated time of arrival. The following messages are related to the Off message:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.14.2  Message System Flow

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

OC016 message system flow

Figure 22. OC016 message system flow

 

3.14.3   Message Details

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

Message Version

OC016 v2

Message Header Details

msgName: OC016
msgClass: PUBLISH
version: 2

Message Specification

OC016 OnType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC016v2On.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Note:
* v1 November 2017 - Deprecated OC016 v1 Arrival, publish message from messageCatalogTemplate and cross-versioning folder and files (mfd, xsl): v1 to v2, v2 to v1

 

3.15 OC017 - Departure

3.15.1  Message Overview

This message is used when updating both the Out and Off times of a flight leg at the same time. While the ETA is not required, it is highly encouraged this is sent with a departure message.

Although ACARS sends distinct messages for Out and Off events, both Out and Off are sent in one message when manually communicating this information using the Departure message. Use the “Is ACARS” field in the case where the ACARS system logs the event, but the official record is entered manually.

3.15.1.1 Additional Notes

  • This message can also capture the movement after push (map) data. This value reports the time after Out and before Off.

Related Messages:
The Departure message updates the actual out and off times for a flight. The following messages are related to the departure message.

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.15.2  Message System Flow

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

OC017 message system flow

Figure 23. OC017 message system flow

 

3.15.3   Message Details

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

Message Version

OC017 v2

Message Header Details

msgName: OC017
msgClass: PUBLISH
version: 2

Message Specification

OC017 DepartureType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC017v2Departure.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

 

3.16 OC018 - Change Flight Leg Identifier

3.16.1  Message Overview

This message is used to change the flight identifier for a flight leg. Use this message to change a flight leg’s flight key rather than canceling and recreating the flight. 

3.16.1.1 Special Case: Changing the Flight Key for a New Date of Departure

Every flight key includes the flight origin date. This is the date of departure for the first leg of a flight. If the first leg needs to be rescheduled to another day, then you must first send the Change Flight Leg Identifier message for each leg of the flight to establish a new flight key. If this message is not sent, then you would have an incorrect flight key—one which shows the flight originating on the wrong day. Additionally, you could experience a duplicate flight key for the same flight leaving the next day. After sending the Change Flight Leg Identifier message, you can safely reschedule the flight. 

For example, the first leg of Flight 1234 from LAX to SFO is scheduled to depart on 12 DEC at 2100. The flight key for this original leg is JP 1234 12DEC LAX. Weather at LAX delays that flight three hours and five minutes, making the new departure time 0005 on December 13. Because the flight origin date (12DEC) is no longer correct, JEP Airlines must send a Change Flight Identifier Message to update the flight origin date in this and every down-leg flight. The new flight key for the first leg is JP 1234 13DEC LAX.

3.16.1.2 Changing the Flight Number

This message can also be used to change a flight number.

Some airlines reserve specific blocks of flight numbers for certain types of flights. For example, JEP Airlines uses flight numbers 2000-2999 for all non-revenue positioning flights and flight numbers 3000-3999 for all charter flights. On December 12, a corporate customer requests a flight from LAX to SFO on any available flights. Flight number 2222 was already scheduled as a positioning flight from LAX to SFO. JEP Airlines changes that flight number to 3333 to designate it as a charter flight. This enables JEP Airlines to quickly repurpose an existing flight without having to cancel the original flight and create a new one for the new purpose.

This message can also be used to rename flight numbers that were incorrectly entered upon creation. Again, this is easier and more efficient than canceling the flight and creating a new one with the correct flight number.

3.16.1.3 Additional Notes

Related Messages:
The Change Flight Leg Identifier message is used to change the flight key. The following message is related to the Change Flight Leg Identifier message:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta. You must use the Change Flight Leg Identifier prior to the Reschedule Flight Leg message in instances where rescheduling changes the date of departure for a multi-legged flight.

 

3.16.2  Message System Flow

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

OC018 message system flow

Figure 24. OC018 message system flow

 

3.16.3   Message Details

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

Message Version

OC018 v3

Message Header Details

msgName: OC018
msgClass: PUBLISH
version: 3

Message Specification

OC018 ChangeFlightLegIdentifierType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC018v3ChangeFlightIdentifier.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.

Version 3
* Created a new version (version 3) of OC018. Added callSign (CallSignType) field.

 

3.17 OC020 - Air Return

3.17.1  Message Overview

This message is used when an aircraft performs an air return. An air return is a special type of diversion where the aircraft returns to the point of departure. When an application creates the continuation leg, the operational suffix field is used to uniquely identify the flight.

An operational suffix is included in the flight key to ensure that each flight key is unique. By law, each flight leg must possess a unique flight key consisting of the airline code, flight number, flight origin date, and point of departure. In situations where an air or ground return is required for one of these legs, the operational suffix field is required to distinguish one flight leg from another.

For example, flight number 1234 takes off from LAX at 2100 on December 12 and is forced to make an air return for mechanical reasons. The flight key for this original leg is JP 1234 12DEC LAX.  The ground crew quickly fixed the mechanical issue and the flight takes off at 2200 on December 12. This second flight has the same airline code, flight number, flight origin date, and point of departure as the first departure attempt. The operational suffix, for example A, is then required to distinguish between the first and second takeoff. The complete flight key for the second departure would then be JP 1234 12DEC LAX A.

Note: Jeppesen reserves the lower alphabet (A through F) for air and ground returns. Flights can experience both air and ground returns for the same leg; in these cases, increment the character for each return. For example, after an air return, the flight number would be 1234A. If that same flight leg had to perform a subsequent ground return, the next attempt would be 1234B.

3.17.1.1 Air return due to mechanical issue

Most air returns are due to mechanical issues and can happen any time from takeoff to the time the plane passes the halfway point to the nearest reasonable airport.
For example, Flight 2233 from LAX to HNL departs over the Pacific Ocean. An hour into the flight the pilots register a problem with the fuel. Because HNL is another 2 hours away, the point of origin (LAX) is still the closest airport. The pilots turn around and perform an air return at LAX. A continuation leg is automatically created for the next attempt to HNL.

3.17.1.2 Additional Notes

  • An operational suffix must be used when creating the continuation leg. Failure to assign an operational suffix would result in duplicate flight keys.
    Jeppesen reserves the lower alphabet (A through F) for air and ground returns. Flights can experience both air and ground returns for the same leg; in these cases, increment up the alphabet for each return. For example, after an air return, the flight number would be 1234A. If that same flight leg had to perform a subsequent ground return, the next attempt would be 1234B.
  • Air returns are typically due to mechanical or passenger issues. They rarely result from weather. In the case of bad weather at the destination, a Divert would be used.
  • Note that certain information is required for an air return. Either the On time or estimated on time is required so that the tower knows when to expect the return. The point of arrival (POA), however, is not required, because in this case it is the same as the point of origin.

Related Messages:
The Air Return message is used to perform an air return, which is a special type of diversion where the aircraft returns to the point of departure. The following messages are related to an air return.

OC005 Divert Flight Leg

Changes a flight’s actual point of arrival. If returning to the original point of departure (pod), then use the Air Return message. 

OC021 Ground Return

Perform a ground return, which is a special type of diversion where the aircraft returns to the point of departure without leaving the ground. 

 

3.17.2  Message System Flow

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

OC020 message system flow

Figure 25. OC020 message system flow

 

3.17.3   Message Details

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

Message Version

OC020 v4

Message Header Details

msgName: OC020
msgClass: PUBLISH
version: 4

Message Specification

OC020 AirReturnType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC020v4AirReturn.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.Changed the use of the following fields from Conditional to Optional in OC020 v2: onTime, eon, eta, inTime. Updated “continueLeg” from M to O.

Version 3
* Created version 3 of OC020 to include operationalSuffix.

Version 4
* Created a new version (version 4) of OC020. Updated continueLeg to use ContinueLegType version 2.

 

3.18 OC021 - Ground Return

3.18.1  Message Overview

This message is used when an aircraft performs a ground return. A ground return is a special type of diversion where the aircraft returns to the point of departure without leaving the ground. When an application creates the continuation leg, the operational suffix field is used to uniquely identify the flight.

An operational suffix is included in the flight key to ensure that each flight key is unique. By law, each flight leg must possess a unique flight key consisting of the airline code, flight number, flight origin date, and point of departure. In situations where an air or ground return is required for one of these legs, the operational suffix field is required to distinguish one flight leg from another.

For example, flight number 1234 takes off from LAX at 2100 on December 12 and is forced to perform a ground return for mechanical reasons. The flight key for this original leg is JP 1234 12DEC LAX.  The ground crew quickly fixed the mechanical issue and the flight takes off at 2200 on December 12. This second flight has the same airline code, flight number, flight origin date, and point of departure as the first departure attempt. The operational suffix, for example A, is then required to distinguish between the first and second attempts. The complete flight key for the second departure would then be JP 1234 12DEC LAX A.

3.18.1.1 Ground return due to mechanical issue

Ground returns occur after the aircraft leaves the gate and before takeoff.

For example, Flight 2233 performed an air return from its LAX to HNL leg, received maintenance, filed a continuation leg, and pushes away from the gate as Flight 2233A. While taxiing to the runway, however, the pilots hear a clanking sound beneath the aircraft. They send the Ground Return message and ground return to the gate to discover that the cargo doors were not secured.

Note that because in this example the ground return was preceded by an air return, the operational suffix will be incriminated to “B” for the next attempt.

3.18.1.2 Additional Notes

  • An operational suffix must be used when creating the continuation leg. Failure to assign an operational suffix would result in duplicate flight keys.
    Jeppesen reserves the lower alphabet (A through F) for air and ground returns. Flights can experience both air and ground returns for the same leg; in these cases, increment up the alphabet for each return. For example, after an air return, the flight number would be 1234A. If that same flight leg had to perform a subsequent ground return, the next attempt would be 1234B.
  • Ground returns are typically due to mechanical or passenger issues. They rarely result from weather. In the case of bad weather at the destination, a Divert would be used.
  • Note that certain information is required for a ground return. Either the In time or estimated time of arrival (eta) is required so that the gate knows when to expect the return. The point of arrival (POA), however, is not required, because in this case it is the same as the point of origin.

Related Messages:
The Air Return message is used to perform an air return, which is a special type of diversion where the aircraft returns to the point of departure. The following messages are related to an air return.

OC005 Divert Flight Leg

Changes a flight’s actual point of arrival. If returning to the original point of departure (pod) without leaving the ground, then use the Ground Return message. 

OC020 Air Return

Perform an air return, which is a special type of diversion where the aircraft returns to the point of departure. 

 

3.18.2  Message System Flow

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

OC021 message system flow

Figure 26. OC021 message system flow

 

3.18.3   Message Details

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

Message Version

OC021 v5

Message Header Details

msgName: OC021
msgClass: PUBLISH
version: 5

Message Specification

OC023 GroundReturnType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC021v5GroundReturn.xml

Message Version History

Version 2
* Created version 2 of message to use the version 2 FlightKeyType.
* Changed the use of the following fields from Conditional to Optional in OC021 v2: inTime, eta, inTime. Modified the notes for the following fields: outTime, inTime, eta, and continueLeg.
* Updated “continueLeg” from M to O in OC020v2 and OC021v2.

Version 3
* Created version 3 of OC021 to include operationalSuffix.

Version 4
* Created a new version (version 4) of OC021. Updated continueLeg to use ContinueLegType version 2.

Version 5
* Deleted the following elements: outTime, eta, map (movement after push time), arrivalDelay (duration, code, information), continueLeg, operationalSuffix, reason (code, information), and information.

 

3.19 OC022 - Delay

3.19.1  Message Overview

This message is used to communicate one or more delays affecting a flight leg. This message overlays any previously sent delays. Delays are posted as actual durations. For departures, delays are the actual differences between the scheduled time of departure (std) and Out. For arrivals, delays are the actual differences between the scheduled time of arrival and In.

3.19.1.1 Posting delay for any reason

This message can be used to communicate any actual information related to delayed departures or arrivals. For example, Flight 1234 from LAX to SFO is delayed due to a mechanical issue. After 30 minutes the aircraft is cleared for takeoff and pushes away from the gate. The Delay message is sent specifying the actual departure delay value and reason.

3.19.1.2 Additional Notes

  • The departure delay and arrival delay are listed as optional because different markets monitor different metrics. For example, US carriers must report their arrival delays to the Department of Transportation, where as European carriers report on departure delays.
  • Delay messages are posted AFTER the departure or arrival, so that they can accurately report actuals. Some airlines hold briefing reports to determine the true cause of delays: for example, crew, weather, maintenance. The report-collection process may take some time; therefore these airlines may not publish delay information for a day or two after the actual flight.
  • The repeating group in the message allows airlines to assign multiple reasons for the delay. For example, an airline might track that a 25 minute departure delay can be partitioned into the following: Weather (10 minutes), Crew (5 minutes), and Maintenance (10 minutes).

Related Messages:
The Delay message is used to communicate actual delay information. For updating scheduled or estimate information use one of the following:

OC010 Reschedule Flight Leg

Update the scheduled time of departure (std) or scheduled time of arrival (sta).

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.19.2  Message System Flow

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

OC022 message system flow

Figure 27. OC022 message system flow

 

3.19.3   Message Details

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

Message Version

OC022 v2

Message Header Details

msgName: OC022
msgClass: PUBLISH
version: 2

Message Specification

OC022 DelayType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC022v2Delay.xml

Message Version History

Version 2
Created version 2 of message to use the version 2 FlightKeyType.

 

3.20 OC023 - Out

3.20.1  Message Overview

This message is used to update the Out time of a flight leg. This is sometimes referred to as the off-block time. It is defined by IATA as the time when the aircraft begins to move, either under its own power or by external power. If the message is an ACARS generated message, the actual trigger event is often either the locking of the aircraft doors or the release of the brake. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user, possibly at the gate. While the ETA is not required, it is highly encouraged this is sent with an out message.

Related Messages:
The Out message updates the actual Out time for a flight. This message can also communicate the flight’s estimated times: eto, eon, and eta. The following messages are related to the Out message:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.20.2  Message System Flow

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

OC023 message system flow

Figure 28. OC023 message system flow

 

3.20.3   Message Details

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

Message Version

OC023 v2

Message Header Details

msgName: OC023
msgClass: PUBLISH
version: 2

Message Specification

OC023 OutType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC023v2Out.xml

Message Version History

Version 2
Created version 2 of message to use the version 2 FlightKeyType.

 

3.21 OC024 - In

3.21.1  Message Overview

This message is used when updating the In time of a flight leg. In is the “on the gate” time, or actual arrival time. If the message is an ACARS generated message, the actual trigger event is often the door open time. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user.

Related Messages:
The Out message updates the actual In time for a flight. The following messages are related to the Out message:

OC010 Reschedule Flight Leg

Update the flight’s schedule times: std and sta.

OC012 Estimate Times

Update any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg.

Note: The messages for Off, On, Out, and In can also be used to communicate estimates and actuals related to those events.

 

3.21.2  Message System Flow

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

OC024 message system flow

Figure 29. OC024 message system flow

 

3.21.3   Message Details

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

Message Version

OC024 v2

Message Header Details

msgName: OC024
msgClass: PUBLISH
version: 2

Message Specification

OC024 InType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC024v2In.xml

Message Version History

Version 2
Created version 2 of message to use the version 2 FlightKeyType.

 

3.22 OC025 - Flight Lock

3.22.1  Message Overview

When an airline has determined that a flight needs potential investigation, they may choose to lock down the data so that no one can change the information. OC025 is typically sent from the Operations Control system to the dispatch system so that the user interface will not allow the flight to be accessed or altered.

3.22.2  Message System Flow

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

OC025 Message Flow

Figure 30. OC025 message system flow

 

3.22.3   Message Details

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

Message Version

OC025 v1

Message Header Details

msgName: OC025
msgClass: PUBLISH
version: 1

Message Specification

OC025 FlightLockType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC025v1FlightLock.xml

Message Version History

No changes.

 

3.23 OC026 - Flight Assignment Data

3.23.1  Message Overview

This message is used to communicate flight assignment data, including aircraft information and crew assignment data, to a system external to the AOCi. This message is typically sent following updates to the schedule planning and crew management systems.

3.23.2  Message System Flow

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

OC026 message system flow

Figure 31. OC026 message system flow

 

3.23.3   Message Details

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

Message Version

OC026 v1

Message Header Details

msgName: OC026
msgClass: PUBLISH
version: 1

Message Specification

OC026 FlightAssignmentDataType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC026v1FlightAssignmentData.xml

Message Version History

No changes.

 

3.24 OC027 - Post Flight Actuals

3.24.1  Message Overview

Following the completion of a flight, the OC027 message can be used to communicate the ACTUAL flight information between systems within the AOC as well as external products. Information includes actual arrival and departure times, crew assignments, and fuel consumption.

3.24.2  Message System Flow

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

OC027 message system flow

Figure 32. OC027 message system flow

 

3.24.3 Message Details

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

Message Version

OC027 v1

Message Header Details

msgName: OC027
msgClass: PUBLISH
version: 1

Message Specification

OC027 PostFlightActualsType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC027v1PostFlightActuals.xml

Message Version History

Updated to vB in AOCi 10.3.

 

3.25 OC028 - Post Flight Summary Report

3.25.1  Message Overview

Flight summary information is often needed following a flight or group of flights. For example, a billing system may require actual flight information to track and analyze flight operation costs. OC028 provides the "actual" data related to a flight or flights within a specified date range. This information can be published from an AOCi system such as Operations Control or from an external system to system consuming the data.

This message interacts with t

3.25.2  Message System Flow

he systems as shown in Figure 33.

OC028 message system flow

Figure 33. OC028 message system flow

 

3.25.3   Message Details

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

Message Version

OC028 v1

Message Header Details

msgName: OC028
msgClass: PUBLISH
version: 1

Message Specification

OC028 PostFlightSummaryReportType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC028v1PostFlightSummaryReport.xml

Message Version History

Minor changes to message.

 

3.26 OC029 - Request Diversion

3.26.1  Message Overview

This message is similar to OC005 Divert Flight Leg, but contains more customer-specific fields. Customers should use OC005 unless advised by a Jeppesen deployment expert to use this message instead.

See OC005 for a description of diversion scenarios.

3.26.2  Message System Flow

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

OC029 message system flow

Figure 34. OC029 message system flow

 

3.26.3   Message Details

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

Message Version

OC029 v1

Message Header Details

msgName: OC029
msgClass: PUBLISH
version: 1

Message Specification

OC029 RequestDiversionType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC029v1RequestDiversion.xml

Message Version History

No changes.

 

3.27 OC030 - Fuel On Board at Enroute Positions

3.27.1  Message Overview

This message is used to send a message originating from an ACARS message through AOCi to a Dispatch or Operations Control system. The message communicates the fuel on board at various points in the flight. The typical information flow is as follows:

  1. Aircraft sends an ACARS message.
  2. ACARS message is retrieved by a receiver on the ground (for example, Arinc).
  3. Message is forwarded to external system, which translates the information into the AOCi OC030 message format.
  4. OC030 is forwarded through AOCi to the receiving Dispatch or Operations Control application.

3.27.2  Message System Flow

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

OC030 message flow

Figure 35. OC030 message system flow

 

3.27.3   Message Details

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

Message Version

OC030 v2

Message Header Details

msgName: OC030
msgClass: PUBLISH
version: 2

Message Specification

OC030 FuelOnBoardAtEnroutePositionsType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC030v2FuelOnBoardForEnroutePositions.xml

Message Version History

Version 1:
* New Message

Version 2:
* Added optional attribute UOM to OC030 fuel on board. 

 

3.28 OC031 - Gate Assignment

3.28.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.28.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.28.3   Message Details

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

Message Version

OC031 v1

Message Header Details

msgName: OC031
msgClass: PUBLISH
version: 1

Message Specification

OC031 GateAssignmentType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC031v1GateAssignment.xml

Message Version History

New Message

 

3.29 OC032 - Ad Hoc Create Flight Leg

3.29.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.29.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.29.3   Message Details

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

Message Version

OC032 v1

Message Header Details (RESPONSE)

msgName: OC032
msgClass: RESPONSE
version: 1

Message Specification

OC032 AdHocCreateFlightLegType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC032v1AdHocCreateFlightLeg.xml

Message Version History

Version 1
* Add new enumeration to "irregularOperationType" of Gate Return.

 

3.30 OC033 - Dispatcher Lock

3.30.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.30.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.30.3   Message Details

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

Message Version

OC033 v1

Message Header Details (REQUEST/RESPONSE)

msgName: OC033
msgClass: REQUEST/RESPONSE
version: 1

Message Specification

OC033 DispatcherLockRequestType
OC033 DispatcherLockResponseType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC033v1DispatcherFlightLockRequest.xml
OC033v1DispatcherFlightLockResponse.xml

Message Version History

Corrected sample messageClass from RESPONSE to REQUEST

 

3.31 OC034 - Aircraft Lock

3.31.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.31.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.31.3   Message Details

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

Message Version

OC034 v1

Message Header Details

msgName: OC034
msgClass: PUBLISH
version: 1

Message Specification

OC034 AircraftLockType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC034v1AircraftLock.xml

Message Version History

Version 1:
* Added airlineCode as mandatory element.

 

3.32 OC035 - Fuel Tankering Advice

3.32.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.32.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.32.3   Message Details

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

Message Version

OC035 v1

Message Header Details

msgName: OC035
msgClass: PUBLISH
version: 1

Message Specification

OC035 FuelTankeringAdviceType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC035v1TankeringAdvice.xml

Message Version History

Version 1:
* Added Tankering Advice record.

 

3.33 OC036 - Request Complete Flight Key

3.33.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.33.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.33.3   Message Details

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

Message Version

OC036 vA

Message Header Details

msgName: OC036
msgClass: PUBLISH
version: A

Message Specification

OC036 RequestCompleteFlightKeyType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC036vACompleteFlightKeyRequestPUBLISH.xml

Message Version History

Initial version

 

3.34 OC037 - Completed Flight Key

3.34.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.34.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.34.3   Message Details

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

Message Version

OC037 vA

Message Header Details

msgName: OC037
msgClass: PUBLISH
version: A

Message Specification

OC037 CompletedFlightKeyType

Defined in XSD

OperationsControl.xsd

Sample Messages

OC037vACompletedFlightKeyPUBLISH.xml

Message Version History

Initial version