Schedule Planning

System and Message Overviews

Document Version: 5.2

Date: March 3, 2014

Document Revision History

The following revision history table reflects all substantive changes to this document.

Table Of Contents

1 Introduction

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.

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 Schedule Planning.

1.2  Scope

This document discusses the Schedule Planning 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: SchedulePlanning.XSD

1.4 Key Concepts

The following key concepts are referenced throughout this document.

1.4.1 Schedules

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.

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:

• ASM – used by Operations Control systems to communicate leg-based schedule changes.
  Example: From historical data, a carrier knows that Flight 2245 from LAX to SFO never fully books on December 25 (Christmas day). The carrier sends an ASM to delete only that specific leg.
• SSM – used by Schedule Planning systems to communicate larger-scale (multiple and regular) schedule changes. br> Example: For the last two months, Flight 2245 from LAX to SFO has under-booked each and every Tuesday. The carrier sends an SSM to delete all occurrences of the Tuesday leg. 

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:

• SP messages contain a flight identifier whereas OC messages use a flight key. This allows schedules to be published without specifying the flight origin date, which is required by a flight key.
• SP messages include a period field for changing multiple flights on the schedule, whereas OC messages must specify specific flights using the flight key. The period includes an effective date, discontinue date and days of the week. This information translates into multiple flight legs.

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.

2  Message Summary

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

Table 2-1 Message Summary

3 AOC Interface Messages

The following messages are processed by the Schedule Planning system.

3.1 SP001 - Change Flight Identifier

3.1.1  Message Overview

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. 

3.1.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.1.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.1.2  Message System Flow

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

Figure 1. SP001 message system flow

3.1.3   Message Details

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

3.2 SP002 - Reschedule Flight

3.2.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) 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.

3.2.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.2.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.2.2  Message System Flow

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

Figure 2. SP002 message system flow

3.2.3  Message Details

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