System and Message Overviews
Document Version: 5.2
Date: March 3, 2014
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.
Table Of Contents
This document defines the interfaces which govern the interchange of data between a Schedule Planning 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.
Schedule Planning systems are used to develop and manage an airline’s marketing schedule.
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 Schedule Planning.
This document discusses the Schedule Planning messages currently supported by the Jeppesen Solution Integrator. Each message description includes the following:
Other data interfaces or formats not included in this document will be considered custom and not supported.
The XML schema for this ICD is published in the following file: SchedulePlanning.XSD
The following key concepts are referenced throughout this document.
Air carriers publish regular flight schedules that specify the date, time and frequency of their flights over a given time period. Most carriers input a single entry into a scheduling system using an industry-standard SSIM, which is then expanded into multiple leg records corresponding to the schedule.
For example, a carrier creates the following flight schedule:
[Flt#] [POD] [POA] [Effective Date] [Discontinue Date] [Days of Week]
2245 LAX SFO 01Jan2007 31DEC2007 1234567
This schedule entry is then expanded into the actual flight legs represented by the statement. In the above case, Flight 1234 would fly every day of the week during 2007, resulting in the creation of 365 flight leg records.
Schedules typically specify the flight number and a period in one table. This information is then expanded into another table of individual legs.
1.4.2 Schedule Changes
As changes to flight schedules occur, carriers must communicate these changes to reservation systems and other systems in the AOC. This is done using a standardized SSIM (Standard Schedules Information Manual) file. Once an SSIM is published, one of the following are sent to communicate schedule changes:
INFO: Operations Control systems include logic to parse an SSM file to locate and process relevant flight information. For example, the OC system receives an SSM file that updates a flight frequency from Monday, Wednesday and Friday to operate only on Monday and Friday. The OC system parses the dates, flags the removed Wednesdays, and sends necessary messages related to the required rescheduling.
1.4.3 Schedule Planning Versus Operations Control Messages
Schedule Planning systems address many of the same issues as Operations Control systems and therefore include many functionally-similar messages. For example, both systems send messages regarding rescheduling flights (SP002 and OC010). The messages contain similar fields with the following general exceptions:
1.4.4 Master Schedule Versus Daily Schedule
Many Schedule Planning systems create and maintain a master schedule from various SSIM files. These master schedules contain flight leg information including the equipment types, but exclude the aircraft identifier (tail number).
Operations Control systems often use daily schedules, which also specify the flight leg information, including the specific tail numbers.
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 “SP”) are further discussed in Section 3 AOC Interface Messages.
The following messages are processed by the Schedule Planning system.
This message is used to change the flight identifier for one or more flight legs within a flight. Use this message to change a flight leg’s flight key rather than canceling and recreating the flight.
184.108.40.206 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.
220.127.116.11 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.
This message interacts with the systems as shown in Figure 1.
The following table provides details on the message version and includes links to the message’s technical specification.
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) within the Schedule Planning system.
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 (SP001) 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.
18.104.22.168 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.
22.214.171.124 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.
This message interacts with the systems as shown in Figure 2.
The following table provides details on the message and includes links to the message’s technical specification.