Jet Plan User Manual

JetPlan User Manual
JetPlan User Manual
VERSION 11.0
Copyright © 2003-2019 Jeppesen. All rights reserved.
DATD_Jepp_JPE_UserManual
Document Revision History
NOTE For additional change history information, see the User Manuals page on
JetPlan.com.
Version Release Date Changes

10.2 October 19, 2018 • The “Route Commands” chapter includes the following
modification to the Runway-to-Runway information: If the
customer specifies a route from the Customer Route Database in
the flight plan request, JetPlan does not check the Preferred
Runways Database for a preferred runway.
• The “Payload, POD/POA, Weight, and Fuel Commands” chapter
includes the following modification to the RESDOM 5 reserve
policy information: The fixed reserves amount for RESDOM 5 is
always 3500 lbs.
• The “Payload, POD/POA, Weight, and Fuel Commands” chapter
includes the following modification to the China Civil Aviation
Regulation 121 (CCAR-121) R5 Fuel Policy information: Before
using the CCAR flight plan option in combination with any other
reserve fuel options, contact Jeppesen Customer Support or your
Jeppesen Service manager.
• The “Customer Aircraft Database” chapter includes the following
modification to the Climb Method (DM) and Descent Method
(DM) parameter definitions: JetPlan no longer uses the (N)
Traditional Raw Sample Method option for DM and CM.
11.0 April 25, 2019 • The “Route Commands” chapter includes modified guidelines for
user-defined alphanumeric waypoints.
• The “ATC Filing” chapter contains the following modification to
information on the Flight Plan Filing database: You can now use
the database to specify more than two destination alternate filing
addresses.
• The “Customer Aircraft Database” chapter includes the following
modification to the ETOP Approval Time (ET) parameter
definition: The supported value has been increased from three to
four digits.
• In the “Customer Aircraft Database” chapter, the definition of the
RNAV (RE) parameter has been modified to clarify how this
parameter is used in flight plan calculations.
• The “Text Weather” chapter now includes information on volcanic
ash reports.
Brief Contents
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
CHAPTER 1
JetPlan Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CHAPTER 2
Option Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
CHAPTER 3
Point of Departure and Point of Arrival Commands . . . . . . . . . . . . . . . . 63
CHAPTER 4
Restricted Area Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
CHAPTER 5
4D Avoid and Alert Restrictive Airspaces . . . . . . . . . . . . . . . . . . . . . . . 109
CHAPTER 6
Route Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
CHAPTER 7
Hold-Alternate Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
CHAPTER 8
Estimated Time of Departure Commands . . . . . . . . . . . . . . . . . . . . . . 309
Brief Contents
CHAPTER 9
Profile Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
CHAPTER 10
Aircraft Type Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
CHAPTER 11
Cruise Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
CHAPTER 12
Cost Index Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
CHAPTER 13
Operational Weight Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
CHAPTER 14
Payload, POD/POA, Weight, and Fuel Commands . . . . . . . . . . . . . . . 413
CHAPTER 15
Fuel Off/On and Payload Off Commands . . . . . . . . . . . . . . . . . . . . . . 475
CHAPTER 16
Departure and Arrival Bias Commands . . . . . . . . . . . . . . . . . . . . . . . . 479
CHAPTER 17
Message Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
CHAPTER 18
Forward Plans and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
CHAPTER 19
ATC Filing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
CHAPTER 20
Reclear Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
CHAPTER 21
ETOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
CHAPTER 22
Overwater Driftdown and Terrain Analysis . . . . . . . . . . . . . . . . . . . . . 593
JetPlan User Manual April 25, 2019

© 2003-2019 Jeppesen. All rights reserved.
iv
Brief Contents
CHAPTER 23
Point of Safe Diversion and Point of Safe Return . . . . . . . . . . . . . . . . 655
CHAPTER 24
Optimal Scenario Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
CHAPTER 25
Enroute Charges and FIR Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . 681
CHAPTER 26
Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
CHAPTER 27
Customer Aircraft Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
CHAPTER 28
Aircraft Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
CHAPTER 29
Customer Alternate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
CHAPTER 30
Customer Airport Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
CHAPTER 31
Airport Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
CHAPTER 32
Generic Airport Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
CHAPTER 33
City Pair Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
CHAPTER 34
City Pair Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
CHAPTER 35
Coded Departure Routes Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
CHAPTER 36
Flight Brief Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
April 25, 2019 JetPlan User Manual

v
Brief Contents
CHAPTER 37
Master Database (MDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
CHAPTER 38
Minimum Equipment List Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
CHAPTER 39
Preferred Runways Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
CHAPTER 40
Restricted Area Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
CHAPTER 41
Customer Route Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
CHAPTER 42
Route Constraint Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
CHAPTER 43
Scenario Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
CHAPTER 44
Customer Schedule Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
CHAPTER 45
Customer Controlled Avoid and Alert Database . . . . . . . . . . . . . . . . 1131
CHAPTER 46
User-Defined Restrictive Airspace Database . . . . . . . . . . . . . . . . . . 1135
CHAPTER 47
Weather Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
CHAPTER 48
Text Weather . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
CHAPTER 49
Graphic Weather . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
CHAPTER 50
JEPPFAX Weather Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215

vi
Brief Contents
CHAPTER 51
Vertical Wind Shear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219

vii
Contents
Tables xxxvii
Introduction 1
About JetPlan® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
About the JetPlan User Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Document Overview and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
User ID and Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Default Flight Plan Output Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Customer Support Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
User ID Attribute File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Customer Preferences Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapter 1: JetPlan Command-Line Interface 9

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Understanding the Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Command-Line Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Information Provided by the CADB Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Optional Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Understanding the Batch Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Command-Line and Batch Method: Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Command-Line and Batch Method: Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 2: Option Commands 21

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Flight Plan Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Contents
Flight Plan Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Flight Plan Options–Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Flight Plan Options–Weather Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Flight Plan Options–Routing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Flight Plan Options–Performance Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Flight Plan Options–Feature Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Flight Plan Options–Flight Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Flight Plan Options–Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Additional Command-Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Support Information and Action Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Flight Plan Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Weather Services Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Messages Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Data Transmission Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 3: Point of Departure and Point of Arrival Commands 63

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Specifying Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Airport Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Diversion Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Sequential Entry Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Paired-Entry Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
ETP Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Determination of Bounding Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Interval Halving Between Bounding Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
CADB Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Variations in ETP Calculation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Default ETP Calculation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Second ETP Calculation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Third ETP Calculation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ETP and Diversion Airport Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Ad Hoc Airports and In-Flight Starts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
About Ad Hoc Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Defining an Ad Hoc Airport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
About Flight Level (FL) and Ad Hoc Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
About In-Flight Starts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Defining an Ad Hoc In-Flight Start Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Ad Hoc Airports as In-Flight Start Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Stored Airports as In-Flight Start Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
NAVAIDs as In-Flight Start Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Running In-Flight-Start ETP Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Taxi Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Taxi Parameters in the Customer Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Entering Taxi Fuel Directly in the Flight Plan Request . . . . . . . . . . . . . . . . . . . . . . 89

x
Contents
Adding the Taxi-Out Value to the ETD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Takeoff Alternate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Specifying a Fuel Price . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Chapter 4: Restricted Area Commands 95

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using the RST Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Delineated Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Restrictions By Route Structure Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
FIR/UIR Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Airway Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Airway Altitude Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Checkpoint Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Customer Route Database Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Applying Restricted Area Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Applying Multiple Restricted Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Omitting a Restricted Area Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Chapter 5: 4D Avoid and Alert Restrictive Airspaces 109

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Understanding the CCAA Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Creation of the Initial CCAA Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Understanding the Source Restrictive Airspace Databases . . . . . . . . . . . . . . . . . . 115
Restrictive Airspace Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Source Restrictive Airspace Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Generic Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Organized Tracks Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . . . . . . 117
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Turbulence Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
FIR/UIR Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Geopolitical Country Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . . . 118
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
User-Defined Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Understanding the Contents of CCAA Database Records . . . . . . . . . . . . . . . . . . . 119
The RSA Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
The ICAO Code in the RSA Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
About the Default SCA Type and Default Avoidance Level . . . . . . . . . . . . . . . . . . . . . 121
Modifying the SCA Type and the Avoidance Level . . . . . . . . . . . . . . . . . . . . 123
Working with the 4D Avoid and Alert Flight Plan Options . . . . . . . . . . . . . . . . . . 124
Understanding the 4D Avoid and Alert Flight Plan Options . . . . . . . . . . . . . . . . . 124

xi
Contents
Using the CCAA, CCAAN, and CCAAF Options . . . . . . . . . . . . . . . . . . . . . . . . . 127

Using the CCAA Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Using the CCAAN Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using the CCAAF Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Using the ORTRKA and ORTRKN Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Using the GCAA and GCAN Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Using the AVDERR Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Using the EXSS Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Using the EXCD Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Using the CCAAQ Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Understanding the City Pair and City Pair Fleet Database CCAAQ Parameters . . . . 134
Overriding an Avoidance Level on a Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Understanding 4D Avoid and Alert Customer Preferences . . . . . . . . . . . . . . . . . . 138
4D Altitudes (4DALTS) Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
AVDERR Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
CCAAQ Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Understanding 4D Avoid and Alert Error Messages . . . . . . . . . . . . . . . . . . . . . . . . 139
Chapter 6: Route Commands 141

About Route Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
About the Route Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
The Navigation Database and Route Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
JetPlan Defined Route Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Applying Route Inputs – General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
JetPlan-Defined Flight Plan Types and the Route Segment Inputs . . . . . . . . . . . . . . . 150
Route Input Segments – Basic Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
RTD and RTA Segments – Input Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Waypoint Identification (RTD/RTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Waypoint External Output (RTD/RTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Waypoint Ambiguity (RTD/RTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
RTW Segment – Input Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
The Route Optimizer and SID/STAR Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Using Route Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Applying Route Inputs – Domestic Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Optimized Direct Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
NAV Optimized Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Airway Optimized Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Nav Optimized Routing Between Specific Waypoints . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Airway Optimized Routing Between Specific Waypoints . . . . . . . . . . . . . . . . . . . . . . . 162
Domestic Planning – All 3 Route Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Applying Route Inputs – International Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Optimized Direct Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
POD and POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Enroute Waypoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Overwater Waypoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

xii
Contents
Nav Optimized Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Airway Optimized Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Nav Optimized Routing – Between Specific Waypoints . . . . . . . . . . . . . . . . . . . 166
Airway Optimized Routing – Between Specific Waypoints . . . . . . . . . . . . . . . . 167
JetPlan Designated Preferred Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
International Planning – Organized Track Structures . . . . . . . . . . . . . . . . . . . . . . 167
North Atlantic Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
North Atlantic Tracks – Basic Route Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
North Atlantic Tracks – Preferred Route Considerations . . . . . . . . . . . . . . . . . . . 171
Area 1 Preferred Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Preferred Routes Without the NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Preferred Route Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
North Atlantic Tracks – Flight Level Considerations . . . . . . . . . . . . . . . . . . . . . . 174
North Atlantic Data Link Mandate (NAT DLM) . . . . . . . . . . . . . . . . . . . . . . 175
North Atlantic Performance-Based Communications and Surveillance . . . . 177
North Atlantic Tracks – Input Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Selecting the Optimal Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Selecting a Specific Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Westbound Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Eastbound Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
North Atlantic Tracks – Crossing Without The NATS . . . . . . . . . . . . . . . . . . . . . . . . . 186
Pacific Organized Track Structures (PACOTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Flex Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Flex Tracks – Route Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
PACOTS – Far East To/From North America . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
PACOTS – Route Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
AUSOTS Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Route Input Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
POD and POA in the Same Route Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
POD and POA in Different Route Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
National Route Program (NRP) Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
NRP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
NRP Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Route Summary Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Filing Strip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Non-Restrictive Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
High-Altitude Redesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
HAR Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
NRS Waypoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
High-Altitude RNAV Routes (Q Routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Pitch and Catch Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
NRR Levels of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
NRR Flight Planning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
NRR Setup Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Customer Preferences Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Customer Aircraft Database (CADB) – Equipment Section . . . . . . . . . . . . . . . . . . . . 205

xiii
Contents
City Pair Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

About the NRR Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
NRR with HAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Pitch and Catch Points in an NRS-Optimized Route . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
NRR with PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
NRR with SRS Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
NRR and NRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
MEL RNAV Degradation and NRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
About the Specific Route Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
The Navigation Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
SRS Facts and Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
SRS Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
The Dash Delimiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Input Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Starting/Ending Route With a Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Starting/Ending Route With an Airway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
SRS Input Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Latitude and Longitude Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Unnamed Latitude and Longitude Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
User-Named Latitude and Longitude Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Guidelines for Naming Waypoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Charted (External) Name Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Charted Names (No Modifier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Charted Names Using “NAVAID Type” Modifiers . . . . . . . . . . . . . . . . . . . . . . . 219
Charted Names Using Coordinate Approximation . . . . . . . . . . . . . . . . . . . . . . . . 220
RNAV Waypoint Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Airway Name Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Charted Airway Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
User-Specified Airway Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
SID/STAR Name Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Runway Name Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
NAVAID/Radial Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
NAVAID/Radial Intersecting a NAVAID/Radial . . . . . . . . . . . . . . . . . . . . . . . . . 223
NAVAID/Radial Intersecting an Airway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
NAVAID/Radial to a Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
NAVAID/Radial/Distance Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Great Circle Route Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Single Segment Great Circle Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Multi-Segment Great Circle Route: Latitudinal or Longitudinal Crossings . . . . . 225
Multi-Segment Great Circle Route: Latitudinal and Longitudinal Crossings . . . . 226
Predominantly East/West Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Predominantly North/South Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Great Circle Route Segment(s) Between Any Two SRS Waypoints . . . . . . . . . . . 227
JetPlan SRS Distance Override/Bias Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
SRS Routing for User-Defined Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

xiv
Contents
SRS Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

VOR, VORDME, VORTAC, TACAN and NDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Named RNAV Waypoints, Intersections, and Reporting Points . . . . . . . . . . . . . . . . . . 231
One-Word Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Multi-Word Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Combination (SRS – Route Optimizer) Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Input Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Combination Routing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Route Optimizer to SRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
SRS to Route Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
SRS to Route Optimizer to SRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Route Optimizer to SRS to Route Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Multiple Switch Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
SRS Static Preferred Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Published Preferred Routing (High Altitude) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Limited Navigational Capability Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Route Line Editing for Route Optimizer and SRS . . . . . . . . . . . . . . . . . . . . . . . . . 240
Route Line Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Changing a Field Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Deleting a Field Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Inserting a Field Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Runway-to-Runway Flight Planning and Preferred Runways . . . . . . . . . . . . . . . 246
Overriding a Preferred Runway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Preferred Runway Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Creating a Preferred Runway Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Creating a Preferred Runway Record in JetPlan.com . . . . . . . . . . . . . . . . . . . . . . . . . 248
Using the JetPlan Command-Line Interface to Manage Preferred Runway Records . 249
Using Customer Route Database Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Route Line Editing of a CRDB Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Using Coded Departure Route (CDR) Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
About Coded Departure Routes (CDRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
About the Customer Coded Departure Route Database . . . . . . . . . . . . . . . . . . . . . 254
Using a Coded Departure Route Database Record As a Flight Plan Input . . . . . . 254
Electronic Route Availability Document Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
About the FlitePlan Core Route Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
About 2HEAVY Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Accessing ERAD 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Options and Inputs Supported with ERAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
ERAD Point of Departure (POD) and Point of Arrival (POA) Inputs . . . . . . . . . . . . . 257
ERAD Route Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
ERAD and the NATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
ERAD Flight-Level Input Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
ERAD and European Conditional Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
ERAD 2.0 Restricted Areas Options and Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

xv
Contents
Avoiding Checkpoints and Airways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Avoiding Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Avoiding Airways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Avoiding Countries by ICAO Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Avoiding FIRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Ignoring RAD Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
RST Options Not Supported with ERAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
How ERAD Responds to Customer Controlled Avoid and Alert Options . . . . . . . . . . . 266
Time, Fuel, and Cost Optimization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
ERAD Special Remarks in the Filing Strip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Suppressing ERAD Special Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
ERAD Lateral Route Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
ERAD Lateral Route Only Option in the Generic Aircraft Database . . . . . . . . . . 269
ERAD 2.0 Flight Plan Options Supported Only in the Command-Line Interface . . . . 270
Include DAL/TOC/BOC Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
ERAD 2.0 Runway-to-Runway Flight Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Dynamic SID/STAR Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
No Internal EUROCONTROL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Chapter 7: Hold-Alternate Commands 273

Hold-Alternate Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Hold-Alternate Fuel Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Hold Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Alternate Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Uplift Option (AIR OPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Alternate Flight Level Restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Calculating an Optimal Route to a Destination Alternate . . . . . . . . . . . . . . . . . . . 280
Using the DAR Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Specifying a Route in DAR Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Using the DAROPT Flight Plan Option with DAR . . . . . . . . . . . . . . . . . . . . . . . . 281
Customer Alternate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Distance Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Route Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Route Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
CALT Database Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Hold-Alternate Command-Line Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Automatic Alternate Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Automatic Selection Criteria and Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Criteria Tests at Compute Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
About the TAF Time Window (TAFWINDW) Customer Preference . . . . . . . . . . . . . . . 291
Alternate Selection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Departure (Takeoff) Alternates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Destination Alternates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
ETOPS/Overwater Driftdown Enroute Alternates (Diversion Airports) . . . . . . . . . . . 294
AIR OPS Enroute Alternates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

xvi
Contents
The Automatic AIR OPS ERA Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

AIR OPS Qualification Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Automatic Alternate Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Setting Up the Customer Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Customer Airport Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Departure Airport (POD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Arrival Airport (POA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Alternate Airport (ALT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Customer Airport Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Chapter 8: Estimated Time of Departure Commands 309

ETD Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
The Standard ETD Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Understanding the Wind and Temperature Database . . . . . . . . . . . . . . . . . . . . . . 313
“PROGS” Time Output on Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Online Winds – Sources and Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
ADF Format (Default) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
NWS Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
UKMO Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
UK MET Office Historical Winds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Reliability Equivalent Winds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
National Center for Atmospheric Research (NCAR) Database . . . . . . . . . . . . . . . . . . 316
Confidence Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Using the Reliability Equivalent Winds Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Required Arrival Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
RATCI (Fixed ETD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
RATCI Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
RATCI and the Customer Aircraft Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
RAT (Variable ETD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
RAT Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
ORBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
ORB Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
ORB and RAT Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Chapter 9: Profile Commands 327

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Altitude Flight Rule Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Altitude Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Auto Step Climb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Changing Flight Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Waypoints As Constraint Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Altitude Change After Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

xvii
Contents
Altitude Change at Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Constraint Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Altitude Control Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Maximum Altitude Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Climb and Descent Altitude Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
FPM Climb and Descent Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Required FPM Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Required FPM Climb and Descent Method Parameter Settings . . . . . . . . . . . . . . 339
Initial Climb and Descent Speed Schedule Settings . . . . . . . . . . . . . . . . . . . . . . . 340
Requesting Climb and Descent Altitude Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Requesting MEA,MAA and GRID MORA Data Constraints . . . . . . . . . . . . . . . . . . . . . 341
SID/STAR Profile Constraints Customer Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Using the FPM Secondary Climb and Descent Option . . . . . . . . . . . . . . . . . . . . . . . . . 342
Flight Plan Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Performance Index (Fuel, Time, and Cost) Optimization . . . . . . . . . . . . . . . . . . . . 342
Fuel Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Time Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Cost Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Order of Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapter 10: Aircraft Type Commands 347

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Using the JetPlan Aircraft Library (Generic Aircraft) . . . . . . . . . . . . . . . . . . . . . . 349
Retrieving Library Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Retrieving Generic Aircraft Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Applying a Generic Aircraft to a Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Using the Customer Aircraft Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Chapter 11: Cruise Mode Commands 359

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Determining an Aircraft’s Cruise Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Standard Cruise Mode Designations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Stored Cruise Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Non-Stored Cruise Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Primary Cruise Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Multiple Primary Cruise Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Cost Index Cruise Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Multiple Primary Cost Index Cruise Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Auxiliary Cruise Mode Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Auxiliary Cruise with Multiple Primary Cruise Modes . . . . . . . . . . . . . . . . . . . . . 371
Climb and Descent Schedule Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
First Principles Aircraft Model Secondary Climb and Descent Options . . . . . . . . 372
Secondary Climb Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

xviii
Contents
FPM Secondary Climb Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Secondary Descent Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
FPM Secondary Descent Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Bias Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Bias Input Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Climb Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
CF – Climb Fuel Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
CT – Climb Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
CD – Climb Distance Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Cruise Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
FF – Fuel Flow Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
AS – True Airspeed Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Descent Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
DF – Descent Fuel Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
DT – Descent Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
DD – Descent Distance Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Alternate Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
AF – Alternate Fuel Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
AT – Alternate Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
AD – Alternate Distance Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Combined Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Applying MEL Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
MEL Input Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Chapter 12: Cost Index Commands 387

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Cost Index Cruise Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Cost Index Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
General Requirements and Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Cost Index Application (Static Method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Cost Index Application (Dynamic Method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Cost Index vs. Other Economy Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Minimum Adjusted Cost Index Cruise Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
MACI and Required Arrival Time Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
MACI Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Configuring Customer Databases for MACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
CADB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
CAPDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
CPFDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Default Block Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Crew Cost Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Lateness Time Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
CAPFDB and ACFDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Related JetPlan Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

xix
Contents
Chapter 13: Operational Weight Commands 409

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Operational Weight Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Chapter 14: Payload, POD/POA, Weight, and Fuel Commands 413

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Load Performance Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Payload, Fuel, and Weight Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Payload Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
xxxxx (Specify Actual Payload Amount – Fuel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
xxxxx,T (Specify Actual Payload Amount – Weight) . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Wxxxxxx/nnnnn (Waypoint Arrival Fuel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
W (Maximize the Payload Amount) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
ZW (Maximize the Payload Amount) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
F (Maximize the Payload Amount) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
ZF (Maximize the Payload Amount) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
xxxxx,Z (Zero Fuel Weight) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
PAXxxx (Passenger Count) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
POD or POA WT Fuel Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Dxxxxx (Departure Case) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Axxxxx (Arrival Case) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
DM (Departure Case, Maximum Load) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
AM (Arrival Case, Maximum Load) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
POD or POA WT Fuel Secondary Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
MFODxxxx (Minimum Fuel On Destination) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
MFAGxxxx (Minimum Fuel at Gate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
MFALTxxxx (Minimum Fuel At Alternate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
AFxxxx (Arrival Fuel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
FC=xxxxx (Fuel Capacity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
FD=x.xx (Fuel Density) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
TO=xxxxxx (Takeoff Weight) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
LA=xxxxxx (Landing Weight) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
ERA=xxxx (Enroute Alternate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Bxxxxx (Ballast Fuel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
ADJ=xxx (Adjustment Fuel Amount) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
MAXT=xxxxx (Maximum Tanker Fuel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
MCHT=xxx (Minimum Contingency Holding Time) . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
PN=1234 (Multi-Sector Tankering) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Domestic, International, and Island Reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Dxxx (Domestic Reserves) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Ixxx (Island Reserves) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
I (International Reserves) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
xxx (International Reserve Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
B43X=xx (B43 International Reserve Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
About the B43 Reserve Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

xx
Contents
How JetPlan Supports B43 Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

B43 Flight Plan Inputs and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
China Civil Aviation Regulation 121 (CCAR-121) R5 Fuel Policy (R5xx) . . . . . . . . . 439
Contingency Fuel and Time Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Reserve Fuel Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Additional Options that Affect Payload, Fuel, and Weight . . . . . . . . . . . . . . . . . . 440
Hold Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Reserve Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Max Fuel Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Automatic Weight Reiteration (Autoweight) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Application of Load Performance Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Arrival Fuel Case/Known Payload Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Departure Fuel Case/Known Payload Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . 444
Arrival Weight Case/Unknown Payload Flight Plans . . . . . . . . . . . . . . . . . . . . . . 446
Departure Weight Case/Unknown Payload Flight Plans . . . . . . . . . . . . . . . . . . . . 447
Departure Fuel Case/Unknown Payload Flight Plans . . . . . . . . . . . . . . . . . . . . . . 448
Departure Weight Case/Tanker Fuel Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . 449
Arrival Weight Case/Tanker Fuel Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Comparing Max Fuel Capacity Plans with MFOD Inputs . . . . . . . . . . . . . . . . . . . 450
Single-Leg Tankering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Fuel Index Tankering: TANK1 and TANK1X . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Database Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Flight Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Decision to Tanker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Maximum Tanker Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Fuel Cost Tankering: TANK2, TANK2X, TANK3, and TANK3X Options . . . . 457
Database Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Decision to Tanker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
TANK2/TANK2X Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
TANK3/TANK3X Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Using Bonded Fuel Prices in Tankering Calculations . . . . . . . . . . . . . . . . . . . . . . . . . 463
Maximum Tanker Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Tanker Limiting Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Fuel Savings Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Multi-Sector Tankering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Automatic Weight Reiteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Arrival Fuel Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Arrival Weight Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Departure Fuel Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Departure Weight Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Reclear Flight Plans And Landing Burnoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Chapter 15: Fuel Off/On and Payload Off Commands 475

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

xxi
Contents
Offloading and Onloading Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Offloading Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Onloading Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Offloading Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Chapter 16: Departure and Arrival Bias Commands 479

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Departure and Arrival Biases and the Customer Aircraft Database . . . . . . . . . . . . 481
Climb/Descent Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Climb/Descent Fuel Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Climb/Descent Time Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Climb/Descent Distance Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Climb Distance Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Climb Bias - TOC Before First Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Climb Bias - TOC After First Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Climb Bias - Flattening Climb Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Descent Distance Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Combining Bias Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Interaction Between Bias Database Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Chapter 17: Message Commands 491

Creating Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Packaging JetPlan Products in Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Combining Products Using the MG Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Message No Number - MGNN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Chapter 18: Forward Plans and Messages 497

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
AFTN, ARINC, and SITA Designators and Priority Codes . . . . . . . . . . . . . . . . . . 499
AFTN Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
ARINC Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
SITA Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Fax Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Basic Fax Forwarding Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Enhanced Fax Forwarding Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
ACARS Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Character Length Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Chapter 19: ATC Filing 511

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
JetPlan Automatic Filing Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Filing a Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

xxii
Contents
The Filing Program Command Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Database Support for the Filing Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
The Customer Aircraft Database (CADB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
The Flight Brief Database (FBDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
The Minimum Equipment List (MEL) Database . . . . . . . . . . . . . . . . . . . . . . . . . 532
The Customer Preference Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
The JetPlan Flight Plan Filing Database (FDB) . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Overriding the Flight Plan Filing Database . . . . . . . . . . . . . . . . . . . . . . . . 535
ICAO 2012 Flight Plan Filings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Summary of ICAO 2012 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
ICAO 2012 Changes to Item 10a/b and Item 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
ICAO 2012 Changes to the JetPlan Automatic Filing Program . . . . . . . . . . . . . . . . . 539
ICAO 2012 Changes to Customer Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Before Filing the ICAO 2012 Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Reducing the Likelihood of Flight Plan Rejects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Filing Priority and Timeliness Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
File Immediately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
AFTN Priority Code Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Delaying Filing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Lead Time Filing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Filing at a Specified Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Canceling Filed ICAO Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Changing Filed ICAO Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Filing Reclear Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Viewing Filing Status and History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Using the STAT Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Using the SHOW Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Working with Domestic Flight Plan Sequence Numbers . . . . . . . . . . . . . . . . . . . 551
Short Autofile Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Domestic U.S. Filing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Canceling a Domestic Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Chapter 20: Reclear Commands 557

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Plan Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Autoweight Flight Plan Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Commands, Options, and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Output Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Reclear Command Line Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Reclear Point Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Reclear Airport and Alternate Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Auto Selection (Reclear Airport and Alternate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Other Reclear Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Route Selection for Reclear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
User-Defined Routing for Reclear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

xxiii
Contents
Routing when Using the Auto Select Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Reclear Scenario Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Known Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Known Takeoff Weight/Optimum Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Known Takeoff Fuel/Optimum Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Known Landing Weight/Optimum Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Landing Burnoff Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Examples of Reclear Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Inputs for Known Payload (Arrival Fuel Case) . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Inputs for Unknown Payload (Departure Weight Case) . . . . . . . . . . . . . . . . . . . . . 579
Inputs for Unknown Payload (Departure Fuel Case) . . . . . . . . . . . . . . . . . . . . . . . 580
Reclear Example Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Decision Point Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
DPP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
EU-OPS Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Chapter 21: ETOPS 589

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Chapter 22: Overwater Driftdown and Terrain Analysis 593

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
FAR Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
FAR 121.191 – One Engine Inoperative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
FAR 121.193 – Two Engines Inoperative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Overwater (Basic) Driftdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Overwater Driftdown Setup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Customer Airport Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
ETP Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Driftdown Performance Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Overwater Driftdown Flight Plan Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Diversion Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
ETP Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Critical Fuel Calculation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Depressurized Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
One-Engine and Two-Engines Inoperative Scenarios . . . . . . . . . . . . . . . . . . . . . . 607
Highest Terrain Diversion Path Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Overwater Driftdown Data on the Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Terrain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Terrain Analysis Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Terrain Analysis Setup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Customer Preferences Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Customer Database Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Customer Airport Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

xxiv
Contents
Customer Airport Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620

Customer Aircraft Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
City Pair Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Minimum Equipment List (MEL) Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Application of Weight Penalties to Terrain Analysis Flight Plans . . . . . . . . . . . . 625
Escape Routes Database Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Terrain Analysis Flight Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Terrain Analysis Front-End Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Terrain Clearance Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Terrain Clearance Output on the Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Mountain Driftdown Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Mountain Driftdown Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Mountain Driftdown Output on the Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Mountain Driftdown Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Terrain Database Extract Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Segment Terrain Profile Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Enroute Terrain Profile Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Off-Route Terrain Profile Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Raw Terrain Data Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Chapter 23: Point of Safe Diversion and Point of Safe Return 655
About Point of Safe Diversion (PSD) Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . 657
PSD Flight Plan Inputs and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
PSD Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Calculating the PSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Calculating Reserve and Divert Leg Fuel Burn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Calculating PSD for Normal Operations and for the Worst Performance Case . . . . . 661
Order of Precedence for Worst Performance Case Calculations . . . . . . . . . . . . . 662
Chapter 24: Optimal Scenario Analysis 665

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Internal Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
External Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Internal and External Scenario Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
OSA Commands and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Basic OSA Examples And Explanations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Multiple External Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Explicit External Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Explicit External Scenario Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Changing Outcome Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Optimizing Direct vs. Specific Route Selector (SRS) Great Circle . . . . . . . . . . . 677
Enroute Charges and OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Enroute Charge Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Enroute Charge Print Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679

xxv
Contents
Route Cost Summary Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Chapter 25: Enroute Charges and FIR Traversal 681

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Accessing Enroute Charges Through JetPlanIII . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Generating an Ad Hoc Enroute Charges Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Viewing Exchange Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Viewing and Modifying Customer Exchange Rate Information . . . . . . . . . . . . . . . . . . 690
Generating a FIR/UIR Traversal Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Chapter 26: Archiving 695

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Enroute Charges Archive and Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Archive Commands (EC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
To save a record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
To cancel a record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
To change the ETD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
To print a record (or records) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Automatic Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Archive and Report Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Cosmic Radiation Archive and Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Archive Commands (CR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
To save a record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
To cancel a record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
To change the ETD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
To print a record (or records) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Automatic Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Chapter 27: Customer Aircraft Database 709

About the Customer Aircraft Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
CADB Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Flight Plan Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
CADB Record Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Searching Generic Aircraft Records for FPM and OUTFLT Information . . . . . . 718
CADB Parameters by Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
CADB Parameters “Weights” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
CADB Parameters: “Fuels” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
CADB Parameters: “Miscellaneous” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
CADB Parameters: “Modes” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
CADB Parameters: “Cutoff Weight Tables” Section . . . . . . . . . . . . . . . . . . . . . . . 738
CADB Parameters: “Bracket Modes” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
CADB Parameters: “Mode Coupling” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

xxvi
Contents
CADB Parameters: “Tanker” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743

CADB Parameters: “Equipment” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Overview of RAIM Prediction Report Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
CADB Parameters: “Certified” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
CADB Parameters: “ATS Plan” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
CADB Parameters: “ETP” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
CADB Parameters: “ETOPS” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
ETOPS Flag and Factor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
ETOPS Activation Flag Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
ETOPS Situation Flag Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
ETOPS Special Flag Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
ETOPS Factor Code Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
CADB Parameters: “Driftdown” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
CADB Parameters: “Biases” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
CADB Parameters: “Special Bias Modifications” Section . . . . . . . . . . . . . . . . . . 782
CADB Parameters: “ICAO 2012 Certification and Equipment” Section . . . . . . . 783
How the CADB Supports the ICAO 2012 Filed Flight Plan Format . . . . . . . . . . . . . . 783
Related Customer Database Changes for ICAO 2012 . . . . . . . . . . . . . . . . . . . . . . . . . 786
Before Using the ICAO 2012 CADB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Reducing the Likelihood of Flight Plan Rejects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
CADB Parameters: ICAO 2012 Certification and Equipment Section . . . . . . . . . . . . 788
Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Using JetPlan to Manage the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
File Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
CADB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Chapter 28: Aircraft Fleet Database 805

About the Aircraft Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
SCM Data Sets and the ACFDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
ACFDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Chapter 29: Customer Alternate Database 823

About the Customer Alternate Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Flight Plan Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825

xxvii
Contents

Using JetPlan to Manage the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
File Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
CALT Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Chapter 30: Customer Airport Database 831

About the Customer Airport Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
CAPDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Chapter 31: Airport Fleet Database 855

About the Customer Airport Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
About Taxi Time Adjustment Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
About Runway-to-Runway Planning and the Preferred Runways Parameters . . . 858
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
CAPFDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Chapter 32: Generic Airport Database 881

About the Generic Airport Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Generic Airport Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889

xxviii
Contents
Chapter 33: City Pair Database 891

About the City Pair Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
City Pair Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Chapter 34: City Pair Fleet Database 903

About the City Pair Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
About Taxi Time Adjustment Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Taxi Time Adjustment Set Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Order of Precedence for Taxi Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
SCM Sets and the CPFDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
About ETOPS SCM Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Setting a Default ETOPS SCM Set in a City Pair Fleet Record . . . . . . . . . . . . . . . . . 910
Order of Precedence for ETOPS SCM Set Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
CPFDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
CPFDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Chapter 35: Coded Departure Routes Database 927

About the Customer Coded Departure Routes Database . . . . . . . . . . . . . . . . . . . . 929
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Coded Departure Routes Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Chapter 36: Flight Brief Database 935

About the Flight Brief Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937

xxix
Contents
The Flight Brief Database and the ICAO 2012 FPL Format . . . . . . . . . . . . . . . . . 938
Before Using the ICAO 2012 Flight Brief Database Parameters . . . . . . . . . . . . . . . . . 938
Flight Brief Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
Chapter 37: Master Database (MDB) 961

About the Master Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
MDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Flight Plan Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Chapter 38: Minimum Equipment List Database 973

About the MEL Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
How the MEL Database Supports the ICAO 2012 FPL . . . . . . . . . . . . . . . . . . . . . 976
Before Using the ICAO 2012 MEL Database Parameters . . . . . . . . . . . . . . . . . . . . . . 977
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
MEL Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Flight Plan Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Applying True Airspeed and Fuel Flow Biases . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Applying Multipliers to Fuel Flow Bias and Weight Penalties . . . . . . . . . . . . . . . 999
Applying the Phase of Flight Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Applying Weight Penalties to Terrain Analysis Flight Plans . . . . . . . . . . . . . . . . 1000
Applying Equipment and Certification Degradations . . . . . . . . . . . . . . . . . . . . . 1002
Chapter 39: Preferred Runways Database 1003

About the Preferred Runways Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005

xxx
Contents
Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006

Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Using JetPlan to Manage the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
File Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Preferred Runways Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Chapter 40: Restricted Area Database 1011

About the Restricted Area Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Flight Plan Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Schedule Database Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Overriding a Restricted Area Database record Built Into a Schedule . . . . . . . . . 1015
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Restricted Area Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Chapter 41: Customer Route Database 1021

About the Customer Route Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Route Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Route Segment Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
The Pre-Effective Database Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Getting Help on Using the Pre-Effective Database . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Sending FMS Route Output to Jeppesen NavData . . . . . . . . . . . . . . . . . . . . . . . 1027
Route Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Route Segment Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
File Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Customer Route Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Generate Command (RT,GEN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Modify Command (RT,CHG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Delete Command (RT,DEL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044

xxxi
Contents
Rename Command (RT,RN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046

Update Command (RT,UPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Route Group Command (RG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
Route Group Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Group Name Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Add Command (RG,ADD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Delete Command (RG,DEL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
Using Group Names to Select Route Files in a Flight Plan . . . . . . . . . . . . . . . . . 1053
Print Command (RT,PRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
List Command (RT,LST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Route Proof Command (RT,RP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
Summary Command (RT,SUM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
Total Command (RT,TOT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
Record Identifier Command (RT,RID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Search Command (RT,SRH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Airway/Checkpoint Search Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Customer Route Database File Content Verification . . . . . . . . . . . . . . . . . . . . . . . . . 1071
Check Command (RT,CHK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
Check List (RT,CHK,LST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
List (LST) Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Check Route Proof (RT,CHK,RP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
OK Command (RT,OK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Changing Failed Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Customer Route Database Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Creating a Customer Route Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Changing a Customer Route Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Displaying a Customer Route Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1080
Renaming a Customer Route Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Deleting a Customer Route Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Displaying a Route Proof of All Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Displaying a Route Proof of a Specific File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Displaying a Summary of All Airports in Customer Route Database . . . . . . . . . 1083
Displaying a Summary of All Stored Routes in Customer Route Database . . . . 1083
Displaying a Summary of All Stored Routes To/From an Airport . . . . . . . . . . . 1084
Displaying a Summary of All Stored Routes Between Two Airports . . . . . . . . . 1084
Flight Plan Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Chapter 42: Route Constraint Database 1087

About the Route Constraint Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Canned Route Optimization Versus Random Route Optimization . . . . . . . . . . . 1090
Route Constraint Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Canned Route Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Random Route Optimization (Route Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092
Random Route Optimization (Restricted Area Only) . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Random Route Optimization (Route & Restricted Area) . . . . . . . . . . . . . . . . . . . . . . 1095

xxxii
Contents

File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Route Constraint Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
Precedence and Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103
Chapter 43: Scenario Database 1105

About the Scenario Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Scenario Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Chapter 44: Customer Schedule Database 1119

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Interaction Between the CSDB and the Customer Aircraft Database . . . . . . . . 1122
File Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
CSDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Using CSDB Files (Without Deferred Inputs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
Using CSDB Files (With Deferred Inputs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
Ad Hoc Restricted Area/Restricted Area Database File . . . . . . . . . . . . . . . . . . . 1129
Overriding CRAD Files Stored in CSDB Files . . . . . . . . . . . . . . . . . . . . . . . . . . 1130
Chapter 45: Customer Controlled Avoid and Alert Database 1131

About the CCAA Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133

xxxiii
Contents
Chapter 46: User-Defined Restrictive Airspace Database 1135

About the User-Defined Restrictive Airspace Database . . . . . . . . . . . . . . . . . . . . 1137
Chapter 47: Weather Introduction 1139

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Weather Commands and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Quick Reference Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Hourly Reports, Special Observations, and Terminal Forecasts . . . . . . . . . . . . . 1145
Single Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Multiple Reports/Complete Briefings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Great Circle Weather Briefing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Chapter 48: Text Weather 1149

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Types Of Weather Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Terminal Forecasts And Surface Observations . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Surface Observations And Special Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Regional Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Regional Surface Observations (METARs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Terminal Forecasts (TAFs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Terminal Forecasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
Area Forecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
NOTAMs - Jeppesen NOTAM Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Winds and Temperatures Aloft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Pilot Reports - PIREPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
U.S. PIREPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
SIGMETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
SIGMETs, AIRMETs - U.S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Convective SIGMETs - U.S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Convective Outlook - U.S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160
SIGMETs - Atlantic, Pacific, Caribbean and Canadian Areas . . . . . . . . . . . . . . . 1160
Severe Weather Watches and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
Typhoon, Hurricane Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
Volcanic Ash Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
NWS Meteorological Forecast Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
NWS Offshore Marine Forecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
ATC Center Weather Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
Multiple Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
Great Circle Weather . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Weather Enroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166

xxxiv
Contents
Chapter 49: Graphic Weather 1169

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171
Accessing Weather Maps Through JetPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171
Weather Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Africa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Asia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174
Australia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176
Canada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
Caribbean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179
East Pacific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Europe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Europe/Asia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
Indian Ocean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Mexico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Middle East . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1191
North Atlantic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
North Pacific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195
South America . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
South Pacific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198
United States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
U.S. Regional (Alaska) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
U.S. Regional (Hawaii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205
U.S. Regional (North Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
U.S. Regional (Northeast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
U.S. Regional (Northwest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
U.S. Regional (South Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
U.S. Regional (Southeast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
U.S. Regional (Southwest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Chapter 50: JEPPFAX Weather Maps 1215

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217
Chapter 51: Vertical Wind Shear 1219

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
Shear Value Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222

xxxv
Tables
JetPlan Command-Line Interface 9

Table 1-1: Command-Line Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 1-2: JetPlan Interface Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Option Commands 21
Table 2-1: Flight Plan Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 2-2: Flight Plan Options–Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 2-3: Flight Plan Options–Weather Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 2-4: Flight Plan Options–Routing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 2-5: Flight Plan Options–Performance Variables . . . . . . . . . . . . . . . . . . . . . . 36
Table 2-6: Flight Plan Options–Feature Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 2-7: Flight Plan Options/Commands–FMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 2-8: Flight Plan Options–Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 2-9: Support Information and Action Commands . . . . . . . . . . . . . . . . . . . . . . 46
Table 2-10: Flight Plan Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 2-11: Flight Plan Commands–Weather Information . . . . . . . . . . . . . . . . . . . . . 56
Table 2-12: Flight Plan Commands–Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Table 2-13: Data Transmission Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 2-14: Flight Plan Commands–Customer Database Access . . . . . . . . . . . . . . . . 58
Restricted Area Commands 95

Table 4-1: Route Structure Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Tables
4D Avoid and Alert Restrictive Airspaces 109

Table 5-1: Default SCA Types and Avoidance Levels in CCAA DB Records . . . . 121
Route Commands 141

Table 6-1: Internal Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Table 6-2: International Track Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Table 6-3: International Track Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Table 6-4: North Atlantic Tracks (Eastbound Examples) . . . . . . . . . . . . . . . . . . . . 170
Table 6-5: North Atlantic Tracks (Westbound Examples) . . . . . . . . . . . . . . . . . . . . 170
Table 6-6: North American Airports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Table 6-7: NAT DLM Phase 2A – 2B Required Item 10a/b Equipment . . . . . . . . . 176
Table 6-8: PBCS – Required Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Table 6-9: Route Inputs Supported with ERAD 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 257
Table 6-10: Route Inputs Planned for a Future Version of ERAD . . . . . . . . . . . . . . 258
Table 6-11: Route Inputs Not Supported or Recommended for Use with ERAD . . . 259
Table 6-12: FP_CDR Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Hold-Alternate Commands 273

Table 7-1: Hold-Alternate Command Line Sample Inputs . . . . . . . . . . . . . . . . . . . 285
Table 7-2: CAPFDB – POD Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Table 7-3: CAPFDB – POA Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Table 7-4: CAPFDB – Alternate Airport Application . . . . . . . . . . . . . . . . . . . . . . . 301
Table 7-5: CAPDB – Alternate Airport Application . . . . . . . . . . . . . . . . . . . . . . . . 306
Profile Commands 327

Table 9-1: Flight Rules Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Cruise Mode Commands 359

Table 11-1: Cruise Mode Designators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Table 11-2: Ad Hoc Bias Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Table 11-3: MEL Record Name Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Cost Index Commands 387

Table 12-1: CAPDB CI Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Table 12-2: CADB CI Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Table 12-3: MACI Cost Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Table 12-4: CADB Operating Cost Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Table 12-5: CADB RAT Max/Min CI Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Table 12-6: CAPDB MACI Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

xxxviii
Tables
Table 12-7: CPFDB Default Block Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 402

Table 12-8: CPFDB Crew Costs Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Table 12-9: Sample Lateness Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Table 12-10: CPFDB Lateness Segment Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 404
Payload, POD/POA, Weight, and Fuel Commands 413

Table 14-1: Common International Reserve Policy Formulas . . . . . . . . . . . . . . . . . 432
Table 14-2: Arrival Fuel Case/Known Payload Basics . . . . . . . . . . . . . . . . . . . . . . . 443
Table 14-3: Departure Fuel Case/Known Payload Basics . . . . . . . . . . . . . . . . . . . . . 445
Table 14-4: Arrival Weight Case/Unknown Payload Basics . . . . . . . . . . . . . . . . . . . 446
Table 14-5: Departure Weight Case/Unknown Payload Basics . . . . . . . . . . . . . . . . 447
Table 14-6: Departure Fuel Case/Unknown Payload Basics . . . . . . . . . . . . . . . . . . . 448
Table 14-7: Departure Weight Case/Tanker Fuel Basics . . . . . . . . . . . . . . . . . . . . . 449
Table 14-8: Arrival Weight Case/Tanker Fuel Basics . . . . . . . . . . . . . . . . . . . . . . . . 450
Table 14-9: Fuel Index Tankering - Database Requirements . . . . . . . . . . . . . . . . . . 453
Table 14-10: Fuel Cost Tankering - Database Requirements . . . . . . . . . . . . . . . . . . . 457
Table 14-11: Tanker Limiting Factors – Output Messages . . . . . . . . . . . . . . . . . . . . . 464
Forward Plans and Messages 497

Table 18-1: Network Designators (AFTN, ARINC, SITA) . . . . . . . . . . . . . . . . . . . 500
Table 18-2: Priority Codes (SITA, ARINC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Table 18-3: Priority Codes (AFTN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Table 18-4: Fax Forwarding Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Table 18-5: Character Length Control Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
ATC Filing 511

Table 19-1: JetPlan Automatic Filing Program Command Prompts . . . . . . . . . . . . . 516
Table 19-2: Links Between Item 18 PBN/ and Item 10a . . . . . . . . . . . . . . . . . . . . . . 538
Table 19-3: FI,SHOW Input Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Table 19-4: FI,SHOW Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Reclear Commands 557

Table 20-1: Canned Tracks Available for Reclear Routing . . . . . . . . . . . . . . . . . . . 572
Overwater Driftdown and Terrain Analysis 593

Table 22-1: Airport Fleet Database Parameters Used in Overwater Driftdown . . . . 599
Table 22-2: Overwater Driftdown – ETP Database Parameters . . . . . . . . . . . . . . . . 600
Table 22-3: Overwater Driftdown Summary Data . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Table 22-4: Terrain Analysis Customer Preferences . . . . . . . . . . . . . . . . . . . . . . . . . 616

xxxix
Tables
Table 22-5: Terrain Analysis – Customer Airport Database Parameters . . . . . . . . . . 619

Table 22-6: Terrain Analysis – Airport Fleet Database Parameters . . . . . . . . . . . . . 620
Table 22-7: Terrain Analysis – Customer Aircraft Database Parameters . . . . . . . . . 621
Table 22-8: Terrain Analysis – City Pair Fleet Database Parameters . . . . . . . . . . . . 623
Table 22-9: Terrain Analysis – MEL Database Parameters . . . . . . . . . . . . . . . . . . . . 624
Table 22-10: Escape Route Record Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Table 22-11: Terrain Analysis Front-End Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Table 22-12: Mountain Driftdown Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Point of Safe Diversion and Point of Safe Return 655

Table 23-1: CADB Parameters Used to Determine Worst Performance Case . . . . . 662
Enroute Charges and FIR Traversal 681

Table 25-1: Enroute Charges Prompts and Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Archiving 695
Table 26-1: Enroute Charges Archive Record Detail . . . . . . . . . . . . . . . . . . . . . . . . 699
Table 26-2: Cosmic Radiation Archive Record Detail . . . . . . . . . . . . . . . . . . . . . . . 704
Customer Aircraft Database 709

Table 27-1: CADB Record Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Table 27-2: CADB Record: “Weights” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Table 27-3: CADB Record: “Fuels” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Table 27-4: CADB Record: “Miscellaneous” Section . . . . . . . . . . . . . . . . . . . . . . . . 727
Table 27-5: CADB Record: “Modes” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Table 27-6: CADB Record: “Cutoff Weight Tables” Section . . . . . . . . . . . . . . . . . . 738
Table 27-7: CADB Record: “Bracket Modes” Section . . . . . . . . . . . . . . . . . . . . . . . 739
Table 27-8: CADB Record: “Mode Coupling” Section . . . . . . . . . . . . . . . . . . . . . . . 742
Table 27-9: CADB Record: “Tanker” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Table 27-10: CADB Record: “Equipment” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Table 27-11: CADB Record: “Certified” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Table 27-12: CADB Record: “ATS Plan” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Table 27-13: CADB Record: “ETP” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Table 27-14: CADB Record: “ETOPS” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Table 27-15: ETOPS Activation Flag Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Table 27-16: ETOPS Situation Flag Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Table 27-17: ETOPS Special Flag Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Table 27-18: ETOPS Factor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Table 27-19: APU Burn Factor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

xl
Tables
Table 27-20: MAP Burn Factor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776

Table 27-21: ETOPS Hold Burn Factor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Table 27-22: ETOPS Cruise Distance Factor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Table 27-23: CADB Record: “Driftdown” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Table 27-24: CADB Record: “Biases” Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Table 27-25: Links Between Item 18 PBN/ and Item 10a . . . . . . . . . . . . . . . . . . . . . . 785
Table 27-26: CADB Record: “ICAO 2012” Section . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Table 27-27: CADB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Aircraft Fleet Database 805

Table 28-1: SCM Data Set Overlap with the CADB . . . . . . . . . . . . . . . . . . . . . . . . 807
Table 28-2: Aircraft Fleet Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Table 28-3: ACFDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . 822
Table 28-4: ACFDB File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Customer Alternate Database 823

Table 29-1: Customer Alternate Database Parameters . . . . . . . . . . . . . . . . . . . . . . . 826
Table 29-2: CALT Database File Maintenance Commands . . . . . . . . . . . . . . . . . . . 829
Customer Airport Database 831

Table 30-1: CAPDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Table 30-2: CAPDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . 852
Table 30-3: CAPDB File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Airport Fleet Database 855

Table 31-1: CAPFDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Table 31-2: CAPFDB Record Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Table 31-3: CAPFDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . 877
Table 31-4: CAPFDB File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Generic Airport Database 881

Table 32-1: Generic Airport Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Table 32-2: Generic Airport Database File Maintenance Commands . . . . . . . . . . . . 889
Table 32-3: Generic Airport Database File Display Commands . . . . . . . . . . . . . . . . 890
City Pair Database 891

Table 33-1: City Pair Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Table 33-2: City Pair Database File Maintenance Commands . . . . . . . . . . . . . . . . . 901
Table 33-3: City Pair Database File Display Commands . . . . . . . . . . . . . . . . . . . . . 901

xli
Tables
City Pair Fleet Database 903

Table 34-1: Order of Precedence for Taxi Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Table 34-2: CPFDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Table 34-3: CPFDB Record Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Table 34-4: CPFDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Table 34-5: CPFDB File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Coded Departure Routes Database 927

Table 35-1: Customer Coded Departure Routes Database Parameters . . . . . . . . . . . 930
Table 35-2: Coded Departure Routes Database File Maintenance Commands . . . . . 932
Table 35-3: Coded Departure Routes Database File Display Commands . . . . . . . . . 933
Flight Brief Database 935

Table 36-1: Flight Brief Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Table 36-2: Flight Brief Database File Maintenance Commands . . . . . . . . . . . . . . . 957
Table 36-3: Flight Brief Database File Display Commands . . . . . . . . . . . . . . . . . . . 958
Master Database (MDB) 961

Table 37-1: MDB Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
Table 37-2: MDB Record Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Table 37-3: MDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Table 37-4: MDB File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
Minimum Equipment List Database 973

Table 38-1: MEL Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Table 38-2: MEL Database File Maintenance Commands . . . . . . . . . . . . . . . . . . . . 994
Table 38-3: MEL Database File Display Commands . . . . . . . . . . . . . . . . . . . . . . . . 995
Preferred Runways Database 1003

Table 39-1: Preferred Runway Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Table 39-2: Preferred Runways Database File Maintenance Commands . . . . . . . . 1010
Table 39-3: Preferred Runways Database File Display Commands . . . . . . . . . . . . 1010
Restricted Area Database 1011

Table 40-1: Restricted Area Database File Maintenance Commands . . . . . . . . . . . 1017
Table 40-2: Restricted Area Database File Display Commands . . . . . . . . . . . . . . . 1018

xlii
Tables
Customer Route Database 1021

Table 41-1: Route Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
Table 41-2: Route Segment Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
Table 41-3: Route Group Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Table 41-4: List (LST) Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Table 41-5: OK Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Route Constraint Database 1087

Table 42-1: Qualifying Parameters in the CADB . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Table 42-2: Route Constraint Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . 1097
Table 42-3: Route Constraint Database File Maintenance Commands . . . . . . . . . . 1100
Table 42-4: Route Constraint Database File Display Commands . . . . . . . . . . . . . . 1102
Scenario Database 1105

Table 43-1: Scenario Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Table 43-2: Scenario Database File Maintenance Commands . . . . . . . . . . . . . . . . 1115
Table 43-3: Scenario Database File Display Commands . . . . . . . . . . . . . . . . . . . . 1117
Customer Schedule Database 1119

Table 44-1: CSDB File Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Table 44-2: CSDB Database File Display Commands . . . . . . . . . . . . . . . . . . . . . . 1127
Weather Introduction 1139

Table 47-1: Weather Commands and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Table 47-2: Single Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Table 47-3: Multiple Reports Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Text Weather 1149

Table 48-1: NWS Weather Bulletins: Regional Surface Observations (METARs) 1152
Table 48-2: NWS Weather Bulletins: Regional Terminal Forecasts (TAFs) . . . . . 1153
Table 48-3: Mexico Region: Hourly Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Table 48-4: United States: Area Forecast Stations . . . . . . . . . . . . . . . . . . . . . . . . . 1154
Table 48-5: International: Area Forecast Stations . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Table 48-6: NOTAM Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Table 48-7: United States: SIGMET/AIRMET Stations . . . . . . . . . . . . . . . . . . . . . 1159
Table 48-8: United States: Convective SIGMET Stations . . . . . . . . . . . . . . . . . . . 1159
Table 48-9: United States: Convective Outlook Stations . . . . . . . . . . . . . . . . . . . . 1160
Table 48-10: Atlantic, Pacific, Caribbean, and Canadian: SIGMET Stations . . . . . . 1160
Table 48-11: United States: Severe Weather Watches and Warnings Stations . . . . . 1161

xliii
Tables
Table 48-12: Other Regions: Severe Weather Warnings Stations . . . . . . . . . . . . . . . 1161

Table 48-13: Other Regions: Typhoon and Hurricane Report Stations . . . . . . . . . . . 1161
Table 48-14: Other Regions: Volcanic Ash Report Stations . . . . . . . . . . . . . . . . . . . 1162
Table 48-15: Multiple Reports Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
Table 48-16: NWS Report Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
Graphic Weather 1169

Table 49-1: Type: Satellite (Africa) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Table 49-2: Type: Surface & Low-level Significant Weather (Africa) . . . . . . . . . . 1172
Table 49-3: Type: High-level Significant Weather (Africa) . . . . . . . . . . . . . . . . . . 1172
Table 49-4: Type: Winds And Temps Aloft (Africa) . . . . . . . . . . . . . . . . . . . . . . . . 1173
Table 49-5: Type: Aviation Hazards (Africa) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
Table 49-6: Type: Satellite (Asia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174
Table 49-7: Type: Surface & Low-level Significant Weather (Asia) . . . . . . . . . . . 1174
Table 49-8: Type: High-level Significant Weather (Asia) . . . . . . . . . . . . . . . . . . . . 1174
Table 49-9: Type: Winds And Temps Aloft (Asia) . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Table 49-10: Type: Aviation Hazards (Asia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Table 49-11: Type: Satellite (Australia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176
Table 49-12: Type: Surface & Low-level Significant Weather (Australia) . . . . . . . . 1176
Table 49-13: Type: High-level Significant Weather (Australia) . . . . . . . . . . . . . . . . 1176
Table 49-14: Type: Winds And Temps Aloft (Australia) . . . . . . . . . . . . . . . . . . . . . 1176
Table 49-15: Type: Aviation Hazards (Australia) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
Table 49-16: Type: Satellite (Canada) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
Table 49-17: Type: Surface & Low-level Significant Weather (Canada) . . . . . . . . . 1178
Table 49-18: Type: High-level Significant Weather (Canada) . . . . . . . . . . . . . . . . . 1178
Table 49-19: Type: Winds and Temps Aloft (Canada) . . . . . . . . . . . . . . . . . . . . . . . 1178
Table 49-20: Type: Aviation HazardS (Canada) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179
Table 49-21: Type: Satellite (Caribbean) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179
Table 49-22: Type: Surface & Low-level Significant Weather (Caribbean) . . . . . . . 1180
Table 49-23: Type: High-level Significant Weather (Caribbean) . . . . . . . . . . . . . . . 1180
Table 49-24: Type: Winds And Temps Aloft (Caribbean) . . . . . . . . . . . . . . . . . . . . 1180
Table 49-25: Type: Aviation Hazards (Caribbean) . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Table 49-26: Type: Satellite (East Pacific) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Table 49-27: Type: Surface & Low-level Significant Weather (East Pacific) . . . . . . 1182
Table 49-28: Type: High-level Significant Weather (East Pacific) . . . . . . . . . . . . . . 1182
Table 49-29: Type: Winds And Temps Aloft (East Pacific) . . . . . . . . . . . . . . . . . . . 1182
Table 49-30: Type: Aviation Hazards (East Pacific) . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Table 49-31: Type: Satellite (Europe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183

xliv
Tables
Table 49-32: Type: Surface & Low-level Significant Weather (Europe) . . . . . . . . . 1183
Table 49-33: Type: High-level Significant Weather (Europe) . . . . . . . . . . . . . . . . . 1184
Table 49-34: Type: Winds And Temps Aloft (Europe) . . . . . . . . . . . . . . . . . . . . . . . 1184
Table 49-35: Type: Satellite (Europe/Asia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
Table 49-36: Type: Surface & Low-level Significant Weather (Europe/Asia) . . . . . 1185
Table 49-37: Type: High-level Significant Weather (Europe/asia) . . . . . . . . . . . . . . 1186
Table 49-38: Type: Winds And Temps Aloft (Europe/Asia) . . . . . . . . . . . . . . . . . . 1186
Table 49-39: Type: Aviation Hazards (Europe/asia) . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Table 49-40: Type: Satellite (Indian Ocean) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Table 49-41: Type: Surface & Low-level Significant Weather (Indian Ocean) . . . . 1187
Table 49-42: Type: High-level Significant Weather (Indian Ocean) . . . . . . . . . . . . 1188
Table 49-43: Type: Winds and Temps Aloft (Indian Ocean) . . . . . . . . . . . . . . . . . . 1188
Table 49-44: Type: Aviation Hazards (Indian Ocean) . . . . . . . . . . . . . . . . . . . . . . . 1189
Table 49-45: Type: Satellite (Mexico) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Table 49-46: Type: Surface & Low-level Significant Weather (Mexico) . . . . . . . . . 1189
Table 49-47: Type: High-level Significant Weather (Mexico) . . . . . . . . . . . . . . . . . 1189
Table 49-48: Type: Winds And Temps Aloft (Mexico) . . . . . . . . . . . . . . . . . . . . . . 1190
Table 49-49: Type: Aviation Hazards (Mexico) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
Table 49-50: Type: Satellite (Middle East) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1191
Table 49-51: Type: Surface & Low-level Significant Weather (Middle East) . . . . . 1191
Table 49-52: Type: High-level Significant Weather (Middle East) . . . . . . . . . . . . . 1191
Table 49-53: Type: Winds And Temps Aloft (Middle East) . . . . . . . . . . . . . . . . . . . 1191
Table 49-54: Type: Aviation Hazards (Middle East) . . . . . . . . . . . . . . . . . . . . . . . . 1192
Table 49-55: Type: Satellite (North Atlantic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
Table 49-56: Type: Surface & Low-level Significant Weather (North Atlantic) . . . 1193
Table 49-57: Type: High-level Significant Weather (North Atlantic) . . . . . . . . . . . 1193
Table 49-58: Type: Winds and Temps Aloft (North Atlantic) . . . . . . . . . . . . . . . . . 1194
Table 49-59: Type: Aviation Hazards (North Atlantic) . . . . . . . . . . . . . . . . . . . . . . . 1194
Table 49-60: Type: Satellite (North Pacific) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195
Table 49-61: Type: Surface & Low-level Significant Weather (North Pacific) . . . . 1195
Table 49-62: Type: High-level Significant Weather (North Pacific) . . . . . . . . . . . . 1195
Table 49-63: Type: Winds and Temps Aloft (North Pacific) . . . . . . . . . . . . . . . . . . 1196
Table 49-64: Type: Aviation Hazards (North Pacific) . . . . . . . . . . . . . . . . . . . . . . . 1196
Table 49-65: Type: Satellite (South America) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
Table 49-66: Type: Surface & Low-level Significant Weather (South America) . . . 1197
Table 49-67: Type: High-level Significant Weather (South America) . . . . . . . . . . . 1197
Table 49-68: Type: Winds And Temps Aloft (South America) . . . . . . . . . . . . . . . . 1197
Table 49-69: Type: Aviation Hazards (South America) . . . . . . . . . . . . . . . . . . . . . . 1198

xlv
Tables
Table 49-70: Type: Surface & Low-level Significant Weather (South Pacific) . . . . 1198
Table 49-71: Type: High-level Significant Weather (South Pacific) . . . . . . . . . . . . . 1199
Table 49-72: Type: Winds and Temps Aloft (South Pacific) . . . . . . . . . . . . . . . . . . 1199
Table 49-73: Type: Aviation Hazards (South Pacific) . . . . . . . . . . . . . . . . . . . . . . . . 1200
Table 49-74: Type: Satellite (U.S.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Table 49-75: Type: Radar (U.S.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Table 49-76: Type: Surface & Low-level Significant Weather (U.S.) . . . . . . . . . . . 1201
Table 49-77: Type: High-level Significant Weather (U.S.) . . . . . . . . . . . . . . . . . . . . 1201
Table 49-78: Type: Winds and Temps Aloft (U.S.) . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Table 49-79: Type: Aviation Hazards (U.S.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Table 49-80: Type: Satellite (Alaska) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Table 49-81: Type: Surface & Low-level Significant Weather (Alaska) . . . . . . . . . 1204
Table 49-82: Type: High-level Significant Weather (Alaska) . . . . . . . . . . . . . . . . . . 1204
Table 49-83: Type: Winds and Temps Aloft (Alaska) . . . . . . . . . . . . . . . . . . . . . . . . 1204
Table 49-84: Type: Satellite (Hawaii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205
Table 49-85: Type: Surface & Low-level Significant Weather (Hawaii) . . . . . . . . . 1205
Table 49-86: Type: Winds and Temps Aloft (Hawaii) . . . . . . . . . . . . . . . . . . . . . . . 1206
Table 49-87: Type: Aviation Hazards (Hawaii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206
Table 49-88: Type: Satellite (U.S. North Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Table 49-89: Type: Radar (U.S. North Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Table 49-90: Type: Surface & Low-level Significant Weather (U.S. North Central) 1207
Table 49-91: Type: Satellite (U.S. Northeast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
Table 49-92: Type: Radar (U.S. Northeast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
Table 49-93: Type: Surface & Low-level Significant Weather (U.S. Northeast) . . . 1208
Table 49-94: Type: Aviation Hazards (U.S. Northeast) . . . . . . . . . . . . . . . . . . . . . . . 1209
Table 49-95: Type: Satellite (U.S. Northwest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Table 49-96: Type: Radar (U.S. Northwest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Table 49-97: Type: Surface & Low-level Significant Weather (U.S. Northwest) . . . 1209
Table 49-98: Type: Satellite (U.S. South Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Table 49-99: Type: Radar (U.S. South Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Table 49-100:Type: Surface & Low-level Significant Weather (U.S. South Central) 1210
Table 49-101:Type: Aviation Hazards (U.S. South Central) . . . . . . . . . . . . . . . . . . . 1211
Table 49-102:Type: Satellite (U.S. Southeast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Table 49-103:Type: Radar (U.S. Southeast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Table 49-104:Type: Surface & Low-level Significant Weather (U.S. Southeast) . . . 1211
Table 49-105:Type: Aviation Hazards (U.S. Southeast) . . . . . . . . . . . . . . . . . . . . . . 1212
Table 49-106:Type: Satellite (U.S. Southwest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Table 49-107:Type: Radar (U.S. Southwest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212

xlvi
Tables
Table 49-108:Type: Surface & Low-level Significant Weather (U.S. Southwest) . . 1213
Table 49-109:Type: Aviation Hazards (U.S. Southwest) . . . . . . . . . . . . . . . . . . . . . . 1213

xlvii
Introduction
Introduction
About JetPlan®
About JetPlan®
Welcome to JetPlan, the complete flight planning and aviation data system provided by
Jeppesen®, a world leader in aviation information and services. JetPlan is the core engine
behind flight-planning user interfaces such as JetPlanner, Jeppesen Dispatch Control, and
JetPlan.com. JetPlan features include but are not limited to:
• Flight plan optimization

• Weather and NOTAM information
• Automated flight plan filing
• Customized customer databases
Once you enter JetPlan through any of its user interfaces, you can access an extensive range of
flight planning features and information. Simply submit your inputs to JetPlan, and it
calculates or retrieves the information you need. Whether you are requesting a local terminal
area forecast (TAF) or computing a flight plan that traverses half the globe, JetPlan is your
resource for increased efficiency and for aviation information.

3
Introduction
About the JetPlan User Manual
About the JetPlan User Manual

NOTE Check the JetPlan.com website for the most current online version of this
document. Printed versions of this manual might not contain the latest changes. If you
have questions about your JetPlan.com user account information, contact Jeppesen
customer support.
The JetPlan User Manual provides information on requesting, retrieving, and maintaining
JetPlan information. This manual describes the options that users can include in a flight plan
request and the resulting calculations and output.This information is useful to anyone using
any of the flight plan products that interface with JetPlan. These interfaces include the
traditional JetPlan interactive Question and Answer command-line interface and graphical
user interface (GUI) applications such as JetPlanner, JetPlan.com, and Jeppesen Dispatch
Control.
Document Overview and Conventions

In this manual, each flight-planning topic is discussed and then demonstrated with examples of
user input. Sometimes, a sample of the JetPlan output is provided, illustrating the relationship
between the input and the resulting output.
This manual contains examples of command-line prompts and commands. Historically, the
command-line interface was the main method of flight planning using JetPlan, and some users
still use this interface. For examples of flight planning with a Jeppesen flight-planning GUI
application, see the user documentation for that product.
NOTE Notes are offset as shown here. They provide important information to
consider when using JetPlan.

4
Introduction
Getting Started
Getting Started
The following sections describe what you need to get started using JetPlan.
User ID and Password

To use the JetPlan system, you must be assigned a user ID and password. Your customer user
ID is a unique, permanent identifier that allows Jeppesen to track your system usage for
accounting and billing purposes. Your password is a unique code that provides secure access
to JetPlan.
Upon request, Jeppesen can assign more than one password to a customer user ID for data
security purposes. For example, some organizations prefer to restrict database management to
specific personnel trained in that function. Jeppesen can provide more passwords, each
conferring unique privileges.
For information on getting or changing a user ID and password or passwords, contact your
Jeppesen account manager.
Default Flight Plan Output Format

An important element of any flight planning system is the flight plan output it produces. The
flight plan output needs to provide all of the basic and critical information for the flight in a
clear and simple-to-read layout.
In the JetPlan system, the JetPlan standard format is the default output format for all flight
plans. You can arrange to have another format set as your default output. For information,
contact your Jeppesen account manager.
The following is an example of the standard JetPlan flight plan format.

5
Introduction
Getting Started
PLAN 0791 KSJC TO KABQ GLF5 M85/F IFR 06/20/07

NONSTOP COMPUTED 2159Z FOR ETD 1700Z PROGS 2012ADF G5 LBS
FUEL TIME DIST ARRIVE TAKEOFF LAND AV PLD OPNLWT

POA KABQ 004696 01/48 0843 1848Z 057007 052311 001200 048000
ALT KELP 001408 00/31 0194 1919Z
HLD 000000 00/00
RES 001703 00/45
XTR 000000 00/00
TXI 000000
TOT 007807 03/04
KSJC SJC9 PXN..CZQ..OAL J58 ILC..BCE..GUP CURLY2 KABQ
WIND P027 MXSH 7/CZQ

FL 450/OAL 490
KSJC ELEV 00062FT

CPT FLT T WIND S TAS GRS MCS DST DSTR ETE ETR FU FR FF/E
FREQ
D303B .. .. .... . .. .. 302.4 003 0840 ./.. ./.. .. .. . .. .

MOONY .. .. .... . .. .. 120.9 028 0812 ./.. ./.. .. .. . .. .
PXN .. .. .... . .. .. 108.4 046 0766 ./.. ./.. .. .. . .. .
112.6
TOC 450 .. .... . .. .. 062.1 015 0751 0/14 1/34 014 0064 .. .
CZQ 450 66 26050 7 479 529 062.1 033 0718 0/04 1/30 002 0063 1281
112.9
OAL 450 66 27050 7 479 522 039.6 118 0600 0/14 1/16 006 0057 1271
117.7
ILC 490 65 26028 4 480 508 068.2 160 0440 0/19 0/57 008 0049 1252
116.3
BCE 490 65 28022 3 480 501 093.2 105 0335 0/12 0/45 005 0044 1193
112.8
GUP 490 68 30017 3 477 494 114.2 212 0123 0/26 0/19 010 0034 1165
115.1
TOD 490 70 29015 2 475 489 080.3 007 0116 0/01 0/18 000 0034 1142
CURLY .. .. .... . .. .. 080.3 080 0036 ./.. ./.. .. .. . .. .
ABQ .. .. .... . .. .. 137.5 026 0010 ./.. ./.. .. .. . .. .
113.2
KABQ .. .. .... . .. .. 079.1 010 0000 0/18 0/00 003 0031 .. .
ELEV 05355FT
FIRS KZLC/0035 KZDV/0106 KZAB/0125
FP GLF5/ 479 SJC 1700 450

SJC.SJC9.PXN..CZQ..OAL.J58.ILC..BCE..GUP.CURLY2.ABQ/0148
END OF JEPPESEN DATAPLAN

REQUEST NO. 0791

6
Introduction
Getting Started
Customer Support Files

The JetPlan system has two customer support files that are mentioned in this manual: the User
ID Attribute file and the Customer Preferences database. User-specific settings in these files
support custom-tailoring of the flight planning system and the flight plan product. Jeppesen
maintains these files. To request any changes, contact Jeppesen Customer Service or your
The following paragraphs briefly describe the User ID Attribute file and the Customer
Preferences database. The description is general but gives an idea of how these files support
customizations.
User ID Attribute File

The User ID Attribute file contains parameter settings, or attributes, which are activated when
you log on to the JetPlan system. The assigned attributes are specific to your user ID. Some of
the attributes are for Jeppesen accounting purposes. Others assign certain user characteristics
that apply to your flight planning operations. You can discuss your User ID Attribute file
settings with your Jeppesen account manager at any time.
The following list describes some of the attributes that can be set to support your use of
JetPlan:
Database Access Attribute settings define your level of access to your customer
databases (Customer Route Database, Customer Aircraft Database,
and so on).
Format Definitions Attribute settings define the layout and design of your flight plan
output, the measurement units used in the flight plan output (metric or
English), and specific calculation methods.
Feature Options Some attribute settings enable you to use features that require
Jeppesen consent —for example, Enroute Charges or Optimal
Scenario Analysis. Other settings support the automatic application of
certain features that would normally require a manual input in the
flight plan request, such as the Autoweight option. (Any settings that
are automatically applied can always be overridden with manual
inputs.)

7
Introduction
Getting Started
Customer Preferences Database

The Customer Preferences database supports settings for numerous flight plan calculation
options, display options, and feature options such as:
• Second alternate calculation method

• Autoweight fuel reduction method versus the standard method, where
payload is typically reduced
• Enroute Charges option (monetary exchange rate information sources)
• Various biasing and fuel burn methods
• Enroute alternate airport display
This list provides just a sample of what is available in the Customer Preferences database. For
more information, contact your Jeppesen account manager.

8
C HAPTER 1
JetPlan Command-Line
Interface
JetPlan Command-Line Interface
Overview
Overview
You can access the JetPlan flight planning functionality through the traditional Question and
Answer command-line interface and through the Jeppesen graphical user interface (GUI)
products that interface with JetPlan, such as JetPlanner, JetPlan.com, and Jeppesen Dispatch
Control. In addition, some JetPlan customers, such as large commercial airlines, have
developed in-house software applications that interface with JetPlan. Most customers now use
one of the GUI interfaces to use JetPlan, but some customers still use the command-line
interface.
This manual covers JetPlan flight-planning concepts relevant for users of any of the JetPlan
interfaces. Each product interfacing with JetPlan also has its own user documentation that
describes how to use that product to perform specific flight-planning tasks. The JetPlan User
Manual provides examples of using command-line prompts to perform flight-planning tasks.

11
Understanding the Command-Line Interface
Understanding the Command-Line

Interface
The JetPlan command-line interface presents a series of standard question and answer prompts
to which you provide specific responses that determine the resulting flight plan or
informational output. Some responses are mandatory, while others are optional. Some prompts
are not always displayed. For example, if JetPlan can use data stored in your Customer
Aircraft Database (CADB) record, the related question prompts do not appear. The following
sections provide an overview of the command-line prompts and how they are used.
Command-Line Prompts
The following table briefly describes each flight planning command-line prompt and provides
information about why some prompts might not appear in a given flight-planning session.
NOTE When using the system, press the ENTER key to confirm your input (or lack
of input) and move on to the next prompt.
Table 1-1 Command-Line Prompts
Command-Line Prompt Description

ENTER ID (Required) This entry is used to log on to JetPlan.
With certain access software, your customer ID is a
stored value and is automatically inserted for you.
ENTER PASSWORD (Required) This entry is used to log on to JetPlan.

With certain access software, your password is a
stored value and is automatically inserted for you.
01 OPTIONS (Required) For a flight plan, enter the flight plan

option codes at a minimum. For the various codes that
can be entered at this prompt, see Chapter 2, “Option
Commands.”
02 POD (Required) Enter the point of departure (POD) airport,

using an ICAO or IATA identifier. Divert airports,
field coordinates, taxi fuel values, and takeoff
alternates can also be entered if necessary. For more
information, see Chapter 3, “Point of Departure and
Point of Arrival Commands.”

12
Table 1-1 Command-Line Prompts (continued)

03 POA (Required) Enter the point of arrival (POA) airport
using an ICAO or IATA identifier. For more
information, see Chapter 3, “Point of Departure and
05 RESTRICTED AREA (Optional) The system presents this prompt only when
RST has been entered on the 01 OPTIONS command
line. Enter a temporary restricted area or a Customer
Restricted Area Database (CRAD) record name. For
more information, see Chapter 40, “Restricted Area
Database.”
06 ROUTE (Optional) Enter a route that follows the syntax rules

of the Route Selector you wish to employ, or use a
Customer Route Database (CRDB) record name. If no
route or record name is entered, JetPlan determines an
optimized route using the best combination of airways
and direct segments. For more information, see
Chapter 6, “Route Commands.”
07 HOLD,ALTERNATE/DIST (Optional) Enter a hold time and/or alternate airport
identifier in either ICAO or IATA format. You can
enter up to four destination alternates on this
command line. You can also override stored alternate
information by entering an alternate distance, a stored
route (CRDB record), or a great circle distance to use
for alternate calculations. For more information, see
Chapter 7, “Hold-Alternate Commands.”
08 ETD (Required) Enter the estimated time of departure
(ETD) using a four-digit coordinated universal time
(UTC) input. For more information, see Chapter 8,
“Estimated Time of Departure Commands.”
09 PROFILE (Required) Enter the altitude flight rule under which
you want to fly (I for IFR; V for VFR). You can also
enter specific flight-level constraints. For more
information, see Chapter 9, “Profile Commands.”
10 A/C TYPE/REGN (Required) Enter either a generic aircraft type or a
CADB record name. When you enter a CADB record
name, some of the other command-line prompts are
not displayed. Instead, the system looks for that
information in the CADB record. For more
information, see “Information Provided by the CADB
Record” on page 15 and Chapter 10, “Aircraft Type
Commands.”

13

11 CRZ MODE (Required) Enter one or more primary cruise modes
and, if needed, an auxiliary cruise mode. You can
specify a secondary climb schedule as well as ad hoc
biases for climb, cruise, descent, and alternate. The
system does not display this prompt when you enter a
CADB record containing a default cruise mode on the
10 A/C TYPE/REGN command line. For more
Record” on page 15 and Chapter 11, “Cruise Mode
Commands.”
12 PRFM INDEX (Required) Enter the performance basis on which the

flight plan is calculated (save fuel, time, or money).
The system does not display this prompt when you
enter a CADB record containing a default
performance index value on the 10 A/C TYPE/REGN
line. For more information, see “Information Provided
by the CADB Record” on page 15 and Chapter 9,
“Profile Commands.”
13 OPERATIONAL WT (Required) Enter the aircraft’s basic operational

weight. The system does not display this prompt when
you enter a CADB record containing the information
on the 10 A/C TYPE/REGN command line. For more
Record” on page 15 and Chapter 13, “Operational
Weight Commands.”
14 PAYLOAD (Optional) Enter a payload amount or let JetPlan

calculate the maximum payload automatically. For
more information, see Chapter 14, “Payload,
POD/POA, Weight, and Fuel Commands.”
15 FUEL OFF/ON (Optional) Enter a checkpoint and fuel off-load or on-
load amount. This option is for fuel off, fuel on, or
payload drop applications. For more information, see
Chapter 15, “Fuel Off/On and Payload Off
Commands.”
16 POD OR POA FUEL (Required) Enter an arrival or departure fuel if a

known payload value or zero fuel (ZF) entry has been
entered on the 14 PAYLOAD command line. For more
information, see Chapter 14, “Payload, POD/POA,
Weight, and Fuel Commands.”
16 POD OR POA WT (Required) Enter an arrival or departure weight if an

unknown payload value has been entered on the 14
PAYLOAD command line. For more information, see
Chapter 14, “Payload, POD/POA, Weight, and Fuel
Commands.”

14

17 RESERVE (Optional) Enter extra reserve fuel if a departure
weight or fuel value is specified on line 16 or 17. The
system does not display this prompt when a CADB
record containing the information has been entered on
the 10 A/C TYPE/REGN command line. For more
Record” on page 15 and Chapter 14, “Payload,
POD/POA, Weight, and Fuel Commands.”
17 MAX FUEL (Required) Enter the maximum fuel available if an

arrival weight or arrival fuel is specified on line 16 or
17. The system does not display this prompt when a
CADB record containing the information has been
entered on the 10 A/C TYPE/REGN command line.
For more information, see “Information Provided by
the CADB Record” on page 15 and Chapter 14,
“Payload, POD/POA, Weight, and Fuel Commands.”
18 CLIMB FUEL,TIME,DIST BIAS (Optional) Enter departure biases. The system does
not display this prompt when a CADB record
containing the information has been entered on the 10
A/C TYPE/REGN command line. For more
Record” on page 15 and Chapter 16, “Departure and
Arrival Bias Commands.”
19 DESCENT FUEL,TIME,DIST BIAS (Optional) Enter arrival biases. The system does not
display this prompt when a CADB record containing
the information has been entered on the 10 A/C
TYPE/REGN command line. For more information,
see “Information Provided by the CADB Record” on
page 15 and Chapter 16, “Departure and Arrival Bias
Commands.”
Information Provided by the CADB Record

On the 10 A/C TYPE/REGN command line, you can enter a generic aircraft type or a CADB
record name. When you enter a CADB record name, JetPlan does not prompt you for entries
on the following command lines because the information exists in the CADB record:
• 11 CRZ MODE
• 12 PRFM INDEX
• 13 OPERATIONAL WT
• 17 RESERVE or MAX FUEL

15
• 18 CLIMB FUEL,TIME,DIST BIAS

• 19 DESCENT FUEL,TIME,DIST BIAS
Optional Responses
The following flight-planning command-line prompts do not require responses. In this case,
your entries provide additional information, beyond the basic information necessary to
calculate a flight plan.
• 05 RESTRICTED AREA
• 07 HOLD,ALTERNATE/DIST
• 18 CLIMB FUEL,TIME,DIST
• 19 DESCENT FUEL,TIME,DIST

16
Understanding the Batch Interface

The following paragraphs are for the benefit of anyone who uses the JetPlan batch interface.
Similarities and differences between the command-line interface and the batch interface are
discussed. A user accesses the batch interface with a dumb terminal and an older message
transmission network (SITA or ARINC). This difference in access method dictates the
difference in input procedures.
Command-Line and Batch Method: Differences

To create a JetPlan request for information, command-line users are prompted for required
inputs through a question and answer session (the command-line interface). In contrast, batch
users have no such session to guide them. Users must provide the batch interface with both the
type of input (keyword) and the input value itself.
For example, once you are connected to the command-line interface, the system prompts you
for the inputs that determine your request. The inputs are simple codes or data values that
define your request parameters. If you request a flight plan, the system prompts you for
specific information such as the departure airport, the arrival airport, or the aircraft. Once you
have satisfactorily answered all of the necessary questions, the system computes your request
and returns the results.
The batch interface, however, requires you to not only enter an input value but also to label the
input with a keyword that identifies it. JetPlan does not understand a batch input value without
the keyword label. To enter the departure airport, the arrival airport, and other values in a
flight plan request, first specify the keyword that defines the input type, and then follow the
keyword with your input value. For example, a departure airport input starts with the keyword
POD and continues with an ICAO or IATA code that defines the specific airport. The batch
interface is more challenging than the command-line interface because a greater intrinsic
knowledge of JetPlan is required to satisfy the request input syntax.
Command-Line and Batch Method: Similarities

Despite their differences, the command-line and batch method interfaces are functionally
similar. They use the same command options (prompts and keywords) to create an input set
that meets the requirements for a request for information. The codes and values you enter after
the command options are identical in most cases.

17
The following table compares the command-line prompts and the batch method keywords.
Table 1-2 JetPlan Interface Comparison
Command-Line Prompts Batch Keywords Notes

ENTER ID //ID
ENTER PASSWORD //PWD
01 OPTIONS //OPT
02 POD //POD
03 POA //POA
05 RESTRICTED AREA //RST
06 ROUTE //RTD (//RTW & //RTA) or //RDB Route Optimizer: If the route
enters more than one JetPlan area
of coverage, the keywords //RTW
and //RTA can be used. You can
use keyword //RDB to enter a
CRDB file as your route input.
07 HOLD, ALTERNATE/DIST //HLD or //ALT If you have a hold time set in the
ID/Attributes file, you can use the
//ALT keyword instead of //HLD.
08 ETD //ETD
09 PROFILE //FLV
10 A/C TYPE/REGN //AC or //ADB Specify the //AC keyword with

GO when loading a previous
request and changing the //FLV
keyword inputs.
11 CRZ MODE //CRZ
12 PRFM INDEX //PRF These command options are not

used when a CADB file is
specified at the A/C TYPE/REGN
prompt or the //ADB keyword.
13 OPERATIONAL WT //OEW These command options are not

14 PAYLOAD //PLD
15 FUEL OFF/ON //RF
16 POD OR POA FUEL //DFL or //AFL
16 POD OR POA WT //DWT or //AWT

18
Table 1-2 JetPlan Interface Comparison (continued)
Command-Line Prompts Batch Keywords Notes

17 RESERVE or MAX FUEL //RES or //MVR These command options are not
18 CLIMB FUEL,TIME,DIST //DBS These command options are not

BIAS used when a CADB file is
19 DESCENT FUEL,TIME,DIST //ABS These command options are not

BIAS used when a CADB file is

19
C HAPTER 2
Option Commands
Option Commands
Overview
Overview
This chapter explains and defines the various command and option codes available for input
on the JetPlan Options command line. The Options command line refers to the 01 OPTIONS
prompt in line mode. On this line, you can enter commands and options for flight planning,
weather information, message and data transmission, reference material, and the customer
databases.
NOTE The total number of command and option inputs on the Options command
line must not exceed 240 characters.
Flight Plan Command

The Flight Plan (FP) command is a required input for original flight plan requests. Flight plan
options must follow the FP command on the Options command line (unless otherwise noted in
this manual). Flight plan options are described in “Flight Plan Command Options” on page 24.
NOTE You can retrieve and recompute previously computed flight plans with the
FPR, LD, or LDR commands, described in the following sections.
Table 2-1 Flight Plan Commands
Command Explanation
FP Flight Plan Request Command. The FP command is a mandatory
input for an original flight plan request.
SC,FLT Schedule Database Flight Plan Request Command. The SC

command is associated with access to and management of the
Customer Schedule Database. However, when combined with the
FLT option and a Schedule Database record, this command
instructs JetPlan to produce a flight plan using the inputs in the
database record.
For example:
SC,FLT,TRIP101
NOTE Do not use the flight plan options listed in “Flight Plan
Command Options” on page 24 with the SC,FLT command. All
options must be added to the Schedule Database record before you
invoke this command.
For more information, see Chapter 44, “Customer Schedule
Database.”

23
Option Commands
Flight Plan Command
Flight Plan Command Options

You can enter flight plan-related options (options that follow the FP command) in random
combinations on the Options command line, unless the options are conflicting or mutually
exclusive. For example, codes that derive similar information from different sources—such as
the route structure selection codes LA and MA—create a conflict in JetPlan logic when
entered together on the Options command line. The result of such conflicts is an output error
or, worse, a flight plan with incorrect output data.
In addition, command codes not listed in the following Flight Plan Options sections cannot be
used with the FP command. Examples of inputs not used with the FP command are: the
Weather Request Command (WX), Message Command (MG), reference codes, or any
database access code.
Flight plan options fall into various categories. The following sections contain examples of
these options. Some of the examples substitute placeholders for values a user would actually
enter when the input value is a user-specific variable, free text, or other variable.
Placeholders are used as follows:
• Options that require text input values (any combination of alphanumeric

characters) include one or more of the lower-case “x” characters as the
dummy value, for example, xxx(xxx). If the number of characters the value
represents is not clearly stated in the Explanation column, you can assume
that the placeholder value includes the proper number of place holders—for
example, “xxx” represents a text variable that is three characters in length.
• Options that require an integer, such as a month number, wind velocity, or
temperature deviation, include one or more pound symbols (#) as the
placeholder value. If the number of digits the value represents is not clearly
stated in the Explanation column, you can assume that the placeholder value
includes the proper number of place holders—for example, ### represents a
numeric component that is three digits in length.
• The numbers, 1234, 2345, and so on, are used in examples that include a
computer transaction number. JetPlan assigns a unique four or five-digit
number for each computer transaction (a flight plan or other information
request) and usually displays the number in the following places:
– At the top and bottom of each flight plan and text weather output
– At the top of each message (except for a no number message)

24
Option Commands
Flight Plan Command
Flight Plan Options–Output

The options in this section are related to flight plan output. They meet various needs by adding
specific information to the output or by changing the appearance or amount of information
presented
Table 2-2 Flight Plan Options–Output
Option Explanation
FP,xxx Output Format (Layout) Option. This option is generally a custom code
applied to identify and use a specific output layout. It determines what
information is presented in the calculated flight plan output, and its
appearance. Jeppesen provides various output formats and can customize
one or more to meet your needs.
NOTE A specific Output Format code can be preset in your ID/Attribute File
to be applied automatically to every flight plan. In this case, you would apply
this option only when you wish to use an Output Format other than your default
one. Contact your account manager for more information.
FP,AP Abbreviated Plan Output Option. The Abbreviated Plan code provides a
summary that includes the following data: enroute burn/time, distance,
takeoff weight, alternate burn, reserve/hold/extra fuel, takeoff fuel, route
summary line, wind component, maximum shear, and altitude profile. It does
not list: arrival times, landing weight, payload, operational weight, or aircraft
database file. This option provides detail that the Short Plan option does not.
FP,LP Long Plan Output Option. The Long Plan code provides the entire flight plan
output; nothing is omitted. This format is generally the default output format.
Typically, this option is used when the first plan is in the Short Plan format,
and the user wants to see the entire output of that plan.
FP,SP Short Plan Output Option. The SP code delivers the top portion of the flight
(Format Specific) plan output only. This output includes the fuel block totals and route
summary. The point-by-point body of the flight plan is omitted.
FP,RP Route Proof Output Option. The RP code provides route summary and total
mileage output only. All other flight plan output is omitted. This option is
useful for checking distance and route information before you request the
more data-intensive short or long flight plan format outputs.
After reviewing the Route Proof information, you can choose to enter FP at
the next 01 OPTIONS prompt and then GO at the next prompt to compute a
flight plan in a more complete form.
NOTE For information on the GO command and changing flight plan inputs,
see “Flight Plan Shortcuts” on page 54.
FP,TP Turboprop Output Option. The TP option instructs JetPlan to provide

waypoint output every five degrees rather than the standard ten. This option
specifically applies to turboprop aircraft, but can be applied to any flight plan
if that type of waypoint output is desired. The estimated time enroute (ETE)
between the checkpoints must exceed the preset minimum value.

25
Option Commands
Flight Plan Command
Table 2-2 Flight Plan Options–Output (continued)
Option Explanation
FP,.xxxxxxxxx. Plan Header Output Option. You can insert a header (or title) at the top of a
flight plan by including this input string. A header is up to 12 characters in
length and must be entered between two periods. Use a comma to separate
this entry from the FP code and any additional inputs.
For example:
FP,.MYFLIGHTPLAN.
FP,CS/xxxxx... Aircraft Call Sign Output Option. This option enables you to insert the call
sign of the aircraft into the flight plan filing program. Enter CS followed by a
slash and the call sign. A call sign entry includes up to 12 characters,
although most ARTCCs/ACCs accept only seven characters. The call sign is
included on the ICAO flight plan filing strip. Some customer formats include
the call sign in the flight plan body as well.
For example:
FP,CS/TANGO11
For more information, see Chapter 19, “ATC Filing.”
FP,FN/xxxxxx... Flight Number Output Option. This option allows the flight number to be
included in the flight plan output and filing program. This option is different
from the Aircraft Call Sign Output Option (FP,CS) with regards to output
placement and filing behavior.
For more information, see Chapter 19, “ATC Filing.”
FP,TLK/xxxxx... Talk (Free Form Text) Output Option. If your format is set up for this feature,
(Format Specific) the Talk option includes your plain text message in the flight plan output. If
more than one line of text is required, end the current line with a space and a
slash (/), and then continue on the next line. A maximum of 80 characters per
line is permitted, with an overall maximum of 200 characters.
For example:
FP,TLK/ENTER YOUR MESSAGE HERE...
FP,TRAK Track Summary Output Option. This option instructs JetPlan to provide a
latitude and longitude summary for every checkpoint on the route of flight at
the bottom of the flight plan.
NOTE The TRAK output is provided even without specifying the TRAK
option if either of the following is true:
A stored aircraft database record is used in question 10 A/C TYPE/REGN
- or -
A generic aircraft ID is used together with a registration number in question 10

A/C TYPE/REGN (entered in the form xxxx/nnnnnn, where xxxx is the generic
JetPlan aircraft ID, and nnnnnn is the registration number of the aircraft).

26
Option Commands
Flight Plan Command
Option Explanation
FP,KILO Measurement Output Option–Kilograms. If the weight unit default in your
ID/Attribute File is set to pounds, but you want to use kilograms on a given
flight plan, use the KILO option. FP,KILO instructs JetPlan to provide the
flight plan output of weight values in kilograms, regardless of the default
setting in your ID/Attribute File.
NOTE The KILO FP option does not override the value of the Weight Unit
(WU) parameter in the Customer Aircraft Database (CADB) record when WU
has been set to anything other than Default. When WU has been set to a non-
default value, it overrides both FP,KILO and the default setting in the
ID/Attribute file.
FP,KM Measurement Output Option–Kilometers. The KM option switches flight

plan output distance/time values from nautical miles to kilometers. This
option is used in combination with the KILO option.
NOTE You can request two separate user passwords for your user ID: one
that displays distance/time values in kilometers, and one that displays them in
nautical miles. Contact your Jeppesen account manager for information.
FP,LBS Measurement Output Option–Pounds. If the weight unit default in your

ID/Attribute File is set to kilograms, but you want to use pounds on a given
flight plan, you can use the LBS option. FP,LBS instructs JetPlan to provide
the flight plan output of weight values in pounds, regardless of the default
setting in your ID/Attribute File.
NOTE The LBS option does not override the value of the Weight Unit (WU)
parameter in the Customer Aircraft Database (CADB) record when WU has
been set to anything other than Default. When WU has been set to a non-
default value, it overrides both FP,KILO and the default setting in the
ID/Attribute file.
FP,NM Measurement Output Option–Nautical Miles. The NM option switches flight

plan output distance/time values from kilometers to nautical miles. This
option is used in combination with the LBS option.
NOTE You can request two separate user passwords for your user ID: one
that displays distance/time values in kilometers, and one that displays them in
nautical miles. Contact your Jeppesen account manager for information.
FP,WXE Enroute Weather Output Option. The WXE option provides enroute weather
information at the end of the calculated flight plan.
An enhanced version of this option is available upon request. Contact
Jeppesen Customer Service for more information.
FP,WXEL Enroute Weather Output List Option. The WXEL option is equivalent to the
WXE option but generates only a list of the enroute airports, not the
associated NOTAMs and weather.

27
Option Commands
Flight Plan Command
Option Explanation
FP,OPGF Winds and Temperatures Aloft Output Option. The OPGF option instructs
(Format Specific) JetPlan to attach forecast data for each enroute waypoint to the end of the
calculated flight plan. (This option only works with certain formats).
Another way to retrieve Winds and Temperatures aloft data is to reformat a
flight plan that has already been computed using the format code WX1. This
method enables any customer to access this type of forecast data. However,
reformatting only outputs the OPGF data, not the complete flight plan.
For example:
RFMT,1234,WX1
Where:
RFMT is the Reformat option.
1234 is the plan number of the flight plan.
WX1 is the format code that retrieves winds and temperature aloft data for the
flight plan number specified.
FP,CPT/xxxxx... Captain’s Name Output Option. This option lets you insert the name of the
(Format Specific) pilot in command into the flight plan filing program so that it appears in the
ICAO flight plan filing strip. Normally, the maximum number of letters
allowed is 20. However, you can request that the option be changed to allow
up to 40 characters.
As for the normal flight plan output, this option is format-specific, meaning
the format must be modified before the option can be applied in this manner.
Given format modifications, the captain’s name appears in the plan output.
You can request a change to allow two separate names. This option requires a
slash (/) between the names.
For example:
FP,CPT/SILVERFP,CPT/D SILVER/B JONES
FP,DSP/xxxxx... Dispatcher’s Name Output Option. The dispatcher’s name option is only for
(Format Specific) formats that have been modified to include this information. The option
enables you to insert the name of the flight’s dispatcher into the plan output.
The maximum number of characters is 40.
For example:
FP,DSP/C PARK
FP,FOF/xxxxx... First Officer’s Name Output Option. The first officer’s name option is only
(Format Specific) for formats that have been modified to include this information. The option
enables you to insert the name of the flight’s first officer into the flight plan.
The maximum number of characters is 40.
For example:
FP,FOF/G NGUYEN

28
Option Commands
Flight Plan Command
Option Explanation
FP,FEN/xxxxx... Flight Engineer’s Name Output Option. The flight engineer’s name option is
(Format Specific) only for formats that have been modified to include this information. The
option enables you to insert the name of the flight engineer into the flight
plan. The maximum number of characters is 40.
For example:
FP,FEN/M ROBERTS
Flight Plan Options–Weather Sources

The following flight plan options enable you to change the source database for wind and
temperature information used in the flight plan calculation.
For more information on these options, see Chapter 8, “Estimated Time of Departure
Commands.”
NOTE These options have nothing to do with text and graphic (map) weather
products available through the Weather Services portion of JetPlan.
Table 2-3 Flight Plan Options–Weather Sources
Option Explanation
FP,WXADF ADF Weather Option. The WXADF option instructs JetPlan to use the
National Weather Service Database in the flight plan computation rather than
your default weather database. The National Weather Service Database is
used in Aviation Digital Format, 2.5° calibration between 20° and 70° north
and 20° and 70° south latitudes. This database contains current winds and
temperature data, collected and compiled by the U.S. National Weather
Service within the previous 24 hours.
FP,WXNWS NWS Weather Option. The WXNWS option instructs JetPlan to use the
National Weather Service Database (1.25° calibration) in the flight plan
computation rather than your default weather database. This database
contains current winds and temperature data, collected and compiled by the
U.S. National Weather Service within the previous 24 hours.
FP,WXUK UK Met Office (UKMO) Weather Option. This option instructs JetPlan to
use the UKMO Database (1.25° calibration) in the flight plan computation
rather than your default weather database. This database contains current
wind and temperature data, collected and compiled by the United Kingdom
Met Office within the previous 24 hours.

29
Option Commands
Flight Plan Command
Table 2-3 Flight Plan Options–Weather Sources (continued)
Option Explanation
FP,W()###,()## User-Specified Weather Option. Typically, JetPlan calculates flight plans
using current weather forecasts from data collected and compiled within the
previous 24 hours. This option is a planning tool, enabling you to review fuel
computations based on various fixed weather scenarios. You enter your own
wind component value (1–3 digits) and ISA deviation value (1–2 digits) into
the flight plan request. JetPlan uses the values to calculate the flight plan
results.
Use the letter P to represent a positive value (a tailwind component or a
greater-than-ISA condition). Use the letter M to represent a negative value (a
headwind component or a less-than-ISA condition).
The following example requests a headwind component of 50 knots and an
ISA deviation component of +10 degrees:
For example:
FP,WM50,P10
FP,WH## UK Met Office Historical Weather Option. Typically, JetPlan calculates

flight plans using current weather forecasts from data collected and compiled
within the previous 24 hours. This option instructs JetPlan to use the UK Met
Office Historical Weather Database in the flight plan computation rather than
your default (current winds and temperatures) weather database. The UK
Met Office Historical Weather Database uses a 30-year history of average
monthly wind values.
Enter WH followed by a two-digit value defining the month of the year. The
following example shows how to access the historical data for the month of
November:
For example:
FP,WH11
FP,WS##(##),R## Reliability Equivalent Winds Option. This option provides the capability of
applying a confidence level (a reliability factor) on weather data from a
historical database. Using a 41-year compilation of information, you can
specify a time of year and apply a confidence level to gain a greater feel for
the accuracy of the predicted winds and temperature data when planning
future flights. The time of year can be specified as a single month or a season
(range of months). The reliability factor is expressed in percentage terms
from 50–98 percent.
CAUTION Jeppesen recommends using a confidence level of no more than
50%. Higher confidence levels can underestimate wind speeds.
In the example below, the reliability equivalence expressed by the inputs
shown is based on a range of months, from December (12) to March (03),
with a confidence level of 50 percent.
For example:
FP,WS1203,R50

30
Option Commands
Flight Plan Command
Flight Plan Options–Routing Variables

The following options provide control over the route calculation process by either allowing or
limiting use of certain types of route structure.
Table 2-4 Flight Plan Options–Routing Variables
Option Explanation
FP,GC Great Circle Option. The Great Circle option forces the Route Optimizer
(RO) to determine great circle routing, even when waypoints are submitted
on the Route command line. Avoid route options that contradict this option
(jet airways [J]). For more information on this option, see Chapter 6, “Route
Commands.”
FP,AX Time-Restricted Routes – Access Option. The AX option instructs JetPlan to

consider all time-restricted routes, regardless of the time frame. As a rule,
JetPlan automatically performs a time-check on all routes accessed via the
Route Optimizer or through a Customer Route Database (CRDB) record.
This option removes the time-check functionality. The following list
describes how the AX option affects the various types of JetPlan routes:
• Route Optimizer routes: JetPlan considers all time-restricted airway
segments among all route possibilities when your route inputs dictate.
• SRS routes: JetPlan ignores this option when using SRS routes.
• Combination routes: JetPlan considers all time-restricted airway
segments among all route possibilities when your Route Optimizer
inputs dictate. This option does not affect SRS inputs.
• CRDB routes: JetPlan considers all CRDB files that meet the
POD/POA limitation and that contain time-restricted airway segments.
FP,NX Time-Restricted Routes – No Access Option. The NX option instructs

JetPlan not to consider any time-restricted routes. As a rule, JetPlan
automatically performs a time-check on all routes accessed via the Route
Optimizer or through a Customer Route Database (CRDB) record. This
option removes all time-restricted airways from consideration, regardless of
the time you are looking at flying them. The following list describes how this
option affects JetPlan routes:
• Route Optimizer routes: JetPlan does not consider any time-restricted
airway segments.
• SRS routes: JetPlan ignores this option when using SRS routes.
• Combination routes: JetPlan does not consider any time-restricted
airway segments for the Route Optimizer inputs. This option does not
affect SRS inputs.
• CRDB routes: JetPlan does not consider any CRDB files that have time-
restricted airway segments.

31
Option Commands
Flight Plan Command
Table 2-4 Flight Plan Options–Routing Variables (continued)
Option Explanation
FP,CRAM Conditional Route Availability Message (CRAM) Processing Option. If the
CRAM preference is available and is inactive in the customer preference
database, this option turns on AUP/UUP (formerly CRAM) processing and
gives access to CDR1/CDR2 AUP/UUP routes as published by
EUROCONTROL.
NOTE CRAM is not compatible with the MA or LA options.The AX and NX
options override the CRAM option or preference.
FP,NOCRAM No Conditional Route Availability Message (CRAM) Processing Option. If

the CRAM preference is available and is active in the customer preference
database, this option turns off AUP/UUP (formerly CRAM) processing.
NOTE When you are using the ERAD 2.0 FP option, the NOCRAM flight plan
option does not turn off processing of AUP/UUP (CRAM) files.
FP,DAROPT NOTE DAROPT must be used with the Dynamic Alternate Route (DAR)
command on the Hold-Alternate Command Line. See “Using the DAROPT
Flight Plan Option with DAR” on page 281.
Dynamic Alternate Route Optimized Option. When used with the DAR
command, the DAROPT flight plan option instructs JetPlan to calculate an
optimized route to the destination alternate. When calculating the route, the
optimizer considers SIDs and STARs, waypoints, NAVAIDS, direct segment
routing, and airways.
NOTE Local JetPlan environments must be configured to support DAR and
DAROPT functionality. For more information, contact your Jeppesen account
manager.
NOTE The Dynamic Alternate Route (DAR) option automatically invokes the
Dynamic Alternate Route Optimized (DAROPT) functionality in client GUI
applications such as JetPlanner.
FP,ERAD Electronic Route Availability Document Option. ERAD is a central

repository of European airspace traffic flow restrictions.
Second-generation ERAD (ERAD 2.0) achieves a high rate of acceptance of
optimized routes by IFPS by providing multi-dimensional optimized route
selection that is fully compliant with routing constraints published by
EUROCONTROL and member states. For information on ERAD, see
FP,ERAD,DOTB ERAD Include DAL/TOC/BOC Option. When used with the ERAD flight
plan option, the DOTB option instructs JetPlan to append the
DAL/TOC/BOC portion of the ERAD special remarks to the JetPlan filing
strip, regardless of the POD and POA.
FP,ERAD,S2PTHT ERAD Dynamic SID/STAR Calculation Option. When used with the ERAD
flight plan option, the S2PTHT option instructs JetPlan to compute SID and
STAR routings dynamically instead of using the pre-calculated SID and
STAR routings stored in the JetPlan Navigation Database.

32
Option Commands
Flight Plan Command
Option Explanation
FP,ERAD,S2R2R ERAD Runway to Runway Option. When used with the ERAD flight plan
option, the S2R2R option instructs JetPlan to select the best runway
automatically, based on the most recent TAF and runway preference
information for airports stored in the Jeppesen Navigation Database
FP,ERAD,S2RTO ERAD Lateral Route Only Option. When used with the ERAD flight plan
option, the S2RTO option instructs JetPlan to process only the lateral route
returned by the ERAD route selector. JetPlan Engine excludes the ERAD
vertical profile calculations and instead uses the JetPlan Engine vertical
profile calculations.
FP,ERAD,S2VF No Internal EUROCONTROL Validation Option. When used with the

ERAD flight plan option, the S2VF option instructs JetPlan to request the
ERAD route selector to return a trajectory (route plus profile) without first
performing EUROCONTROL validation.
FP,LA Low Altitude Navigational Database Option. The Low Altitude option
instructs JetPlan to access the low-altitude navigational database when
computing the flight plan. The low altitude database is available worldwide.
NOTE You can use the input LA by itself in place of FP,LA. The FP option is
implied.
FP,MA Mid Altitude Navigational Database Option. The Mid Altitude option
instructs JetPlan to access the mid altitude navigational database (FL 195 to
FL 245) when computing the flight plan. The mid altitude database is only
applicable in portions of Area 2 (France, Switzerland, Belgium, Netherlands,
and Finland). Using this option, JetPlan accesses the low altitude database in
Area 2 when operating outside of the aforementioned countries.
NOTE You can use the input MA by itself in place of FP,MA. The FP option is
implied.
FP,RN RNAV Routes Option. This option instructs JetPlan to consider RNAV
segments when calculating the flight plan’s route.
The RN option overrides the Customer Aircraft Database (CADB) setting for
RNAV and ignores any MEL degradations that have been applied to RNAV.
NOTE RNAV routes are not available with the low and mid-altitude (LA, MA)
navigational databases.
FP,NOERA No Automatic Enroute Alternate (ERA) Option. If the Automatic ERA

customer preference is set to Yes, the NOERA option enables you to disable
the automatic ERA search on a per-flight plan basis.
NOTE When set to Yes, the Automatic ERA customer preference instructs
JetPlan to perform an automatic search for an enroute alternate, assuming
that no enroute alternate has been manually entered in the flight plan request
using the ERA command on line 16. For information on the ERA command,
see Chapter 14, “Payload, POD/POA, Weight, and Fuel Commands.”
NOTE Use of the Automatic ERA preference depends on other preference,
database settings, and format settings. For more information, contact your

33
Option Commands
Flight Plan Command
Option Explanation
FP,NORN No RNAV Routes Option. This option directs the Route Optimizer to avoid
all RNAV segments. The NORN option overrides the Customer Aircraft
Database (CADB) setting for RNAV and ignores any MEL degradations that
have been applied to RNAV.
FP,NOSTAR No STAR Option. This option overrides any user preferences for preferred
departure/arrival procedures. When this option is used, Standard Terminal
Arrival Route altitude constraints are ignored.
FP,NRP National Route Program Option. The NRP option enables you to flight plan
in the conterminous U.S. using free flight rules (per AC 90-91).
For more information, see Chapter 6, “Route Commands.”
FP,NRR Non-Restrictive Routing Option. The NRR option enables you to flight plan
above FL350 in the conterminous U.S. using free flight rules (per AC 90-
99).
FP,PITCAH NRR Pitch and Catch Option. The PITCAH option enables you to include
pitch and catch points in the route (per AC 90-99). This option must be used
with the NRR flight plan option.
FP,RST Restricted Area Option. The RST option enables you to define an area along
the intended or generally expected route of flight as restricted airspace that
the plan’s computed route avoids. The area can be defined using a delineated
boundary or a common route structure element. A delineated boundary
definition can even be stored as a Customer Restricted Area Database record.
For more information, see Chapter 4, “Restricted Area Commands.”
FP,NRTC No Route Constraint Option. The NRTC option prevents the application of a
route constraint record from the Route Constraint Database, regardless of the
characteristics of the selected customer aircraft.
Prerequisite: The Override Flag parameter (OVR) in the Route Constraint
Database must be set to Yes (OVR=Y). If OVR is set to N, no explicit
override is possible with the NRTC option.
FP,TR TACAN Routes Option. This option instructs JetPlan to consider European
TACAN routes as viable choices in the route selection process of a flight
plan in that sphere of operation.

34
Option Commands
Flight Plan Command
Option Explanation
FP,OWATAN Overwater Alert Option. This option instructs JetPlan to generate an alert
when the aircraft specified in the flight plan request does not have the
necessary level of overwater certification to fly the specified route. The
Overwater Capability (OA) parameter in the Customer Aircraft database
(CADB) defines the overwater certification, which can be Full, Limited, or
None. See Chapter 27, “Customer Aircraft Database.”
In addition, when the OWATAN or the OWATAA option (see below) is used,
JetPlan checks the Overwater (OWI) parameter in the City Pair database
(CPDB) to determine whether an aircraft flying this flight leg route must
have limited or full overwater capability. If OWI is set to No, JetPlan ignores
the OWATAN or OWATAA option for any flight plan computed for that city
pair. For more information on the OWI parameter, see Chapter 33, “City Pair
Database.”
FP,OWATAA Overwater Avoid Option. This option instructs JetPlan to compute an

optimized route so that the aircraft specified in the flight plan request does
not (based on its overwater certification) violate overwater restrictions at any
point along the route. The Overwater Capability (OA) parameter in the
Customer Aircraft database (CADB) defines the overwater certification,
which can be Full, Limited, or None. See Chapter 27, “Customer Aircraft
Database.”
During route optimization, if the system cannot find a valid route around full
or limited overwater airspaces, it generates an error indicating that a valid
route cannot be found. If the user specifies a route (using SRS) through an
overwater airspace, and the aircraft does not have the necessary level of
overwater capability, JetPlan generates an alert.
When the OWATAN (see above) or the OWATAA option is used, JetPlan
checks the Overwater (OWI) parameter in the City Pair database (CPDB) to
determine whether an aircraft flying this flight-leg route must have limited or
full overwater capability. It OWI is set the No, JetPlan ignores the OWATAN
or OWATAA option for any flight plan computed for that city pair. For more
information on the OWI parameter, see Chapter 33, “City Pair Database.”
FP,PSD Point of Safe Diversion and Point of Safe Return (PSD) Option. This option
directs JetPlan to calculate PSDs along a flight plan route. A PSD is the point
where the fuel required to fly to a divert airport is the same as the fuel
onboard while maintaining necessary reserve fuel. You can use this option to
specify airports for consideration as PSD divert airports. JetPlan always
considers the POD as the first divert airport. When JetPlan identifies a PSD
for the POD, that PSD is also the Point of Safe Return (PSR), the point at
which it is possible to return to the POD with required reserve fuel intact. For
more information on the PSD option, see Chapter 23, “Point of Safe
Diversion and Point of Safe Return.”

35
Option Commands
Flight Plan Command
Flight Plan Options–Performance Variables

The following options directly affect the performance calculation process of the flight plan.
Table 2-5 Flight Plan Options–Performance Variables
Option Explanation
FP,AW Autoweight Option. The AW option instructs JetPlan to run an iterative
process whereby any plan calculation that exceeds a weight limit or fuel
capacity limit is automatically recalculated using a reduced weight value.
This option eliminates most of the “Too Heavy” errors that occur when limits
are unknowingly tested. The Autoweight option can be preset in your
ID/Attribute File to be invoked on every flight plan calculation. Contact your
Account Manager for information.
For more information, see Chapter 14, “Payload, POD/POA, Weight, and
Fuel Commands.”
FP,NOAW No Autoweight Option. This option turns off the Autoweight feature when it
is the default setting in your ID/Attribute File (see the AW option above).

36
Option Commands
Flight Plan Command
Flight Plan Options–Feature Options

The following options provide special and unique capabilities to any flight operation. The
information provided here is for quick reference only. Review the individual chapters or
sections about these options for more complete information.
Table 2-6 Flight Plan Options–Feature Options
Option Explanation
FP,EUETS EU ETS Option. This option supports ad hoc requests for CO2 calculations
that are then included in the flight plan output.
When the EU ETS emission computation is performed, JetPlan reports the
EU ETS distance as equal to the Great Circle Distance (GCD) in kilometers
from the POD to the POA plus 95 kilometers. The latitude/longitude
coordinates of the POD and POA and the GCD between them are computed
in compliance with the WGS-84 standard.
EU ETS emissions results are returned in metric units (metric tons and
kilometers), regardless of the units used for the rest of the flight plan. The
EU ETS outputs are available for archiving by utilizing the archiving options
with an XML (X09) format.
Prerequisite: The Fuel Type parameter must be set for the aircraft record in
the CADB before you can use the EU ETS option. Otherwise, JetPlan returns
an error.
You can also implement the EU ETS option by setting the EU-ETS
Emissions Flag in the Flight Brief Database. For more information, see
Chapter 36, “Flight Brief Database.”
NOTE Contact your Jeppesen account manager for information about
compatible flight plan formats or to arrange to have your format modified.
FP,RC or FP,RCC Reclear Option. The RC option invokes the Reclear feature. This option lets
you enter the inputs necessary to perform a reserve fuel recalculation, which
can legally reduce the international reserve fuel carried.
The purpose of Reclear is to increase payload or extend mileage. It generally
includes output for the original flight plan with full international reserves, a
recleared plan to the original destination with reduced reserves, and a
recleared plan to a user-specified reclear airport with full international
reserves.
The RCC option is format-specific, meaning the output created by this
option depends on your format. It provides flight plan information for each
of the reclear plans mentioned above, but in a compressed layout.
Compression Print Command. Another way to compress previously
computed reclear flight plans into one informative output format is to use the
Reclear Compression Print Command. Depending on your output format,
you can compress two or three reclear flight plans by specifying the plan
numbers after the CM command.
For example:
CM1234,1235,1236
For more information, see Chapter 20, “Reclear Commands.”

37
Option Commands
Flight Plan Command
Table 2-6 Flight Plan Options–Feature Options (continued)
Option Explanation
FP,RC,DPP Decision Point Procedure Option. An extension of the Reclear option, the
DPP option also enables you to reduce international reserve fuel legally. This
option is an AIR OPS compliant operation.
FP,ETOP or ETOPS Option. This option invokes the JetPlan ETOPS feature for extended
FP,ETOPX (Format twin engine operations. Both options, ETOP and ETOPX, provide critical
Specific) fuel data based on Equal Time Point (ETP) information you provide.
ETOPX, which is format-specific, also provides extended information
through a detailed fuel analysis of the computed flight.
For more information, see Chapter 21, “ETOPS.”
FP,DRFT or Driftdown and Driftdown Extended options. These options both invoke the
FP,DRFTX JetPlan Overwater Driftdown feature, which provides for the following
driftdown scenarios: depressurization, one engine-out, and two engines-out.
Both Driftdown (DRFT) and Driftdown Extended (DRFTX) provide critical
fuel data based on Equal Time Point (ETP) information you provide.
DRFTX also provides extended information through a detailed fuel analysis
of the computed flight.
For more information, see Chapter 22, “Overwater Driftdown and Terrain
Analysis.”
FP,TANK1 or Single-Leg Tankering Option (Fuel Index). This option instructs JetPlan to
FP,TANK1X determine whether tankering fuel is warranted or not. The TANK1/1X option
uses a fuel index method for making the determination. The fuel index
method is desirable if fuel price information is sensitive. The TANK1X
option provides extended information in the flight plan output.
Fuel Commands.” This chapter also contains information on Multi-sector
Tankering, where fuel requirements for the initial leg of a two-legged flight
are determined in the second leg and carried over to the flight plan request
for the first leg.
FP,TANK2 or Single-Leg Tankering Option (Fuel Cost). Like the previous option, the
FP,TANK2X TANK2/2X option also instructs JetPlan to determine whether tankering fuel
is warranted or not. However, the TANK2/2X option uses actual fuel prices
to make the determination. The TANK2X option provides extended
information in the flight plan output.
Fuel Commands.” This chapter also contains information on Multi-sector
Tankering, where fuel requirements for the initial leg of a two-legged flight
are determined in the second leg and carried over to the flight plan request
for the first leg.

38
Option Commands
Flight Plan Command
Option Explanation
FP,TANK3 or Single-Leg Tankering Option (Varying Percentages). This option displays
FP,TANK3X results for tankering different amounts of fuel (20%, 40%, 60%, 80%, and
100%). This option can be useful if you are deciding whether to tanker the
maximum amount of fuel or a lesser quantity.
Fuel Commands.”
FP,4DF or 4DC Optimal Scenario Analysis (OSA) Option. This option enables you to enter
multiple scenarios for a given flight plan request. Each scenario is comprised
of a unique combination of flight plan inputs. A given scenario is made
distinct from any of the other scenarios by the unique contents of at least one
of these inputs. Each scenario is subjected to a complete flight plan
computation, and the scenario that produces the overall optimum result
based on user-specified optimization criteria (fuel, time, or cost) is
determined. The flight plan computed for that scenario then serves as the
basis for the detailed formatted flight plan output presented to the user. At
the end of the detailed output, certain parameters taken from the flight plans
computed for the other scenarios are presented in summary form, ranked
based on optimization. When you enter 4DF or 4DC along with the RT/ALL
input, a scenario is defined for each customer route currently active for the
specified POD and POA airports.
For more information, see Chapter 24, “Optimal Scenario Analysis.”
FP,CCAA 4D Avoid and Alert Option. This option instructs JetPlan to avoid avoid-
level Special Use Airspaces (SUAs), user-defined airspaces, Jeppesen
turbulence airspaces, or FIR/UIR airspaces when determining an optimum
route and profile. JetPlan allows the optimum route and profile to traverse
notify-level SUAs, user-defined airspaces, Jeppesen turbulence airspaces, or
FIR/UIR airspaces, but alerts must be posted for each such traversal.
NOTE CCAA does not apply to Organized Track airspaces.
For more information, see Chapter 5, “4D Avoid and Alert Restrictive
Airspaces.”
FP,CCAAN 4D Alert Option. This option instructs JetPlan to allow transversal of avoid
and notify-level Special Use Airspaces (SUAs), user-defined airspaces,
Jeppesen turbulence airspaces, or FIR/UIR airspaces when determining an
optimum route and profile. Alerts must be posted for each such traversal.
Alerts for traversal of avoid-level SUAs, user-defined airspaces, Jeppesen
turbulence airspaces, or FIR/UIR airspaces must be distinguishable from
alerts for traversal of notify-level SUAs, user-defined airspaces, Jeppesen
turbulence airspaces, or FIR/UIR airspaces.
NOTE CCAAN does not apply to Organized Track airspaces.
Airspaces.”

39
Option Commands
Flight Plan Command
Option Explanation
FP,CCAAF CCAA – Fine Grid Option. This option invokes 4D Avoid and Alert
functionality (CCAA), using a finer latitude/longitude grid for avoidance of
avoid-level airspaces when D routing has been specified on the flight plan.
Airspaces.”
FP,ORTRKA 4D Avoid Functionality for Organized Track Airspaces Option. When

ORTRKA is specified, JetPlan ensures that all avoid-level Organized Track
Airspaces are avoided when determining an optimum route and profile.
JetPlan allows the optimum route and profile to traverse notify-level
Organized Track Airspaces, but alerts must be posted for each such traversal.
Airspaces.”
FP,ORTRKN 4D Alert Functionality for Organized Track Airspaces Option. When

ORTRKN is specified, JetPlan allows both avoid and notify-level organized
track airspaces to be traversed when determining an optimum route and
profile. Alerts must be posted for each such traversal.
Airspaces.”
FP,GCAA The GCAA option invokes 4D Avoid functionality for geopolitical country
airspaces. The GCAA option avoids a country with the avoidance level of
avoid in the CCAA DB when determining an optimal route and profile. The
GCAA option can be used with or without the CCAA or CCAAN option.
Airspaces.”
FP,GCAN The GCAN option invokes 4D Alert functionality for geopolitical country
airspaces. This option allows countries with an avoidance level of avoid or
notify when determining an optimal route and profile, but generates an alert
for each such traversal. The GCAN option can be used with or without the
CCAA or CCAAN option.
Airspaces.”
FP,CCAA,AVDERR CCAA – Avoid Error Messaging Functionality Option. When the AVDERR
flight plan option is invoked together with the CCAA option, JetPlan alerts
the user when JetPlan cannot find a valid route due to incursions of avoid-
level SUAs, user-defined airspaces, Jeppesen turbulence airspaces, or
FIR/UIR airspaces. The system also lists the specific route segment and
airspace name for each incursion.
NOTE AVDERR is also available as a customer preference. When the
preference is enabled, AVDERR functionality applies to all CCAA flight plans
automatically.
Airspaces.”

40
Option Commands
Flight Plan Command
Option Explanation
FP,CCAA,CCAAQ CCAA Qualify Option. When the CCAAQ flight plan option is invoked
together with the CCAA option, the system computes the route from the
POA to the POD, looking for any avoid-level SUA, user-defined, Jeppesen
turbulence airspaces, or FIR/UIR airspaces. If such an incursion occurs, the
system automatically reruns the flight plan as a CCAA plan.
NOTE CCAAQ is also available as a customer preference. When the
preference is set, CCAAQ functionality applies to all CCAA flight plans
automatically.
Airspaces.”
FP,CCAA,EXSS CCAA/CCAAN – Except SIDS and STARS Option. When the EXSS option
FP,CCAAN,EXSS is invoked together with the CCAA or CCAAN option, standard CCAA and
CCAAN functionality applies except that alerts for traversal of SUAs are
suppressed for any segment that is part of a SID or STAR.
Airspaces.”
FP,CCAA,EXCD CCAA/CCAAN – Except Climb and Descent Option. When the EXCD
FP,CCAAN,EXCD option is invoked together with the CCAA or CCAAN option, segments
starting before Top of Climb (TOC) or ending after Top of Descent (TOD) or
that are part of a SID or STAR are not checked for incursions of Generic
Restrictive Airspaces.
Airspaces.”
FP,PBNDC=Y/N • PBNDC=Y – Compute Geopolitical Country Boundary Crossings

Option. The PBNDC=Y flight plan option directs the system to
generate a country border crossing report and output it on supporting
flight plan formats.
• PBNDC=N – Suppress Geopolitical Country Boundary Crossings
Option. The PBNDC=N flight plan option directs the system to
suppress a country border crossing report. If the Flight Brief Database
contains a matching record in which the Display Political Boundary
Report (PBNDC) parameter is set to Yes, you can suppress the
boundary crossing report on an individual flight plan by including the
PBNDC=N option in the request. For more information, see Chapter 36,
“Flight Brief Database.”
NOTE The political boundary report includes only boundary crossings for
countries for which records exist in the CCAA database with the avoid level set
to either Avoid or Alert. See the CCAA Database Help topic on JetPlan.com.
NOTE The boundary crossing report requires a specific format. You might
need to request a format change if you wish to use this report. Contact your
Jeppesen account manager for information.
NOTE The PBNDC=Y/N flight plan option overrides the value of the PBNDC
parameter in the Flight Brief Database.

41
Option Commands
Flight Plan Command
Option Explanation
FP,FBNDC=Y/N • FBNDC=Y – Compute FIR/UIR Boundary Crossings Option. The
FBNDC=Y flight plan option directs the system to generate a FIR/UIR
border crossing report and output it on supporting flight plan formats.
• FBNDC=N – Suppress FIR/UIR Boundary Crossings Option. The
FBNDC=N flight plan option directs the system to suppress a FIR/UIR
border crossing report. If the Flight Brief Database contains a matching
record in which the Display FIR/UIR Boundary Report (FBNDC)
parameter is set to Yes, you can suppress the boundary crossing report
on an individual flight plan by including the FBNDC=N option in the
request. For more information, see Chapter 36, “Flight Brief Database.”
NOTE The FIR/UIR boundary report includes only boundary crossings for
FIR/UIRs for which records exist in the CCAA database with the avoid level set
to either Avoid or Alert. See the CCAA Database Help topic on JetPlan.com.
NOTE The boundary crossing report requires a specific format. You might
need to request a format change if you wish to use this report. Contact your
Jeppesen account manager for information.
NOTE The FBNDC=Y/N flight plan option overrides the value of the FBNDC
parameter in the Flight Brief Database.

42
Option Commands
Flight Plan Command
Flight Plan Options–Flight Management Systems

This section provides both options and commands. Each option instructs JetPlan to store
internally the computed flight plan data in a format that is compatible with the selected Flight
Management System (FMS). The command associated with each option enables you to print
(to screen) the newly formatted FMS data.
NOTE If you use JetPlanner to run flight plans, the output generated by any of the
listed FMS reformat commands is automatically downloaded to a file on your
computer. The file can then be uploaded to the FMS on the aircraft if it has data-
loading capabilities.
Table 2-7 Flight Plan Options/Commands–FMS
Option/Command Explanation
FP,SFS Sperry FMS Option. The SFS option instructs JetPlan to store internally the
computed flight plan data in a format that is compatible with the Sperry
FMS. Externally, no change is visible in the output of your flight plan.
However, the data is prepared for the next command (see below).
FM1234 Sperry FMS Reformat Command. This command prints the data stored from
a flight plan that used the SFS option. The data is formatted for the Sperry
FMS. Enter FM and the appropriate computer transaction number from your
SFS plan.
FP,UNI Universal FMS Option. The UNI option instructs JetPlan to store internally
the computed flight plan data in a format that is compatible with the
Universal FMS. Externally, no change is visible in the output of your flight
plan. However, the data is prepared for the next command (see below).
UN1234 Universal FMS Reformat Command. This command prints the data stored
from a flight plan that used the UNI option. The data is formatted for the
Universal FMS. Enter UN and the appropriate computer transaction number
from your UNI plan.
FP,AFIS Global-Wulfsberg (Honeywell) AFIS Option. The AFIS option instructs

JetPlan to store internally the computed flight plan data in a format that is
compatible with the Global-Wulfsberg FMS. Externally, no change is visible
in the output of your flight plan. However, the data is prepared for the next
command (see below).
GW1234 Global-Wulfsberg (Honeywell) Reformat Command. This command prints

the data stored from a flight plan that used the AFIS option. The data is
formatted for the Global-Wulfsberg FMS. The data is sent to Allied Signal's
Global Data Center for upload to the aircraft via AFIS. Enter GW and the
appropriate computer transaction number from your AFIS plan.

43
Option Commands
Flight Plan Command
Table 2-7 Flight Plan Options/Commands–FMS (continued)
Option/Command Explanation
FP,LTN Litton FMS Option. The LTN option instructs JetPlan to store internally the
computed flight plan data in a format that is compatible with the Litton FMS.
Externally, no change is visible in the output of your flight plan. However,
the data is prepared for the next command (see below).
LT1234 Litton FMS Reformat Command. This command prints the data stored from
a flight plan that used the LTN option. The data is formatted for the Litton
FMS. Enter LT and the appropriate computer transaction number from your
LTN plan.
Flight Plan Options–Miscellaneous

These options provide various capabilities. The CR and EC options are also commands that
can be used without running a flight plan at the same time (see Flight Plan Support Commands
below).
Table 2-8 Flight Plan Options–Miscellaneous
Option Explanation
FP,-E Enroute Charges Option. Considers enroute navigational fees (see related
Output Option below). This option is typically only used when performing
4D cost-based analysis.
FP,-O Enroute Charges – Output Option. This option (a dash or minus sign
followed by the letter O) displays the calculated navigational fees at the
bottom of the flight plan.
NOTE This feature requires activation of specific settings in your ID/Attribute
File. Contact Jeppesen Customer Service for more information.
FP,CR Cosmic Radiation – Long-Term Archive Option. This option stores specific
information from the flight plan to track crew exposure to the possibly
harmful effects of cosmic radiation. The archive function provides long-term
storage of up to one year.
For more information, see Chapter 25, “Enroute Charges and FIR Traversal.”
NOTE Both this feature and the application that automatically performs this
function (Automatic Archive) require activation of specific settings in your
ID/Attribute File. Contact Jeppesen Customer Service for more information.

44
Option Commands
Flight Plan Command
Table 2-8 Flight Plan Options–Miscellaneous (continued)
Option Explanation
FP,EC Enroute Charges – Long Term Archive Option. This option stores specific
information from the flight plan to track navigational fees associated with
flight over other countries’ airspace. The archive function provides long-
term storage of up to one year.
For more information, see Chapter 25, “Enroute Charges and FIR Traversal.”
FP,HOLD Hold Option. The Hold option instructs JetPlan to look for inputs not
otherwise required. For example, when you request a flight plan that
specifies a departure weight or fuel value, JetPlan does not typically prompt
a reserve fuel input. However, with HOLD specified on the Options
command line, the JetPlan Interactive system prompts you for a reserve fuel
input (Question 17).
The Hold option also enables you to change pre-stored option values for the
flight plan request at hand without permanently affecting the stored values.
For example, you can change the Performance Index on an immediate flight
plan request from fuel optimization (F) to time optimization (T), without
changing the stored value (in the Customer Aircraft Database) of fuel
optimization in future plan requests.
FP,PMIN Precision Minima Option. This option directs JetPlan to use precision
minima for checking suitability of alternate airports. Normally, the more
conservative non-precision minima are used. This option allows airports
with lower ceiling or visibility forecasts to be used as alternates.
NOTE The Precision Approach Alternate Ceiling Minimum (P3) and
Precision Approach Alternate Visibility Minimum (P4) parameters must be set
in the Customer Airport Fleet Database and/or the Customer Airport Database.
FP,R5xx China Civil Aviation Regulation 121 (CCAR-121) R5 Fuel Policy (R5xx)
Option. The CCAR-121 R5 fuel policy defines formulas for calculating
contingency and reserve fuel for operators flying under Chinese Civil
Aviation Regulations.
Fuel Commands.”
FP,RF Fuel Off/On and Payload Off Option. The RF option is a request to include a
fuel on-load or off-load (or a payload off-load) as part of your flight
plan.When the RF option is invoked, JetPlan prompts for an on-load/off-load
input with the Refuel command line (Question 15).
For more information, see Chapter 15, “Fuel Off/On and Payload Off
Commands.”
FP,XFDB Exception to Filing Database Option. This option directs JetPlan to ignore
the special addresses and/or filing parameters set in your Filing database (if
you have one). For this flight plan request, default addresses and/or
parameters are used.

45
Option Commands
Additional Command-Line Options

The following sections cover options that are entered on the 01 OPTIONS command line but
that are not used with the FP command.
Support Information and Action Commands

The following commands are entered on the Options command line. They provide separate
support information or perform specific action functionality for the JetPlan system (flight
planning, weather, and so on).
NOTE These commands are not used with the FP command at all.
Table 2-9 Support Information and Action Commands
Command Explanation
ATTRA,PRI Print Attributes Command. This command displays the attributes that are
associated with your password (your ID/Attribute File).
BU Bulletins Command. Entering BU displays the current on-line bulletins. This

includes the status of organized track structures (OTS) such as those in the
Pacific and North Atlantic, and other system pertinent information.
CM1234,1235 Reclear Compression Print Command. This command provides output of

(Format Specific) reclear flight plans in a compressed format. Depending on your output
format, you can compress two or three reclear flight plans by specifying the
plan numbers after the CM command.
For example:
CM1234,1235,1236
CR,1234 Cosmic Radiation – Archive and Report Command. This command enables
you to track your crews’ increased exposure to the possibly harmful effects
of cosmic radiation. The archive function provides long-term storage of
specific flight data for up to one year. You can use this feature on a per plan
basis or set it to store information for every flight plan computed
automatically. For information on cosmic radiation archive and report
functionality, see Chapter 26, “Archiving.”

46
Option Commands
Table 2-9 Support Information and Action Commands (continued)
Command Explanation
CR,1234,CX Cosmic Radiation – Archive and Report Cancel Command. Marks flight
plans in the archive as canceled and prevents their display in future reports.
For information on the cosmic radiation archive and report functionality, see
Chapter 26, “Archiving.”
EC,1234 Enroute Charges – Long-Term Archive Command. Provides long-term
storage (up to one year) of navigational fee records, including specific
information about the flight. You can use this feature on a per plan basis or
set it to store information for every flight plan computed automatically. For
information on the archive and report functionality, see Chapter 26,
“Archiving.”
EC,1234,CX Enroute Charges – Long-Term Archive Cancel Command. Marks flight

plans in the archive as canceled, and prevents their display in future reports.
For information on the archive and report functionality, see Chapter 26,
“Archiving.”
ER,xxxxx... Error Decode Command. This option provides plain language error
explanations if not already preset in your ID/Attribute File. Enter ER
immediately followed by the error code (or a comma and the error code).
For example:
ER,SEAGUL06
FI1234 Filing Command. Enables you to file the flight plan by the transaction
number.
For more information, see Chapter 19, “ATC Filing.” For information on
automatic archive functionality, see Chapter 26, “Archiving.”
FI1234,CHG,(various Filing Change Command. Sends a change message based on the entries
entries) included.
FI1234,CX Filing Cancel Command. Enables you to cancel previously filed flight plans
(by transaction number).
For more information, see Chapter 19, “ATC Filing.” For information on
automatic archive functionality, see Chapter 26, “Archiving.”
FI1234,DLA=#### Filing Delay Command. Allows the ETD on a previously filed plan to be
delayed.
For example:
FI2615,DLA=1745
FI1234,HOLD Filing Hold Command. Prompts “enter question number or GO” to allow
user to make changes before filing.
FI1234,NOW File Now Command. Makes filing immediate, rather than holding in queue.

47
Option Commands
Command Explanation
FIxxxx,STAT Filing Status Command. Provides the status of a flight plan, whether filed,
queued, or canceled.
For example:
01 OPTIONS FI2615,STAT
ATC MESSAGES FOR PLAN 2615DATE/TIME (GMT) STATUS
CENTER REFNO SEQNO SEND
BY04/12/2007-10:31:57 FILING ACCEPTED LFPYZMFP 25240
For example:
01 OPTIONS FI2615,STAT,ALL
ATC MESSAGES FOR PLAN 2615DATE/TIME (GMT) STATUS
CENTER REFNO SEQNO SEND
BY04/12/2007-10:31:04 FILING QUEUED ~~~~ 25238
04/12/2007-10:3104/12/2007-10:31:37 FILING SUBMITTED
~~~~ 2523804/12/2007-10:31:57 FILING ACCEPTED
LFPYZMFP 25240
FPR Flight Plan Reload Command. Reloads the inputs from the most recent
previously computed flight plan during an uninterrupted connection to the
JetPlan system, saving you from having to answer all of the flight plan
prompts again.
IATA,xxx IATA Airport Decode Command. Displays an airport's IATA and ICAO
identifiers, coordinates, and full (proper) airport name. Either a comma or a
space can be entered between IATA and the identifier.
For example:
IATA,JFK
ICAO,xxxx ICAO Airport Decode Command. Displays an airport's IATA and ICAO
identifiers, coordinates, and full (proper) airport name. Either a comma or a
space can be entered between ICAO and the identifier.
For example:
ICAO,KJFK
IFS,FLEX Print PACOTS (eastbound flex tracks) Command. Displays the eastbound
Flex Track NOTAM (routes from Japan to Hawaii). These particular tracks
are on-line between 00-02Z, and are valid 10-21Z for aircraft crossing 160E
between 12-16Z.
IFS,FREEFLOW Print PACOTS (westbound) Command. Displays the route inputs necessary
to access the westbound Pacific Organized Track Structure. These particular
tracks are on-line between 14-16Z, and are valid 19-08Z for aircraft crossing
160E between 02-06Z.

48
Option Commands
Command Explanation
IFS,PAC-OTS Print PACOTS (eastbound) Command. Displays the route inputs necessary
to access the eastbound Pacific Organized Track Structure. These particular
tracks are on-line between 21-23Z, and are valid 07-23Z for aircraft crossing
160E between 09-16Z.
NOTE The dash (minus sign) is required between PAC and OTS when you
input this support command.
IFS,WFTR Print PACOTS (westbound flex tracks) Command. Displays the westbound
Flex Track NOTAM (routes from Hawaii to Japan). These particular tracks
are on-line between 11-13Z, and are valid 19-08Z for aircraft crossing 160E
between 23-06Z.
INFO,ABS Arrival Bias Reference Command. Displays all arrival biases stored under
your ID/Password.
INFO,ACQREF Aircraft Reference Command. Displays the names of all the manufacturers
with aircraft loaded in the JetPlan Aircraft Library. You can enter subset
commands by specifying an individual manufacturer or the ICAO code for
the aircraft. The first example is a request for all Boeing aircraft loaded in the
JetPlan library (by the ICAO code).
For example:
INFO,BOEING
The next example is a request for all aircraft in the JetPlan library with the
ICAO code B747
For example:
INFO,B747
INFO,ATC ATC Reference Command. Displays Center Flight Data phone numbers and
addresses.
INFO,CHANGES Customer Database Changes Command. Displays a summary of all changes

to your Customer Route Database. Changes occur periodically, and are
usually based on the AIRAC cycle.
INFO,DBS Departure Bias Reference Command. Displays all departure biases stored
under your ID/Password.
INFO,FAX FAX-Forwarding Reference Command. Displays all FAX-forwarding

features.
INFO,FAXCHRG FAX Charges Reference Command. Lists the international communication

charges associated with the FAX-forwarding feature.
INFO,IDQREF Aircraft ID Reference Command. Displays all of the JetPlan identifiers for
generic aircraft loaded in the JetPlan Aircraft Library. Each identifier is
cross-referenced to its counterpart ICAO identifier. Use the JetPlan aircraft
identifier as your A/C input if you wish to flight plan with a generic aircraft.
INFO,JPOPT JetPlan Options Reference Command. Lists most JetPlan options.

49
Option Commands
Command Explanation
INFO,MAPS Map Codes Reference Command. Lists all of the codes used to obtain
weather maps on the JetPlan system. See the WX command.
INFO,METAR METAR Decode Command. Displays a METAR weather report example

along with a decoding of the METAR hourly weather report format.
INFO,TAF TAF Decode Command. Displays a TAF weather report example along with
a decoding of the TAF terminal forecast format.
JPIII JetPlan III Reference Help Command. This command accesses database
information you can use when researching and creating flight plans. Type
JPIII on the Options command line and follow the on-screen directions.
Information that you can access includes:
• Airport information
• High/Low altitude airway information
• SID/STAR information
• SID/STAR details, including altitude constraint and rule information
for checkpoints
• Waypoint information
• Currency exchange rates
• FIR traversal information
• Enroute charges information
You can use the JPIII command to display altitude constraint and rule
information for checkpoints in SIDs and STARs. After typing JPIII on the
Options command line, type 4 for SID/STAR detail. Then follow the on-
screen prompts to display details for a SID or a STAR. JetPlan displays the
altitude in the ALT column and rules in the RULE column, where:
• The plus (+) sign in the RULE column means that the aircraft must
cross the fix at or above the altitude specified in the ALT column. For
example, 13000 + means cross the fix at or above 13000 feet (FL 130).
• The minus (-) sign in the RULE column means that the aircraft must
cross the fix at or below the altitude specified in the ALT column. For
example, 13000 - means cross the fix at or below 13000 feet (FL 130).
• The letter B in the RULE column means that the aircraft must cross the
referenced fix between 1000 feet above and 1000 feet below the flight
level specified in the ALT column. For example, 12000 B means cross
the fix between 11000 feet (FL110) and 13000 feet (FL 130).

50
Option Commands
Command Explanation
JPIII (continued) The following example shows altitude constraint and rule information for the
SIER7A STAR:
AIRPORT - VHHH STAR - SIER7A TRANSITION - SIERA
RUNWAY - 07B
CPT DST TOTDST MCS ALT RULE

CANTO 21.8 21.8 159.5 13000 +
MURRY 8.6 30.5 45.0 12000 B
SILVA 7.5 37.9 45.0 0
LIMES 16.8 54.8 337.8 0
VHHH 14.3 69.1 34.7
JPRA1234,1235 JetPlan Route Analysis Command. This command enables you to condense
up to 14 long or short format flight plans into a comparative analysis onto
one page. The standard output format, STF, must be used with this option.
LD1234 and Load Commands. The LD and LDR commands enable you to reuse inputs
LDR1234 from a previously computed flight plan. Simply enter the command (LD or
LDR), followed by the computer transaction number (flight plan number) of
the plan you wish to reuse. Transaction numbers must be from plans that
were run in the past 8–12 hours. Otherwise, the input data is lost.
Both LD and LDR enable you to change any of the previously entered
inputs. However, only LDR lets you insert additional codes on the Options
command line without affecting previous entries on that line. If LD is used,
and additional codes are intended, reenter the entire line of inputs (Options
command line only).
For example, to make a long plan (LP) from a previously computed short
plan, use the following entry:
LDR1234,LP
As for all other command-line inputs, entering LD or LDR enables you to
change any of these other entry lines. You can use the at symbol (@) to move
to the command line you want to edit or change, without affecting the inputs
on the other command lines. Enter @, followed by the command-line
number you want to change.
NOTE If question 10 A/C TYPE/REGN is changed, also re-answer question
11 CRZ MODE, question 14 PAYLOAD, and question 16 POD OR POA FUEL.
After all changes are made and your request is ready to be recomputed, type
GO at the next command line to start the computation. For example, the
following inputs illustrate creating a long plan (LP) from a previously
computed short plan (SP) and changing the route, payload and arrival fuel:
01 OPTIONS LDR1234,LP
02 POD @6
06 ROUTE J,FIM
07 HOLD,ALTERNATE/DIST @14
14 PAYLOAD 84250
16 POD OR POA FUEL A0,I
17 MVR GO

51
Option Commands
Command Explanation
LL,()####,()##### or LAT/LONG Database Search Commands. This option provides the JetPlan
LLX,xxxxx internal name of a waypoint. You can enter either the waypoint’s coordinates
after LL or the waypoint's charted (external) name after LLX.
When entering the waypoint’s coordinates, use four digits to express the
latitude and five digits to express the longitude. Also, when specifying South
or East coordinates, the letters S and E (or a minus sign) must precede the
coordinate entries. The letters N and W are optional (they are default) for
north and west coordinates.
See the following examples:
LL,-3356,-11510 (south 33 deg., 56 min.; east 115 deg., 10
min.)
LL,S3356,E11510
LLX,ALCOA
LLX,SPY
PA Print ABC NATs Command. Displays the current westbound North Atlantic
Tracks (ABCs), including valid altitudes. These tracks are updated between
23-01Z, and valid between 1130-19Z.
PI1234 Print Inputs Command. This command followed by a specific flight plan or
message transaction number prints the inputs of that particular flight plan or
message.
PN1234 Print Plan (Transaction) Number Command. This command followed by a

specific flight plan or message transaction number prints the output of a
particular flight plan or message.
PW<####> Print Weather Command. This command followed by a specific flight plan
number prints the most recent WXE report for that flight plan.
PZ Print XYZ NATs Command. Displays the current eastbound North Atlantic
Tracks (XYZs), including valid altitudes. These tracks are updated between
12-14Z, and valid between 01-08Z.
RFMT,1234,xxx Reformat Plan Command. Enables you to reformat a previously computed

flight plan without actually computing it again. Enter the plan transaction
number from the flight plan you wish to reformat and a different output
format (layout) code to complete the input.
For example:
RFMT,1234,STF
NOTE The RFMT command might not always translate information from one
plan format to another plan format properly. Certain information might be lost
due to the differences in the formats.
VERSION JetPlan Version Number Command. Displays the current JetPlan program
version.

52
Option Commands
Command Explanation
WXE1234 Enroute Weather Command. Enter WXE, followed by the plan transaction
number, and JetPlan reproduces the plan, including the enroute weather. A
maximum of four flight plan numbers can be entered separated by commas.
For example:
WXE1234,2345,3456,4567
NOTE This command does not recalculate the flight plan. The enroute
weather briefing is based on the route from the flight plan with the transaction
number specified.
XAP,ALT,xxxx Alternate Search Command. A search for alternate airports can be

accomplished using the following commands:
XAP,ALT,origin,rad,rwy,etd,ete,gsa,lst
where:
origin = an ICAO or IATA airport code, or lat/long coordinates entered as
[N|S|+|-]ddmm[W|E|+|-]dddmm (for example, N3356W11824)
rad = nnnn: search radius in NM (default is 100)
rwy = nnn: minimum length of longest runway in hundreds of feet (default is
80)
etd = hhmm or ddmmyyyy@hhmm: UTC departure time or date@time from
the POD, not the origin (used for TAF processing)
ete = hhmm: flight time to origin from the POD (used for TAF processing)
gsa = nnn: origin-to-alternate groundspeed in KT (default is 250)
lst = nnn: maximum number of alternates in response (default is 20)
NOTE All parameters except origin are optional (default values are used).
NOTE TAF-processing is bypassed when both ETD and ETE inputs are
omitted.
For example:
Explanation: Search for airports within 150 nm of KLVK with runway
lengths of at least 7000 feet.
01 OPTIONS XAP,ALT,KLVK,RAD=150,RWY=70
or
01 OPTIONS XAP,ALT,KLVK,150,70D

53
Option Commands
Flight Plan Shortcuts

The following inputs can be entered on the Options command line. They are time-saving
shortcuts that expedite the flight planning process.
Table 2-10 Flight Plan Shortcuts
Command Explanation
FPR Reloads the inputs from the most recent previous flight plan during an
uninterrupted interactive session. This command saves you time because you do
not need to answer all of the flight plan prompts again.
LD Loads (or reloads) the inputs from a flight plan previously computed in the
preceding 8–12 hours. See above.
LDR Same as LD except LDR allows for additional inputs to be added to the Options
command line. See above.
RFMT Enables you to reformat a previously computed flight plan without actually
computing it again. Enter the transaction number from the flight plan you wish to
reformat and a different format code to complete the input (for example,
RFMT,1234,STF).
NOTE The RFMT command might not always translate information from one plan
format to another plan format properly. Certain information might be lost due to the
differences in the formats.
The following command inputs can be entered from any command line.
• @–The At command. When followed by an interactive line number, this

JetPlan shortcut jumps to the logical position of the line specified where the
desired change is needed. This command simplifies the flight planning
process immensely because you can move immediately to the line that needs
to be added, changed, or corrected without answering other command inputs
again.
• GO–The GO command. Directs JetPlan to begin computing the flight plan
request immediately.

54
Option Commands
The following example demonstrates the application of JetPlan shortcuts. Assume a flight plan
has just been computed, and it was not correct. You want to change your route and cruise
mode information. In this case, you can apply the following shortcuts as shown in the
following example.
Example:
01 OPTIONS FPR
02 POD @6
06 ROUTE J,FIM
11 CRUISE MODE LRC
12 PRFM INDEX GO
Explanation:
• Option Line – User reloads the flight plan from the immediately previous
computation.
• POD Line – User jumps to the Route Line, bypassing all command lines in
between.
• Hold Line – User jumps to the Cruise Line, bypassing all command lines in
between.
• Performance Index Line – User directs JetPlan to begin the computation of
the edited plan, bypassing all other possible inputs.

55
Option Commands
Weather Services Command

The following command accesses text and graphical (maps) weather information from the
Jeppesen Weather Services portion of the JetPlan system.
NOTE This command is not used with the FP command at all.
Table 2-11 Flight Plan Commands–Weather Information
Command Explanation
WX Weather Request Command. The WX command enables you to display
Jeppesen weather products, including text briefings and graphic weather
depictions (maps).
Upon input of this command, JetPlan prompts for your weather request input
on the Stations command line (02 STATIONS).
For more information, see Chapter 49, “Graphic Weather.” See also
Chapter 48, “Text Weather.”
Messages Command
You can compose and store text messages for transmission using the command shown below.
You can also include previously computed non-graphic JetPlan products (flight plans and
weather briefings) into one package using this feature.
NOTE This command is not used with the FP command at all.
Table 2-12 Flight Plan Commands–Messages
Command Explanation
MG Message Command. Entering this command enables you to create a plain
text message. It also enables you to bundle other JetPlan products together
under one transaction number. The created message or message package can
be transmitted via one of the major data communication networks (AFTN,
ARINC, SITA) or faxed.
JetPlan provides for up to 55 lines of text and 68 characters per line.
For more information, see Chapter 17, “Message Commands.”
MGNN Message No Number Option. This command is the same as the MG

command except that the No Number option, NN, suppresses the transaction
number when the message is printed or forwarded via a communication
network.

56
Option Commands
Data Transmission Commands

You can forward any recently computed, non-graphic JetPlan product via a specific data
network using the commands in the following table.
For more information on these commands, see Chapter 18, “Forward Plans and Messages.”
Table 2-13 Data Transmission Commands
Command Explanation
AF AFTN Command. This command enables you to transmit flight
plan/message/weather data via the AFTN network.
AR ARINC Command. This command enables you to transmit flight

plan/message/weather data via the ARINC network.
FX FAX Command. This command enables you to transmit flight

plan/message/weather data via FACSIMILE.
SI SITA Command. This command enables you to transmit flight

plan/message/weather data via the SITA network.
UL,1234 ACARS Uplink Command. This command enables you to upload flight
plans or text message information to the FMS system on the aircraft.
Presently, you can uplink to three types of systems: Universal, Smith
Industries, and Honeywell.
For example:
UL,AR,1234,UF,RG=N123ZZ

57
Option Commands
Database Commands
The following commands access specific customer databases. Using these access commands,
you can create and manage information used in your flight plan requests, customizing the
information that affects your flight plans while simplifying your inputs.
Table 2-14 Flight Plan Commands–Customer Database Access
Command Explanation
AC Aircraft Database Access Command. Enables you to create and manage
custom records of the aircraft you use in the JetPlan system. An aircraft
record’s parameter settings are invoked in a flight plan when the record name
is specified in the flight plan request.
For more information, see Chapter 27, “Customer Aircraft Database.”
ACF Aircraft Fleet Database Access Command. Enables you to create and
manage custom records of the aircraft fleet types you use in the JetPlan
system. A fleet type is the Jeppesen generic aircraft ID that defines a specific
airframe/engine combination. An aircraft fleet record’s parameter settings
are invoked in a flight plan when the record name is specified in the flight
plan request.
For more information, see Chapter 28, “Aircraft Fleet Database.”
ALT Alternate Database Access Command. Enables you to create and manage
alternate airport records for any arrival station you choose. Also enables you
to define the route and/or distance information from a POA to an alternate if
desired. If your flight plan request contains a POA that is recognized as
having alternate information in the database, alternate airport records are
invoked automatically
For more information, Chapter 29, “Customer Alternate Database.”
AP Airport Database Access Command. Enables you to create and manage
custom records for any airport you wish to store in the database. Records can
include obstacle information, special procedures, fuel prices, taxi times and
more. If your flight plan request contains a POD or POA that is recognized
as having information in the database, Airport Database records are invoked
automatically
For more information, see Chapter 30, “Customer Airport Database.”

58
Option Commands
Table 2-14 Flight Plan Commands–Customer Database Access (continued)
Command Explanation
APF Airport Fleet Database Access Command. Enables you to create and manage
custom records that define an airport’s practical usefulness for the type of
aircraft (fleet type) being used in the flight plan. If your flight plan contains a
POD, POA, or implicit alternate with information stored in the database,
Airport Fleet Database records are automatically reviewed. Further, if the
specific fleet type in the flight plan request coincides with a particular airport
record, information in the record is then invoked.
For more information, see Chapter 31, “Airport Fleet Database.”
CDR Coded Departure Routes Database Access Command. Coded Departure
Routes (CDRs) are predefined alternate routes for flying between city pairs
when a user-preferred route is not available due to weather or traffic
constraints. This database enables you to find, view, and mark as “OK to
Use” records of CDRs between specific airport pairs.
For more information, see Chapter 35, “Coded Departure Routes Database.”
CP City Pair Database Access Command. Enables you to create and manage
records that contain values specific to specific airport pairs.
For more information, see Chapter 33, “City Pair Database.”
CPF City Pair Fleet Database Access Command. Enables you to create and
manage records that contain values specific to certain aircraft types operating
between specific airport pairs.
For more information, see Chapter 34, “City Pair Fleet Database.”
FB Flight Brief Database Access Command. Enables you to create and manage
records that identify remarks intended for ATC or the flight crew. Remarks
can include diplomatic clearance information, crew notes, or weather
information. An FB record is applied in a flight plan if certain conditions for
the flight (for example, departure FIR, arrival FIR, flight number, and fleet
type) match user-defined, key parameters in the database.
NOTE A quick help file is available to guide you through the various
management inputs for this database. Enter FB,HLP on the Options command
line.
For more information, see Chapter 36, “Flight Brief Database.”

59
Option Commands
Command Explanation
MEL MEL Database Access Command. Accesses the Minimum Equipment
List/Configuration Deviation List Database. Enables you to create and
manage records that address performance degradations and/or equipment
shortcomings for aircraft of a specific fleet type. Records are invoked when a
MEL Database record name is specified in a flight plan request.
NOTE You can have your output format customized to display MEL
information from the database in the flight plan.
For more information, see Chapter 38, “Minimum Equipment List
Database.”
MDB Master (MEL) Database Access Command. Enables you to create and
manage records that address performance and/or equipment degradations for
individual aircraft. This database is keyed by the aircraft’s Customer Aircraft
Database (CADB) record name rather than by its fleet type. A record is
invoked any time the CADB record name is used in a flight plan request as
long as it has not expired. This database depends on the MEL Database for
information.
For more information, see Chapter 37, “Master Database (MDB).”
RST Restricted Area Database Access Command. Enables you to create and
manage records that identify restricted areas you define. A restricted area
from the database is invoked when a record’s file name is specified in a flight
plan request.
For more information, see Chapter 40, “Restricted Area Database.”
RT Route Database Access Command. Enables you to create and manage as
many routes between specific airport pairs as you need. A record is invoked
when a route file name is specified in a flight plan request.
For more information, see Chapter 41, “Customer Route Database.”
RG Route Group Access Command. Enables you to create and manage records
that categorize Customer Route Database records by group record names.
For more information, see Chapter 41, “Customer Route Database.”
RTC Route Constraint Database Access Command. Enables you to create and
manage records that restrict routes based on aircraft capabilities, limitations,
or equipment.
For more information, see Chapter 42, “Route Constraint Database.”
RWY Preferred Runways Database Access Command. Enables you to create and
manage records that rank runways in terms of preference. The Runway-to-
Runway feature uses this database. For more information, see Chapter 39,
“Preferred Runways Database.”

60
Option Commands
Command Explanation
SDB Scenario Database Access Command. Enables you to create and manage
records of inputs that can be used automatically with the OSA (4D) feature.
For more information, see Chapter 43, “Scenario Database.”
SC Schedule Database Access Command. Enables you to create and manage

flight plan request sets in a database of scheduled records. A schedule record
is invoked when specified in a flight plan request (SC,FLT,record name).
For more information, see Chapter 44, “Customer Schedule Database.”

61
C HAPTER 3
Point of Departure and

Point of Arrival
Commands
Point of Departure and Point of Arrival Commands
Overview
Overview
This chapter contains information on entering a point of departure (POD) and a point of arrival
(POA) in a JetPlan flight plan request. This chapter also introduces optional features and other
capabilities related to the POD and POA command lines. These features include:
• Equal Time Point (ETP) locations

• Taxi-out and taxi-in fuel
• POD and POA positions and elevations for user-defined airports and in-
flight start points
• Takeoff alternate (POD command line only)
Specifying Airports
The following sections describe options for entering airport information.
Airport Identification
JetPlan recognizes all airports stored in its Navigation Database, which contains information
on the location and elevation of each airport. The system uses the location and elevation of the
airport in the calculation that determines the route and performance information for the flight.
You can enter airports on the POD and POA command lines. Specify the four-character ICAO
or three-character IATA identifiers to confirm your departure and arrival airports.
Example:
02 POD KDEN or DEN
03 POA PHNL or HNL
NOTE For information on using airports that are not in the Navigation Database, see
“Ad Hoc Airports and In-Flight Starts” on page 79.

65
Specifying Airports
Diversion Airports
You can include diversion airports in the flight plan calculation. JetPlan uses diversion airports
to determine ETP information.
You can specify a maximum of 12 diversion airports in your flight plan request. JetPlan has
two methods for specifying diversion airports: sequential entry or paired entry.
Sequential Entry Method

The sequential entry method requires you to type the diversion airports one after the other
(sequentially) on the POD line only. These inputs follow the departure airport input and are
separated from the POD and from each other by a slash (/).
With the sequential method, the first divert airport (aft) is the POD. The POA is the last
forward divert airport. In the following example, JetPlan determines ETP information between
KLAX and KSFO, KSFO and PACD, PACD and RJCC, and, finally, between RJCC and
RJAA.
Example:
02 POD KLAX/KSFO/PACD/RJCC
03 POA RJAA
Paired-Entry Method
The paired-entry method requires you to specify the diversion airports in paired sets between
the POD and the POA lines. These inputs follow the departure and arrival airport inputs and
are separated from the POD, POA, and each other by a slash (/).
With the paired-entry method, the first divert airport (aft) is the first airport identified after the
departure airport. The last (forward) divert airport is the last airport identified on the POA line.
In the following example, JetPlan determines ETP information in two places: between KSFO
and PACD and between PACD and RJCC. (This input method is easier to follow if you view
the example from top to bottom rather than from left to right.)
Example:
02 POD KLAX/KSFO/PACD
03 POA RJAA/PACD/RJCC

66
Specifying Airports
ETP Calculations
When using diversion airports to calculate ETP information, JetPlan first computes the basic
flight plan (POD to POA). Before JetPlan delivers the results, it runs the ETP subroutine that
applies your specified divert airports. This calculation is not based on a complex mathematical
formula but rather on a simple iterative process.
This process requires JetPlan to determine both a route to the divert airport and a time factor
on which a comparison can be made. JetPlan determines the route using a great circle
projection from a point along the route of flight to the candidate divert airport. The system
determines the time factor by gathering information that defines a groundspeed. JetPlan uses
wind averages based on forecast data at a selected altitude (or millibar level) for this
information. Once this information is set, the system performs a comparison process involving
the following two steps:
• Step 1 – Determination of the bounding points

• Step 2 – Interval halving between the bounding points
NOTE Several JetPlan applications use this approach, including Basic ETP
Calculator, ETOPS, and Overwater Driftdown. However, variations in this method
exist for certain formats or aircraft. These variations are discussed later in this
section.
The two-step approach analyzes the results of repetitive calls (iterations) to a trial ETP
calculation function. This technique is based on the existence of a forward and backward
divert airport. The trial ETP calculation determines the enroute time required from a trial point
on the flight plan route to either a forward or a backward divert airport. The airport closest to
the flight plan POD is the backward divert airport. The airport closest to the flight plan POA is
the forward divert airport.
Determination of Bounding Points

The objective of the first step is to determine the checkpoints that contain, or bound, the ETP
position. This process uses the ETP airspeed and flight level data stored in either the generic
aircraft data file or in a Customer Aircraft Database (CADB) record. The particular parameters
the system uses to calculate a specific set of ETP positions depend on the specific JetPlan

67
Specifying Airports
application. For example, the ETOPS program uses different parameters than the Basic ETP
calculation program. In any event, the algorithm that determines the bounding pair of
checkpoints begins.
NOTE For basic ETP calculations, JetPlan looks in the CADB for the NA/NF
parameters first. If no data exists for these parameters, the system uses the
EA/EM(F) parameters.
Starting at the beginning of the primary route of flight (the route in the basic flight plan) and
proceeding incrementally with each checkpoint, JetPlan creates an ETP trial point. When
divert airports are entered sequentially, the POD is generally the first ETP trial point. See
Figure 3.1.
Dulles (KIAD) - Heathrow (EGLL)

Diverts CYQX / LPLA
EA=320kts EF=10,000ft
CYQX
EINN
Trial
ETP #1
KIAD EGLL
LPLA
ETP METHODOLOGY
Determine the trial ETP
Figure 3.1. Trial Equal Time Point

68
Specifying Airports
To collect wind and temperature data, JetPlan runs a great circle route from the ETP trial point
to each divert airport. JetPlan uses this data to determine an overall wind component that can
be used with the ETP airspeed to determine a time enroute to each divert airport. If the time to
the divert airports does not come within 30 seconds of being equal, JetPlan moves to the
ensuing checkpoint and makes it the next ETP trial point. See Figure 3.2 and Figure 3.3.

Diverts CYQX / LPLA
CYQX
Great Circle Route 1
+15 kt tailwind
2:00 hrs
EINN
Trial
ETP #1
Great C ircle Route 2
KIAD +30 kt tailwind EGLL
5:00 hrs
LPLA
ETP METHODO LOG Y
Test of Trial ETP #1
Figure 3.2. Test of Trial Equal Time Point #1

69
Specifying Airports

Diverts CYQX / LPLA
Great Circle CYQX

Route 3
1:00 hr
Trial
ETP #2 EINN
Great Circle R oute 4

KIAD 3:55 hr EGLL
LPLA
ETP METHODOLOGY
Test of T rial ETP #2
Figure 3.3. Test of Trial Equal Time Point #2
Initially, the time to the forward divert airport is greater than the time to the backward divert
airport. The system detects a time switch at the waypoint where the time to the forward airport
becomes less than the time to the backward airport. This point is known as the switch point.

70
Specifying Airports
JetPlan knows that the ETP must exist somewhere between the switch point and the
checkpoint analyzed immediately prior to the switch point. The bounding points are now
known. See Figure 3.4.

Diverts CYQX / LPLA

CYQX 2:55 hr
Bounding Point #1
Bounding Point #2 (Switch point)

EINN

1:45 hr
KIAD EGLL
ETP METHODOLOGY
LPLA
Test of Trial ETP #7,
Switch point is determined
Figure 3.4. Determining the ETP Switch Point

71
Specifying Airports
Interval Halving Between Bounding Points

The objective of the second step is to determine the ETP position precisely, using the interval
halving technique. JetPlan creates a new ETP trial point that is midway between the two
bounding points. The system can then recalculate the time to each of the two divert airports
and note the difference. If the time difference is less than 30 seconds, the iteration is satisfied,
and the trial ETP position is established as the actual ETP. See Figure 3.5.

Diverts CYQX / LPLA

CYQX 2:35 hr
Bounding Point # 1
New Trial ETP
Bounding Point #2 (Switch point)
EINN
Trial
ETP #1 Great Circle Route 16
2:05 hr
KIAD EGLL
ETP METHODOLOGY
LPLA
Post Interval Halving Test
of Ne w Trial ETP
Figure 3.5. Interval-Halving Test of New Trial ETP
If the time difference between the backward and forward airports and the trial ETP is greater
than 30 seconds, JetPlan determines a new pair of bounding points. The system uses the
current ETP trial point as one of the bounding points. A new trial ETP is computed midway

72
Specifying Airports
between the current trial ETP and the other bounding point (interval halving is applied again).
This process continues over and over until the less-than-30-seconds check is satisfied, and an
actual ETP is determined. See Figure 3.6.

Diverts CYQX / LPLA

CYQX 2:20 hr
Bounding Point #1
New Trial ETP (Ultimate ETP)
New Bounding Point & Switch Point
Bounding Point #2 (original switch point)
EINN
Trial
ETP #1 Great Circle Route 18
2:20 hr
KIAD EGLL
ETP METHODOLOGY
Second Interval Halving LPLA
Test of New T rial ETP
Actual ETP Determined
Figure 3.6. Determining the ETP
CADB Considerations
The system determines both the trial and the final ETP points in one of the following ways:
• By applying the default true airspeed (TAS) and wind extract level found in
the generic aircraft data file
- or -
• By applying the customer-specified TAS and wind extract level stored in the
CADB
In the CADB, the ETP TAS value is stored as the value of the EA parameter (ETP airspeed),
while the ETP wind extract level is stored as the value of the EM parameter (ETP millibar).
By default, the CADB record display shows the wind extract parameter as EM. If you use the
EM parameter, you are required to apply one of the following millibar values: 850, 700, 500,
400, 300, 250 or 200. However, you can apply a flight level rather than a millibar value by

73
Specifying Airports
specifying the EF parameter (ETP flight level) and entering a flight level value in hundreds of
feet (for example, EF310 for 31,000 feet). The EF parameter lets you specify any flight level,
as long as it is valid for the aircraft.
Normally, JetPlan uses the EA and EM/EF parameters for the basic ETP calculations. JetPlan
also makes ETP calculations when the ETOPS and Driftdown options are selected.
If the ETOPS option is selected, the EA parameter is used to specify the ETP TAS, and the
EM/EF parameter is used to specify both the ETP wind selection altitude and the low-level
cruise altitude.
If the Driftdown option is selected, the EA parameter is used to specify the low-level all-
engine cruise ETP TAS, and the EM/EF parameter is used to specify both the ETP wind
selection altitude and the low-level all-engine cruise altitude.
The Driftdown option also calculates ETPs for one and two-engine out scenarios (for three and
four engine aircraft). This process requires you to provide the following CADB parameter
values:
• EA1 – specifies the one engine-out (1LE) ETP TAS

• EM1/EF1 – specifies the one engine-out ETP wind selection altitude
• EA2 – specifies the two engines-out (2LE) ETP TAS
• EM2/EF2 – specifies the two engines-out ETP wind selection altitude
The cruise altitude for one engine-out and two engines-out is determined by a table lookup that
considers aircraft weight and ambient temperature.

74
Specifying Airports
Some users prefer to use a high-altitude ETP for basic ETP calculations. JetPlan refers to this
scenario as a non-emergency ETP. In this case, the NA (non-emergency TAS) parameter is
used to specify the non-emergency ETP TAS. The NF (non-emergency flight level) parameter
is used to specify the non-emergency ETP wind level. The NF parameter recognizes a flight
level only; no millibar levels are allowed (no NM parameter exists).
NOTE The term non-emergency refers to the operational integrity of the aircraft.
The non-emergency ETP might, in fact, be used in an emergency situation, such as a
passenger medical emergency on board. In this case, the aircraft is not compromised,
but a diversion is still required.
NOTE When you apply the Driftdown option to a flight plan with an aircraft that has
NA and NF values in the CADB, the ETP output at the top of the flight plan is based
on these parameters (the non-emergency scenario). However, the ETP information in
the Driftdown summary block is based on the other ETP parameters, depending on
the scenario applied (all-engine, one engine-out, or two engines-out calculations).
For more information, see the ETOPS User’s Guide: 2 Engine Aircraft on JetPlan.com and
Chapter 22, “Overwater Driftdown and Terrain Analysis.”
Variations in ETP Calculation Methods

JetPlan has three variations in the methods used to calculate ETP data. Each is briefly
explained in the following paragraphs. The first method is the default and available to most
users, depending on the generic aircraft or CADB file applied. The second and third methods
are more format and aircraft-specific.
Default ETP Calculation Method

The default method calculates the ETP location using a TAS constant and a specific flight
level or millibar for weather data (winds and temps aloft). These constants are stored either in
the generic aircraft data file in use or in the CADB record (EA, EM/EF parameters). If the
CADB record is used, both parameter values can be altered. However, a generic aircraft data
file is used, only the TAS constant can be changed.

75
Specifying Airports
Most generic aircraft data files that have ETOPS or Driftdown table data available contain the
following information:
• One of the following TAS constants:

– All-engine, low-level cruise (usually LRC)
– One engine-out cruise (usually 1LE)
• A wind extract flight level of 700mb (approximately FL100). Some older
generic aircraft loads have a flight level of 300mb (approximately FL300).
JetPlan determines a wind-component value by running a great circle flight at the ETP flight
level from a trial ETP to the divert airports. JetPlan then applies the wind component value to
the TAS constant at the midpoint between the ETP and the divert airports to determine the
groundspeed for the ETP formula.
Second ETP Calculation Method

The second ETP calculation method, applicable to specific formats and aircraft, determines
the ETP location in the same manner as the first method. In addition, this method determines
the fuel burn from the ETP to one or more diversion airports, based on user-supplied fuel flow
constants. Typically, these fuel flow constants represent all-engine, low-level cruise, or one
engine-out cruise. The fuel burn calculations include:
• Descent from cruise altitude to the specified wind data flight level (millibar)
loaded in the CADB. For example, if 700mb is specified, the divert cruise
altitude is 10,000 feet.
• Cruise to the divert airport at the specified wind data flight level.
• Descent to the divert airport.
• Hold over the divert airport for the user-specified time and altitude.
Third ETP Calculation Method

The third ETP calculation method is an enhanced version of the second method. Instead of
using constants for the TAS and fuel flow, table data is used to determine slightly more
accurate TAS and fuel flow values. For specific two-engine aircraft, JetPlan can use this
method in ETOPS flight plans. For specific two, three, and four-engine aircraft, JetPlan can
use this method in Driftdown flight plans.
For more information, see the ETOPS User’s Guide: 2 Engine Aircraft at JetPlan.com and
Chapter 22, “Overwater Driftdown and Terrain Analysis.”

76
Specifying Airports
ETP and Diversion Airport Output

The following airport output is typical for the default ETP calculation method.
ETP KSFO/PACD 03/05 1404NM P009/M028 BURN 0536 N42402W145348

ETP PACD/RJAA 07/34 3490NM P038/P000 BURN 1149 N41492E167180
--- --------- ----- ------ --------- --------- -------------
1 2 3 4 5/6 7 8
Explanation:
• Column 1 – ETP indicator.

• Column 2 – Airport pair.
• Column 3 – Estimated time enroute (ETE) from the POD to the ETP with all
engines operating.
• Column 4 – Distance from the POD to the ETP.
• Column 5 – Wind component from the ETP to the rearward ETP airport
(KSFO on the first line)—in this case, plus nine knots (tailwind).
• Column 6 – Wind component from the ETP to the forward ETP airport
(PACD on the first line)—in this case, minus 28 knots (headwind).
• Column 7 – Total fuel burn from the POD to the ETP. Most formats
generally round off this value to the nearest hundred pounds (for example,
0536 on the first line is 53,600+ pounds). Other available formats display
this value to the nearest pound.
• Column 8 – The ETP coordinates.
The following output is representative of the second or third ETP calculation method.
RJAA-PACD
DIST 2093 DIST 1620 -LINE 1
TIME 04.03 TIME 02.54 -LINE 2
BURN 1274 BURN 0575 -LINE 3
LAT/LONG N36402 E168210 -LINE 4
AVG W/C RJAA M012 TO PACD P080 -LINE 5
Explanation:
• Line 1 (DIST) – The distance (DIST) in the left column is from the POD to
the ETP. The distance in the right column is from the ETP to the forward
ETP airport (PACD).

77
Specifying Airports
• Line 2 (TIME) – The time in the left column is from the POD to the ETP.
The time in the right column is from the ETP to the forward ETP airport
(PACD).
• Line 3 (BURN) – The burn in the left column is from the POD to the ETP.
The burn in the right column is from the ETP to the forward ETP airport
(PACD).
• Line 4 (LAT/LONG) – The ETP coordinates.
• Line 5 (AVG W/C)– The average wind components to the rearward ETP
airport (RJAA–M012) and to the forward ETP airport (PACD–P080).

78
Ad Hoc Airports and In-Flight Starts

This section contains information on the Ad Hoc Airport and In-Flight Start features. The
inputs for these two features on the POD and POA lines are very similar, but they are used for
different purposes, and JetPlan interprets the inputs differently, depending partly on the value
of the Flight Level (FL) input, which defines field elevation for ad hoc airports and actual
flight level for in-flight start points. The following paragraphs describe the Ad Hoc Airport
and In-Flight Start features and the differences between them.
About Ad Hoc Airports

An ad hoc airport is a user-defined airport that is not stored in the Navigation Database or the
Generic Airport Database. You enter the ad hoc airport directly in a flight plan request on the
POD or POA line. Because the ad hoc airport is not stored, you need to enter it in the flight
plan request each time you want to use it.
You can create a valid JetPlan POD or POA value for an ad hoc airport by creating a unique,
arbitrary four-character alphanumeric dummy identifier—for example, KXXX. Enter the
dummy identifier plus the ad hoc airport’s coordinates and elevation on the POD or POA line.
For complete guidelines, see “Defining an Ad Hoc Airport” on page 79.
When the flight plan request includes a valid ad hoc airport, JetPlan includes the following
values in the flight plan calculation: Taxi-Out and In Fuel (from the flight plan request or from
the CADB record) and Minimum Departure Fuel, Minimum Hold Fuel, and Minimum
Alternate Fuel from the CADB.
Defining an Ad Hoc Airport

Define the ad hoc airport by entering the following information on the POD or POA line:
Dummy Airport Provide a dummy airport identifier that contains four alphanumeric
Identifier characters —for example, KXXX. The dummy identifier must not
match any identifiers in the Navigation Database or Generic Airport
Database. Use K as the first character in the dummy airport identifier
for a flight in the United States. The initial K helps ATC recognize
that the filing strip contains domestic United States information.

79
Airport Location After the dummy airport identifier, type the coordinate values for the
Coordinates ad hoc airport. The coordinate values follow the convention of a four-
digit latitude and a five-digit longitude value. A dash, or minus sign
(-), precedes southern or eastern hemisphere coordinate values.
Flight Level After the coordinate values, enter the ad hoc airport field elevation
(FLxxx) using FL, for flight level, followed by a three-digit value (in hundreds
of feet) that is less than 10,000 feet —for example, FL090. If you do
not provide an elevation, JetPlan assumes that the ad hoc airport is at
sea level.
NOTE If the field elevation input for an ad hoc airport is FL100 or greater, JetPlan
automatically treats the airport as an in-flight start point and ignores ad hoc or stored
taxi-out and taxi-in fuel and the minimum fuel values in the CADB. For more
information, see “About Flight Level (FL) and Ad Hoc Airports” on page 80 and
“Defining an Ad Hoc In-Flight Start Point” on page 81.
Example:
The following example illustrates how to enter an ad hoc airport—in this case, as a POD. The
coordinates for this airport are N4135.6 W10409.4, and the elevation is 5,535 feet. The values
are rounded to comply with coordinate and elevation input rules. Because the elevation is less
than 10,000 feet, JetPlan treats this as an ad hoc airport and not an in-flight start.
02 POD KXXX,4136,10409,FL055
You can add ad hoc taxi fuel to an ad hoc airport, as you can for any POD or POA. See
“Entering Taxi Fuel Directly in the Flight Plan Request” on page 89.
About Flight Level (FL) and Ad Hoc Airports

For ad hoc airports, the FL input on the POD or POA line always defines the elevation of the
airfield. For in-flight starts, on the other hand, FL defines the altitude of an in-flight start point.
If the FL value for an ad hoc airport is less than 10,000 feet (FL100), JetPlan automatically
considers it an airport and includes the following values in the calculation: Taxi-Out and In
Fuel (from the flight plan request or from the CADB record) and Minimum Departure Fuel,
Minimum Hold Fuel, and Minimum Alternate Fuel from the CADB.

80
However, if the FL value is FL100 or more, JetPlan considers the ad hoc airport an in-flight
start point and ignores ad hoc or stored taxi-out and taxi-in fuel and the fuel minimums stored
in the CADB.
As a workaround, if you need to specify an airport with a field elevation of 10,000 feet or
more, add it to the Generic Airport Database and do not use it as an ad hoc airport.
See also “Defining an Ad Hoc In-Flight Start Point” on page 81.
About In-Flight Starts

The term in-flight start refers to beginning a flight plan at altitude, or in-flight. In-Flight Start
can also be applied to a POA, in which case the term in-flight start applies to the end point.
You can define in-flight start points on the POD and POA lines. To define the geographical
location of an in-flight start point, use any of the following: an airport that is stored in a
JetPlan database, an ad hoc airport, or a NAVAID. Provide the altitude of the in-flight start
point in hundreds of feet, using the FL option. (Note that for in-flight starts, the FL input
defines the altitude of the in-flight start point, not the elevation of an airfield. For more
information about the value of FL, see “Defining an Ad Hoc In-Flight Start Point” on
page 81.)
Because you cannot add fuel to a plan for a flight that is already underway, JetPlan ignores the
following: Taxi-Out and In Fuel (from the flight plan request or from the CADB record) and
Minimum Departure Fuel, Minimum Hold Fuel, and Minimum Alternate Fuel from the
CADB.
Defining an Ad Hoc In-Flight Start Point

The following paragraphs describe how to use an altitude value with an ad hoc airport, a stored
airport, or a NAVAID to define an in-flight start point.
Ad Hoc Airports as In-Flight Start Points

If you use an ad hoc airport to define the geographical location of the in-flight start point, enter
the dummy airport identifier and the coordinate values for the airport on the POD or POA line,
following the guidelines in “Defining an Ad Hoc Airport” on page 79. However, do not use
the FL option to specify the airport elevation. Instead, use FL to specify the altitude of the in-

81
flight start point. For in-flight start points, the FL input always specifies an actual flight level
at which to begin the flight—or end it, in the case of a POA. To be considered an in-flight start
point, the altitude must be 10,000 feet (FL100) or above.
Note that the value of the FL input is the only thing that distinguishes between an ad hoc
airport used as an airport and an ad hoc airport used as an in-flight start point:
• If the FL value is less than FL100, JetPlan automatically considers the ad

hoc airport as a POD or POA and includes Taxi-Out and Taxi-In Fuel (from
the flight plan request or from the CADB record), and Minimum Departure
Fuel, Minimum Hold Fuel, and Minimum Alternate Fuel in the CADB.
• If the FL value is FL100 or more, JetPlan automatically considers the ad hoc
airport as a geographical location at a specific altitude to be used for in-
flight starts. In this case, the system ignores Taxi-Out and Taxi-In Fuel
(from the flight plan request or from the CADB record), and Minimum
Departure Fuel, Minimum Hold Fuel, and Minimum Alternate Fuel in the
CADB.
As a workaround, if you want to use an in-flight start point at a flight level below 10,000 feet,
change the CADB record for the aircraft in the request, removing the Taxi-Out and Taxi-In
Fuel, Minimum Departure Fuel, Minimum Hold Fuel, and Minimum Alternate Fuel values.
Otherwise, JetPlan automatically includes these values in the flight plan calculation
The following are examples of an ad hoc airport and an in-flight start point defined by an ad
hoc airport location.
Example:
The following entry includes an ad hoc airport, with a field elevation of 5,000 feet. Because
the FL value is less than 10,000 feet, JetPlan considers this ad hoc entry an airport and not an
in-flight start point.
02 POD KXXX,4136,10409,FL050
Example:
The following example includes an ad hoc airport used to define the geographical location of
the in-flight start point, followed by an in-flight start altitude of 35,000 ft. Because the FL
value is at least 10,000 feet, JetPlan considers this ad hoc entry an in-flight start point.
02 POD KXXX,4136,10409,FL350

82
Stored Airports as In-Flight Start Points

To use an airport stored in the Navigation Database or Generic Airport Database as an in-flight
start point, enter its ICAO or IATA identifier on the POA or POD line. After the airport
identifier, use the FL option to enter the altitude of the in-flight start point.
To be considered an in-flight start point, the altitude must be 10,000 feet (FL100) or above. If
the FL is equal to or more than FL100, JetPlan ignores Taxi-Out and Taxi-In Fuel (from the
flight plan request or from the CADB record), and Minimum Departure Fuel, Minimum Hold
Fuel, and Minimum Alternate Fuel in the CADB. If the FL is under FL100, JetPlan considers
the point as a POD or POA rather than an in-flight point and includes stored or ad hoc taxi-in
and out fuel and CADB minimum fuel values in the calculation.
As a workaround, if you want to use an in-flight start point at a flight level below 10,000 feet,
change the CADB record for the aircraft in the request, removing the Taxi-Out and Taxi-In
Fuel, Minimum Departure Fuel, Minimum Hold Fuel, and Minimum Alternate Fuel values.
For more information, see “About Flight Level (FL) and Ad Hoc Airports” on page 80.
Example:
For airports stored in the JetPlan Navigation Database or the Generic Airport Database, enter
the ICAO or IATA identifier followed by the in-flight start altitude. Here, an in-flight start is
applied at Pendleton (KPDT) at 39,000 ft.
02 POD KPDT,FL390
NAVAIDs as In-Flight Start Points

Enter the NAVAID on the POD or POA line, followed by the altitude of the in-flight start
point.
Example:
To specify a NAVAID that is collocated at an airport, use the ARINC 424 alphanumeric
method of identification. Here, the in-flight start begins at the Pendleton VOR, K1, using a
flight level of 37,000 ft.
02 POD PDT,K1,FL370
Example:
You can also specify a NAVAID that is located over some known route structure, such as an
organized track structure (OTS). Use the ARINC 424 alphanumeric method of identification
for the NAVAID. Here, an in-flight start is applied using the waypoint, BILLO, from the
Hawaiian Track structure R-464 at an altitude of 36,000 ft.
02 POD BILLO,P,FL360

83
Running In-Flight-Start ETP Flight Plans

This section describes the In-Flight Start flight plan with an engine-out cruise mode. Two
techniques exist to output one engine-out and two engine-out performance data. The first
technique invokes the Driftdown option. (For more information, see Chapter 22, “Overwater
Driftdown and Terrain Analysis.”) The second technique requires an In-flight Start flight plan.
NOTE JetPlan considers a one engine-out ferry flight plan as a normal plan, using
an aircraft data file with one engine-out climb and cruise data. JetPlan has many
corporate and transport generic aircraft data files with one engine-out data. JetPlan
also has some transport generic aircraft data files with two engine-out data.
The following steps illustrate how to run optimized In-Flight Start flight plans from the ETP to
the rearward and forward ETP airports.

84
To run an In-flight Start ETP plan

1. Run a flight plan from the POD to the POA, specifying ETP airport pairs
that meet operational requirements (for example, weather, NAVAID
availability, and runway length). The following inputs are representative of
a flight plan from KJFK to EGLL using sequential ETP airports.
NOTE Items with an asterisk are not required if a CADB record is used (for
example, $345/).
Example:
01 OPTIONS FP
02 POD KJFK/CYHZ/CYYR/BIKF/EINN,TX1200
03 POA EGLL
06 ROUTE P//P
07 HOLD,ALTERNATE/DIST 30,EGSS
08 ETD 0200
09 PROFILE I
10 A/C TYPE/REGN D30M/N12345 or CADB entry $345/
11 CRUISE MODE M82,M82
12 PRFM INDEX F *
13 OPERATIONAL WT 270000 *
14 PAYLOAD 75000
17 MAX FUEL 243000 *
18 CLIMB FUEL,TIME,DIST *
19 DESCENT FUEL,TIME,DIST *
2. From this flight plan, you can determine the following items for the ETP in-
flight start flight plans:
• The ETP coordinates constitute the POD (in-flight start point).
• The POD elevation is the cruise altitude at the ETP.
• The POA is one of the diversion airports.
• The in-flight start ETD is determined by adding the enroute time to
the ETP to the original flight plan ETD.

85
• Determine the POD fuel by subtracting the fuel burn to the ETP
from the takeoff fuel.
You must also specify the appropriate cruise mode. The most common one
engine-out cruise mode is 1LE (one less engine). The most common two
engines-out cruise mode is 2LE (two less engines).
3. Run the first in-flight start flight plan:
Example:
01 OPTIONS FP
02 POD ETPX,5028,03807,FL330
03 POA BIKF
06 ROUTE D//D
07 HOLD,ALTERNATE/DIST <ENTER>
08 ETD 0506 (original flight plan ETD plus ETE to the
ETP)
09 PROFILE I
10 A/C TYPE/REGN M1LE/N12345 or CADB entry $345/
11 CRUISE MODE 1LE (use the designated one or two
engine-out cruise mode)
12 PRFM INDEX F *
14 PAYLOAD 75000
16 POD OR POA FUEL D64500 (fuel remaining at ETP)
17 RESERVE 0 *
18 CLIMB FUEL,TIME,DIST BIAS *
19 DESCENT FUEL,TIME,DIST BIAS *

86
4. After receiving the first in-flight start flight plan, run the second in-flight
start flight plan, specifying the other diversion airport as the POA.
NOTE If a CADB file is used (for example, $345/), items with an asterisk are not
required.
Example:
01 OPTIONS FPR
02 POD ETPX,5028,03807,FL330
03 POA CYYR
06 ROUTE D//D
07 HOLD,ALTERNATE/DIST <ENTER>
08 ETD 0506
09 PROFILE I
10 A/C TYPE/REGN M1LE/N12345 or CADB entry $345/
11 CRUISE 1LE
12 PRFM INDEX F *
14 PAYLOAD 75000
16 POD OR POA FUEL D64500
17 RESERVE 0 *
18 CLIMB FUEL,TIME,DIST BIAS *
19 DESCENT FUEL,TIME,DIST BIAS *
Flight plans can be run for each ETP airport pair in a similar manner.
NOTE The generic aircraft data file, M1LE, is embedded in the D30M load,
supporting use of the Driftdown feature with the D30M load. The M1LE generic load is
selected since the D30M does not have a 1LE cruise mode. Jeppesen Customer
Service can provide a list of corporate and transport generic aircraft data files with
one engine-out and two engines-out cruise modes.

87
Taxi Fuel
Taxi Fuel
The following sections discuss options for entering information about taxi fuel.
Taxi Parameters in the Customer Databases

The CADB includes three parameters that affect the inclusion of taxi fuel:
• DT – POD taxi fuel weight

• AT – POA taxi fuel weight
• TX – Taxi fuel flow (pounds/hour)
When the CADB record is specified in the flight plan request, the DT and AT parameters
apply a specific amount of fuel (by weight) to your flight plan.
The CADB parameter TX affects flight planning only when a taxi time amount is specified.
Taxi time is specified through the parameters TO (AVE Taxi Out Minutes) and TI (AVE Taxi
In Minutes) in the Customer Airport Database. If the correct combination of aircraft and
airports is specified in your flight plan request, these parameters produce a taxi fuel amount in
the flight plan output.
The amount of fuel derived from the TX parameter in the CADB (together with the TO and TI
parameters in the Airport Database) overrides the DT and AT parameter values.
NOTE The CADB TX parameter also works in coordination with the taxi-in and taxi-
out data sets in the City Pair Fleet Database and the Airport Fleet Database. For
information, see Chapter 28, “Aircraft Fleet Database” and Chapter 34, “City Pair
Fleet Database.”

88
Taxi Fuel
Entering Taxi Fuel Directly in the Flight Plan Request

You can use the POD and POA command lines to add taxi fuel to your flight plan requests.
You can enter the taxi fuel value in weight or time.
NOTE Entering taxi fuel directly in the flight plan request overrides any parameter
setting in your customer databases.
NOTE Many different output formats provide separate taxi fuel information in the
fuel block summaries of flight plans. Other formats embed taxi fuel in other totals. If
you want taxi fuel totals output on a separate fuel summary line, you can change your
output format to one that does show this information. You can also have a taxi fuel
line added to your output format. Contact your Jeppesen account manager for more
information.
To enter the taxi fuel value in weight, enter the TX option on the POD or the POA line or both.
Include the weight value immediately after the option. Depending on your weight measure
preferences, the value you enter is in pounds or kilograms.
Example:
02 POD KLAS/KLAX/KSFO,TX1200
Explanation: Include 1200 pounds taxi-out fuel.
Example:
03 POA PHNL/PHTO/PHTO,TX400
Explanation: Include 400 pounds taxi-in fuel.
NOTE As a rule, JetPlan subtracts taxi-out fuel from the total fuel before takeoff.
JetPlan considers taxi-in fuel as extra fuel carried to the POA.
To enter the taxi fuel value in minutes, enter the TXT option on either the POD or POA line or
both. Include the time in minutes immediately after the option.
Example:
02 POD KSFO,TXT12
Explanation: Include 12 minutes of taxi-out fuel

89
Taxi Fuel
Example:
03 POA KMAN,TXT14
Explanation: Include 14 minutes of taxi-in fuel
Adding the Taxi-Out Value to the ETD

The TXA option enables you to add the taxi-out value to the ETD time specified in the flight
plan request. The ETD used in the flight plan calculation is then the taxi-out time plus ETD.
If you do not enter a taxi-out value in the flight plan request, JetPlan looks in the customer
databases for a taxi-out value to use. See “Taxi Parameters in the Customer Databases” on
page 88.
When TXA is specified and taxi-out is a non-zero value, the following information is added to
the RMK/ field in the filing strip: TAXI#####, where ##### is the taxi time in minutes (for
example, 30) or, if needed, in hours and minutes (0130).
To add the taxi-out time to the ETD in the flight plan request, type TXA on the POD line.
Example:
02 POD KSFO,TXA
03 POA KMAN
Explanation: These entries prompt JetPlan to add the taxi-out time to the ETD to determine the
actual ETD used in the flight plan computation. The taxi-out time is then added to the value
entered for the ETD. Because no taxi-in or taxi-out time is specified in the flight plan request,
JetPlan determines the values based on what is stored in the customer databases.
Example:
02 POD KSFO,TXT16,TXA
03 POA KMAN,TXT11
Explanation: These entries prompt JetPlan to add the taxi-out time (16 minutes) to the ETD to
determine the actual ETD to be used in the flight plan computation. A taxi-in time of 11
minutes is requested. The taxi-out and taxi-in time values entered on the flight plan request
override any taxi-in and taxi-out values stored in the customer databases.
Example:
02 POD KSFO,TXA
03 POA KMAN,TXT8

90
Taxi Fuel
Explanation: These entries prompt JetPlan to add the taxi-out time to the ETD to determine the
actual ETD to be used in the flight plan computation. A taxi-in time of eight minutes is
requested. Because no taxi-out time is specified in the flight plan request, JetPlan determines
the value based on what is stored in the customer databases. The taxi-out time is then added to
the value entered for the ETD. The taxi-in time entered on the flight plan request overrides any
taxi-in value stored in the customer databases.

91
Takeoff Alternate
Takeoff Alternate
Takeoff Alternate is an AIR OPS compliant feature that enables you to specify one alternate in
IATA or ICAO format on the POD command line.
Example:
02 POD EGLL,ALT=LGW
- or -
02 POD EGLL,ALT=EGKK
To validate whether the entered takeoff alternate meets AIR OPS requirements, JetPlan:
• Determines the total distance from the POD to the takeoff alternate. To
perform this determination, JetPlan uses a sequential checklist. JetPlan first
searches in the Alternate Database (which stores either the Route Database
distance or the user-specified distance), and then JetPlan performs a great
circle distance check.
• Determines if the total distance from the POD to the takeoff alternate is less
than the maximum allowable distance based on the engine-out true airspeed
(EA1) specified in the ETP section of the CADB.
• Determines the value of the ETOPS approval time parameter (ET) in the
ETOPS section of the CADB. The ET parameter value implements a time
factor of one or two hours. A blank or zero value provides for a one-hour
factor at engine-out cruise speed. A value of 60 minutes to 180 minutes
provides for a two-hour factor at engine-out cruise speed.
• Displays the takeoff alternate data (format-dependent).
• Prints a warning message at the bottom of the flight plan when a takeoff
alternate is not specified or is not within the maximum allowable distance.
• Uses the engine-out flight level (EM1) value set in the ETP section of the
CADB.

92
Specifying a Fuel Price
Specifying a Fuel Price

You can specify fuel price on the 02 POD command line for use in Cost Index flight plans,
using the following syntax: FP=$$$.$$. JetPlan outputs this value as DOLLARS COST in the
flight plan. When applying the specified fuel price, JetPlan uses the fuel currency (FC) value
set in the airport record in the Customer Airport Database (CAPDB).
Example:
02 POD KEWR,FP=4.90
Any fuel price value entered on the 02 POD command line overrides all customer database
fuel price values and any fuel price value entered with the parameter M on the 12 PRFM
INDEX command line. For complete information on the order of precedence for fuel price in
Cost Index plans, see “Order of Precedence” on page 345 in Chapter 9, “Profile Commands.”

93
C HAPTER 4
Restricted Area
Commands
Restricted Area Commands
Overview
Overview
JetPlan allows you to define an area along the intended, or generally expected route of flight as
restricted airspace through the use of the RST option and Restricted Area command line.
Application of this feature forces JetPlan to generate a route that avoids the defined restriction.
A restricted area can be defined at the time of flight plan creation or predefined for future and
continued use.
There are two types of user-defined restricted areas: delineated boundary and common route
structure element. A delineated boundary is created by the demarcation of a region through the
use of coordinate values. Elements of common route structure that can be used to define
restricted areas include FIR/UIR boundaries, airways, and navaids.
In addition, delineated boundary restricted areas can be stored in the Restricted Area Database
for use at any time, as flight requirements dictate (see Chapter 40, “Restricted Area
Database.”).
NOTE The restricted area functionality invoked by the RST option command and
the 4D Avoid and Alert restrictive airspace functionality are two separate and distinct
features. For information on the 4D Avoid and Alert feature, see Chapter 5, “4D Avoid
and Alert Restrictive Airspaces.”

97
Using the RST Option

To apply a restricted area input to a flight plan, you must first invoke the RST option in the
flight plan request. The RST option is entered on the 01 OPTIONS command line anywhere
after the FP command (for example, FP,RST or FP,LP,AW,RST).
When entered without any further qualifying information on the Options command line, the
RST option tells JetPlan to prompt you for a restricted area input later (on the 05
RESTRICTED AREA line). At this prompt, you can enter either a delineated boundary, a
common route structure element, or a record from the Restricted Area Database. If needed,
you can even enter multiple inputs (excluding the delineated boundary type).
Example:
01 OPTIONS FP,LP,RST
02 POD EDDF
03 POA LIRA
05 RESTRICTED AREA (Single Input or Multiple Inputs)
06 ROUTE J
You can also enter a restricted area input on the Options command line immediately after the
RST option. However, this input must be of the predefined variety (database file name or
common route structure element), and only one input is allowed here. You cannot enter a
delineated boundary type of input on the Options command line. To add a restricted area input
on the Options command line, enter RST, followed by a slash (/) and the file or element input.
The slash after RST is required (RST/XAVD1).
Example:
01 OPTIONS FP,LP,RST/XAVD01

98
Delineated Boundaries
There are two techniques for defining delineated boundary restricted areas. The first is to
demarcate a polygonal area using coordinates as corner points. The other is to define a circular
region by providing a coordinate and a radius distance. In either case, each coordinate must be
expressed as a number set with latitudinal and longitudinal values.
User-de lineated Restricted Are as
Polygonal Areas Circu lar Area
The following rules apply to restricted area inputs of the delineated boundary type:
• A delineated boundary can be either a polygonal or circular area.

– A polygonal area is composed of three to five sets of coordinates.
– Coordinates must be input in a manner similar to connecting points
on a piece of paper, with no lines crossing and the area enclosed.
– A circular area is composed of a single coordinate followed by a
radius distance. The radius must be specified in nautical miles and
have the letter, R, appended.
– All coordinate sets must be expressed as four-digit latitude and five-
digit longitude values. South latitude and East longitude entries
must be prefixed with a minus sign (-), or the letters “S” and “E”
respectively. A prefix can be omitted for the North latitude and
West longitude entries (these hemispheres are accepted as default).
However, you can prefix these coordinates with a plus sign (+), or
the letters “N” and “W” respectively.
Example:
Explanation: The restricted area is the four-sided polygon created by the coordinate sets
identified.
01 OPTIONS FP,CS/JD123,CPT/J SMITH,DSP/D JONES,RST

02 POD MMUN
03 POA LFPG
05 RESTRICTED AREA 5700,05000,5700,01000,4800,02000,4800,05000

99
Example:
Explanation: The restricted area is a one hundred mile radius around the coordinate point
identified.

02 POD MMUN
03 POA LFPG
05 RESTRICTED AREA N5700,W01000,100R
Restrictions By Route Structure Element

There are three elements of route structure which can be used to define a restricted area:
FIR/UIR boundaries, airway segments, and navaids. Using a FIR or UIR as a restricted area
input allows you to avoid an entire airspace region, while specifying an airway segment or a
NAVAID as a restricted area allows you to avoid the identified route structure element.
When using a route structure element as a restricted area input you must explicitly identify the
element by prefixing the input with a code that identifies the type of element you are entering.
The following table shows each element type, its required prefix, and a description of the input
value.
Table 4-1 Route Structure Elements
Element Prefix Input Description

FIR/UIR XIR= Charted FIR/UIR
identifier
Ex. XIR=LIMM
Airway Segment AW= Nav1 AirwayID Nav2

Ex. AW=DQO J75 GVE
Navaid CP= Charted NAVAID

identifier
Ex. CP=KOKSY or
CP=CTL
Route structure elements as restricted area inputs are typically entered on the Options
command line, immediately after the RST option (RST/prefix=element input). While this
method saves time, it does limit the input to only one restricted area entry.
You can enter route structure elements as inputs on the Restricted Area command line. This
method allows you to enter multiple restricted area inputs if needed.

100
FIR/UIR Examples
The examples below demonstrate the use of airspace regions as restricted area inputs. Two
examples are given; one shows a restricted area input on the Options command line, the other
shows a restricted area input on the Restricted Area command line.
NOTE Extraneous command line inputs are omitted for brevity (for example, POD,
POA, and so on).
Example:
Explanation: (Options command line) This example defines the Switzerland UIR boundary as
the area to be avoided.
01 OPTIONS FP,RCC,CS/JD123,CPT/S SMITH,DSP/R JONES,RST/XIR=LSAS
Example:
Explanation: (Restricted Area command line) This example defines the Milan, Italy UIR
boundary as the area to be avoided.

02 POD EDDF
03 POA HECA
05 RESTRICTED AREA XIR=LIMM
06 ROUTE J
Airway Examples
When defining an airway restriction, you must define an airway segment. This is done by
entering a begin and an end point on the airway you wish to avoid using charted NAVAID
identifiers. Enter the option, AW=, followed by the NAVAID that marks the start of the
airway segment, the airway identifier/name, and finally the NAVAID that marks the end of the
airway segment. Separate each identifier with a blank space. Do not enter a comma between
these entries.

101
The examples below demonstrate the use of airways as restricted area inputs. Two examples
are given; one shows a restricted area input on the Options command line, the other shows a
restricted area input on the Restricted Area command line.
POA, and so on).
Example:
Explanation: (Options command line) This example defines the airway segment between
Konan and Nattenheim on UL607 as restricted. Notice that a blank space separates the
NAVAID and airway identifiers, not a comma.
01 OPTIONS FP,RST/AW=KONAN UL607 NTM

06 ROUTE J
Example:
Explanation: (Restricted Area command line) This example defines the airway, UB4, between
Rolampont and Chatillon, as restricted.
01 OPTIONS FP,RST
05 RESTRICTED AREA AW=RLP UB4 CTL
06 ROUTE J
Airway Altitude Restrictions

You can restrict certain altitudes on a particular airway by including the altitude restriction
option on your airway restriction input. This type of restriction instructs JetPlan to test two
routes (generate two flight plans). The first flight plan uses the route that includes the defined
airway segment, but at an altitude above or below the altitude restriction. The second plan uses
the route that avoids the defined airway segment altogether. JetPlan prints the plan that
provides the optimum results (based on your preferred performance index: fuel, time, or
money).
To add an altitude restriction to the airway restriction option, enter a slash (/) at the end of the
defined airway restriction, followed by the prefix, FL=, and the altitude range you wish to
avoid. The altitude range input follows standard flight level syntax, except that a dash ( - )
separates the two flight level inputs rather than a comma.

102
Example:
Explanation: This example defines an airway restriction on UB4 (same as previous example),
but with a specific altitude restriction (330 to 370). The possible outcome of this input is a plan
that includes the airway, UB4, with a flight level above or below the specified avoid range; or
a plan that avoids UB4 between the points, RLP and CTL.
01 OPTIONS FP,RST
05 RESTRICTED AREA AW=RLP UB4 CTL/FL=330-370
06 ROUTE J
Checkpoint Examples
The examples below demonstrate the use of checkpoints as restricted area inputs. Two
examples are given; one shows a restricted area input on the Options command line, the other
show a restricted area input on the Restricted Area command line.
POA, and so on).
Example:
Explanation: (Options command line) This example defines the Frankfurt NAVAID, FFM, as
a restricted overfly point.
01 OPTIONS FP,RST/CP=FFM
06 ROUTE J
Example:
Explanation: (Restricted Area command line) This example defines the Honiley NAVAID,
HON, as a restricted overfly point.
01 OPTIONS FP,RST
05 RESTRICTED AREA CP=HON
06 ROUTE J

103
Customer Route Database Considerations

When using a Customer Route Database (CRDB) file as your route input, be careful not to
specify a restricted area input that conflicts with the stored route.
If you are going to create a flight plan request in which a CRDB file and a restricted area are
both applied as the route input and the route restriction input respectively, there is a possible
conflict to consider. A problem arises when a route structure element within the CRDB file (a
NAVAID or airway) matches a route structure element named as a restricted area input.
The conflict is the opposing logic between the two inputs you are supplying JetPlan. On the
one hand, you are saying, “give me the route stored in this CRDB file”. On the other, you are
saying “be sure to avoid this route structure,” even if it is part of the stored route data. If the
element you wish to avoid is part of the route you are supplying JetPlan, an error occurs.
For example, consider the following inputs.
Example:
01 OPTIONS FP,RST/CP=FFM
06 ROUTE RT/RTE1
If the CRDB input, RTE1, includes the checkpoint you wish to avoid, FFM, an error message
is generated.
This is due to the fact that there is no dynamic route selection when using a CRDB file as your
route input. JetPlan, in this case, can only deliver a route based on the information stored in the
CRDB file. If the stored information includes the NAVAID or airway you wish to avoid, then
an obvious conflict exists.
The same can be said for FIR/UIR restricted area inputs too. If the submitted route file is
designed to traverse the FIR/UIR named as a restricted area, an error occurs.
To alleviate this type of conflict, you must remove the restricted area input or select another
CRDB file; one that does not contain the named restriction.
NOTE When using a restricted area input and the Route command line input,
RT/ALL, the same conflict is possible. However, if the file selected as the optimum
route contains the defined restriction (the route element you wish to avoid), only a
warning banner is produced (no error message is generated).

104
Applying Restricted Area Database Files

Restricted Area Database files can be applied to a flight plan request (standard or scheduled)
on either the Options command line or the Restricted Area command line.
NOTE This section does not consider the creation or maintenance of Restricted
Area Database files. To create or manage such files, see the Customer Restricted
Area Database chapter.
If you wish to enter a Restricted Area Database file name after RST on the Options command
line, you can enter only one. Be sure to separate the option from the input value with a slash
(/).
Example:
Explanation: A single Restricted Area Database file name is entered after the RST option on a
standard flight plan request.
01 OPTIONS FP,RCC,CS/JD123,CPT/S SMITH,DSP/R JONES,RST/XNAT1
Example:
Explanation: A single Restricted Area Database file name is entered after the RST option on a
schedule flight plan request.
01 OPTIONS SC,FLT,JFK-LHR,DRFT,RST/XNAT1
You can enter one or more database file names on the Restricted Area command line.
NOTE For multiple inputs, see the next section below.
Example:
Explanation: A single Restricted Area Database file name is entered on the Restricted Area
command line.
01 OPTIONS FP,RCC,CS/JD123,CPT/S SMITH,DSP/R JONES,RST

02 POD MMUN
03 POA LFPG
05 RESTRICTED AREA XNAT1

105
Applying Multiple Restricted Areas

If you wish to enter more than one restricted area input in a flight plan request, you must use
the Restricted Area command line. Multiple inputs cannot be entered on the Options command
line.
Multiple restricted area entries can include any combination of database file names and route
structure elements. Each entry in a multiple input must be separated by a comma.
NOTE You cannot enter more than one delineated boundary input (the type that is
defined by coordinate sets).
Example:
Explanation: Multiple database file names are entered on the Restricted Area command line.
01 OPTIONS FP,RST
02 POD MMUN
03 POA LFPG
05 RESTRICTED AREA XAVD1,XAVD2
Example:
Explanation: Multiple inputs, including a FIR/UIR boundary, are entered on the Restricted
Area command line.
01 OPTIONS FP,RST
02 POD MMUN
03 POA LFPG
05 RESTRICTED AREA XIR=LECM,XAVD1,XAVD2
NOTE You can enter up to five FIR entries.
Example:
Explanation: Multiple airway/altitude restrictions are entered on the Restricted Area command
line.
01 OPTIONS FP,RST
05 RESTRICTED AREA AW=ONL J114 SNY/FL=200-370,AW=AVE J6 HEC/FL=310-
370
06 ROUTE J

106
Omitting a Restricted Area Input
Omitting a Restricted Area Input

When working with stored or previously computed flight plans that contain restricted area
inputs, you can enter the option, NORST, on the Options command line to prevent or cancel
the application of that input. In other words, when computing or recomputing a plan that
includes a restricted area input – database file name, route structure element, or delineated
boundary – you can supersede that input by adding the NORST option.
The NORST option can be entered on the Options command line after the FP, FPR, LD or
LDR commands. With the NORST option, the 05 RESTRICTED AREA prompt is
suppressed. If for some reason this does not suppress the 05 RESTRICTED AREA prompt, or
if you forget to enter this option, you can enter NONE as your input at the prompt and
continue to the next question.
Example:
01 OPTIONS FPR,NORST
or
01 OPTIONS FP
02 POD MMUN
03 POA LFPG
05 RESTRICTED AREA NONE

107
C HAPTER 5
4D Avoid and Alert

Restrictive Airspaces
4D Avoid and Alert Restrictive Airspaces
Overview
Overview
NOTE The 4D Avoid and Alert restrictive airspace functionality and the restricted
area functionality are two separate and distinct features. The restricted area
functionality is invoked by the RST option. For information on the RST option
command, see the “Restricted Area Commands” chapter in the Jetplan User Manual.
This chapter provides information on the JetPlan 4D Avoid and Alert feature. This feature
governs JetPlan’s behavior when it is:
• Determining an optimized route and vertical profile

• Providing airspace incursion alerts for a user-entered route and its computed
vertical profile
• Providing airspace incursion alerts for a user-entered customer route and its
computed vertical profile
The aspects of a restrictive airspace that most impact route optimization and route validation
are its vertical and lateral boundaries, operational times, and avoidance level. Three avoidance
levels are possible: Ignore, Notify, and Avoid. These are discussed in detail in the following
sections.
Prerequisites
The following prerequisites exist for the 4D Avoid and Alert feature:
Restrictive A restrictive airspace alert is provided for each segment of the route
Airspace Alerts of a completed flight plan that is determined to incur at least one
restrictive airspace with an avoidance level of Avoid or Notify. To
display such alerts, you need either a flight plan format that supports
alerts or an interface that automatically displays them. For more
information on these requirements, contact your Jeppesen account
manager.
Customer As mentioned above, the JetPlan 4D Avoid and Alert feature requires
Controlled Avoid the existence of customer records—both in the CCAA Database and
and Alert (CCAA) in source restrictive airspace databases. These databases are discussed
Database in detail in the following sections.

111
Overview
The remainder of this chapter covers the following topics:
The Customer These database records contain information relative to the avoidance
Controlled Avoid levels of restrictive airspaces. The CCAA Database is a prerequisite
and Alert (CCAA) for the 4D Avoid and Alert feature. See “Understanding the CCAA
Database and the Database” on page 113.
source restrictive
airspace
databases
The JetPlan 4D These options invoke the restrictive airspace avoid and alert
Avoid and Alert functionality. See “Working with the 4D Avoid and Alert Flight Plan
flight plan options Options” on page 124.

112
Understanding the CCAA Database

NOTE This section presents an overview of the CCAA Database and how it
supports the Avoid and Alert flight plan options. For complete information on creating
and maintaining CCAA Database records, see the JetPlan.com Help file for the CCAA
Database.
The CCAA Database allows users to create and manage records that reference pre-defined
restrictive airspace records residing in several different source restrictive airspace databases.
The pre-defined restrictive airspace records contain data originating in sources such as an
ARINC 424 extract, customer-provided source, or an online electronic service (for example,
organized track updates or customer or vendor-provided turbulence forecasts). For this reason,
these databases are referred to as “source” restrictive airspace databases. Records in the source
restrictive airspace databases are referred to as “referenced” records, and records in the CCAA
Database are referred to as “referencing” records.
While the CCAA Database does not allow you to alter restrictive airspace records stored in
source restrictive airspace databases, you can set and modify the following two important
parameters in the referencing CCAA Database records:
Avoidance Level JetPlan uses the avoidance level to determine how to treat the
referenced restrictive airspace when computing a flight plan—as an
Avoid or Notify airspace or as an airspace that can be ignored.
Special Customer The SCA Type is a unique, user-defined value. You can use the SCA
Airspace Type Type to invoke an ad hoc override of a restrictive airspace’s
(SCA Type) avoidance level.
Application of the avoidance level and SCA Type by the JetPlan 4D Avoid and Alert feature is
discussed in more detail in the following paragraphs. For detailed descriptions of these two
parameters, see the JetPlan.com Help file for the CCAA and User-Defined Restrictive
Airspace Databases.

113
Creation of the Initial CCAA Database
NOTE For step-by-step procedures on creating and maintaining the CCAA

Database, see the JetPlan.com Help file.
A customer-appointed authorized user is required to invoke a special procedure to initially

create/reconcile the customer’s CCAA Database. This procedure both creates the CCAA
Database and reconciles it to each of the source restrictive airspace databases.
The CCAA Database create/reconcile procedure must be performed before the JetPlan 4D
Avoid and Alert options can be used. The create/reconcile procedure only needs to be invoked
once. Afterwards, the CCAA Database is automatically updated and reconciled each time one
of the source restrictive airspace databases is updated. However, in the event of loss or
corruption of either the CCAA Database or one or more of the source restrictive airspace
databases, the authorized user can always perform the create/reconcile procedure to ensure
that the CCAA Database is properly constituted.
JetPlan.com provides a convenient way to perform the CCAA Database create/reconcile

procedure. For instructions, see the JetPlan.com Help file. For users of the JetPlan command-
line interface, the command for invoking the CCAA create/reconcile procedure is as follows:
01 OPTIONS CAA,GEN

114
Understanding the Source Restrictive Airspace

Databases
As discussed in the previous section, the CCAA Database is initially populated and
subsequently updated through automatic reconciliation with the source restrictive airspace
databases. The following paragraphs provide more information about these databases.
Restrictive Airspace Terminology

The following terms are used throughout this chapter to describe types of restrictive airspace:
Special Use A government-managed airspace stored in the Generic Restrictive

Airspace (SUA) Airspace Database.
User-Defined A user-defined airspace stored in the User-Defined Restrictive

Airspace Airspace Database.
Organized Track An airspace formed around an organized track and stored in the
Airspace Organized Track Restrictive Airspace Database.
Jeppesen An airspace for which there is forecasted turbulence.

Turbulence
Airspace
Flight Information An airspace formed by the boundaries of a FIR or UIR.

Region/Upper
Information
Region Airspace
(FIR/UIR)
Geopolitical An airspace formed by the boundaries of a country.

Country Boundary
Avoid-Level An airspace for which the referencing CCAA Database record has an
Airspace avoidance level of Avoid.

115
Notify-Level An airspace for which the referencing CCAA Database record has an
Airspace avoidance level of Notify.
Ignore-Level An airspace for which the referencing CCAA Database record has an
Airspace avoidance level of Ignore.
Source Restrictive Airspace Databases

The following source restrictive airspace databases are referenced by records in the CCAA
Database.
NOTE Only the User-Defined Restrictive Airspace Database can be modified. The
other databases are read-only.
Generic Restrictive Airspace Database

The Generic Restrictive Airspace Database is included in the suite of JetPlan navigational
databases provided to you by Jeppesen. This database contains a standard, customer-
independent set of restrictive airspaces, each of which is constructed based on a specific
government-defined Special Use Airspace (SUA). All SUAs are extracted from the ARINC
424 file that is provided by Jeppesen’s NavData service every 28 days. These extracts are
processed to produce and store airspaces in the Generic Restrictive Airspace Database.
Updates
The Generic Restrictive Airspace Database is updated by Jeppesen every 28 days per the
ARINC 424 28-day cycle. For flight planning purposes, you have access to the current version
of this database and all subsequent updates to it as soon as creation of the initial CCAA
Database has been completed. From that point on, each update to the Generic Restrictive
Airspace Database is immediately followed by an automatic reconciliation of the CCAA
Database.

116
Organized Tracks Restrictive Airspace Database

The Organized Tracks Restrictive Airspace Database is included in the suite of JetPlan
navigational databases provided to you by Jeppesen. This database contains Organized Tracks
restrictive airspaces built around the following organized track structures:
• North Atlantic tracks (NATS)

• Pacific tracks (PACOTS) – includes the Northern Pacific tracks as well as
the Flex tracks for Hawaii to and from Japan
• Australian tracks (AUSOTS)
Updates
Jeppesen updates the Organized Tracks Restrictive Airspace Database periodically over a 24-
hour period each day as it receives and processes track updates from the appropriate
government agencies. For flight planning purposes, you have access to the current version of
this database and all subsequent updates as soon as creation of the initial CCAA Database has
been completed. From that point on, each update to the Organized Tracks Restrictive Airspace
Database is immediately followed by an automatic reconciliation of the CCAA Database.
Turbulence Restrictive Airspace Database

This customer-specific database contains restrictive airspaces based on forecasted turbulence.
Data such as lateral and vertical boundaries and intensity levels that define any given
forecasted turbulence restrictive airspace must be provided by a system operated by the
customer or by a vendor on behalf of the customer.
Updates
Customer forecasted turbulence data is received by an offline Jeppesen process that initially
populates the Turbulence Restrictive Airspace Database and then maintains it 24 hours a day,
seven days a week. For flight planning purposes, you have access to the current version of this
database and all subsequent updates as soon as creation of the initial CCAA Database has been
completed. From that point on, each update to the Turbulence Restrictive Airspace Database is
immediately followed by an automatic reconciliation of the CCAA Database.
NOTE Only customers that provide their own data defining forecasted turbulence
airspaces have access to the Turbulence Restrictive Airspace Database. Contact
your Jeppesen account manager for more information.

117
FIR/UIR Restrictive Airspace Database

The FIR/UIR Restrictive Airspace Database is included in the suite of JetPlan navigational
databases provided to you by Jeppesen. This database contains FIR/UIR restrictive airspaces
built around FIR/UIR boundaries.
Updates
FIR/UIR data is extracted from the ARINC 424 file that is provided by Jeppesen’s NavData
service every 28 days. The data is normally not modified during mid-cycle (non 28-day)
updates, but can be if needed. For flight planning purposes, you have access to the current
version of this database and all subsequent updates as soon as creation of the initial CCAA
Database has been completed. From that point on, each update to the FIR/UIR Restrictive
Airspace Database is immediately followed by an automatic reconciliation of the CCAA
Database.
Geopolitical Country Restrictive Airspace Database

The Geopolitical Country Restrictive Airspace Database is included in the suite of JetPlan
navigational databases provided to you by Jeppesen. This database contains airspaces defined
by geopolitical country boundaries.
Updates
Geopolitical country boundary data is derived from Jeppesen’s NavData. For flight planning
purposes, you have access to the current version of this database and all subsequent updates as
soon as creation of the initial CCAA Database has been completed. From that point on, any
update to the Geopolitical Country Restrictive Airspace Database is immediately followed by
an automatic reconciliation of the CCAA Database.
User-Defined Restrictive Airspace Database

This database contains restrictive airspaces that are specific to a customer. A customer-
authorized user can create and change airspaces in the User-Defined Restrictive Airspace
Database by using the User-Defined Restricted Areas options on the CCAA Database page in
JetPlan.com.
For information on creating User-Defined Restrictive Airspace Database records, see the
JetPlan.com Help file.

118
Understanding the Contents of CCAA Database

Records
This section covers the following elements of CCAA Database records:
• The RSA Tag

• The SCA Type
• Default avoidance levels
The RSA Tag

A given CCAA Database record is uniquely defined by its Restrictive Airspace (RSA) Tag.
The RSA Tag is made up of (from left to right):
• The ICAO code (two characters)

• The restrictive type (one character)
• The restrictive airspace designation (up to ten characters)
• The multiple code (optional – one character)
For example, WXUHURIRENE_1 is an RSA Tag, where WX is the ICAO code, U is the
restrictive type, HURIRENE is the restrictive airspace designation, and 1 is the multiple code.
The RSA Tag in a CCAA Database record acts as a reference to an airspace that has the same
tag and that is stored in one of the source restrictive airspace databases. Interfaces such as
JetPlan.com take advantage of this relationship by enabling you to view a particular CCAA
Database record and also the source restrictive airspace record that it references. You can view
any of the parameters stored for the referenced airspace, such as vertical and lateral
boundaries, operational times, start and end effectivity, and so on.
The ICAO Code in the RSA Tag

For a CCAA Database record that references an SUA record in the Generic Restrictive
Airspace Database, the ICAO code portion of the RSA tag is the actual ICAO code that
defines the region within which that SUA resides. However, for a CCAA Database record that
references a record in one of the other source restrictive airspace databases, the ICAO code in
the RSA Tag is an arbitrary 2-letter code that represents the airspace type.

119
To identify the airspace type for records in the Organized Track, Turbulence, FIR/UIR, and
Geopolitical Country Restrictive Airspace Databases and for their corresponding records in
the CCAA Database, Jeppesen inserts the following codes into the ICAO portion of the RSA
tag:
• OT – For records in the Organized Track Restrictive Airspace Database and

their corresponding CCAA Database referencing records
• JT – For records in the Turbulence Restrictive Airspace Database and their
corresponding CCAA Database referencing records
• JF – For records in the FIR/UIR Restrictive Airspace Database and their
corresponding CCAA Database referencing records
• CB – For records in the Geopolitical Country Restrictive Airspace Database
and the corresponding CCAA Database referencing records.
For user-defined airspaces, the user decides how to define the ICAO code portion of the RSA
tag. For instance, in the user-defined record with the RSA tag WXUHURIRENE_1, the
airspace type is WX, which the user has chosen to convey the fact that the referenced airspace
is based on weather activity.

120
About the Default SCA Type and Default Avoidance Level

As discussed above, each CCAA Database record also contains an SCA Type and an
avoidance level. Three avoidance levels are possible: Ignore, Notify (Alert), and Avoid.
When the CCAA Database is first established, each of its records is assigned an initial, source-
dependent default SCA Type and also a default avoidance level. The methods used to
determine these default values vary, depending on which source restrictive airspace database a
CCAA Database record is referencing. The following table shows how the default SCA Types
and avoidance levels are determined.
Table 5-1 Default SCA Types and Avoidance Levels in CCAA DB Records
Referenced Source
Database Records Default SCA Types Default Avoidance Levels
Generic Restrictive Airspace CCAA Database records that CCAA Database records that
Database records (SUAs) reference SUA records in the reference SUA records in the
Generic Restrictive Airspace Generic Restrictive Airspace
Database have a blank default Database have a default avoidance
SCA Type value. level value determined by an
automatic mapping between the
restrictive airspace type and
avoidance level. This mapping is
controlled by preferences stored in
the JetPlan Customer Preference
Database.
For example, for a given customer,
a part of the mapping might be that
all SUAs for which the restrictive
type is R are mapped to the Avoid
avoidance level. For more
information on the mapping of
restrictive type to avoidance level
in your Customer Preference
Database, contact your Jeppesen
account manager.
Organized Tracks Restrictive CCAA Database records that The default avoidance level for
Airspace Database records reference records in the Organized CCAA Database references to
Tracks Restrictive Airspace NAT and PACOTS restrictive
Database have a default SCA Type airspaces is Avoid.
value of NAT for NATs, PAC for The default avoidance level for
PACOTS, and AUS for AUSOTS. CCAA Database references to
AUSOTS restrictive airspaces is
Notify.

121
Table 5-1 Default SCA Types and Avoidance Levels in CCAA DB Records (continued)
Referenced Source
Turbulence Restrictive Airspace CCAA Database records that CCAA Database records that
Database Records reference records in the reference records in the
Turbulence Restrictive Airspace Turbulence Restrictive Airspace
Database have a default SCA Type Database have a default avoidance
value of JTA. level value determined by the
avoidance level.
For Turbulence Restrictive
Airspace Database records, the
restrictive airspace type is always
set to the turbulence intensity
level, which is a number between 0
and 9.For information on the
mapping of airspace-type to
avoidance-level in your Customer
Preference Database, contact your
FIR/UIR Restrictive Airspace Each CCAA Database record that The default avoidance level for
Database Records references records in the FIR/UIR CCAA Database references to
Restrictive Airspace Database has FIR/UIR restrictive airspaces is
a default SCA Type value of one of Ignore. To use these restrictive
the following: airspaces in CCAA, CCAAN,
• FIR – Flight information CCAAQ, and CCAAF flight plans,
region (lower level) change the default avoidance level
in the appropriate CCAA Database
• UIR – Upper information
record to Avoid or Notify.
region
• F/U – Both upper and lower
information region
Geopolitical Country Restrictive Each CCAA Database record that The default avoidance level for
Airspace Database Records references records in the CCAA Database references to
Geopolitical Country Restrictive Geopolitical Country restrictive
Airspace Database has a default airspaces is Ignore. To use these
SCA Type that corresponds to the restrictive airspaces in GCAN and
ISO code for the country—for GCAA flight plans, change the
example, GB for the United default avoidance level in the
Kingdom, BE for Belgium, BD for appropriate CCAA Database
Bangladesh, and so on. record to Avoid or Notify.

122
Table 5-1 Default SCA Types and Avoidance Levels in CCAA DB Records (continued)
Referenced Source
User-Defined Restrictive Airspace CCAA Database records that CCAA Database records that
Database Records reference records in the User- reference records in the User-
Defined Restrictive Airspace Defined Restrictive Airspace
Database have a blank default Database have a default avoidance
SCA Type value. level value determined by an
avoidance level. This mapping is
controlled by preferences stored in
the JetPlan Customer Preference
Database.
For example, for a given customer,
a part of the mapping might be that
all user-defined restrictive
airspaces for which the restrictive
type is U are mapped to the Ignore
avoidance level. For more
information on the mapping of
airspace type to avoidance level in
your Customer Preference
Database, contact your Jeppesen
account manager.
Modifying the SCA Type and the Avoidance Level
NOTE For step-by-step procedures on modifying CCAA Database records, see the
JetPlan.com Help file.
An authorized user can, at any time, set or change the value for the SCA Type in a CCAA
Database record using JetPlan.com. This is significant because the SCA Type can be used to
override the avoidance level of certain airspaces on a specific flight plan request.
In addition, an authorized user can change the avoidance level in a CCAA Database record
using JetPlan.com. The avoidance level determines how JetPlan treats a restrictive airspace
with regard to optimizing and validating routes and vertical profiles and issuing alerts.
Once you change an avoidance level in a CCAA Database record, that avoidance level remains
unchanged when the associated airspace record in the source restrictive airspace database is
subsequently updated. The same concept applies to the SCA Type. For example, assume that
you have a CCAA Database record that has the RSA Tag K2R2601A and an avoidance level
of Avoid. This CCAA Database record references a source record with the same RSA Tag in

123
Working with the 4D Avoid and Alert Flight Plan Options
the Generic Restrictive Airspace Database. If you change the CCAA Database record’s
avoidance level to Notify and its SCA Type to MI, the avoidance level and the SCA Type in
the CCAA Database record stays the same, even if the referenced source restrictive airspace
record is changed by a 28-day cycle update of the Generic Restrictive Airspace Database.
Working with the 4D Avoid and Alert

Flight Plan Options
This section describes the 4D Avoid and Alert flight plan options and how they are used in
flight planning.
NOTE The CCAA Database must contain records before you can use the 4D Avoid
and Alert flight plan options. See “Creation of the Initial CCAA Database” on
page 114. See also the CCAA Database and User-Defined Restrictive Area Database
Help files in JetPlan.com.
Understanding the 4D Avoid and Alert Flight Plan

Options
The JetPlan 4D Avoid and Alert Functionality is activated and influenced by the following
flight plan options:
CCAA This option invokes the 4D Avoid and Alert functionality. When
CCAA is specified, JetPlan ensures that avoid-level SUAs, user-
defined airspaces, Jeppesen turbulence airspaces, or FIR/UIR
airspaces are avoided when determining an optimum route and
profile. JetPlan allows notify-level SUAs, user-defined airspaces,
Jeppesen turbulence airspaces, or FIR/UIR airspaces to be traversed
by the optimum route and profile, but alerts must be posted for each
such traversal. For more information, see “Using the CCAA,
CCAAN, and CCAAF Options” on page 127.
CCAAN This option invokes the 4D Alert functionality. When CCAAN is

specified, JetPlan allows both avoid and notify-level SUAs, user-
defined airspaces, Jeppesen turbulence airspaces, or FIR/UIR
airspaces to be traversed when determining an optimum route and

124
profile. Alerts must be posted for each such traversal. Alerts for
traversal of avoid-level airspaces must be distinguishable from alerts
for traversal of notify-level airspaces. For more information, see
“Using the CCAA, CCAAN, and CCAAF Options” on page 127.
NOTE CCAA and CCAAN apply to SUAs, user-defined airspaces, Jeppesen

turbulence airspaces, and FIR/UIR airspaces but not to organized track or geopolitical
country airspaces. See “Using the ORTRKA and ORTRKN Options” on page 130 and
“Using the GCAA and GCAN Options” on page 131.
CCAAF This option invokes 4D Avoid and Alert functionality, using a finer
latitude/longitude (lat/long) grid for avoidance of avoid-level
airspaces when direct (D) routing has been specified on the flight
plan. For more information, see “Using the CCAA, CCAAN, and
CCAAF Options” on page 127.
ORTRKA This option invokes 4D Avoid functionality for organized track

airspaces. When ORTRKA is specified, JetPlan ensures that all
avoid-level organized track airspaces are avoided when determining
an optimum route and profile. JetPlan allows notify-level organized
track airspaces to be traversed by the optimum route and profile, but
alerts must be posted for each such traversal. For more information,
see “Using the ORTRKA and ORTRKN Options” on page 130.
ORTRKN This option invokes 4D Alert functionality for organized track

airspaces. When ORTRKN is specified, JetPlan allows both avoid
and notify-level organized track airspaces to be traversed when
determining an optimum route and profile. Alerts must be posted for
each such traversal. For more information, see “Using the ORTRKA
and ORTRKN Options” on page 130.
GCAA The GCAA option invokes 4D Avoid functionality for geopolitical

country airspaces. The GCAA option avoids a country with the
avoidance level of Avoid in the CCAA DB when determining an
optimal route and profile. The GCAA option can be used with or
without the CCAA or CCAAN option.

125
GCAN The GCAN option invokes 4D Alert functionality for geopolitical

country airspaces. This option allows countries with an avoidance
level of Avoid or Notify when determining an optimal route and
profile, but generates an alert for each such traversal. The GCAN
option can be used with or without the CCAA or CCAAN option.
Options that can be used in combination with CCAA or CCAAN are as follows:
AVDERR This option invokes Avoid Error messaging functionality, which

includes specific information about avoid-level airspace incursions in
error messages when applicable. For details, see “Using the
AVDERR Option” on page 132.
EXSS This option invokes Except SIDS/STARS functionality, which allows

certain exceptions for SIDS and STARS traversing SUAs. For details,
see “Using the EXSS Option” on page 132.
EXCD This option invokes Except Climb and Descent functionality, which
allows certain exceptions for segments starting before Top of Climb
(TOC) or ending after Top of Descent (TOD) or that are part of a SID
or STAR. For details, see “Using the EXCD Option” on page 133.
CCAAQ This option invokes CCAA Qualify functionality, which directs the
system to qualify the route as needing 4D avoidance before
computing an optimized route with 4D in effect. For details, see
“Using the CCAAQ Option” on page 133.
NOTE AVDERR and CCAAQ are also customer preferences. See “Understanding
4D Avoid and Alert Customer Preferences” on page 138.
All of the options summarized above are described in more detail in the following sections.

126
Using the CCAA, CCAAN, and CCAAF Options

The CCAA, CCAAN, and CCAAF options apply to all SUAs, user-defined airspaces,
Jeppesen turbulence airspaces, and FIR/UIR airspaces but not to organized tracks or
geopolitical country airspaces.
Using the CCAA Option

The CCAA option invokes the 4D Avoid and Alert functionality, with full avoidance of avoid-
level SUAs, user-defined airspaces, Jeppesen turbulence airspaces, and FIR/UIR airspaces. In
addition, alerts are generated for incursions of notify-level SUAs, user-defined airspaces,
Jeppesen turbulence airspaces, and FIR/UIR airspaces. Organized track restrictive airspaces
are not considered.
In the JetPlan command-line interface, the input for the CCAA option is as follows:
01 OPTIONS FP,CCAA
When the CCAA flight plan option is invoked, any SUAs, user-defined airspaces, Jeppesen
turbulence airspaces, or FIR/UIR airspaces can impact (1) JetPlan’s determination of an
optimum route and vertical profile, (2) JetPlan’s provision of alerts based on a user-defined
route and its computed vertical profile, and (3) JetPlan’s provision of alerts based on a user-
selected customer route and its computed vertical profile. The manner of the impact depends
on whether the airspace is an ignore, alert, or avoid-level airspace, as described below:
Ignore-Level The airspace has no impact on the flight plan computation or flight
Airspace plan output. JetPlan ignores the restrictive airspace.
Notify-Level The airspace has no impact on the flight plan computation. JetPlan
Airspace generates an alert for each segment of the flight plan that incurs the
airspace.

127
Avoid-Level JetPlan responds as follows to restrictive airspaces with an avoidance

Airspace level of Avoid:
• When determining an optimum route. JetPlan avoids the

airspace in the most optimal manner (laterally by route or
vertically by profile), depending on the capacity of the aircraft
and on the restrictive airspace’s operational time, its effective
status, and its lateral, upper, and lower boundaries.
NOTE If, for a given flight plan computation, it is not possible to determine a route
and profile that successfully avoid all of the relevant avoid-level SUAs, user-defined
airspaces, Jeppesen turbulence airspaces, or FIR/UIR airspaces, JetPlan returns an
error.
• When the user defines the route using the Specific Route
Selector (SRS), that route is subjected to vertical profile
optimization. If one or more route segments of that route are
then determined to incur the restrictive airspace, an alert is
issued for each combination of segment and airspace.
• When the user requests customer route optimization, then each
customer route is subjected to vertical profile optimization. If,
for a given customer route, one or more route segments of that
route are determined to incur the restrictive airspace, the entire
route is eliminated from consideration as the optimum route. If
for a given flight plan computation, all customer routes are
eliminated because each incurs at least one airspace with the
avoidance level of Avoid, JetPlan returns an error.
• When the user requests a specific customer route, that route is
subjected to vertical profile optimization. If one or more route
segments of that route are then determined to incur the
restrictive airspace, an alert is issued for each combination of
segment and incurred airspace.
Using the CCAAN Option

The CCAAN flight plan option differs from the CCAA option in the treatment of avoid-level
airspaces. While the CCAA option invokes full avoidance of avoid-level SUAs, user-defined
airspaces, Jeppesen turbulence airspaces, and FIR/UIR airspaces, the CCAAN option invokes
alerting for route segment incursions of these airspaces. No attempt is made to avoid avoid-
level restrictive airspaces.

128
In the JetPlan command-line interface, the input for CCAAN is as follows:
01 OPTIONS FP,CCAAN
This command invokes the 4D Alert functionality, alerting on all incursions of avoid-level and
notify-level SUAs, user-defined airspaces, Jeppesen turbulence airspaces, and FIR/UIR
airspaces. Avoid-level restrictive airspaces are not avoided. Organized track restrictive
airspaces are not considered.
NOTE The CCAAN option overrides the CCAA option if both are entered on the
same flight plan request.
NOTE The CCAA/CCAAN options can be used with the ORTRKA/ORTRKN and
GCAA/GCAN options. See “Using the ORTRKA and ORTRKN Options” on page 130
and “Using the GCAA and GCAN Options” on page 131.
Using the CCAAF Option

The CCAAF option is intended for use when CCAA does not produce a reasonable flight plan
because of excessive avoid-level SUA or user-defined, Jeppesen turbulence, or FIR/UIR
airspace congestion anywhere along the route. When the CCAAF option is invoked, and direct
(D) routing has been specified on the flight plan, the route optimizer uses a finer lat/long grid
than is used when the standard CCAA or CCAAN option has been invoked.
The spacing of the fine lat/long grid is one half the size of the standard grid used with CCAA
flight plans. For example the standard grid is 1 degree latitude by 10 degrees longitude for an
east/west non-polar region. The fine grid for the same route would be ½ degree latitude by 5
degrees longitude.
A good indication that CCAAF might be preferable to the CCAA option is when a large
deviation from the great circle route results with D routing and the CCAA flight plan option.
For example, because of the density of SUAs in Mexico, Arizona, and Southern California on

129
the route from KDFW to KLAX, the CCAA option can result in the flight deviating north well
into Colorado and Utah or south into Mexico, depending on the weather. When the CCAAF
option is invoked, the route goes through New Mexico and Arizona.
NOTE Because the use of the fine grid generates so many possible segments for
evaluation, additional compute time is required. Very long flights might exceed the
capabilities of the system and produce a “WETRAD” error.
NOTE If you enter both the CCAA and the CCAAF commands on the same flight
plan request, the system uses the first command entered and ignores the second
command. Also, the CCAAN option always overrides both the CCAA and the CCAAF
option.
Using the ORTRKA and ORTRKN Options

The ORTRKA and ORTRKN options apply only to organized tracks airspaces. The impact of
the ORTRKA option on JetPlan’s treatment of organized track airspaces is the same as the
impact of the CCAA option on JetPlan’s treatment of avoid-level SUAs and user-defined,
Jeppesen turbulence, and FIR/UIR airspaces. Similarly, the ORTRKN option has the same
impact as the CCAAN option but applies only to organized tracks restrictive airspaces.
When required to avoid one or more organized track airspaces, JetPlan attempts to avoid them
either laterally or vertically, taking into account the effective times of the restriction. It is the
nature of such airspaces that lateral avoidance keeps the aircraft at least 60 nm from the
associated track.
In the JetPlan command-line interface, the input for ORTRKA is as follows:
01 OPTIONS FP,ORTRKA
This command invokes the 4D Avoid and Alert functionality, with full avoidance of organized
tracks airspaces. Other types of restrictive airspaces (SUAs, user-defined, Jeppesen turbulence
airspaces, and FIR/UIR airspaces) are not considered.
In the JetPlan command-line interface, the input for ORTRKAN is as follows:
01 OPTIONS FP,ORTRKAN

130
This command invokes the 4D Alert functionality, alerting on all incursions of organized
tracks airspaces. No organized tracks airspaces are avoided. Other types of restrictive
airspaces (SUAs, user-defined, Jeppesen turbulence airspaces, FIR/UIR, and geopolitical
country airspaces) are not considered.
NOTE The ORTRKA/ORTRKN options can be used with or without the

CCAA/CCAAN options. See “Using the CCAA, CCAAN, and CCAAF Options” on
page 127).
Using the GCAA and GCAN Options

The GCAA and GCAN options apply only to geopolitical country airspaces. The GCAA
option avoids a country with the avoidance level of Avoid in the CCAA DB when determining
an optimal route and profile. The GCAN option invokes 4D Alert functionality for geopolitical
country airspaces. This option allows countries with an avoidance level of Avoid or Notify
when determining an optimal route and profile, but generates an alert for each such traversal.
The default avoidance level for geopolitical country airspaces is Ignore.
NOTE The GCAA/GCAN options can be used with or without the CCAA/CCAAN
options. See “Using the CCAA, CCAAN, and CCAAF Options” on page 127).
The impact of the GCAA option on JetPlan’s treatment of geopolitical country airspaces is the
same as the impact of the CCAA option on JetPlan’s treatment of avoid-level SUA, user-
defined, Jeppesen turbulence airspaces, and FIR/UIR airspaces. Similarly, the GCAN option
has the same impact as the CCAAN option but applies only to geopolitical country airspaces.
In the JetPlan command-line interface, the input for GCAA is as follows:
01 OPTIONS FP,GCAA
This command invokes the 4D Avoid and Alert functionality, with full avoidance of
geopolitical country airspaces. Other types of restrictive airspaces (SUAs, user-defined,
Jeppesen turbulence, FIR/UIRs, and organized tracks) are not considered.
In the JetPlan command-line interface, the input for GCAN is as follows:
01 OPTIONS FP,GCAN

131
This command invokes the 4D Alert functionality, alerting on all incursions of geopolitical
country airspaces. No geopolitical country airspaces are avoided. Other types of restrictive
airspaces (SUAs, user-defined, Jeppesen turbulence, FIR/UIRs, and organized tracks) are not
considered
Using the AVDERR Option
NOTE AVDERR is also available as a customer preference. When the preference is

enabled, AVDERR functionality applies to all CCAA flight plans automatically. See
“Understanding 4D Avoid and Alert Customer Preferences” on page 138.
As explained in “Using the CCAA Option” on page 127, if it is not possible to determine a
route that successfully avoids all restrictive airspaces that have an avoidance level of Avoid,
JetPlan returns an error. In this case, the general PUZZLE01 error message indicates only that
a valid route could not be found, given the flight plan inputs. No information about avoid-level
airspace incursions is provided. The AVDERR flight plan option is designed to provide such
information.
When the AVDERR flight plan option is invoked along with the CCAA option, JetPlan alerts
the user when JetPlan cannot find a valid route due to incursions of avoid-level SUAs, user-
defined airspaces, Jeppesen turbulence airspaces, and FIR/UIR airspaces. The system also lists
the specific route segment and airspace name for each incursion.
In the JetPlan command-line interface, the inputs are as follows:
01 OPTIONS FP,CCAA,AVDERR
NOTE When the EXSS flight plan option is invoked, SIDs and STARs are not
checked for incursions of SUAs, and thus, these incursions by SIDs and STARs do
not generate errors or alerts. See “Using the EXSS Option” on page 132.
Using the EXSS Option

It is not uncommon for a SID or STAR to traverse avoid-level SUAs or notify-level SUAs.
When the EXSS option is invoked with the CCAA or CCAAN option, standard CCAA and
CCAAN functionality applies except that JetPlan considers it acceptable for SIDS and STARS
to traverse SUAs. Therefore, alerts for traversal of SUAs are suppressed for any segment that
is part of a SID or STAR.

132
01 OPTIONS FP,CCAA,EXSS
- or -
01 OPTIONS FP,CCAAN,EXSS
Using the EXCD Option

When the EXCD option is invoked with the CCAA or CCAAN option, standard CCAA and
CCAAN functionality applies except that segments starting before Top of Climb (TOC) or
ending after Top of Descent (TOD) or that are part of a SID or STAR are not checked for SUA
incursions. Airspace incursion alerts are suppressed for any segments that meet one or more of
the following conditions:
• The segment coincides with a SID or STAR (same functionality as for the
EXSS option; see “Using the EXSS Option” on page 132).
• The segment’s initial fix occurs prior to but not at TOC.
• The segment’s ending fix occurs after but not at TOD.
01 OPTIONS FP,CCAA,EXCD
- or -
01 OPTIONS FP,CCAAN,EXCD
Using the CCAAQ Option
NOTE CCAAQ is also available as a customer preference. When the preference is

set, CCAAQ functionality applies to all CCAA flight plans automatically. See
“Understanding 4D Avoid and Alert Customer Preferences” on page 138.
When the CCAAQ flight plan option is invoked together with the CCAA option, the system
computes the route from the POA to the POD, looking for any avoid-level SUA, user-defined,
Jeppesen turbulence, or FIR/UIR airspace incursions. If even one such incursion occurs, the
system automatically reruns the flight plan as a CCAA plan.

133
For city pairs for which the probability of one or more avoid-level SUA, user-defined airspace,
Jeppesen turbulence, or FIR/UIR airspace incursions by the optimum route/profile is less than
50% on a long-term basis for any given departure time/date, use of the CCAAQ option along
with the CCAA option can save significant computation time compared to use of the CCAA
alone. For the majority of flight plans, it saves the route selector from having to perform
unnecessary time consuming airspace avoidance computations for each candidate radial
within the optimization ellipse.
On the other hand, for city pairs for which the probability of one or more avoid-level SUA,
user-defined, Jeppesen turbulence, or FIR/UIR airspace incursions is greater than 50%, use of
the CCAAQ option along with the CCAA is not advised as it adds to the computation time for
the majority of flight plan computations compared to use of the CCAA option by itself.
In summary, the CCAAQ option is preferable as an add-on to the CCAA option for any given
city pair if it is determined that there is less than a 50% probability of one or more avoid-level
SUA, user-defined, Jeppesen turbulence, or FIR/UIR airspace incursions by the optimum
route for that city pair on a long-term basis.
CCAAQ is functional only when entered along with the CCAA flight plan option. It has no
impact when entered alone or with the CCAAN option.
Understanding the City Pair and City Pair Fleet Database

CCAAQ Parameters
The City Pair Fleet and City Pair Databases each contain a CCAAQ parameter. The value of
each parameter has the potential to influence the application of the CCAAQ option on flight
plan requests that include the CCAA option and the applicable city pair or city pair fleet
combination.
In both the City Pair Fleet and the City Pair Databases, the choices for the CCAAQ parameter
are:
• Yes – Ensures that the CCAAQ option is imposed whenever the CCAA
option and the city pair or city pair fleet combination are present in the flight
plan request.
• No – Ensures that the CCAAQ option is not imposed whenever the CCAA
option is in effect for the city pair or city pair fleet combination, unless the
CCAAQ option is explicitly invoked by the user on the flight plan request.
• Unset (Default) – The CCAAQ parameter has no influence.

134
The City Pair Fleet Database has precedence over the City Pair Database. In other words, if the
CCAAQ parameter in the City Pair Fleet Database is set to No and the parameter in the City
Pair Database is set to Yes, then the effective value is No.
The CCAAQ City Pair and City Pair Fleet Database parameters are applied together with the
CCAAQ User Preference setting as follows:
• If the CCAAQ flight plan option is specified in conjunction with CCAA (for
example, 01 OPTIONS FP,CCAA,CCAAQ, in command-line mode), then
the CCAAQ option is in effect, no matter what the settings are for the
CCAAQ parameters in the City Pair Fleet and/or City Pair Database records
and regardless of whether or not the CCAAQ preference is turned on.
• If the CCAAQ flight plan option is not specified, but the CCAA option is
(for example, 01 OPTIONS FP,CCAA, in command-line mode), then the
CCAAQ option is in effect if one of the following conditions is met:
– The CCAAQ parameter in the applicable City Pair Fleet Database
record is set to Yes.
- or -
– The CCAAQ parameter in the applicable City Pair Database record
is set to Yes, and the CCAAQ parameter in the applicable City Pair
Fleet Database record is set to Yes or Unset.
- or -
– The CCAAQ parameters in the City Pair and City Pair Fleet
Database records are not set, but the CCAAQ User Preference is
turned on.
Overriding an Avoidance Level on a Flight Plan

As described above, an airspace’s avoidance level is determined by the avoidance level set in
its referencing CCAA Database record. If you are using a front-end GUI application such as
JetPlan.com or Jeppesen Dispatch Control, you can override this avoidance level for a given
flight plan request. JetPlan applies the ad hoc avoidance level during route optimization or
validation, regardless of the airspace’s default avoidance level in its referencing CCAA
Database record.

135
This ad hoc avoidance level override can be accomplished by any of the following means:
• You can specify the restrictive airspaces by name (called “Restrictive

Airspace Designation” or “AD” in JetPlan.com).
• You can specify SCA Types as defined and stored in CCAA Database
records. For each SCA Type specified, all referencing restrictive airspace
records in the CCAA Database with that SCA Type are impacted by the ad
hoc avoidance-level override.
• You can specify a combination of restrictive airspaces by name and SCA
Type.
JetPlan applies the following precedence rules when ad hoc avoidance-level overrides are
specified in a flight plan request:
• For a given airspace, an ad hoc avoidance-level override always takes

precedence over the avoidance level in the airspace’s referencing CCAA
Database record.
• Avoidance levels for restrictive airspaces that are specified by name
(Restrictive Airspace Designation) in an ad hoc avoidance-level override
have higher priority than avoidance levels for the same airspaces specified
by SCA Type.
For example, a flight plan request can include an ad hoc avoidance-level
override for an airspace specified by name. The same flight plan request can
also include another avoidance-level override for an SCA Type that happens
to apply to the same airspace specified by name. In this case, the ad hoc
avoidance level applied to the airspace by name takes precedence over the
avoidance level applied by SCA Type.
• If, on a given flight plan, there are two or more ad hoc avoidance-level
overrides applied to the same airspace name or to the same SCA Type, the
specification of Avoid takes precedence over any other avoidance-level
specified.

136
As an example, the following graphic shows the Customer Controlled Avoid and Alert area
in the New Flight Planner in JetPlan.com. You can use this area to invoke 4D Avoid and Alert
options and enter ad hod avoidance levels. (Note that in this view, the SCA Type is
abbreviated as “SCAT.”)
Figure 5.1. Customer Controlled Avoid and Alert Options in JetPlan.com
NOTE For more information, see the documentation for your front-end GUI
application or contact your Jeppesen account manager.

137
Understanding 4D Avoid and Alert Customer Preferences
Understanding 4D Avoid and Alert

Customer Preferences
Settings for the following customer preferences can be used to customize the application of the
CCAA and CCAAN flight plan options. When the customer preference is enabled, the
specified functionality is applied automatically rather than having to be invoked on a flight
plan-by-flight plan basis.
NOTE Customer preferences are set by Jeppesen. For more information on these
preferences, contact your Jeppesen account manager.
NOTE As discussed in “Overriding an Avoidance Level on a Flight Plan” on

page 135, Customer Preference settings determine the default avoidance level for
each record in the CCAA Database. For more information, contact your Jeppesen
account manager.
4D Altitudes (4DALTS) Preference

The 4DALTS preference allows you to define the lowest cruise altitude used for eliminating
avoid restrictive airspaces. This speeds up CCAA computations by reducing the number of
avoid restrictive airspaces considered for a given flight plan. For example, when
4DALTS=290, the minimum cruise altitude to be considered by the 4D Avoid and Alert
function is FL290. You also have the option to specify minimum flight levels that apply within
the range of up to four separate, defined great circles. For example, you can set 4DALTS to
use FL050 within a great circle distance of 0 nm to 300 nm, FL150 within a great circle
distance of 301 nm to 1000 nm, and so on, up to four great circles.
AVDERR Preference
When the AVDERR preference is set, and the CCAA flight plan option has been invoked, the
system automatically behaves as if the AVDERR flight plan option has been submitted along
with the CCAA option.
For information on how AVDERR works, see “Using the AVDERR Option” on page 132.

138
Understanding 4D Avoid and Alert Error Messages
CCAAQ Preference
When the CCAAQ preference is set, and the CCAA flight plan option has been invoked, the
system automatically behaves as if the CCAAQ flight plan option has been submitted along
with the CCAA option.
For information on how CCAAQ works, see “Using the CCAAQ Option” on page 133.
Understanding 4D Avoid and Alert Error

Messages
When a user specifies a route on a CCAA flight plan (for example, an SRS or company route),
alert messages provide information about any incursions of avoid or notify-level SUAs, user-
defined airspaces, Jeppesen turbulence airspaces, and FIR/UIR airspaces. Similarly, for a
CCAAN flight plan, alert messages provide information about any incursions of avoid or
notify-level SUAs, user-defined airspaces, Jeppesen turbulence airspaces, and FIR/UIR
airspaces. Each alert message contains the following information:
• The avoidance level of the airspace that has been incurred.

• The start and end point of the route segment that has incurred the airspace.
• Information on the airspace, including a one-character code for the source
restrictive airspace database (G for Generic, U for User-Defined, J for
Turbulence, F for FIR/UIR, P for Geopolitical Country).
• The RSA Tag for the airspace.
• Repetition of the restrictive airspace designation and the multiplier code
from the RSA Tag to make it easier to find in case the user wants to use it
for an ad hoc override of the airspace’s default avoidance level. See
“Overriding an Avoidance Level on a Flight Plan” on page 135.
For example, the following is an example of an alert message for an incursion of a notify-level
airspace by a customer-entered route:
Segment MEDOG ABAPO incurs alert airspace GEGD203_____B:203_____B

SENNYBRIDGE

139
Understanding 4D Avoid and Alert Error Messages
In the alert message above:
• G signifies that the source database is the Generic Restrictive Airspace

Database (the airspace is an SUA).
• EGD203_____B is the RSA Tag.
• The ICAO code is EG.
• The restrictive type is D, the restrictive airspace designation is 203_____,
and the multiple code is B.
Note that the restrictive airspace designation and multiple code (203_____B) are repeated
after the colon.
The following is an example of an alert message for an incursion of an avoid-level restrictive

airspace by a customer-entered route. The User-Defined Restrictive Airspace Database is the
source database, and, again, the airspace designation is repeated after the colon.
Route incurs avoid-level restrictive airspace:

Segment SLANY MALOT incurs avoid airspace UJKPTEST0:TEST0 TEST
For a description of the RSA Tag, see “Understanding the Contents of CCAA Database
Records” on page 119.

140
C HAPTER 6
Route Commands
Route Commands
About Route Commands
About Route Commands

JetPlan provides the following methods for selecting a route. Each route-selection method
supports the ultimate goal of producing a flight plan. The methods vary to some degree in
approach and application. This chapter focuses on how each method is used.
Route Optimizer This is JetPlan’s traditional route selection method. Your inputs (or
lack thereof) are the tools that control the route selection process. The
Route Optimizer works with both “dynamic” and “non-dynamic”
inputs. A dynamic route input is one that entrusts the system to
determine and deliver the missing pieces of the routing puzzle. A
non-dynamic route input is one that dictates the route each step of the
way. Routes are generated using the JetPlan Navigation Database as
the source of airway and waypoint information. The Route Optimizer
can be used alone or combined with the Specific Route Selector to
produce the precise routing that meets your needs. See “About the
Route Optimizer” on page 144.
Specific Route The SRS allows complete control of the route. Unlike the Route
Selector (SRS) Optimizer, the SRS requires input of the full route. Using Jeppesen
syntax, you can specify a customer route from POD to POA. The SRS
can also be used in conjunction with the Route Optimizer to produce
combination routes. The source of navigational information for the
SRS is the Jeppesen Aviation Database (JAD), which uses the
ARINC 424 standard. See “About the Specific Route Selector” on
page 211.
Customer Route This is another non-dynamic route input method because you enter a
Database (CRDB) user-defined CRDB record name to use a pre-stored route when the
flight plan is computed. Before you can use a CRDB record, you must
first create the desired route using one of the route selection tools
mentioned above. When satisfied with the route, you can save it to the
CRDB for subsequent recall and application in your flight plan
requests. See “Using Customer Route Database Records” on
page 251.
Coded Departure Coded Departure Routes are predefined alternate routes for flying
Route (CDR) between city pairs when a user-preferred route is not available due to
Database weather or traffic constraints. Coded departure routes are complete
routes from departure to arrival, including terminal procedures. The
FAA maintains coded departure routes and publishes an updated list

143
Route Commands
About the Route Optimizer
of the effective coded departure routes every 56 days. Each record in

the Customer Coded Departure Route Database is a duplicate of a
coded departure route stored in the generic NavData Coded Departure
Route Database, which is replaced every 56 days. You can enter the
coded departure route record name to use the pre-stored route when
the flight plan is computed. See “Using Coded Departure Route
(CDR) Records” on page 253.
Electronic Route The ERAD option employs a route selector that is designed for flights
Availability using European airspace and that produces a multi-dimensional route
Document (ERAD) that is optimized and fully compliant with EUROCONTROL traffic
flow restrictions. See “Electronic Route Availability Document
Option” on page 256
The following sections cover each of the above route selection tools in detail.

The Route Optimizer is both the simplest and the most complicated means of entering a route
input on the JetPlan system. The simplicity shines in its dynamic ability to provide a route
with a minimum of inputs. The complexity comes with the routing concepts and syntax rules
you must apply to make the inputs you do enter valid and effective. You can let the Route
Optimizer do the work for you, or you can limit its dynamic abilities by providing more inputs.
This section explains how to use this flight planning tool.
The Route Optimizer enables you to apply complete route optimization, partial route
optimization, or no route optimization to your flight plans. Each is defined below.
Complete Route Defined as a route created without user input. This “no-input” method
Optimization allows the Route Optimizer to dynamically determine the route based
solely on the POD and POA entries.
Partial Route Defined as a route that is controlled to some degree by the user’s
Optimization inputs. This method still allows the Route Optimizer to dynamically
determine the route, but the user has provided constraints that must be
followed. For example, you could choose to limit the route to airways
only, overflight of a particular waypoint, ATC preferred routing, or
something more complicated.

144
Route Commands
No Route Defined as a route that is controlled every step of the way by the user.
Optimization Though the Route Optimizer is designed to dynamically determine a
route based on a minimum of inputs, you can instruct it to use the
course you determine by specifying each waypoint along the way.
The Navigation Database and Route Areas

How you achieve the route optimization level of your choice depends on your inputs and the
sphere of operation in which a flight is to be flown. The Route Optimizer’s source of
navigational information is the JetPlan Navigation Database. This database, which is
originally derived from the Jeppesen Aviation Database (JAD), separates the world into
logical “route areas” for flight planning purposes. There are five different land mass areas
(labeled as Areas 1 through 5) and one overwater area (Area 0) within this database.
The following list is a breakdown of the major countries or land masses defined as route areas
in the JetPlan Navigation Database:
Area 1 Alaska, Canada, Greenland, United States, Mexico, Central America,

Caribbean, and northern South America.
Area 2 Europe (up to and including Western Russia), Africa, and most of the
Middle East.
Area 3 South America (with the exception of that portion of South America
covered by Area 1).
Area 4 Part of the Middle East, China, South East Asia, Japan, Philippines,
Indonesia, Malaysia, Australia, New Zealand, Guam, South Pacific
Islands, Eastern Russia.
Area 5 Hawaiian Islands, Iceland, and Azores.
Area 0 All areas not covered under areas 1 through 5, including overwater
areas. Further, all airports defined by latitude/longitude (LAT/LONG)
coordinates are considered to be in Area 0. (For more information,
see Chapter 3, “Point of Departure and Point of Arrival Commands.”)

145
Route Commands
The map below provides a rough overview of the defined route areas in the JetPlan Navigation
Database.
Figure 6.1. Navigation Database Route Areas
The JetPlan Navigation Database uses three altitude route structures:
High Altitude The high-altitude route structure is used the default information for
all flight plans. However, two subset options are available for various
altitude restrictions.
Low Altitude (LA) The low-altitude (LA) option provides worldwide low-altitude route
structure. For regions of the world that do not have separate low and
high-altitude structures, the low-altitude option uses the same route
structure as the high-altitude option.
Mid Altitude (MA) The mid-altitude (MA) option provides a hybrid high/low-altitude
route structure over Europe (Area 2) for flight planning between
flight level (FL) 200 and FL245. This structure is needed to handle
the different altitudes that countries in Europe use to separate low and
high altitude airspace.

146
Route Commands
You can use only one of the three (high, mid, or low) options per flight plan request. For
information on the application of the LA and MA subset options, see the following sections in
this chapter and Chapter 2, “Option Commands.”
NOTE You can use SRS inputs or the CRDB to accommodate unique flight planning
situations not covered by standard Route Optimizer inputs. These options are
discussed later in this chapter.
JetPlan Defined Route Types

There are a variety of route types you can use when applying Route Optimizer concepts. They
include the following:
Optimized Routes Optimized routes are dynamically calculated routes that use wind
direction and speed to come up with the best path. Depending on the
aircraft’s general course of flight, the Route Optimizer attempts to
either maximize a tailwind or minimize a headwind. Optimized routes
are based on the following:
• The best combination of airways or direct segments between

NAVAIDS. This type of optimizing (within navigational route
structure) is referred to as “Nav Optimized” routing.
• The best available airways (high, mid, or low altitude
navigational route structure). This type of optimizing (airway
structure only) is referred to as “Airway Optimized” routing or
simply as “Airways.”
The navigational route structure used in either of these route

optimization types can vary, depending on the altitude option
used (high, mid, or low).

147
Route Commands
• The best latitude/longitude direct route. This type of optimizing

ignores the JetPlan Navigation Database, meaning that
NAVAID and airway structure is irrelevant. It is often referred
to as “random” routing, but this manual refers to it as Direct
routing.
NOTE Do not be confused or misled by this manual’s use of the term Direct. With
regard to the Route Optimizer, the term Direct is used in two contexts:
- A route segment of sufficient length to allow the route optimization algorithms to

determine the optimal route (winds and temperatures are factored into the equation).
- A route segment too short to be thought of as anything other than a direct route. The
segment is sufficiently short so as not to be changed by any optimization algorithms.
Published Organized track structures (OTS) include: the dynamic (changing

Organized Track daily) North Atlantic (NATS) routes, Pacific (PACOTS—includes
Structures Northern Pacific Tracks as well as the Flex Tracks for Hawaii to and
from Japan) routes, and Australian (AUSOTS) routes.
CRDB Records CRDB route records apply to the Route Optimizer only, in the sense
that they can be created using the Route Optimizer.
Time-Restricted JetPlan considers the availability of a time-restricted (daily or

Airway weekly) airway, based on the Estimated Time of Arrival (ETA) over a
window waypoint. In addition, JetPlan has two options that override
this capability: AX and NX. Either option is applied on the Options
command line after the FP entry, as follows:
• AX allows the Route Optimizer to consider routes normally not

available due to time restrictions associated with one or more
segments.
• NX prevents JetPlan from considering any time-restricted
airway that would normally be available for flight planning
based on an ETA over a window fix.
National Route NRP refers to the FAA National Route Program, which allows flights
Program (NRP) operating at or above FL290 within the conterminous U.S. to
participate in minimum time/cost routes without restrictions (free
flight). Although NRP plans do not require route inputs for the typical

148
Route Commands
U.S. domestic flight, some coordination might be necessary if using

NRP for the U.S. portion of an international flight plan. For more
information, see “National Route Program (NRP) Option” on
page 196.
Non-Restrictive NRR refers to the FAA Non-Restrictive Routing program, which

Routing (NRR) applies to flights operating at or above FL350 (configurable) within
Routes the conterminous U.S. NRR allows the flexibility and increased
efficiency of point-to-point navigation, rather than requiring flights to
traverse existing airway structures such as Jet airways. Two levels of
NRR service are available: High Altitude Redesign (HAR) and Point-
to-Point (PTP). For additional information on these two NRR service
levels, including setup requirements, see “Non-Restrictive Routing”
on page 199.
Applying Route Inputs – General
NOTE For information about route input limits, see “Route Input Limits” on
page 192.
The Route Optimizer provides three route segments for your inputs: the Departure Area
Routing (RTD) segment, Overwater Area Routing (RTW) segment, and the Arrival Area
Routing (RTA) segment. This design was created to meet the needs of intercontinental flight
while complying with the design of a navigational database that separates data into specific
route areas.
For example, if you are flying from Area 1 to Area 2 (see the picture above) and you want to
apply some sort of control over the route, the RTD segment allows you to enter navigational
fixes within the area of your departure airport, the RTW segment allows you to enter some sort
of transition routing over the Atlantic Ocean (for example, a North Atlantic Track), and the
RTA segment allows you to enter navigational fixes within the area of your arrival airport.
The three segments combined provide the input fields necessary to develop a route between
two airports for almost any flight plan. In many cases, only one route input segment (RTD) is
necessary because many flights never leave the departure airport route area.

149
Route Commands
The following paragraphs describe the RTD, RTW, and RTA segments in more detail:
RTD Departure Area Routing – The RTD segment is used to navigate route
structure within the same route area as the POD. It is the only route
segment necessary if the flight stays within the same route area (the
POD and POA are in the same area-of-coverage). It can also be used
to enter specific route constraints for departure area routing on
intercontinental flights (from one route area to another).
RTW Overwater Area Routing – The purpose of the RTW segment is to

control the route transiting between non-zero route areas (1 through
5), or any other Area 0 routing (for example, Organized Track
Structures, latitude/longitude coordinates, and so on).
RTA Arrival Area Routing – The RTA segment is used to navigate route
structure within the same route area as the Point-of-Arrival. This
route segment is required any time the arrival airport is in a route area
that differs from the departure airport route area. It also applies any
time inputs are made to the RTW segment.
NOTE JetPlan accepts all three segments of inputs on one Route command line (06
ROUTE). Each segment is separated by forward slashes— for example, 06 ROUTE
RTD input/RTW input/RTA input. If it is necessary to continue a route input to the next
computer screen line, a comma is entered before the entry does a line wrap.
JetPlan-Defined Flight Plan Types and the Route Segment

Inputs
The following paragraphs describe the JetPlan flight plan types and how they relate to the
RTD, RTW, and RTA route segments.
Domestic Flight As it applies to the Route Optimizer, JetPlan defines a domestic flight
Plans plan as one in which the POD and POA are in the same route area (for
example, Area 1 to Area 1), not the same country. Even if the POD
and the POA are both in Area 0 (overwater area), the flight plan is
still defined as domestic because the origination and termination
occur within the same JetPlan logical area. In either case, an RTD
route input is generally necessary (unless nav optimization is desired,

150
Route Commands
in which case no inputs are made). The RTW and RTA segments do
not need to be entered at all, unless the flight plan is transitioning
from one area to another (international flights) or using preferred
routes or canned tracks (see “Domestic Flight Plans with Three Route
Segment Inputs” below).
Domestic Flight There are times when a domestic flight plan uses the three route
Plans with Three segments (RTD/RTW/RTA) rather than the single segment normally
Route Segment used, despite having a POD and POA in the same route area. You
Inputs specify RTD, RTW, and RTA inputs when you want to use one of the
following RTW input types:
• A published preferred route

• A JetPlan canned route
• An Area 0 waypoint or a latitude/longitude coordinate set
International Flight International flight plans are defined as those plans that originate in
Plans one JetPlan route area and terminate in another JetPlan route area (for
example, flights from North America to Europe). When a flight plan
transits the Atlantic, Pacific, or any other Area 0 region, JetPlan
clearly regards this as transiting three areas: the POD route area, the
overwater route area, and the POA route area. In this case, you
generally have to specify route inputs for the RTD and RTA. If one or
more Area 0 waypoints or latitude/longitude coordinate sets are to be
included in the route input, then an RTW segment must also be
specified.
If coordinates are used to define either the POD or the POA, then
JetPlan recognizes this point to be in Area 0. Specific rules must be
followed to define the route correctly for the computer.
Route Input Segments – Basic Structure

If you want to let the Route Optimizer determine the entire route without constraints (complete
route optimization), then no route segment inputs are necessary. The Route Optimizer either
determines the route dynamically or provides an error message suggesting further user
intervention in the form of route inputs.

151
Route Commands
Assuming that some sort of user control (input) is to be applied to the route, it might not be
necessary to apply inputs to all three route segments, as in the case of flights within a single
route area.
Example:
06 ROUTE (RTD inputs)
If a flight is to transit two route areas (for example, Area 1 to Area 2), specify route inputs for
at least the RTD and RTA segments. Note that the slash must be entered to separate the route
segments, and in the case of no RTW input, two consecutive slashes are necessary to signify
the separation of route areas and the lack of an RTW input. See example below.
Example:
06 ROUTE (RTD inputs)//(RTA inputs)
If an overwater (Area 0) input is needed, specify information for the RTD, the RTW, and the
RTA segments. Note that a slash separates each segment.
Example:
06 ROUTE (RTD inputs)/(RTW inputs)/(RTA inputs)
RTD and RTA Segments – Input Types

The RTD and RTA route segments allow the same types of input and require the same syntax.
The following route entry types and syntax rules apply to the RTD and RTA segments.
Jet Airways (J) You must enter the J option if you want to ensure that the Route
Optimizer looks for airway routing throughout the flight. The J option
must be entered only once, and it must be the first entry on the RTD
or RTA segment. If the J option is applied anywhere but in the first
position, you can expect a flight plan error at best or an invalid route
at worst. When using both the RTD and RTA input segments, there is
no requirement to use the J option on both segments unless you
expressly want airways in both route areas. When the J option is used,
the Route Optimizer discriminates against improper use of one-way
airways.

152
Route Commands
Victor Airways (V) You can use the V option in place of the J option to designate a low
altitude airway request. The rules for the V option are the same as for
the J option.
NOTE You must specify the low altitude navigation database (LA option) on the
Options command line to use Victor airways properly.
Direct Segments The D option instructs the Route Optimizer to ignore navigational
(D) route structure and fly an “optimized direct” route between the points
specified (whether that be enroute waypoints or airport pair). This
option can be placed in any position on the RTD or RTA segment,
except in front of the J option. When used together with the J option,
the D option always overrides the airway requirement to perform the
direct routing for that portion of the flight specified, before reverting
back to airway routing. For example, if a direct segment is required
from a departure airport to a nearby NAVAID, and airways are
otherwise desired for the majority of the flight, then the opening input
on the RTD segment is J,D followed by any other valid entry.
The following syntax rule apply: the D option is entered as the last
entry on the RTD segment and the first entry on the RTA segment
when waypoints are specified on the RTW segment. This type of
input solidifies the transition into and out of Area 0. There are some
instances where this input method is not necessary, but it is generally
a good idea to follow this procedure, as it ensures a smooth transition.
If airways are required after the RTW segment, then you must begin
your RTA input with J followed by any other valid entry.
The only exception to the practice of ending an RTD input (or

beginning an RTA input) with D or J,D is when an international track
code is used on the RTW segment. In this case, the D only interferes
with the track selection process. International track codes are JetPlan
inputs that access the best airway from a set of Organized Track
Structures (A or Z for the NATs, OW or OE for the PACOTS, and so
on).
Preferred Routes In conjunction with the North Atlantic Tracks, ATC preferred routes
(P) are available to and from selected airports in North America. The P
option can be used on the RTD or RTA segment to access these
preferred routes. Entering P alone, or with specific preferred route
waypoint connections, picks up the preferred North American Routes

153
Route Commands
(NARs) in Area 1. Used in the same manner as the J option, the P

option is generally the first input on the segment, although there are
cases where it can be entered as the second entry—but only after a J
input (J,P). Entering J,P instructs the Route Optimizer to ignore the
non-common portion of the NAR and instead fly airways. Using the P
option as an input on flights in other parts of the world (not related to
the NATs), generates an error at best or produces an invalid route at
worst. Also, do not use the D option with the P option.
Waypoints Waypoints can be entered on the RTD and RTA input segments in
two different ways. You can enter the charted ID of the waypoint
(usually a two- to five-character input) or enter the JetPlan three-
character ID (an internal code). Normally, internal IDs are only used
to clarify confusion between two similarly identified points (see
“Waypoint Ambiguity (RTD/RTA)” on page 155).
NOTE When entering the above input types, apply the following rules:
- All route entries for the RTD and RTA segments must be separated by commas with
no spaces in between (for example, J,D,OVR,HVQ,ALB or P/Z/J,LND,KOK).
- A comma must never be the last item for an RTD or RTA input.
Waypoint Identification (RTD/RTA)

The Route Optimizer is designed to perform all flight planning computations using the JetPlan
Navigation Database. Since this database contains waypoints available around the world, it is
very important that each waypoint has a unique identifier. For example, the NAVAIDS for
Manchester, England and Muscat, Oman have the same identifier (MCT). Thus, a unique
identifier for each is assigned (MCT for Manchester and M2B for Muscat).
Since the Route Optimizer performs all computations using the JetPlan internal identifier for
each waypoint, it would seem practical to use these internal IDs when entering your route
inputs. However, trying to determine what internal ID to use for each waypoint can be
cumbersome. For this reason, the Route Optimizer accepts waypoint entries by both the
charted and the internal identifiers. In fact, using charted identifiers for waypoint input is both
acceptable and recommended. This practice saves you time in the long run, because JetPlan
can scan your input, determine the identifier’s location, and convert it to the internal ID faster
than you can.

154
Route Commands
The following rules apply to the input of charted and internal waypoint identifiers. These rules
apply only to entries on the RTD or RTA input segments (route Areas 1 through 5).
Charted Identifiers These are generally two to five-character inputs. What you find on the
navigational chart is what you enter. Navaids are typically two or
three-character inputs (for example, CH, DVR, and HVQ), while
compulsory (CRP) and non-compulsory reporting points (NCRP) are
typically five-character inputs (for example, BRADD, KANNI, and
WHALE).
Internal Identifiers These are three or four-character inputs.These identifiers are typically
composed of the elements listed in the following table.
Table 6-1 Internal Identifiers
Identifier Composition Examples

Alphanumeric characters FQF,TNP,AVE,T90, F41
Period PU.
Hyphen (often referred to as a dash) HL-
Waypoint External Output (RTD/RTA)

JetPlan prints out the charted name of a waypoint in the flight plan output. For example, the
four-character internal identifier ADSM prints out as ADSAM, which is a waypoint on the
Arctic track NCA ALFA. The three-character internal identifier C1R prints out as the two-
character identifier CH.
Waypoint Ambiguity (RTD/RTA)

As mentioned above, one of the aspects of using charted identifiers for your waypoint inputs is
the fact that, occasionally, some waypoints within the same route area have the same
identifiers. For example, CH is the identifier for both the Cheung Chau VOR in China and the
Christchurch VOR in New Zealand. Both are in the same JetPlan route area (Area 4).
Knowledge of the JetPlan internal identifiers for these waypoints would be helpful because
each internal ID is unique. However, this is not always practical. Sometimes you only know
what you have in front of you, which are the names on the charts. Entering the charted name in
this situation could cause problems because the Route Optimizer cannot determine which
identifier you want. This is referred to as “waypoint ambiguity.”

155
Route Commands
If faced with waypoint ambiguity, JetPlan attempts to automatically resolve the problem by
selecting the waypoint closest to the route of flight.If automatic waypoint resolution fails, you
can try the following:
Latitude/Longitude Specify latitude/longitude coordinates in parentheses, approximate to

Approximation your waypoint, next to the waypoint input. Use the Route Optimizer
rules for latitude and longitude input. This technique forces JetPlan to
use the charted waypoint identifier closest to the specified
coordinates.
Nearby Waypoint Specify another waypoint near the waypoint causing the ambiguity.
This additional waypoint needs to be on your intended route of flight.
Internal Identifier Specify the internal identifier of the waypoint. Because JetPlan
assumes that all waypoint identifiers entered in a flight plan request
are charted names, you must enter a left parenthesis before the
internal waypoint name. This facilitates the waypoint file search.
Example:
06 ROUTE J,(CH-
RTW Segment – Input Types

The RTW route segment allows you to navigate in Area 0. There are several types of RTW
inputs and all are specific to the RTW segment only. None of the input types listed for the
RTD or RTA segments are allowed on the RTW segment. The following input types and rules
apply to the RTW route input segment.
Latitude/Longitude The Route Optimizer recognizes user-defined latitude/longitude

Coordinates coordinates on the RTW segment only. Coordinates can be entered in
a different ways. The standard Route Optimizer method is given
below:
• Latitude is entered as a four-digit input; two digits define

degrees, and two digits define minutes (ddmm).
• Longitude is entered as a five-digit input; three digits define
degrees, and two digits define minutes (dddmm).

156
Route Commands
• South and East coordinates must be prefixed with a minus sign

(-) to differentiate these coordinates from North and West
coordinates.
• A comma must separate the latitude from the longitude and a
coordinate set from any other RTW entry.
Example:
D/3800,17000,3900,18000,4000,-17000,4000,-16000/D
Other latitude/longitude entry methods are taken from the Specific

Route Selector tool. However, these methods do work with the Route
Optimizer. The following paragraphs describe these methods:
• Latitude can be entered as a two-digit (dd) or a four-digit

(ddmm) input, depending on whether you want to express a
minutes value. If the minutes value is a non-zero value, enter a
four-digit input. If not, then simply enter the two-digit degree
value.
• Longitude can be entered as a three-digit (ddd) or a five-digit
(dddmm) input, depending on whether you want to express a
minutes value. If the minutes value is a non-zero value, enter a
five-digit input. If not, then simply enter the three-digit degree
value.
• All coordinates must be prefixed with the single letter
designating the hemispherical location of the coordinates (N, S,
E, or W).
• Commas between latitude and longitude are not necessary.
However, you must separate one coordinate set
(latitude/longitude combination) from another with either a
comma or a space.
Example:
D/N38W170 N39W180 N40E170 N40E160/D or
D/N3830W17000,N39W180,N4015E17000,N3950E16000/D
International Track You can invoke access to certain Organized Track Structures (OTS)
Codes by entering JetPlan international track code. The code you enter
instructs the Route Optimizer to determine the optimal track from the
set of tracks available for the given POD/POA combination. For more

157
Route Commands
information about international track codes and the associated

Organized Track Structures, see “International Planning – Organized
Track Structures” on page 167.
The Route Optimizer and SID/STAR Application

The Route Optimizer selects a SID or STAR provided the following conditions are met:
• A SID/STAR transition is part of the optimized route.

• The SID/STAR identifier is loaded in the navigation database.
If an optimized route does not print out a SID or a STAR, then you might have to specify a
transition waypoint to pick up the SID or STAR. If a SID or a STAR is not loaded in the
navigation database, contact Jeppesen Customer Service to have it loaded.
NOTE The Route Optimizer considers a SID or a STAR identifier—the label given to
the route structure that makes up the SID or STAR—an airway name. If the Optimizer
constructs a route overflying a NAVAID that has a SID or a STAR connected to it,
then the SID or STAR identifier might print out in the flight plan just like any other
airway. This does not occur often, and it can be avoided, given assistance from
Jeppesen Customer Service.
Using Route Proof

You can use the Route Proof (RP) command as a planning tool to determine the following:
• Operational validity of the route

• Necessary route input changes
• Where to make user-specified altitude (profile) changes
• Where to make user-specified cruise mode changes
To use Route Proof, enter FP,RP on the Options command line, and then enter the rest of the
flight plan request inputs (for example, POD, POA, RTD/RTW/RTA, and so on). Route Proof
prints out the route of flight and ground distances based on your route inputs.
NOTE Using the JetPlan “shortcuts” simplifies the Route Proof process. See “Flight
Plan Shortcuts” on page 54 in Chapter 2, “Option Commands.”

158
Route Commands
Once the route is “proven” satisfactory, you can build the desired flight plan request, using the
information gathered from the Route Proof. Start by typing all of the necessary command
inputs after FP on the Options command line, and then make changes to the other inputs, if
necessary. Type GO at any point if the plan is ready to be calculated.
The following example illustrates a Route Proof request, a follow-up Route Proof request that
modifies the route entry, and a final plan (long version) with all of the desired commands and
options, including a profile change.
Example:
Explanation: The following is the original route proof request.
01 OPTIONS FP,RP
02 POD WIII/WBSB/RPMM/RCTP/RJFK,TX800
03 POA RKSI
06 ROUTE J
07 HOLD,ALTERNATE/DIST 30,RKSM
08 ETD 0100
09 PROFILE I
10 A/C TYPE/REGN $N123
11 CRUISE MODE LRC
14 PAYLOAD 50000
Example:
Explanation: The following is the follow-up route proof request with route modification (FPR
is the Flight Plan Reload command).
01 OPTIONS FPR
02 POD @6 or @06
06 ROUTE J,LBG
07 HOLD,ALTERNATE/DIST GO
Example:
Explanation: The following is the final, complete flight plan request.
01 OPTIONS FPR,ETOP,DRFT,CS/JD123,CPT/S RAWLUK,DSP/T MURPHY

02 POD @9
09 PROFILE I,330,35010 A/C TYPE/REGN GO

159
Route Commands
Applying Route Inputs – Domestic Planning

As stated above, domestic flight plans originate and terminate within the same JetPlan route
area. Even if the POD and the POA are both in Area 0 (the overwater area), the flight plan is
still in one area. In either case, an RTD input is generally necessary, except in the case of pure
nav optimization (no inputs). RTW and RTA inputs are not necessary unless overflying one or
more Area 0 waypoints or using preferred routes or canned tracks.
NOTE This section applies the general route input concepts described previously by
including more concrete examples. To keep the examples as realistic and
understandable as possible, actual inputs are used, including departure, arrival, and
waypoint identifiers. In addition, route areas are noted to help clarify the reason
certain entries are made.
Optimized Direct Routing

If you want to request the best direct route without regard for NAVAID or airway structure,
then enter the “D” input type. This provides the best latitude/longitude direct route. For
predominantly east/west routes, it is based on calculations at every 1 degree of latitude and 10
degrees of longitude. In other words, a computer-generated waypoint, in latitude/longitude
format, prints every 10 degrees of longitude. For predominantly north/south routes, it is based
on calculations at every 5 degrees of latitude and 1 degree of longitude.
You can specify direct routes between an airport pair or between enroute waypoints. As more
overfly waypoints are specified, the Route Optimizer capability is diminished.
NOTE In a zero wind scenario, direct routing is roughly equivalent to great circle
routing.
Example:
Route explanation: Optimum direct (D) route from KLAX to KJFK.
02 POD KLAX
03 POA KJFK
06 ROUTE D

160
Route Commands
Example:
Route explanation: Nav optimize to DAG, fly direct from DAG to LVZ, and then nav optimize
to POA. JetPlan prints out the SID or STAR, if either are loaded in the database.
02 POD KLAX
03 POA KJFK
06 ROUTE DAG,D,LVZ
NAV Optimized Routing

Any route input, or lack of route input, that does not specifically select a direct segment (D) or
airways (J) automatically produces nav optimization. A nav-optimized route is one that looks
at the navigational structure to produce the best combination of airways or direct segments
between NAVAIDS. To nav optimize, withhold all route inputs as shown in the example
below.
Example:
Route explanation: Nav optimize from POD to POA (no route input).
02 POD KSFO
03 POA KJFK
06 ROUTE <Press ENTER> (no entry)
Airway Optimized Routing

If you want to request the best airway route, then enter the “J” input type. This selects the
optimal route based on the best combination of jet airway routes available. To consider RNAV
routes, specify RN on the Options command line (you can also use an aircraft from the
Aircraft Database that has the RNAV parameter turned on). To avoid RNAV routes, specify
NORN on the Options command line.
Example:
Route explanation: Fly jet routes from POD to POA.
02 POD KSFO
03 POA KJFK
06 ROUTE J

161
Route Commands
Nav Optimized Routing Between Specific Waypoints

You can request a nav optimized route while overflying specific waypoints. Enter one or more
waypoints as part of the route input. JetPlan nav optimizes between the waypoints as long as
the J input is not specified, and the D input is not placed between waypoints. As the number of
overfly waypoints increases, Route Optimizer capability decreases.
Example:
Route explanation: Nav optimize the entire flight, but overfly LIN and LVZ.
02 POD KSFO
03 POA KJFK
06 ROUTE LIN,LVZ
Airway Optimized Routing Between Specific Waypoints

You can request airway routing while overflying specific waypoints. Enter the J input and one
or more waypoints as part of the route input. JetPlan airway optimizes between waypoints as
long as airway structure exists between them and as long as the D input is not entered to
disrupt this type of request. As the number of overfly waypoints increases, Route Optimizer
capability decreases.
Example:
Route explanation: Fly airways from POD to POA, but overfly TIGRA, KRK, TRL, and SIT.
If jet routes do not connect all of these points, then an error occurs.
02 POD EDDM
03 POA HECA
06 ROUTE J,TIGRA,KRK,TRL,SIT
Domestic Planning – All 3 Route Segments

There are times when a domestic flight plan uses all three route input segments
(RTD/RTW/RTA) rather than the single segment (RTD) normally used, despite being in the
same JetPlan route area. This is effectively the same as entering international route inputs.You
specify three route segments when an Area 0 input (RTW input) is necessary.

162
Route Commands
Example:
Route explanation: Fly optimized routing to DVV VOR, then fly direct to N42/W110, then
direct to MLD VOR, then fly optimized to POA.
02 POD KMCI
03 POA KSFO
06 ROUTE DVV,D/N42w110/D,MLD
Applying Route Inputs – International Planning

As stated, international flight plans originate in one JetPlan route area and terminate in another
(for example, flight plans from North America to Europe or Asia to North America). When a
flight plan transits the Atlantic, Pacific, or any Area 0 region, JetPlan deems this a three area
transition: the POD area, the overwater area, and the POA area.
NOTE This section applies the general route input concepts described previously by
including more concrete examples. To keep the examples as realistic and
understandable as possible, actual inputs are used, including departure, arrival, and
waypoint identifiers. In addition, route areas are noted to help clarify the reason
certain entries are made.
Because general syntax rules for the Route Optimizer apply equally to both the
“domestic” and the “international” route entries, detailed review of the different types
of route entries would be redundant here. Therefore, only specific differences from
domestic inputs and examples are explained below.
Optimized Direct Routing

You can request the best direct route between the POD route area and the POA route area,
without regard for navigational structure. The following paragraphs cover specifying direct
routes when planning international flights.

163
Route Commands
POD and POA
Example:
Route explanation: In this example, a direct route is entered on a flight from Honolulu (Area 5)
to Calgary (Area 1). All published route structure is ignored. Note that a non-entry on the
RTW segment (blank RTW) is the same as a D on the RTD or RTA.
02 POD PHNL
03 POA CYYC
06 ROUTE D//D
Enroute Waypoints
Example:
Route explanation: In this example, direct segments are entered between waypoints in Area
1on a flight from New York (Area 1) to London (Area 2). With the exception of the entered
waypoints, all published route structure is ignored. Note that a non-entry on the RTW segment
(blank RTW) is the same as a D on the RTD or RTA.
02 POD KJFK
03 POA EGLL
06 ROUTE D,ACK,D,YHZ//D
Overwater Waypoints
Example:
Route explanation: The inputs instruct the Route Optimizer to calculate direct segments from
PHNL to ZIGIE, from ZIGIE into the overwater area, direct (no input) for the overwater area
to TOU in Area 1, and direct from TOU to CYYC. Note that no input on the RTW segment is
the same as a D on the RTD or RTA.
02 POD PHNL
03 POA CYYC
06 ROUTE D,ZIGIE,D//D,TOU,D
Directs between overwater waypoints (Area 0 fixes) are implied, as the following example
illustrates.

164
Route Commands
Example:
Route explanation: The inputs instruct the Route Optimizer to calculate direct segments from
EINN to 52N015W, from 52N015W to 54N030W, from 54N030W to SCROD, and from
SCROD to CYYR. The additional route examples portray variations of the same RTW input.
Note that an implied direct (D) exists between every entry on the RTW segment.
02 POD EINN
03 POA CYYR
06 ROUTE D/5200,01500,5400,03000,SCROD/D
or
06 ROUTE D/N52W015 N54W030 SCROD/D
or
06 ROUTE D/N52W015,N54W030,SCROD/D
Nav Optimized Routing

You can request the optimal routing based on the best combination of jet airways or direct
segments between NAVAIDS. A non-input on the RTD and RTA segments instructs the
Route Optimizer to nav optimize in both route areas (the POD route area and the POA route
area). If the route crosses an overwater area (Area 0) between the POD and the POA route
areas (more than just the transition between the two route area land masses), JetPlan selects an
optimized direct route across the overwater area. Note that no input on the RTW segment is
the same as a D on the RTD or RTA.
Example:
Route explanation: Route nav optimizes from POD through Area 1, optimizes direct across the
North Atlantic, and then nav optimizes through Area 2 to the POA.
02 POD KJFK
03 POA EDDF
06 ROUTE <Press ENTER> (no entry)
In addition, when planning an international flight, a nav-optimized route can be selected for
one route area, POD or POA, while the other route area has various route inputs.
For example, if jet airway or direct routing is desired for the POA route area only, then omit
any RTD or RTW inputs.
Example:
Route explanation: Same as the previous example, except that the Route Optimizer now uses
jet airways to the POA (through Area 2 only).

165
Route Commands
02 POD KJFK
03 POA EDDF
06 ROUTE //J
Airway Optimized Routing

You can select the optimal route based on the best combination of jet airway routes available.
Example:
Route explanation: This example specifies airways through Area 2, optimized direct routing
over the North Atlantic (Area 0), and then airways through Area 1 to POA.
02 POD EDDF
03 POA KLAX
06 ROUTE J//J
Like nav optimization, airway optimization can be applied to one route area if desired. Simply
remove the J input from the route area that you want to free from airway requirements. See the
example given for nav optimization in one route area (above).
Nav Optimized Routing – Between Specific Waypoints

You can specify one or more waypoints as part of the route in the POD or POA route area.
JetPlan nav optimizes between waypoints as long as the route elements, J or D, have not been
specified. As the number of overfly waypoints increases, Route Optimizer capability
decreases.
Example:
Route explanation: Fly nav optimized routing through Area 1, optimize direct across the North
Atlantic (Area 0), and then fly nav optimized routing through Area 2 to POA via SUM and
AAL.
02 POD KSEA
03 POA EKCH
06 ROUTE //SUM,AAL
Example:
Route explanation: Fly nav optimized routing through Area 1, optimize direct across the North
Atlantic (Area 0) via N61E000, and then, after going direct to ZOL, nav optimize in Area 2 to
POA via VES.

166
Route Commands
02 POD KSEA
03 POA EKCH
06 ROUTE /N61E000/D,ZOL,VES
Airway Optimized Routing – Between Specific Waypoints

You can specify a J input and one or more waypoints as part of the route in the POD or POA
area. JetPlan airway optimizes between the waypoints as long as airways exist between the
waypoints and a D input has not been requested. As the number of overfly waypoints
increases, Route Optimizer capability decreases.
Example:
Route explanation: Fly airways through Area 1, optimize direct across the North Atlantic
(Area 0), and then fly airways through Area 2 to the POA via SUM.
02 POD KSEA
03 POA EKCH
06 ROUTE J//J,SUM
Example:
Route explanation: Fly airways through Area 2 via TIGRA, KRK, TRL, SIT, and DBA, and
then transition to airways through Area 4 to POA.
02 POD EDDM
03 POA VABB
06 ROUTE J,TIGRA,KRK,TRL,SIT,DBA//J
JetPlan Designated Preferred Routes

You can invoke preferred routes between specific airport pairs located in different route areas.
To do so, enter the D input on the RTD and RTA segments and PR on the RTW segment. For
a list of airport pairs with preferred routes loaded between them, contact Jeppesen Customer
Service.
International Planning – Organized Track Structures

Organized Track Structures (OTS) are sets of ATC-approved tracks designed to facilitate
traffic flow across large bodies of water. There are two kinds of organized track structures:
static and dynamic. Static structures are, more or less, permanent airways that do not change
over time. They can be found on navigation charts. Occasionally, waypoints on these airways

167
Route Commands
might be repositioned, but charts are generally updated and changes are minimal. Static
structures provide a set of valid flight levels that can be used for the direction flown. Some of
these airways might be available for two-way traffic, while others are only available in one
direction.
Dynamic structures are airways that can change from day to day. A controlling agency
disseminates NOTAMs that define the structure for a given time period, including valid flight
levels. Dynamic structures are not on navigation charts.
JetPlan provides international track codes for several OTS systems. These codes, which are
entered on the RTW route input segment, allow you to access the optimal track, from the given
set of airways available, for the given POD/POA combination. The following table shows the
JetPlan code (input) that is used on the RTW segment and the corresponding track structure
being referenced. All of the track structures in this table are dynamic.
Table 6-2 International Track Codes
Code (Input) Organized Track Structure Name (Direction)

A North Atlantic Tracks (NATs – westbound)
Z North Atlantic Tracks (NATs – eastbound)
OE Pacific Organized Track Structures (PACOTS – eastbound)
OW Pacific Organized Track Structures (PACOTS – westbound)
North Atlantic Tracks

The North Atlantic Tracks (NATs) are a set of airways designed to alleviate traffic flow
between Europe and North America. They are a dynamic track structure in that they are
updated on a daily basis. The eastbound set, referred to as the “XYZ” tracks, is published by
Gander OAC. The westbound set, referred to as the “ABC” tracks, is published by Shanwick
OAC. Each set of tracks is available on the JetPlan system immediately upon receipt from the
aforementioned agencies. To obtain a print of the latest NAT update, specify one of the
following inputs on the Options command line:
• PZ – Prints a current copy of the eastbound North Atlantic Tracks

• PA – Prints a current copy of the westbound North Atlantic Tracks

168
Route Commands
When planning to use the NATs, consider the following restrictions:
• Daytime (westbound) NATs constrain traffic at the 30 West parallel from

1130 to 1800 UTC for flight levels 310 through 390. This means that for you
to consider using the westbound NATs, your flight needs to be at or past the
30 West parallel within the time frame specified.
• Nighttime (eastbound) NATs constrain traffic at the 30 West parallel from
0100 to 0800 UTC for flight levels 310 through 390. This means that for you
to consider using the eastbound NATs, your flight needs to be at or past the
30 West parallel within the time specified.
• The CAA and FAA recommend that random route (non-NAT) flights that
cross the 30 West parallel within the hour preceding the onset of a new NAT
set flight plan on the new NAT set or maintain vertical or lateral separation
from the new NAT set.
To request routing over the NATs, enter one of the following international track codes on the
RTW route input segment.
Table 6-3 International Track Codes
Track Code Tracks Times

A A, B, C, and so on Valid 1130Z–1900Z
Z U, V, W, and so on Valid 0100Z–0800Z
When a NAT is requested on a submitted flight plan, the Route Optimizer automatically
determines the optimum track. Flight levels are constrained to valid NAT altitudes during the
NAT portion of the flight.
North Atlantic Tracks – Basic Route Inputs

The examples below demonstrate the various basic inputs that access the North Atlantic
Tracks. Subsequent sections provide more concrete input examples. Keep in mind that all
input rules previously established in this chapter apply.

169
Route Commands
The following input examples request the optimum eastbound track. Enter a “Z” on the RTW
input segment. You can request nav optimization, jet airways, or preferred routing for your
Area 1 and Area 2 inputs (the RTD and RTA input segments).
NOTE Not every possible combination of NAT route inputs is shown in the tables
below.
Table 6-4 North Atlantic Tracks (Eastbound Examples)
Input Route Explanation

/Z/ Nav optimize through Area 1, optimum eastbound
track, nav optimize through Area 2.
J/Z/J Jet airways through Area 1, optimum eastbound track,

jet airways through Area 2.
/Z/J Nav optimize through Area 1, optimum eastbound

track, jet airways through Area 2.
P/Z/J ATC preferred routing through Area 1 (a.k.a., NARs),

optimum eastbound track, nav optimize through Area
2.
The following input examples request the optimum westbound track. Enter an “A” on the
RTW input segment. RTD and RTA inputs can be used in similar fashion to those shown
above.
Table 6-5 North Atlantic Tracks (Westbound Examples)
Input Route Explanation

/A/ Nav optimize through Area 2, optimum westbound
J/A/J Jet airways through Area 2, optimum westbound
track, jet airways through Area 1.
J/A/P Jet airways through Area 2, optimum westbound
track, ATC preferred routing through Area 1 (NARs).
J/A/ Jet airways through Area 2, optimum westbound

/A/P NAV optimize through Area 2, optimum westbound

track, ATC preferred routing through Area 1 (NARs).
Overfly points can be added to your Area 1 or Area 2 route input. One type of overfly point
that you might want to use is the coastal fix. Coastal fixes are waypoints that enter or exit a
particular track, and they are part of the track messages that come from the controlling ATC

170
Route Commands
agencies. By entering a coastal fix, you imply to the Route Optimizer that you want to use a
specific track. For example, if you specify the coastal waypoint COLOR, and COLOR is
connected to track Charlie (NAT C) on today’s westbound tracks (ABCs), then the likelihood
of track Charlie being used in the computed flight plan is increased significantly. This
implication need only be specified in one route area for it to work this way. See the following
examples for application of overfly points within a NAT request (specifically coastal
waypoints).
Example:
J/A/P,COLOR
- or -
J,BURAK/A/J,P,SSM,LIT
North Atlantic Tracks – Preferred Route Considerations

A NAT-associated preferred route can be requested in Area 1 by entering the P option on your
RTD or RTA input segment.
NOTE The P option used on the RTD and RTA is only available in relation to North
Atlantic travel. It does not access any other preferred routing except as defined here.
Area 1 Preferred Routing

In Area 1, the preferred routes associated with the NATs are called North American Routes
(NARs). Every NAR consists of two segments, the common portion and the non-common
portion. The common portion exists between a coastal waypoint (where the NAT is either
entered or exited) and an inland navigational fix. The non-common segment is the connection
between the inland navigational fix and the departure (or arrival) airport, depending on the
direction of the flight.
The table below shows the North American (Area 1) airports connected to the North Atlantic
Tracks by common and non-common NAR segments.
Table 6-6 North American Airports
East West West West

KADW CYMX KDTW KORL
KBOS CYYZ KEWR KPHL
KBWI CYUL KFLL KPIT

171
Route Commands
Table 6-6 North American Airports (continued)
East West West West

KCHS KADW KHPN KRDU
KDOV KATL KIAD KSFB
KEWR KBOS KIAH KSTL
KHPN KBWI KJFK KTEB
KIAD KCHS KLAS KTPA
KJFK KCLT KLAX KWRI
KPHL KCVG KMCO
KSFB KDEN KMIA
KTEB KDFW KMSP
KWRI KDOV KORD
If you want to use the preferred route option as your Area 1 input, it is typically used alone.
However, because of the segmented nature of NARs, you can apply additional route inputs to
your Area 1 routing.
When applying additional inputs to your Area 1 preferred route request, the direction
determines where to place the P option. If departing Area 1 (eastbound), the P option can be
placed in the last position of the input segment. If arriving Area 1 (westbound), the P option is
placed in the first or second position of the input segment (this is dependent on whether you
want to specify jet airways, the J option, at all).
Area 1 preferred route inputs: When departing Area 1, the P might be the last input on the
RTD.
Example:
02 POD KDFW
03 POA EDDF
06 ROUTE J,JAROM,P/Z/J
Area 1 preferred route inputs: When arriving Area 1, it is the first or second input on the RTA.
Example:
02 POD EDDF
03 POA KDFW
06 ROUTE J/A/J,P

172
Route Commands
For westbound flights, you can override the non-common portion of a NAR by specifying the
inland navigational fix (the endpoint for a westbound common segment) after the P option and
then entering additional waypoints that deviate from the non-common segment.
Example:
Route explanation: Preferred route from EHAM to the optimum westbound NAT. After the
NAT, pick up the common portion of the NAR to SSM (inland navigational fix), and then fly
jet airways from SSM to KDFW via LIT.
02 POD EHAM
03 POA KDFW
06 ROUTE J/A/J,P,SSM,LIT
For North American airports not connected to the NARs, the P option accesses a common
NAR segment. However, the route output to or from the common NAR depends on your input.
If the P option is used alone (no other input option is specified), the route nav optimizes as
follows:
• Eastbound: the route optimizes from the POD to the start of the common
NAR. Overfly waypoints can be specified with this input. However, the P is
the last input on the RTD.
• Westbound: the route nav optimizes from the end of the common NAR to
the POA. Overfly waypoints can be specified with this input.
If the J option is included with the P option (such as J,P), the route airway optimizes as
follows:
• Eastbound: the route selects optimal jet airways to the start of the common
NAR. Overfly waypoints can be specified with this input. However, the P is
the last input on the RTD.
• Westbound: the route selects optimal jet airways from the end of the
common NAR. Overfly waypoints can be specified with this input.
Preferred Routes Without the NATs

The preferred route option can be used even when the NATs are not specified. For example, if
you are planning to cross the Atlantic but prefer to use latitude/longitude coordinates rather
than specify a North Atlantic Track, you can enter the coordinates on the RTW input segment
while specifying preferred routes on the RTD or RTA.

173
Route Commands
Example:
02 POD EGLL
03 POA KBOS
06 ROUTE J/5500,02000,5000,05000/P
Preferred Route Restrictions

The following restrictions apply to the P option for Area 1.
When departing Area 1, do not use a D to direct the route from a waypoint on a common NAR
segment to a waypoint input specified on the RTW route segment. The following example
demonstrates an incorrect route input.
Example:
Error Message outputs: Cannot direct route from a NAR way-point—YYT—to 4800,05000.
02 POD KJFK
03 POA EGLL
06 ROUTE YYT,P,D/4800,05000/J,DOLIP
When arriving Area 1, do not use a D to direct the route from a waypoint on the RTW route
segment to a waypoint on a common NAR segment. The following example demonstrates an
incorrect route input.
Example:
Error Message outputs: cannot direct route from 5000,05000 to the beginning waypoint on a
common NAR—YYT.
02 POD EGLL
03 POA KJFK
06 ROUTE J/5000,05000/P,D,YYT
North Atlantic Tracks – Flight Level Considerations

When using the North Atlantic OTS, a Profile command input of I (for IFR) or C (for IFR and
no step-climbs) is acceptable. In addition, waypoints can be specified as altitude constraint
parameters.
Without the C profile option, JetPlan step climbs into, through, or above the valid NAT flight
levels if the change results in a better profile. If step climbs are not desired, you can constrain
the NAT portion by adding the C option to your Profile command line.

174
Route Commands
In the example below, the C option is specified. JetPlan selects IFR altitudes until the NAT
track, where it selects a valid flight level and holds it (no step-climbs) for the duration of the
track. After the track, JetPlan reverts back to IFR altitude rules.
Example:
02 POD EDDF
03 POA KPHL
06 ROUTE J/A/J,P,BRIGS
09 PROFILE C
In the next example, waypoints are specified as altitude constraint parameters. These inputs
approximate typical ATC arrival restrictions in Area 1.
Example:
02 POD EDDF
03 POA KPHL
06 ROUTE J/A/J,P,BRIGS
09 PROFILE C,PVD,240,HOFFI,200
North Atlantic Data Link Mandate (NAT DLM)

Phase 2 of the NAT DLM is being implemented in three phases (2A, 2B, and 2C). Phase 2A
was implemented on February 5, 2015, Phase 2B was implemented on December 7, 2017, and
Phase 2C is planned for January 30, 2020.
The NAT DLM Phase 2A required that all aircraft operating between FL350 and FL390
(inclusive) on the NAT organized tracks system (OTS) be equipped with FANS 1/A (or
equivalent) Controller-Pilot Data Link Communications (CPDLC) and Automatic Dependent
Surveillance (ADS) equipment.
The NAT DLM Phase 2B, effective December 7, 2017, restricts the entire NAT airspace that
is not in ATS Surveillance Airspace to NAT DLM-equipped aircraft between FL350 and
FL390 (inclusive). JetPlan automatically restricts this airspace to aircraft with the required
CPDLC and ADS-C equipment in Item10a/b on the ICAO filed flight plan (FPL). The
application applies this restriction if the Profile command input is I or C for the NAT portion
of the flight plan.
NOTE For regulatory information, see the “NAT OPS Bulletin 2017-001 Rev2_NAT
common DLM AIC” (19 July 2017) at:
https://www.icao.int/EURNAT/EUR%20and%20NAT%20Documents/NAT%20Docum
ents/NAT%20OPS%20Bulletins/NAT%20OPS%20Bulletin%202017_001.pdf

175
Route Commands
The following airspace is not included in NAT Region DLM airspace:
• ATS Surveillance Airspace. ATS Surveillance Airspace is airspace where

surveillance is provided by radar, multilateration, and/or ADS-B and VHF
voice communications are available. Aircraft must be suitably equipped
with transponder/ADS-B Extended Squitter (ES) transmitter.
• Airspace north of 80° North. (Airspace north of 80°N lies outside the
reliable service area of geostationary satellites).
• The New York Oceanic FIR.
• Tango Routes. Aircraft not data-link equipped are allowed to continue to
operate on the following routes:
– T9 and T213. Aircraft not data-link equipped are allowed to operate
on T9 and T213 until solutions to provide ATS surveillance and
VHF coverage on those routes are implemented. (When that
coverage is provided, the NAT DLM will no longer be applicable to
those routes. T213 will be moved to the east in order to provide
ATS Surveillance and VHF coverage). ATS surveillance and VHF
coverage will be provided on these routes as early as possible, but
no later than January 30, 2020.
– T13 and re-aligned T16 and T25 until 30 January 2020.
The Customer Aircraft Database record must be configured to support NAT DLM Phase 2B.
Table 6-7 lists the equipment codes that are required to satisfy the NAT DLM. (As long as the
required codes are present, other equipment codes might also be present in Item10a/b.)
Table 6-7 NAT DLM Phase 2A – 2B Required Item 10a/b Equipment
ICAO FPL Item Equipment Type Equipment Codes

EQUIPMENT 10a CPDLC One or more of the following CPDLC codes:
• J2 – CPDLC FANS 1/A HFDL
• J5 – CPDLC FANS 1/A SATCOM (INM)
• J7 – CPDLC FANS 1/A SATCOM (IRID)
EQUIPMENT 10b ADS D1 – ADS-C with FANS 1/A Capabilities
The CPDLC and ADS equipment in Table 6-7 is stored in the NC2 parameter in the “ICAO
2012 Certification and Equipment” section of the Customer Aircraft Database record. When
the NC2 parameter is configured with this data, JetPlan automatically inserts the 10a
equipment codes before the / indicator and the 10b codes after the / indicator in Item 10a/b
EQUIPMENT on the filing strip. For more information, see Chapter 27, “Customer Aircraft
Database.”

176
Route Commands
If the Customer Aircraft Database record is not configured to support NAT DLM Phase 2B,
JetPlan generates the following alert message for flight plans in the NAT area:
ALERT TAG NATEQPD

ALERT MSG No ADS or CPDLC equipment found. Flight levels 350-390 in
NAT area prohibited.
You can override automatic altitude checking by specifying an altitude range on the 09 Profile
command line — for example, I,250,350 or C,250,350. In this case, JetPlan generates the
following alert message for flight plans in the NAT area:
ALERT TAG NATSPOV

ALERT MSG NAT Space altitude checking overridden
North Atlantic Performance-Based Communications and Surveillance

On March 30, 2018, Performance-Based Communications and Surveillance (PBCS) replaces
the North Atlantic Reduced Lateral Separation Minimum (RLatSM) trial. PBCS expands the
requirements and scope of the RLatSM trial it replaces. Under PBCS, east and westbound
NATs can include multiple PBCS half-degree (latitude) tracks, along with adjacent whole
degree tracks to the north and the south. Only aircraft with the required PBCS equipment are
allowed to operate between FL350 and FL390 (inclusive) on the PBCS half-degree track and
between FL350 and FL390 (inclusive) on the adjacent whole-degree PBCS tracks. The
adjacent whole-degree tracks can be used at or below FL340 without the PBCS equipment.
Required Equipment
To support PBCS, JetPlan restricts FL350–390 (inclusive) on the PBCS half-degree track and
on the adjacent whole-degree tracks to aircraft with the required PBCS equipment codes in
Item 10a, Item 10b, Item 18 PBN/, and Item 18 SUR/.

177
Route Commands
Table 6-8 lists the equipment types and codes required for compliance with PBCS. JetPlan
automatically inserts these codes in the filing strip when they are configured in the CADB
record.
Table 6-8 PBCS – Required Equipment
ICAO FPL Item Equipment Type Required Equipment Codes

EQUIPMENT 10a • RCP • P2
• CPDLC • One or both of the following CPDLC
codes:
- J5 – CPDLC FANS 1/A SATCOM
(INM)
- J7 – CPDLC FANS 1/A SATCOM
(IRID)
EQUIPMENT 10b ADS D1 – ADS-C with FANS 1/A Capabilities
Item 18 PBN/ RNP L1 – RNP 4

NOTE The R-PBN Certified parameter must
also be set to Yes for the L1 code to appear in
Item 18 of the ICAO filing strip. The R-PBN
Certified parameter is in the “ICAO 2012
Certification and Equipment” section of the
CADB record.
Item 18 SUR/ RSP RSP180
About the Required Equipment Codes in the CADB

The Equipment 10a and 10b values in Table 6-8 are stored in the 10a/b Equipment (NC2)
parameter in the “ICAO 2012 Certification and Equipment” section of the CADB record.
When the NC2 parameter contains 10a/b Equipment codes, JetPlan automatically inserts those
10a codes before the / indicator and the 10b codes after the / indicator in Item 10a/b
EQUIPMENT on the filing strip—for example, NC2=SDHIJ5P2/D1.

178
Route Commands
Figure 6.2 shows the required PBCS 10a CPDLC and Required Communication Performance
(RCP) equipment codes in the “ICAO 2012” section of the CADB on JetPlan.com. P2 must be
selected. You can select either J5 and J7 or both, but at least one is required. As long as the
required codes are selected, you can add other 10a codes and still comply with the PBCS
requirements.
NOTE Figure 6.2 shows the CADB ICAO 2012 page as it will appear when the
Required Communication Performance (RCP) equipment codes are added to
JetPlan.com. You can also select P2 using the JetPlan command-line interface.
Figure 6.2. Field 10a Equipment Required: J5 and/or J7 and P2

179
Route Commands
Figure 6.3 shows the required 10b ADS code, D1, in the “ICAO 2012” section of the CADB
record on JetPlan.com. As long as D1 is selected, you can include other 10b codes and still
comply with the PBCS requirements.
Figure 6.3. Field 10b Equipment Required: D1
The Item 18 PBN/ value in Table 6-8 is stored in the 18 PBN/ (I2) parameter in the “ICAO
2012” section of the CADB record. When the I2 parameter is set to L1, JetPlan automatically
inserts L1 in Item 18 on the filing strip.
NOTE The R-PBN Certified parameter must also be set to Yes for the selected L1
code to appear in Item 18 of the ICAO filing strip. The R-PBN Certified parameter is
also in the “ICAO 2012” section of the CADB record.

180
Route Commands
Figure 6.4 shows the required Item 18 PBN/ (I2) RNP specification code, L1, in the “ICAO
2012” section of the CADB in JetPlan.com. As long as L1 is selected, you can include up to
seven other codes and still meet the PBCS requirements. Note that PBN CERTIFIED (I1)
must be set to Yes for PBN codes to appear in Item 18 on the filing strip.
Figure 6.4. Field 18 PBN/ RNP Specification Required: L1
The Item 18 SUR/ value in Table 6-8 is stored in the 18 SUR/ (I5) parameter in the “ICAO
2012” section of the CADB record. When the I5 parameter is set to RSP180, JetPlan
automatically inserts RSP180 in Item 18 on the filing strip. Figure 6.5 shows the required Item
18 SUR/ (I5) RSP180 code in the “ICAO 2012” section of the CADB record on JetPlan.com.
Figure 6.5. Field 18 SUR/
For more information on the equipment parameters, see Chapter 27, “Customer Aircraft
Database.”

181
Route Commands
Possible PBCS Error Message ─ Half-Degree PBCS Track

If JetPlan or the user attempts to plan a route using a half-degree PBCS track, and any of the
required PBCS equipment is missing, JetPlan does not compute a plan and displays the
following error message:
ADS, CPDLC, or RNP 4 equipment missing. PBCS Half Latitude track

[track ID of the half-latitude track] prohibited.
Possible PBCS Alert Messages ─ Whole-Degree PBCS Tracks

If the planned route includes an adjacent whole-degree PBCS track, no altitude is specified in
the request, and the required PBCS equipment is missing, JetPlan plans the route at or below
FL340 on the whole-degree PBCS track and displays the following alert:
ALERT TAG NATEQUI

ALERT MSG NAT PBCS equipment missing. Flight levels 350 to 390
prohibited.
You can specify altitudes within FL350 to FL390 (inclusive) on an adjacent whole-degree
PBCS track. If the required PBCS equipment is missing, JetPlan plans the route and the
requested altitude but displays the following alert:
ALERT TAG NATEQUI

ALERT MSG NAT PBCS equipment missing. Flight levels 350 to 390
prohibited.
Output of Half-Degree Latitude Points on the Operational Flight Plan

The ICAO and Air Navigation Service Providers (ANSPs) request that flight planning systems
and aircraft operators use the new Hdddd output format for the half-degree PBCS tracks on
operational flight plans. For example, the point at 5430N050W equates to H5450 in the flight
plan output.
JetPlan uses the Hdddd output format for the latitude points in the half-degree PBCS tracks
and also for optimizer routes or ad hoc user route inputs in these Flight Information Regions
(FIRS):
• Gander Oceanic/CZQX
• Shanwick Oceanic/EGGX
• REYKJAVIK/BIRD

182
Route Commands
JetPlan Engine also uses the Hdddd format in Item 18 Estimated Elapsed Time (EET) on the
ICAO FPL, as shown in the following example:
EET/CZQM0034 CZQX0111 TUDEP0151 CZQX0153 H52500206 H54400243

EGGX0318 H55200352 EISN0410 NETKI0414 EGTT0446 EHAA0522
NOTE The Hdddd output format applies only to points in the North Atlantic airspace
(north latitude and west longitude) within the FIRs listed above. All other areas
continue to appear in the Ndddd format.
North Atlantic Tracks – Input Examples

This section provides concrete examples that depict inputs that select the optimum track from
those available, and specific tracks.
Selecting the Optimal Track

The following examples are representative of a user’s request for the optimum NAT.
Example:
Route explanation: Non-common and common NAR for Area 1, optimal eastbound NAT, then
airways through Area 2 to destination.
02 POD KJFK
03 POA OEJN
06 ROUTE P/Z/J
Example:
Route explanation: Jet airways for Area 2, optimal westbound NAT, and then the NAR
through Area 1 to destination.
02 POD EDDF
03 POA CYMX
06 ROUTE J/A/P
Example:
Route explanation: Nav optimize through Area 1, optimal eastbound NAT, and then airway
optimized through Area 2 to destination.
02 POD KTEB

183
Route Commands
03 POA EGLL
06 ROUTE /Z/J
Example:
Route explanation: Airways via LIT to the inland navigational fix, SSM, and then the NAR,
the optimal NAT, and finally, airway optimized through Area 2 to destination.
02 POD KDFW
03 POA EDDF
06 ROUTE J,P,LIT,SSM/Z/J
Selecting a Specific Track

Selecting a particular NAT track for your flight plan requires you to include one or more
coastal waypoints in your input. The number and location of points specified determines
whether the input is a demonstrative command to fly a particular NAT track or merely a mild
suggestion for which track to aim. There are many variations to this technique, and
representative examples are illustrated below.
Westbound Flight Plans
Example:
Route explanation: Jet airway optimized through Area 2 to the NAT that connects with the
Area 1 coastal fix, HO. Pick up common and non-common NAR through Area 1 to
destination.
NOTE A valid track must exist with the coastal fix, HO, included.
02 POD EDDF
03 POA KORD
06 ROUTE J/A/P,HO

184
Route Commands
Example:
Route explanation: Same as previous example except that only the common portion of the
NAR is requested. Once the inland navigational fix (the endpoint for the common segment) is
reached, jet airways prevail to the destination.
NOTE A valid NAT track with the coastal fix, HO, must exist. Also, the inclusion of
the J option overrides the non-common NAR segment.
02 POD EDDF
03 POA KORD
06 ROUTE J/A/J,P,HO
Example:
Route explanation: Same as previous example except that the jet airways after the common
segment of the NAR must overfly the waypoint, TUL.
02 POD EGLL
03 POA KDFW
06 ROUTE J/A/J,P,HO,TUL
Example:
Route explanation: Jet optimized through Area 2 to the NAT that connects with the inland
navigational fix, STEAM. Pick up the common and non-common NAR segments in Area 1 to
destination.
NOTE A valid track with the coastal fix, STEAM, must exist.
02 POD EHAM
03 POA KDFW
06 ROUTE J/A/P,STEAM
Eastbound Flight Plans
Example:
Route explanation: Preferred route (NARs) through Area 1 to the coastal fix, VIXUN, pick up
NAT that is connected to VIXUN, and then fly jet optimized through Area 2 to destination.

185
Route Commands
02 POD KATL
03 POA EGLL
06 ROUTE P,VIXUN/Z/J
Example:
Route explanation: Jet airways through Area 1 to the inland navigational fix (the start point for
the common segment of the NAR), pick up the NAR to the coastal fix, COLOR, and then the
NAT connected to COLOR. Jet optimized through Area 2 to destination.
02 POD KDFW
03 POA EDDF
06 ROUTE J,COLOR,P/Z/J
North Atlantic Tracks – Crossing Without The NATS

The same types of RTD and RTA inputs used on a NAT flight plan can be used for a random
route flight plan across the North Atlantic. If an organized track across the North Atlantic is
not desired, omit the international track code (A or Z) and the Route Optimizer develops an
optimized direct route for the overwater portion of the flight.
Example:
Route explanation: Preferred NAR through Area 1, optimize direct across the North Atlantic
(with waypoints defined every ten degrees of longitude), and then jet airways through Area 5
to destination.
02 POD KTEB
03 POA BIKF
06 ROUTE P//J
Example:
Route explanation: Jet optimized through Area 2, optimize direct across the North Atlantic,
and then preferred NAR through Area 1 to destination.
02 POD EGLL
03 POA CYUL
06 ROUTE J//P

186
Route Commands
Pacific Organized Track Structures (PACOTS)

PACOTS refers to the multiple, dynamic airway structures that exist in the North and Mid-
Pacific. PACOTS are dynamic because they are updated daily for flight planning purposes
during specific time-frames.
PACOTS includes Northern Pacific Tracks as well as the Flex Tracks for Hawaii to and from
Japan. The tracks in the North Pacific lie between the west coast of North America (Area 1)
and the Asian Far East (Area 4—generally landing or overflying Japan). The Mid-Pacific
tracks, historically referred to as the “Flex Tracks,” lie between Hawaii (Area 5) and Japan
(Area 4).
Flex Tracks
The Flex Tracks exist between Hawaii and Japan. They are updated on a daily basis and are
available only at specific times of the day. The eastbound Flex Tracks are valid on JetPlan
from 1000 to 2100 UTC (for flights crossing the 160 East parallel between 1200 and 1600
UTC). The westbound tracks are valid from 1900 to 0800 UTC (for flights crossing the 160
East parallel between 2300 and 0600 UTC). To view the latest update of these tracks, enter the
following on the Options command line:
01 IFS,FLEX – Prints the eastbound Flex Track NOTAM.
01 IFS,WFTR – Prints the westbound Flex Track NOTAM.
NOTE The outputs resulting from these two inputs differ significantly. The
eastbound tracks (FLEX) printout provides the “route of flight” to follow. You must
enter your inputs based on this information. The westbound tracks (WFTR) printout
provides the “user inputs” that you enter to access any one of the tracks. The reason
for this output difference involves how each structure is stored on the JetPlan system.
Flex Tracks – Route Inputs

Routing in both directions (east and west) requires similar basic inputs to use the track
structure. By entering the international track code, OE, on the RTW segment, you access the
Flex track system—given the POD and POA are in Area 5 and Area 4 respectively.
Entering “J” on the RTD or RTA generally provides the optimal Flex Track. For more control,
you can enter some or all of the overfly points specified in the track NOTAM.
Example inputs for each direction are shown below.

187
Route Commands
Example:
Route explanation: Jet airways through Area 4, the optimum Flex Track, jet airways through
Area 5 to destination. The route input used in this example is valid for either direction.
02 POD RJAA (Area 4)

03 POA PHNL (Area 5)
06 ROUTE J/OE/J
Example:
Route explanation: Jet airways through Area 4 via MILVA, pick up the Flex track connected
to MILVA, jet airways through Area 5 to destination.
02 POD RJAA
03 POA PHNL
06 ROUTE J,MILVA/OE/J
Example:
Route explanation: Jet airways in Area 5 to SOK, and then direct to DANNO; pick up the Flex
Track connected to the specified waypoints, and then jet airways through Area 4 via MILVA,
SMOLT, SUNNS and LIBRA to destination.
02 POD PHNL
03 POA RJAA
06 ROUTE J,SOK,D,DANNO/OW/J,MILVA,SMOLT,SUNNS,LIBRA
PACOTS – Far East To/From North America

The PACOTS between the Far East (Area 4—landing or overflying Japan) and the west coast
of North America (Area 1) are updated on a daily basis. They are available only at specific
times of the day. The eastbound tracks are valid on JetPlan from 0900 to 1600 UTC (for flights
crossing the 160 East parallel). The westbound tracks are valid from 1900 to 0800 UTC (for
flights crossing the 160 East parallel). To view the latest update of these tracks, enter the
following on the Options command line:
IFS,PAC-OTS – Prints the eastbound PACOTS Tracks NOTAM.

188
Route Commands
IFS,FREEFLOW – Prints the westbound PACOTS Tracks NOTAM.
NOTE The output resulting from this input is in a user-input format. The output is
prepared by the Jeppesen Customer Service staff.
PACOTS – Route Inputs

Routing in both directions requires similar basic inputs to use the track structure. The two-
letter designator OE is entered on the RTW input segment to access the optimum eastbound
PACOTS track. The two-letter designator OW is entered on the RTW input segment to access
the optimum westbound PACOTS track.
You can use the J option or nav optimize on the RTD or RTA route segments when accessing
the optimal track. For more control, you can enter some or all of the overfly waypoints
provided in the track printout message.
Example inputs for each direction are shown below.
Example:
Route explanation: Jet airways through Area 4, the optimum eastbound track, jet airways
through Area 1 to destination. The route input used in this example is valid for either direction.
02 POD RJAA
03 POA CYVR
06 ROUTE J/OE/J
Example:
Route explanation: Jet airways through Area 1 via ALCOA, pick up the westbound track
connected to the specified waypoints, and then jet airways through Area 4 via GARRY,
SCORE, VIRGO and LIBRA to destination.
02 POD KSFO
03 POA RJAA
06 ROUTE J,ALCOA/OW/J,GARRY,SCORE,VIRGO,LIBRA
If you are planning for flights between North America and Taipei, Hong Kong, Manila, or
some other similar arrival, you can enter a special Customer Route Database entry,
RT/ALL/TOS, to invoke the optimum track from the two tracks, K and L. This input searches

189
Route Commands
a “public” CRDB record, allowing you to use these specific routes that are maintained by
Jeppesen. To invoke Track K specifically, enter RT/PACK/TOS. To invoke Track L
specifically, enter RT/PACL/TOS.
Example:
Route explanation: Entering the CRDB input shown selects the more advantageous of the two
tracks, K or L.
02 POD KLAX
03 POA VHHH
06 ROUTE RT/ALL/TOS
Example:
Route explanation: The following CRDB input selects track K.
02 POD KLAX
03 POA VHHH
06 ROUTE RT/PACK/TOS
Example:
Route explanation: The following CRDB input selects track L.
02 POD KLAX
03 POA VHHH
06 ROUTE RT/PACL/TOS
AUSOTS Tracks
The AUSOTS tracks are flexible tracks published daily across Australia to and from the three
main airports in eastern/southern Australia (YMML, YSSY and YBBN). There are three
different AUSOTS groups currently ingested daily into JetPlan:
• GROUP A – South/East Australia to/from Southeast Asia

• GROUP B – South/East Australia to/from Middle East
• GROUP E – Perth (YPPH) to/from Brisbane (YBBN)
For each group, both Eastbound and Westbound tracks are published. Each track has a specific
valid time that varies in begin time, but most (if not all) end at 2200Z daily.

190
Route Commands
To use the AUSOTS tracks in JetPlan, the following inputs are used (independent of direction
of flight):
GROUP A – J/AA/J
GROUP B – J/AB/J
GROUP E – J/AE/J
A copy of the current AUSOTS tracks can be retrieved in JetPlan by using the following input
on the Options command line:
IFS,AUSOTS
A sample track message follows:
01 OPTIONS ifs,ausots
20 COMPUTING 0626
(TDM TRK XB13 091111060001

0911110900 0911112200
ELATI MUTMI 07S097E TATOD NODAB METAB BRISO BIGUP CESCI GEKKO
ANZAC LATOM TAVEV TAM
RTS/TAM V327 HAWKE Y491 SMOKA Y177 BN YBBN
RMK/AUSOTS GROUP B
(TDM TRK XM13 091111060001

0911120900 0911122200
DADAR 07S085E 11S090E 14S095E 17S100E 20S105E SWAGY TINDA NALAR
HITCH CLAMY RUFLE BUNGY MTG
RTS/MTG Y53 WENDY V279 ML YMML
RMK/AUSOTS GROUP B
(TDM TRK XS13 091111060001

0911110900 0911112200
DADAR 07S085E 11S090E 14S095E 17S100E 20S105E WONSA 25S118E
BUNNY LEC SAPED NEWMO EKKEY
RTS/EKKEY J141 PKS H319 TARAL Y59 SY YSSY
RMK/AUSOTS GROUP B
(TDM TRK BY1A 091111120001

0911111100 0911112200
MORRO ROM TAVEV VINAX PARTY MONIC 14S130E KIKEM
RTS/YBBN BN G326 MORRO
RMK/AUSOTS GROUP A

191
Route Commands
(TDM TRK MX13 091111110001

0911111100 0911112200
ROBET WHA RUSAD 26S127E NONAX MELBO SAPDA
RTS/YMML ML H164 KEPPA Q168 ROBET
RMK/AUSOTS GROUP B
(TDM TRK MY1A 091111120001

0911111100 0911112200
ROBET OJJAY PUGUT ROOKS DUBIS JUGGL PONTI ATMAP
RTS/YMML ML H164 KEPPA Q168 ROBET
RMK/AUSOTS GROUP A
(TDM TRK SY1A 091111120001

0911111100 0911112200
NYN POLEV AS TIMMI 17S125E ITCHY ATMAP
RTS/YSSY SY H202 RIC UH226 NYN
RMK/AUSOTS GROUP A
(TDM TRK YB1A 091111120001

0911111300 0911112200
ONOXA TOBIE MONIC TASHA EML
RTS/EML UY409 EAGLE Y177 BN YBBN
RMK/AUSOTS GROUP A
(TDM TRK YM1A 091111120001

0911111300 0911112200
SAPDA MELBO NONAX 28S130E RUSAD WHA HINDY
RTS/HINDY Y12 ARBEY H119 ML YMML
RMK/AUSOTS GROUP A

REQUEST NO. 0626
Route Input Limits

The Route Optimizer has a finite limit to the number of input elements that can be entered on
each flight plan request. The maximum number of input elements is 18. This is true whether
entering elements on the RTD segment only, or on all three route segments (RTD, RTW and
RTA). In addition, there is a total limit of 408 characters, including spaces, for any kind of
route input—route optimizer, SRS, or combination.

192
Route Commands
POD and POA in the Same Route Area

When both the POD and the POA are in the same route area, and all of the waypoints entered
on the RTD are in the same area, the following rules apply:
• The entry “D” counts as a route element against your 18 possible inputs
when it is the first input, the second input (for example, J,D), or the last
input on the RTD segment.
• For waypoints only: you can specify 10 waypoints in succession.
• For waypoints and one or more “D” entries: you can specify 11 waypoints in
succession, if the string of 11 waypoints is preceded or followed by a “D”.
• The airway entry “J” does not count as a route element against your 18
possible inputs.
Example:
Limit explanation: 10 waypoints.
02 POD KSEA
03 POA KBGR
06 ROUTE BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK
Example:
Limit explanation: 11 waypoints, D, 7 waypoints.
02 POD KSEA
03 POA KBGR
06 ROUTE BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK,
EMG,D,LIT,PXV,ROD,DJB,JHW,SYR,PLB
Example:
Limit explanation: 11 waypoints, D.
02 POD KSEA
03 POA KBGR
06 ROUTE BTG,LMT,EHF,PMD,BLH,GBN,SSO,ELP,INK,SAT,IAH,D
Example:
Limit explanation: D, 11 waypoints, D, 5 waypoints, D = 18 elements.
02 POD KSEA

193
Route Commands
03 POA KBGR
06 ROUTE D,BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK,
EMG,D,LIT,PXV,ROD,DJB,JHW,D
POD and POA in Different Route Areas

When the POD and the POA are in different route areas, the rules stated above apply with the
following exceptions:
• The route input “D” does not count when it is the last route element on the
RTD segment. It does count as an element on the RTD when it is the first or
the second entry (when preceded immediately by a “J”).
• The entry “D” does not count when it is the first route element on the RTA
segment, or when it is preceded immediately by a “J”. (It does count as an
element when it is the last entry on the RTA.)
And the following inclusion:
• Each overwater waypoint and latitude/longitude fix (RTW segment entries)

counts as one route element.
Example:
Limit explanation: Airways through Area 5 = 0 elements (the “J” does not count); Area 0 = 0
elements; Area 1 = 11 waypoints, D, 7 waypoints; total = 18 elements.
02 POD PHNL
03 POA KBGR
06 ROUTE J//OAK,SNS,RZS,LAX,BLH,ELP,INK,SAT,IAH,
LFK,EMG,D,LIT,PXV,ROD,DJB,JHW,SYR,PLB
Example:
Limit explanation: Area 5 = 1 waypoint; Area 0 = 0 elements; Area 1 = 10 waypoints, D, 7

waypoints; total = 18 elements.
02 POD PHNL
03 POA KBGR
06 ROUTE J,CKH,D//J,OAK,RZS,LAX,BLH,ELP,INK,SAT,
IAH,LFK,EMG,D,LIT,PXV,ROD,DJB,JHW,SYR,PLB

194
Route Commands
Example:
Limit explanation: Area 1 = 2 waypoints; Area 0 = 11 waypoints; Area 4 = 4 waypoints, D;

total = 18 elements.
02 POD KLAX
03 POA RJAA
06 ROUTE J,SNS,D,OSI,D/
ALCOA,3800,13000,3900,14000,4100,15000,4200,16000,4100,17000,
4100,18000,4000,-17000,4000,-16500,4000,-16000,CALMA/
J,D,COMFE,D,VACKY,PETAL,CVC,D

195
Route Commands
National Route Program (NRP) Option

NRP refers to the FAA National Route Program, which allows flights operating at or above
FL290, within the conterminous U.S., and regardless of city pairs, to participate in minimum
time/cost routes, without route limiting restrictions (Free Flight).
The NRP option in JetPlan conforms to all FAA rules, up to and including the latest Advisory
Circulars. The option provides the following features:
• The NRP transition points are either: (a) NRP approved transition points
from the list of SIDs and STARs provided by the FAA (see AC 90-91B,
Appendices 1 and 2), or (b) the closest checkpoints, at least 200 nautical
miles (nm) from the POD and POA, on the optimal NAVAID route.
• Checkpoints on the NRP portion of the flight are in Fix-Radial-Distance
format.
• Checkpoints are inserted for ARTCC reporting requirements as follows: (a)
each ARTCC contains at least one checkpoint; if an ARTCC is entered and
exited multiple times, each segment within the ARTCC contains at least one
checkpoint; (b) each ARTCC has a checkpoint within 200nm of the flight’s
entry point into the ARTCC.
• The NRP flight plan avoids active restricted areas, including 3D Avoid
regions. In respect to 3D Avoid regions, the flight plan either avoids the area
completely or transitions from NRP to NAVAID structure and flies valid 3D
Avoid deviation radials, avoiding the blocked altitudes for the area. A flight
plan might transition from NRP to NAVAID structure to traverse an active
3D Avoid area and then transition back to NRP after clearing the area.
• NRP is entered on all domestic flight plan filing strips.
• In the event that the optimal route transits Canadian airspace (for example,
on a Boston to Seattle flight), the NRP flight plan can make the transition
from NRP routing to Canadian RNAV routing and back again.
NRP Usage
NRP is activated by entering NRP on the Options command line. For a domestic flight plan,
route inputs are not necessary unless specifying a published preferred IFR route for that
portion of the flight that is within the 200nm boundary of the POD (egress) or POA (ingress).
Flights can be filed and flown on the complete transition of SIDs or STARs for the airport
areas listed by the FAA, in lieu of the 200nm ingress/egress filing requirements.

196
Route Commands
For an international flight plan, route inputs are not necessary for that portion of flight within
the conterminous U.S. However, routing on the overwater and the international portions are
input as normal.
Example:
NRP routing in Area 1—no inputs, optimum eastbound NAT track, European preferred
routing in Area 2.
02 POD KLAX
03 POA EGLL
06 ROUTE /Z/P
NRP Output
An NRP flight plan has output that includes a route summary line that clearly indicates the
NRP route, and a filing strip (if requested) that clearly indicates that the flight is an “NRP”
plan. See the NRP plan on the next page.
Route Summary Line

Note that the route summary line (below) shows the NRP portion in fix-radial-distance format.
The portions immediately preceding and then following the NRP portion is the preferred
NAVAID structure routing. The points CFB and PGS are the required transitions, positioned
at least 200nm from the POD and POA.
Immediately below the route summary line, in parentheses, is the indication of inserted
waypoints. In the event the flight plan passes through one or more (ARTCC) traffic centers
without the normal JetPlan calculation of an “optimized direct waypoint,” then one or more
are inserted so that NRP rules are followed. In the example below, one waypoint was inserted
between CFB and DKK278032 (BUF200033), and one was inserted between CRL295073 and
BDF340053 (IOW292060).
KBOS VECTOR..BAF..HNK..CFB..BUF200033..DKK278032..CRL295073..
IOW292060..BDF340053..DSM253062..HYS324076..PUB303038..PGS J128
CIVET CIVET4 KLAX
(DIR RTE CRB-DKK278032)
(DIR RTE CRL295073-BDF340053)

197
Route Commands
Filing Strip
Highlighted at the bottom of the NRP plan output, and shown separately below, is the ATC
filing strip. On the NRP domestic flight plan, the designation NRP is clearly displayed. No
such designation occurs on an NRP international flight plan at this time.
FP H/B74B/ 502 BOS 0000 350

BOS..BAF..HNK..CFB..DKK278032..CRL295073..BDF340053..DSM253062..
HYS324076..PUB303038..PGS.J128.CIVET.CIVET4.LAX/0457 :NRP

198
Route Commands
Non-Restrictive Routing
JetPlan supports the use of Non-Restrictive Routing (NRR). NRR supports point-to-point
navigation, rather than requiring flights to traverse existing airway structures such as Jet
airways. Flights with adequately equipped aircraft operating at or above FL350 (configurable)
in U.S. airspace can maximize efficiency, choosing points along their path to report in a flight
plan.
High-Altitude Redesign
NRR allows aircraft to fly optimal routes in High-Altitude Redesign (HAR) airspace, which
takes its name from the FAA program that has implemented fundamental changes in
navigation structure and operating methods away from using ground-based NAVAIDs to
leveraging the flexibility of point-to-point navigation. In HAR airspace, operators can opt to
fly outside of structured routing using the NRR options.
HAR Phases
The first two phases of the FAA HAR program have been implemented. The program has the
following characteristics:
• Applies to aircraft with equipment accompanying transponder suffixes E, F,

G, and R
• Enables point-to-point navigation
• Is restricted to altitudes of FL350 and above (in JetPlan, this is configurable)
• Supports waypoint navigation around Special Use Airspace (SUA)
• Uses high-altitude RNAV routes (Q Routes)
• Implements a reference grid of waypoints for flight navigation planning
called Navigation Reference System (NRS)
Supports user-defined NRR, including entering/exiting HAR airspace via “pitch and catch”
points. If no pitch and catch points are available, appropriate SID/STAR endpoints can be
used. Figure 6.6 shows HAR airspace as of 2007 and which centers are part of the airspace.

199
Route Commands
Figure 6.6. HAR Airspace in 2007
NRS Waypoints
NRR is characterized in a flight plan through the identification of one waypoint per Air Route
Traffic Control Center (ARTCC) in HAR airspace. To support NRR, the FAA developed the
NRS, a grid of waypoints and waypoint naming conventions to serve as the navigation
structure for HAR. See Figure 6.7 for an illustration of the waypoint naming convention.
KD54W is a waypoint, where:
• K represents the FIR (USA)

• D represents the center or sub-FIR (Denver)
• 54 represents the latitude (lat 39 00’)
• W represents the longitude (104 degrees west longitude)

200
Route Commands
Figure 6.7. NRS Waypoints and Naming Convention
High-Altitude RNAV Routes (Q Routes)

As part of the HAR program, the FAA introduced high altitude RNAV routes. The FAA also
refers to these routes as preferred IFR routes. The use of RNAV facilitates less restrictive
routing than is commonly available with navigation via radar vectors. This allows for more
efficient routing through high-density corridors. “Q” is the International ICAO-assigned
designator for a published RNAV route in Canada or the U.S. Q routes are spaced more
closely than standard airways, allowing additional routes in the same airspace, and fewer
conflicts between routes. Q-routes can have direction, flight level, equipment, and time
constraints associated with them.
Pitch and Catch Points

The FAA has defined points, called pitch and catch points, for getting into and out of HAR
airspace. The pitch points indicate an end of a departure procedure, a preferred IFR routing, or
other established routing program where a flight can begin a segment of NRR. The catch point
indicates where a flight ends a segment of NRR and joins published arrival procedures,

201
Route Commands
preferred IFR routings, or other established routing programs. For the portion of the route in
between the pitch and catch points, NRR is permitted. If no pitch and catch points are
available, appropriate SID/STAR endpoints can be used.
The FAA has defined a Vertical Pitch Line (VPL) to indicate the boundary for flights to begin
NRR in HAR from the East coast of the U.S. Because of the density and traffic, there are few
pitch points defined for airports east of the VPL. Flights originating outside of HAR airspace
and flying westbound cannot pitch into HAR until they fly to the VPL. However, flights
originating west of the VPL and flying eastbound can catch out of HAR through catch points
located throughout the area east of the VPL. North/south routes outside of HAR airspace are
not permitted for HAR. The FAA has chosen to keep existing airway structures in place when
flying in the densely populated eastern Air Traffic Control Centers.
NOTE You can find the pitch and catch points and VPL in the airport/facility
directory.
NRR Levels of Service

The two levels of NRR service are as follows:
HAR When the aircraft has all NRS waypoints in its flight management
systems (FMS) and is RNAV-equipped, the flight plan can be filed as
full-service capability HAR. Depending on the configuration of the
NRRPRC customer preference (see “Customer Preferences
Database” on page 204), “HAR” appears in the filing remarks of
these flight plans.
Point-to-Point When the aircraft has the traditional waypoints (not the NRS
waypoints) in its FMS and is RNAV-equipped, the flight plan can be
filed as limited-service capability PTP. You can also choose to

202
Route Commands
request a PTP flight plan for an aircraft that is NRS-capable.

Depending on the configuration of the NRRPRC customer preference
(see “Customer Preferences Database” on page 204), “PTP” appears
in the filing remarks of these flight plans.
NOTE The flight plan can be filed as a National Route Program (NRP) plan when
the following are true: The aircraft is RNAV equipped, the FMS does or does not
recognize NRS waypoints, the initial cruise is a flight level above 29,000 feet and
below 35,000 feet, and the route of flight contains at least one published waypoint per
each ATC center. In this case, “NRP” appears in the ATC filing remarks, depending
on the configuration of the NRRPRC customer preference. For more information
about NRP, see “National Route Program (NRP) Option” on page 196
For additional information on NRR and the HAR redesign program, refer to FAA Advisory
Circular AC 90-99.
NRR Flight Planning Guidelines

The following guidelines apply to NRR flight planning with JetPlan:
• (Required) The aircraft must be RNAV-equipped. JetPlan checks the

aircraft’s RNAV value in the Customer Aircraft Database (CADB). If the
RNAV parameter is set to No, the system alerts you that the aircraft is
unable to create an NRR flight plan.
• The aircraft has the NRS waypoints (required for HAR plans) or traditional
waypoints in its FMS. If you request an NRR flight plan with HAR, JetPlan
checks the value of the NRS-Capable parameter in the CADB. If NRS
Capable is set to No, JetPlan generates a HARSET01 error.
• (Required) The route of flight contains at least one NRS waypoint or
NAVAID per each Air Route Traffic Control Center (ARTCC). You can
allow JetPlan to generate the route, or you can input an SRS route.
• (Required) An initial cruise of FL350 and above. This is a configuration
item in the Customer Preference Database (see “Customer Preferences
Database” on page 204).
NOTE JetPlan currently checks for RVSM for aircraft to fly between FL290 and
FL410.

203
Route Commands
• (Optional) The use of pitch and catch points. You can use pitch and catch
points by entering PITCAH on the Options command line or through the
front-end flight planning software. If you do not enter the pitch and catch
command directly on the flight plan request, JetPlan checks the Pitch-Catch
parameter for the indicated city pair in the City Pair Fleet Database
(CPFDB). If the Pitch-Catch parameter is set to Yes, the system generates a
flight plan request for an NRR-optimized flight plan using pitch and catch
points.
NRR Setup Guidelines

This section describes how your JetPlan preferences and customer databases are configured to
support NRR flight planning.

The Customer Preferences Database, which is not customer-controlled, contains the following
options that apply to NRR:
Non-Restrictive Specifies a flight level floor for non-restrictive routing. This is the
Routing Flight initial cruise an aircraft must reach to file an NRR flight plan as HAR
Level Floor or PTP. The default value is FL350.
(NRRFLF) –
Non-Restrictive Specifies an FAA preferential route check for NRR. Determines

Routing whether the system bases the NRR ATC filing remarks off of the
Preferential Route existence of an FAA Preferential Route. The default value is Yes.
Check (NRRPRC)
This configuration item allows operators the flexibility to file NRR
routes, whether or not FAA preferential routes exist. If the
configuration is set to Yes, and an FAA preferential route exists, then
the system files an NRR-appropriate remark in the ATC filing
remarks field (“HAR,” “PTP,” or “NRP”). However, if the
configuration is set to Yes, and an FAA preferential route does not
exist, then the system does not file an NRR-appropriate remark in the
ATC filing remarks field. If the NRRPRC configuration is set to No,
it does not matter if an FAA preferential route exists; NRR remarks
are always in the ATC filing remarks field.

204
Route Commands
NAVALERT Aircraft flying NRR routes must be RNAV-equipped, as indicated by

the setting of the RNAV parameter in the Customer Aircraft Database
(CADB). The functionality associated with the RNAV setting
requires the NAVALERT customer preference to be set. When the
NAVALERT preference is set, and the RNAV parameter is set to a
value other than Terminal and Enroute, the system optimizes to avoid
RNAV segments beyond the navigational capabilities of the aircraft.
If the system looks for and cannot find such a route, it fails the flight
plan calculation and returns an error. If you specify a route that
includes RNAV segments that exceed the RNAV capability of the
aircraft, an alert is returned with the flight plan.
Customer Aircraft Database (CADB) – Equipment Section

The Customer Aircraft Database, which is customer-controlled, contains the following options
that apply to NRR:
NRS Capable (NR) When set to Yes, the aircraft’s navigational database contains the
NRS points for the HAR program. This parameter must be set to Yes
for an aircraft to be used in a HAR flight plan that uses the NRS
points. If NRS Capable is set to No, JetPlan generates a HARSET01
error when you request the HAR flight plan.
RNAV (RE) This parameter indicates whether or not the aircraft has RNAV
equipment onboard. This parameter must be set to Terminal and
Enroute (T or Y in JetPlan command-line mode) or Enroute (E in
JetPlan command-line mode) to access RNAV routing. If the RNAV
parameter is set to No, the system alerts you that the aircraft is unable
to create an NRR flight plan.
NOTE The functionality associated with the RNAV setting requires the NAVALERT
customer preference to be set. For information about the NAVALERT preference, see
“Customer Preferences Database” on page 204.

205
Route Commands
City Pair Fleet Database

The City Pair Fleet Database, which is customer-controlled, contains the following option that
applies to NRR:
Pitch-Catch (PC) This parameter determines whether JetPlan uses available pitch and
catch points when creating a NRR flight plan for a given city pair and
fleet type. When you request an NRR-optimized flight plan but do not
indicate the use of pitch and catch points on the JetPlan Options
command line or through a front-end flight planning system, JetPlan
looks for the value of the Pitch-Catch flag in the CPFDB for the
indicated city pair and fleet type. If the Pitch-Catch flag is set to Yes,
the system generates a flight plan request for an NRR-optimized
flight plan using pitch and catch points.
About the NRR Options

NRR is activated by entering NRR on the Options command line. Other inputs, along with the
values in the customer and preference databases, determine whether the flight plan is filed as
HAR, PTP, or NRP. The following paragraphs illustrate use of these options.
NRR with HAR

In this example, either an FAA preferential route exists for the city pair and the NRRPRC
preference is set to Yes, or the preference is set to No and the existence of a preferential route
is irrelevant— in either case, “HAR” appears in the flight plan. The flight level is at or above
the value set by the NRRFLF customer preference.
Example:
Explanation: NRR on the Options command line requests NRR remarks and “H” on the Route
Command (06 ROUTE) line requests an NRS Optimized route (using the NRS waypoints).
01 FP,NRR
02 POD KSFO
03 POA KORD
06 ROUTE H

206
Route Commands
Output
The resulting HAR flight plan has a route summary line containing the NRS waypoints.
KSFO..SAC..HAROL..KU66K..KU69M..KU72O..KU75Q..KD78U..KD81Y..KP81A..KP81C..KP81E..K
P81G..KP81I..KG81K..DLL..MSN..JVL JVL5 KORD
The HAR remark in the filing strip indicates the crew is willing and the aircraft is capable of
accepting a re-route including NRS points.
(FPL-N901AN-IS
-B738/M-SXDIRGHW/S
-KSFO0100
-N0455F390 DCT SAC DCT HAROL DCT KU66K DCT KU69M DCT KU72O DCT
KU75Q DCT KD78U DCT KD81Y DCT KP81A DCT KP81C DCT KP81E DCT KP81G
DCT KP81I DCT KG81K DCT DLL DCT MSN DCT JVL JVL5
-KORD0342
-EET/KZLC0042 KZDV0145 KZMP0219 KZAU0311
REG/N901AN SEL/ACBJ DAT/V
RMK/HAR)
If the NRRPRC preference is set to Yes, and an FAA preferential route does not exist, the
following alert appears, and “HAR” does not appear in the remarks:
ALERT TAG NRR01
ALERT MSG No NRR Remarks are used because a FAA Pref Route does not
exist.
Pitch and Catch Points in an NRS-Optimized Route
Example:
Explanation: PITCAH on the Options command line requests use of catch and pitch points in
the NRS-optimized route. The route contains a catch point for Denver.
01 OPTIONS FP,NRR,PITCAH
02 POD KLAX
03 POA KDEN
06 ROUTE H
Note that JetPlan observes the Vertical Pitch Line.

207
Route Commands
Example:
Explanation: The route uses NRS points beyond the Vertical Pitch Line only.
01 OPTIONS FP,NRR,PITCAH
02 POD KMIA
03 POA KLAX
06 ROUTE H
NRR with PTP

In this example, either an FAA preferential route exists for the city pair and the NRRPRC
preference is set to Yes, or the preference is set to No and the existence of a preferential route
is irrelevant— in either case, “PTP” appears in the flight plan. The flight level is at or above
the value set by the NRRFLF customer preference.
Example:
Explanation: NRR on the Options command line requests NRR remarks and nothing on the
ROUTE 06 requests a “NAVAID optimized” flight plan that does not use the NRS points.
01 FP,NRR
02 POD KSFO
03 POA KORD
06
Output
The resulting PTP flight plan has a route summary line containing the waypoints and the
“PTP” remark in the filing strip.
If the NRRPRC preference is set to Yes, and an FAA preferential route does not exist, “PTP”
does not appear in the filing strip and the following alert displays.
ALERT TAG NRR01
ALERT MSG No NRR Remarks are used because a FAA Pref Route does not
exist.

208
Route Commands
NRR with SRS Routing

The specified route might use NRS waypoints.
Example:
01 OPTIONS FP,TST,WH06,NRR
02 POD KSFO
03 POA KORD
06 ROUTE -SAC HAROL KU66K KU69M KU72O KU75Q KD78U KD81Y KP81A KP81C
KP81E KP81G KP81I KG81K DLL MSN JVL JVL5
(FPL-N901AN-IS
-B738/M-SXDIRGHW/S
-KSFO0100
-N0455F390 DCT SAC DCT HAROL DCT KU66K DCT KU69M DCT KU72O DCT
KU75Q DCT KD78U DCT KD81Y DCT KP81A DCT KP81C DCT KP81E DCT KP81G
DCT KP81I DCT KG81K DCT DLL DCT MSN DCT JVL JVL5
-KORD0342
-EET/KZLC0042 KZDV0145 KZMP0219 KZAU0311
REG/N901AN SEL/ACBJ DAT/V
RMK/PTP)
NRR and NRP

“NRP” appears as a remark in the filing strip when the following are true:
• The NRR remarks are requested.

• The route is computed either as NRS optimized (HAR) or as NAVAID
optimized (PTP).
• Either an FAA preferential route exists for the city pair and the NRRPRC
preference is set to Yes, or the preference is set to No and the existence of a
preferential route is irrelevant.
• The flight level is below the NRR flight level set by the NRRFLF customer
preference but at or above the flight level set for NRP.
For more information on NRP, see “National Route Program (NRP) Option” on page 196.
MEL RNAV Degradation and NRR

It is possible that an MEL item overrides the setting of the RNAV parameter in the CADB for
an aircraft used in an NRR flight plan. The RNAV Degradation parameter in the MEL
Database record determines the level, if any, of RNAV degradation that might apply to the

209
Route Commands
RNAV setting in the CADB. When the RNAV Degradation parameter is set to Terminal, the
flight plan is calculated with no terminal RNAV capability. When the parameter is set to All,
the flight plan is calculated with no RNAV capability at all. For more information, see
Chapter 38, “Minimum Equipment List Database.”.
The RN and NORN flight plan options override the Customer Aircraft Database (CADB)
setting for RNAV and ignore any MEL degradations that have been applied to RNAV. If an
MEL item exists that degrades the RNAV capability, JetPlan returns an alert on the NRR flight
plan. For more information, see Chapter 6, “Route Commands.”

210
Route Commands
About the Specific Route Selector

The input methodologies of the Route Optimizer are substantially different from those of the
Specific Route Selector (SRS). SRS requires no keywords (for example, RTD, RTW, RTA),
no knowledge of route areas (for example, Area 1 and Area 2), and no input type options to
remember (for example, J,D,ABC,P/Z/J). It is separate and independent of the Route
Optimizer. Nevertheless, SRS does have its own syntax rules and guidelines to follow. This
section describes that information.
SRS provides a very useful method for entering a route between any two points (airports or
waypoints). You define the route of flight with your explicit inputs. Enter each NAVAID and
airway element sequentially, as you would file a flight plan with ATC. Simply specify the
route, start to finish, and you get an output that matches your input.
In addition, low and high altitude airway segments might be combined in one route request.
By specifying an entry waypoint, the published high (or low) altitude airway, and an exit
waypoint, you define the desired route of flight on the airway structure of your choice. If
desired, you can also specify as many enroute waypoints as necessary. SRS builds great circle
segments using your specified inputs.
NOTE If necessary, there is a method for combining SRS and Route Optimizer
inputs, which is discussed in “Combination (SRS – Route Optimizer) Routing” in this
chapter.
SRS provides the following features:
• Independence from Route Optimizer conventions if desired.

• SRS inputs can be used to create Customer Route Database (CRDB) files.
• Ability to specify waypoints that are considered “terminal” waypoints (an
ARINC 424 standard.)
• Ability to delineate SID/STAR route information in the flight plan output,
including each fix and track to a fix. The fix data is obtained from the
Jeppesen Aviation Database (ARINC 424 standard).
• Ability to work in conjunction with the Route Optimizer if necessary. This
provides flexibility in that portions of the route can be dynamically
constructed using the Route Optimizer, while other portions are explicitly
defined using SRS.
• Ability to accept and interpret both IATA and ICAO identifiers from your
POD, POA, Hold, Alternate, and Reclear inputs.

211
Route Commands
The Navigation Database

SRS navigational data originates in the Jeppesen Aviation Database (JAD). Specific data is
extracted from JAD and placed in a file formatted to ARINC 424 standards, where it can be
used for flight planning purposes. The converted database file contains worldwide airport,
airway, and waypoint information.
SRS has no “route area” concept to consider. All airports, airways, and waypoints are defined
in the same data source, meaning that there are no subsections (route areas) to worry about.
SRS Facts and Guidelines

When requesting an SRS route, be aware of the following input guidelines:
• Route inputs are limited to a total of 408 characters, including spaces.

• SRS route inputs are entered as they would be filed with ATC. The route is
defined by entering both the airway and the waypoint names in the order of
flight. The names entered on the Route command line need to be loaded in
the navigation database.
• Lat/long coordinates not associated with airway structures can be entered as
part of your route input.
• NAVAID radial/distance fixes (RNAV waypoints) not associated with
airway structures can also be entered as part of your route input.
• All waypoint name inputs must be entered according to their charted
(external) name. If the charted name exists more than once in the navigation
database, SRS selects the waypoint closest in proximity to the previously
entered waypoint.
• Waypoints can be entered using latitude/longitude coordinates. You can also
include a name to be associated with the entered coordinate.
• A route can be created, all or in part, based on the entry and exit waypoints
to one or more published airways.
• Both high and low altitude waypoint names can be included in the same
SRS route input.

212
Route Commands
• If needed, you can clarify a waypoint external name entry by further

defining the entry using modifiers. There are two basic types of modifiers:
“NAVAID type” and “coordinate approximation.” NAVAID type modifiers
are used to differentiate between two waypoints that are different NAVAID
types, but are located in close proximity to each other.
There are three NAVAID type modifiers that can be appended to your
waypoint entry: VOR, NDB, or FIX. Coordinate approximation modifiers
are latitude/longitude inputs appended to your waypoint name entry to help
the Specific Route Selector locate the waypoint.
• When applying a coordinate approximation modifier, SRS uses your
modifier to determine the waypoint. It then uses the coordinates from the
navigation database, rather than your approximation, to complete the route
calculation.
• Static track structures can be used with SRS.
• You can specify an airway name between two waypoints stored in the
navigation database, or between two waypoints defined by you.
• You can specify a coded departure route.
SRS Syntax Rules

The following syntax rules are applied during the input of an SRS route. Please contact
Jeppesen Customer Service to resolve any questions regarding route input.
The Dash Delimiter

The most important syntax rule to remember is to always begin an SRS input with a dash (for
example, -OSI V25 PYE). If the dash is omitted, JetPlan does not recognize the route entry as
an SRS input, but rather as a Route Optimizer input, leaving you with invalid inputs for the
route selection tool in use.
Example:
Explanation: The dash delimiter (-) is always the first entry in an SRS route input. It designates
that the SRS tool is being implemented.
06 ROUTE -OSI V25 PYE

213
Route Commands
Input Styles
Two different route input styles can be employed when entering an SRS route. The first style
resembles the route syntax found in an ICAO flight plan filing request, where each route
element (airway name, NAVAID or waypoint name) is separated from the next by a space.
The second style resembles the route syntax found in a U.S. domestic flight plan filing request,
where each route element is separated from the next by a period.
Example:
Explanation: ICAO style—a blank space separates each route element.
06 ROUTE -J16 BIL J151 ONL J94 OBK
Example:
Explanation: U.S. Domestic style—a single period separates each route element.
06 ROUTE -J16.BIL.J151.ONL.J94.OBK
NOTE When using the U.S. Domestic input style, one period is entered between
dissimilar route elements (for example, airway.navaid.airway.way-point). However,
similar route elements are separated by two periods (for example,
airway..airway.navaid.airway..airway.navaid).
Example:
Explanation: U.S. domestic style—two periods separate similar route elements, while a single
period separates dissimilar elements.
06 ROUTE -J16..J52.DBS.J82..J107.DPR.J34.BAE
Starting/Ending Route With a Waypoint

If a NAVAID or waypoint is entered immediately after the dash, SRS creates a direct segment
from the POD to that point. Similarly, if a NAVAID or waypoint is included as the last
element in the route input, SRS creates a direct segment to the POA.

214
Route Commands
Example:
Explanation: SRS creates a direct to the NAVAID DAG, and a direct from the NAVAID DVV
to the POA.
02 POD KLAX
03 POA KDEN
06 ROUTE -DAG J146 HBU J10 DVV
Starting/Ending Route With an Airway

If an airway identifier (or SID) is entered immediately after the dash, then SRS uses that
airway (or SID) to begin the route. Similarly, if an airway identifier (or STAR) is included as
the last element in the route input, SRS uses that airway (or STAR) to the POA.
Example:
Explanation: SRS uses the LOOP9 SID to DAG.
06 ROUTE -LOOP9 DAG J146 HBU J10 DVV
Jeppesen defines a circle around each NAVAID during the JetPlan route database build
process. The circumference of the circle is in nautical miles and is determined by Jeppesen. If
the POD (or POA) is not located within the NAVAID circle of a NAVAID on the specified
airway, an error occurs.
Example:
Explanation: In this case, the POD does not reside within a nearby NAVAID circle on J16, so
a route error occurs.
02 POD KPDX
03 POA KORD
06 ROUTE -J16 MCW J90 BRIBE
To alleviate this problem, a NAVAID must be entered before the airway on the departure.
Example:
Explanation: By adding the NAVAID BTG to the start of the SRS route input, a direct
segment is created and the subsequent route becomes acceptable.
06 ROUTE -BTG J16 MCW J90 BRIBE

215
Route Commands
Using similar logic, a NAVAID must be entered after the airway on the arrival if the POA is
not within the NAVAID circle.
Example:
Explanation: In this case, the POA does not reside within a nearby NAVAID circle on J16, so
a route error occurs.
02 POD KORD
03 POA KPDX
06 ROUTE -BRIBE J90 MCW J16
Explanation: By adding the NAVAID BTG to the end of the SRS route input, a direct segment
is created and the subsequent route becomes acceptable.
06 ROUTE -BRIBE J90 MCW J16 BTG
SRS Input Types

This section discusses all of the types of inputs that can be entered using the SRS
methodology. The following paragraphs include examples of these inputs.
Latitude and Longitude Entries

The following sections describe latitude and longitude entries.
Unnamed Latitude and Longitude Entries

To specify latitude, you can prefix or suffix any of the following coordinate entries with the
letter N for North or S for South:
• One or two digits, assumed to be degrees.

• Optionally, three or four digits, the last two digits assumed to be minutes.
• Optionally, enter a period and a single digit for tenths of a minute.
The latitude coordinate, 3712.4N, can be entered using any of the following formats:
N37 N3712 N3712.4 3712N

216
Route Commands
To specify longitude, you can prefix or suffix any of the following coordinate entries with the
letter W for West, or E for East:
• One to three digits assumed to be degrees.

• Optionally, four or five digits, the last two digits assumed to be minutes.
• Optionally, input a period and a single digit for tenths of a minute.
The longitude coordinate 09823.6W can be entered using any of the following formats:
W98 W098 W9823 W09823

W9823.6 W09823.6 98W 09823.6W
To specify a complete coordinate, use the guidelines described above. You can include a slash,
space, or comma between the latitude entry and the longitude entry. However, these separators
are not required. For example, to specify the coordinate 3712.4N/09823.6W, enter any of the
following:
N37W98 N37W098 N3712W9823

N3712W09823 N3712.4W9823.6 N3712.4W09823.6
N3712.4 W09823.6
User-Named Latitude and Longitude Entries

For user-named waypoints, apply the rules described in “Unnamed Latitude and Longitude
Entries” on page 216 to specify the coordinates. Then, prefix the latitude and longitude entry
with a four-to-five character name inside parentheses. For example, to attach a name to
3712.4N/09823.6W, you can use either of the following formats:
• (pt01)N3712W9823
• (pt01)N3712.4W09823.6

217
Route Commands
Guidelines for Naming Waypoints
Outside of China, the following guidelines apply to user-defined waypoint names:
• Waypoint names can consist of four-to-five alphanumeric characters.

• Waypoint names that include at least one number display as the latitude and
longitude coordinates in the ICAO filed flight plan (FPL).
• Waypoint names that include only letters display as the user-defined names
in the FPL.
Inside China, the following guidelines apply to user-defined waypoint names:
• Waypoint names can consist of four-to-five alphanumeric characters.

• Alphanumeric waypoint names display as the defined names in the ICAO
FPL.
Example
The following example shows two user-defined waypoints on line 06 in the flight plan request.
Both waypoints use alphanumeric naming. The first named waypoint (pt13) is outside China,
and the second waypoint (pt14) is inside China. In the FPL, the first named waypoint appears
as the latitude and longitude coordinates because the name contains one number and the point
is outside China. The second named waypoint displays as the defined name (pt14) because it is
in China.
02 pod rodn
03 poa zdpd
06 route -(pt13)n2450e134 (pt14)n29e121
(fpl-pkgsh-is
-b772/h-sdghij2p2rwxyz/lb1d1
-rodn2300
-n0486f410 dct 2450n13400e dct pt14 dct
-zspd0258
-pbn/a1b1d1l1 nav/ausep rnav1 rnp5 rnp10 com/b1m1e2 sur/ea0cs2ac2
dof/190227 reg/pkgsh eet/rcaa0209 zsha0215 sel/ehfr code/f10000
per/d rmk/agcs equipped tcas equipped)

218
Route Commands
Charted (External) Name Inputs

There are a few ways to specify the charted (external) name of a waypoint. One way is to
simply enter the name as it exists on the chart. Another way is to attach modifiers to the
external name. Modifiers can describe the fix by its type—VOR, NDB, or FIX—or as an
approximation of the latitude and longitude coordinates of the waypoint.
Charted Names (No Modifier)

To specify the charted (external) name of a waypoint without modifiers, enter the one to five
(1-5) alphanumeric/special character name from the chart. Your entry must match the
waypoint name stored in the navigation database.
ALCOA APPLE RIPKI MAARI ACKIL
Charted Names Using “NAVAID Type” Modifiers

To specify the charted name of a waypoint by NAVAID type, follow the procedure established
for charted names (above), and append the NAVAID type within parentheses. A database
search is made for the waypoint whose charted name is closest to the last known position and
whose NAVAID type corresponds to the type specified (VOR, NDB, or FIX). Once found,
JetPlan uses the coordinates associated with the waypoint in the flight plan.
BNA(VOR) BNA(NDB)
Some countries have VORs and NDBs that are either collocated or located in close proximity
to each other, where airway structure is defined on the NDB in one quadrant but defined on the
VOR in another quadrant. In this case, the only way to get airway continuity is to specify the
input in the following manner:
1. Inbound airway name

2. Inbound NAVAID identifier
3. Outbound NAVAID identifier
4. Outbound airway name
If the VOR and NDB have the same identifier, then the NAVAID type modifier must be
attached. Since this can be confusing, it can be more practical to specify the inbound airway
name, inbound NAVAID name, and then a direct segment to the first waypoint or NAVAID
on the outbound airway.

219
Route Commands
In the example below, J111 is defined on the Nome VOR, whereas G212 is defined on the Ft.
Davis NDB. Both are in close proximity to each other.
Example:
Route explanation (for the points in question): Inbound on airway J111 to the Nome VOR
(OME), direct to the Ft. Davis NDB (FDV), and then outbound on airway G212 to TA.
02 POD PANC
03 POA UHMM
06 ROUTE -ANC J111 OME FDV G212 TA G212G UHMM
Charted Names Using Coordinate Approximation

To specify the charted name of a waypoint by coordinate approximation, follow the procedure
established for charted names (above), followed by the latitude and longitude (using the syntax
rules established earlier) within parentheses. A database check is made for the waypoint whose
charted name is closest to the latitude-longitude coordinate. Once the closest waypoint is
found, JetPlan uses the waypoint coordinates found in the navigation database rather than the
approximated coordinates. If you also apply a user-specified name and it does not match
anything in the database, an error message is generated. See the examples below.
GILRO(N37W121) AMERT(N4439.7W07743.1)
RNAV Waypoint Inputs

To enter an RNAV waypoint, specify the point in “Fix-Radial-Distance” format. Enter the
two- or three-character charted name of the NAVAID, followed by the radial in magnetic
degrees (001–360), and the distance from the NAVAID (in nautical miles). SRS performs a
database search for the NAVAID with the name that matches your input and that is in closest
proximity to the previously entered user waypoint.
OAK216160 RZS133024 UPP066164
Airway Name Inputs

There are two ways to specify an airway name: 1) by the charted name, 2) by a user-specified
convention. The latter is used for specific airways not recognized in the SRS navigation
database. For example, the SRS navigation database does not recognize “ATS” and “D”
airway names.

220
Route Commands
Charted Airway Names

Most airways on the charts are available for input. The method for entering these airways is to
simply specify the name in your route input as it is found on the chart. This means entering the
airway using the one to six alphanumeric characters that identify the airway. The first
character must be an alpha character. Do not insert any spaces in the airway name.
A586 W41 NCA15 PTSQ ACAO
User-Specified Airway Names

To specify an airway name that is “user-created” or not in the SRS navigation database, you
must demarcate the begin and endpoints of the airway and make a unique entry in between. Do
this by specifying the waypoint that marks your entry to the airway in question, the airway
name prefixed with a special input, and the waypoint that marks the end of the airway
segment. The prefix to the airway name is “AW/” or “AW=”. This airway input must be
within parentheses.
The following route input illustrates the user-specified designation of an airway not
recognized in the SRS navigation database.
Example:
Route explanation: Pick up the ATS airway between KCC and CU, and between CU and
OKC.
06 ROUTE -GO W18 KC (AW/ATS) CU (AW/ATS) OKC V23 IWC ...
The next route input illustrates the designation of a fictitious airway name, TRK34, between
the waypoints ALPHA and BRAVO.
Example:
06 ROUTE -(ALPHA)N40W110 (AW/TRK34) (BRAVO)N40W100
SID/STAR Name Inputs

SRS lets you enter an ARINC-424 compliant SID or STAR name (maximum of six
alphanumeric characters) in your route input. In addition, you can enter a transition waypoint
name. The inclusion of a transition waypoint forces JetPlan to consider the POD or POA
information and search the database for intermediate waypoint data.

221
Route Commands
To specify a published SID or STAR and include intermediate waypoint data, enter the SID or
STAR name (maximum of six alphanumeric characters) and the charted name of the SID or
STAR transition waypoint.
Example:
Route explanation: Pick up the LOOP2 departure to DAG, fly route, then pick up the MOD2
arrival from CZQ. By entering the transition waypoints (DAG and CZQ), intermediate
waypoint data for both the SID and STAR are included in the flight plan output.
02 POD KLAX
03 POA KSFO
06 ROUTE LOOP2 DAG...<continuing input>...CZQ MOD2
Runway Name Inputs

To specify a departure or arrival runway within a SID or STAR input, append the runway
name to the SID (or STAR) name. Use the dollar symbol ($) to separate the runway number
from the SID/STAR name and the transition name. A space (or period) separates the transition
waypoint entry from the SID/STAR/Runway input. For example:
-PORTE9$28$ AVE -GMN1$24$ AVE
The following rules apply to entering runway names:
• The runway number must always be two digits.

• Use L to designate left runway, R to designate right runway, and B to
designate a procedure common to both parallel runways. For example:
-GMN1$07L$ AVE -GMN1$24B$ AVE
– If there is no common procedure stored for two parallel runways,
SRS defaults to the left runway procedure, and then the right
runway procedure. If only the runway number is specified for
parallel runways, SRS defaults first to common procedure, and then
to the left procedure, and then to the right procedure.
– If no procedures are stored for the specified SID/STAR and runway,
or you do not specify a runway, SRS defaults to the procedure for
the lowest numbered runway for the specified SID/STAR.
– If SRS cannot find a SID/STAR input in the SRS database, but it
does find the specified SID/STAR in the Route Optimizer database,
JetPlan prints out the SID/STAR identified in the route summary
line. However, no intermediate waypoints are printed.

222
Route Commands
– It is possible to instruct SRS to go direct to all of the stored

intermediate waypoints of a published SID/STAR. JetPlan prints
out the appropriate SID/STAR name after the route is established on
either the SID or STAR. ARTCC and ACC centers might not accept
this type of routing when the automatic filing feature is used.
NAVAID/Radial Inputs
The combination of a NAVAID and a radial can be used as an SRS route input for the purpose
of furthering the route when the published airway structure does not meet your needs. A
NAVAID/radial input is a six-character entry, combining the three-letter NAVAID identifier
with a three-digit radial value. There are several ways to use a NAVAID and radial
combination as a route entry. Each is described in this section.
NAVAID/Radial Intersecting a NAVAID/Radial

To designate the point where a NAVAID/radial intersects another NAVAID/radial, enter the
intersection in the following manner:
First enter the initial enroute NAVAID from which the first radial exists. Next, enter the six-
character NAVAID/radial combination based on the initial NAVAID. Then enter the six-
character NAVAID/radial combination based on the subsequent enroute NAVAID. Lastly,
enter the subsequent NAVAID from which the other radial exists. See the examples below.
Example:
Route explanation: Beginning at the initial NAVAID, OOD, fly the 198 radial (OOD198) until
it intersects with the SBY014, and then fly the 014 radial to SBY.
06 ROUTE -OOD OOD198 SBY014 SBY
Example:
Route explanation: Same as previous example, except using U.S. domestic input style. Note
that two periods separate the similar input elements (in this case, the NAVAID/radial
combinations OOD198 and SBY014).
06 ROUTE -OOD.OOD198..SBY014.SBY

223
Route Commands
NAVAID/Radial Intersecting an Airway

To designate a route input where a NAVAID/radial intersects an airway, enter the initial
enroute NAVAID, the NAVAID/radial input, and the airway name (using the rules
established). See the example below.
Example:
Route explanation: Beginning at the initial NAVAID, DQO, fly the 306 radial (DQO306) until
it intersects with airway J110. Fly airway J110 via VINSE to the IHD310 radial, and then fly
the 310 radial to DJB.
06 ROUTE -DQO DQO306 J110 VINSE J110 IHD310 DJB
NAVAID/Radial to a Waypoint
To designate a NAVAID radial routing to or from a waypoint, specify the NAVAID/radial
entry followed (or preceded) by the waypoint. See example.
Example:
Route explanation: Overfly the PTW vortac, and then proceed via the PTW320 radial to the
RAV vortac.
06 ROUTE -PTW PTW320 RAV

06 ROUTE -PTW.PTW320.RAV
NAVAID/Radial/Distance Waypoint
To designate a NAVAID radial/distance waypoint, enter the combination of the charted two-
or three-character name of the NAVAID, the radial in magnetic degrees (001–360), and the
distance in nautical miles. This is the same rule as stated for designating RNAV waypoints.
See the examples below.
OAK216160 RZS133024 UPP066164
Great Circle Route Inputs

Great Circle routing is available using SRS. In contrast to the Route Optimizer’s “optimized
direct” routing, which approximates a great circle route on direct segments when the GC
option is specified on the Options command line, the SRS great circle capability generates a
true great circle route.

224
Route Commands
Using the Route Optimizer, a predominantly east/west great circle route is generated with
longitudinal crossings printed in multiples of ten degrees and latitudinal crossings printed in
multiples of one degree (see “Optimized Direct Routing” in this chapter). The deviation
(round-off) of the latitudinal crossings from the exact great circle position is for appearance
sake.
SRS on the other hand, generates a predominantly east/west great circle route with
longitudinal crossings printed in segments of user-defined degrees, and the exact latitudinal
crossings are printed (not rounded to whole degree values).
For example, if you request SRS to compute a flight plan from KJFK to PHNL in 10 degree
segments of longitude, SRS might cross W100 at N3858.6. If the Route Optimizer calculated a
similar route, it would deviate from an exact great circle route to cross W100 at N3900.0.
Likewise, a predominantly north/south route generated by the Route Optimizer has latitudinal
crossings printed in multiples of five degrees and longitudinal crossings printed in multiples of
one degree.
SRS on the other hand, generates a north/south route with latitudinal crossings printed in
segments of user-defined degrees, and exact longitudinal crossings printed. Again, no round-
off is done. For example, if you request SRS to compute a flight plan from FHAW to BIKF, in
5 degree segments of latitude, SRS might cross N10 at W01534.6. If the Route Optimizer
calculated a similar route, it would deviate from an exact great circle route to cross N10 at
W01600.0.
Single Segment Great Circle Route

To specify a single segment SRS great circle route (POD to POA), enter a dash (for SRS
routing) as the only route element input. With no route elements entered, JetPlan samples wind
and temperature data at only one point along the route.
Example:
06 ROUTE
Multi-Segment Great Circle Route: Latitudinal or Longitudinal Crossings

To specify a multi-segment SRS great circle route with latitudinal or longitudinal crossings at
whole degree intervals, enter the following inputs without any spaces between them: a dash
(for SRS routing), followed by the command “GR8C”, followed by a crossing interval value.
The crossing interval value must be a four-digit number. The first two digits represent a
latitude entry, while the last two digits represent a longitude entry. The entry has a nonzero
input for one directional value or the other (latitude or longitude), not both. Zeros are entered
for the direction not taken.

225
Route Commands
For a predominantly north/south route, only the first two digits (designated latitude parameter)
are used. For a predominantly east/west route, only the last two digits (designated longitude
parameter) are used. The examples below are typical of inputs necessary for predominantly
north/south routes.
Example:
Explanation: The first route input shows an entry that produces a plan with latitude crossings
every 5 degrees. The second route input shows the entry that produces a plan with latitude
crossings every 10 degrees.
06 ROUTE -GR8C0500
06 ROUTE -GR8C1000
The next set of examples are typical of inputs necessary for predominantly east/west routes.
Example:
Explanation: The first route input shows an entry that produces a plan with longitude crossings
every 10 degrees. The second route input shows the entry that produces a plan with longitude
crossings every 20 degrees.
06 ROUTE -GR8C0010
06 ROUTE -GR8C0020
Multi-Segment Great Circle Route: Latitudinal and Longitudinal

Crossings
To specify a multi-segment SRS great circle route with latitudinal and longitudinal crossings
at whole degree intervals, make the following entries without any spaces between them: a dash
(for SRS routing), followed by “GR8C”, followed by a crossing interval value. The crossing
interval value is a four-digit number specified by you. The first two digits represent a latitude
entry, while the last two digits represent a longitude entry. Each two-digit value is entered as
something greater than zero in this type of input.
Predominantly East/West Routes

For predominantly east/west routes, only the last two digits (longitude parameter) are typically
given a value greater than zero. However, to include additional waypoints, you can also enter a
value greater than zero for the first two digits (latitude parameter), thereby creating waypoints
at the specified intervals of latitude. At the additional waypoints, the longitude coordinate
values prints out in degrees, minutes, and tenths of minutes without any rounding.

226
Route Commands
Example:
Explanation: Print 10-degree intervals of longitude when flight planning predominantly

east/west, such as KJFK to PHNL. Also print additional way-points at 10-degree intervals of
latitude.
06 ROUTE -GR8C1010
Example:
Explanation: Print 20-degree intervals of longitude when flight planning predominantly

east/west. Also print additional waypoints at 5-degree intervals of latitude.
06 ROUTE -GR8C0520
Predominantly North/South Routes

For predominantly north/south routes, only the first two digits (designated latitude parameter)
are typically given a value greater than zero. However, to include additional waypoints, you
can also enter a value greater than zero for the last two digits (designated longitude parameter),
thereby creating waypoints at the specified intervals of longitude. At the additional waypoints,
the latitude coordinate values print out in degrees, minutes, and tenths of minutes without any
rounding.
Example:
Explanation: Print 5-degree intervals of latitude when flight planning predominantly

north/south, such as FHAW to BIKF. Also print additional waypoints at 3-degree intervals of
longitude.
06 ROUTE -GR8C0503
Example:
Explanation: Print 10-degree intervals of latitude when flight planning predominantly

north/south. Also print additional waypoints at 5-degree intervals of longitude.
06 ROUTE -GR8C1005
Great Circle Route Segment(s) Between Any Two SRS Waypoints

To specify one great circle route segment between any two SRS waypoints, enter either a
space (ICAO style) or two periods (domestic style) between the two waypoints. SRS builds
one great circle direct segment between the two waypoints, regardless of distance. To specify

227
Route Commands
multi-segment great circle routing between any two SRS waypoints, enter GR8Cnnnn between
the two waypoints. Specify the desired segments of latitude/longitude (nnnn) using the syntax
rules explained in the previous sections.
In the following example, the first input generates a single segment great circle route between
two points. The second input also generates a great circle route between two points, but with
multiple segments.
Example:
Explanation: Generate a single great circle route segment between SYA and PABBA.
02 POD KSJC
03 POA RJAA
06 ROUTE -OSI PYE J143 ENI C1486 DAANN G215 SYA PABBA OTR6
KETAR OTR10 CVC
Example:
Explanation: Generate a great circle route between SYA and PABBA, but with multiple
segments. Since this is a predominantly east/west flight, the input prints 10-degree intervals of
longitude, and prints additional waypoints at every 10-degree intervals of latitude.
02 POD KSJC
03 POA RJAA
06 ROUTE -OSI PYE J143 ENI C1486 DAANN G215 SYA GR8C1010
PABBA OTR6 KETAR OTR10 CVC
JetPlan SRS Distance Override/Bias Specification

You can enter an absolute distance or specify a distance bias between checkpoints in the SRS
route input.
Examples:
06 ROUTE -ABC (DIST=260) XYZ
Explanation: You have specified a distance of 260 nm between ABC and XYZ. The 260 nm
distance overrides the direct point-to-point distance that JetPlan would have otherwise
calculated between ABC and XYZ.
06 ROUTE -ABC (DIST=+33) XYZ

228
Route Commands
Explanation: You have specified an incremental distance of 33 nm between ABC and XYZ. A
33 nm distance bias is added to the point-to-point distance that JetPlan calculated between
ABC and XYZ.
06 ROUTE -(DIST=15) HOLTZ7 TRM IRK LVZ LENDY5
Explanation: You have specified a distance of 15 nm between the departure airport and the
first checkpoint of the HOLTZ7 departure procedure (DLREY). The 15 nm distance overrides
the direct point-to-point distance that JetPlan would have otherwise calculated between the
POD and DLREY (first leg on the SID procedure).
06 ROUTE -HOLTZ7 TRM IRK LVZ LENDY5 (DST=+22)
Explanation: You have specified an arrival procedure distance bias of 22 nm. This bias is
reflected between the last checkpoint of the LENDY5 arrival procedure (LGA) and the arrival
airport. The 22 nm distance bias is added to the point-to-point distance that JetPlan calculated
between LGA and the POA. (The added distance is reflected on the last leg of the STAR
procedure).
If the requested distance override is less than the great circle distance between the checkpoints,
one of the following error messages appears:
• SID DIST – If the requested distance of a segment (from POD to the first
SID checkpoint) is less than the great circle distance for that segment.
• STARDIST – If the requested distance of a segment (from last checkpoint of
STAR to POA) is less than the great circle distance for that segment.
• RTE DIST – If the requested distance of a segment (between two successive
enroute checkpoints) is less than the great circle distance for that segment.

229
Route Commands
SRS Routing for User-Defined Airports

To specify SRS routing when flight planning to or from user-defined airports (see the POD
and POA Commands chapter), the typical inputs can be one of the following:
• A great circle route for part or all of the route.

Example:
02 POD AAAA,3900,12000
03 POA XXXX,3900,07000
06 ROUTE -
Example:
02 POD AAAA,3900,12000
03 POA XXXX,3900,07000
06 ROUTE -GR8C0010
• A combination of great circle and airway routes.
Example:
02 POD AAAA,3900,12000
03 POA XXXX,3900,07000
06 ROUTE -LAX J78 J161 FMN DVV GR8C0010
• A direct segment to a waypoint, and then airway structure—if the POD is
defined by coordinates.
• Airway structure to a waypoint, and then a direct segment to the POA—if
the POA is defined by coordinates.

230
Route Commands
SRS Naming Conventions

SRS follows the ARINC 424 standard for data naming conventions. Common naming
conventions are shown in the following sections.
VOR, VORDME, VORTAC, TACAN and NDB

Waypoints located at any of the above types of facilities take on the official one-, two-, three-,
or four-character identifier of the facility.
Named RNAV Waypoints, Intersections, and Reporting Points

In many countries, these waypoints are assigned unique five-character names. The identifier is
the same as the name. For waypoints not so named, an identifier is developed using five or
fewer character names, according to the following rules.
One-Word Names
• Use the full name if five or less characters are involved.
ACRA LOGAN PIKE DOT
• Eliminate double letters.
KIMMEL becomes KIMEL, COTTON becomes COTON, and RABBITT
becomes RABIT.
• Keep the first letter, first vowel, and last letter. Drop other vowels starting
from right to left.
ADOLPH becomes ADLPH, BAILEY becomes BAILY, and BURWELL
becomes BURWL.
• Drop consonants, starting from right to left.
ANDREWS becomes ANDRS, BRIDGEPORT becomes BRIDT, and
KHABAROVSK becomes KHABK.

231
Route Commands
Multi-Word Names
Use the first letter of the first word and abbreviate the last word using the above rules for
single word names to reduce the last word to four characters.
CLEAR LAKE becomes CLAKE, and ROUGH AND READY becomes RREDY.

232
Route Commands
Combination (SRS – Route Optimizer) Routing
Combination (SRS – Route Optimizer)

Routing
You can alternate between SRS and Route Optimizer types of inputs to create a combination
route request. This capability allows you to take advantage of the unique benefits of both
methods. There is no restriction on the number of times you alternate between SRS and Route
Optimizer within your route input.
Input Rules
Combination routing requires you to adhere to some guidelines when entering your route
request. First, all current SRS and Route Optimizer syntax rules and guidelines must be
followed when applying the particular methodology. Next, you must follow the unique and
specific guidelines listed below to ensure the proper parsing of input information.
• When alternating between SRS and Route Optimizer inputs, separate each
selection tool segment with two dashes. You can include spacing around the
two dashes, or have no spacing at all.
Example:
Explanation: The first line demonstrates the “no spacing” style that can be
applied. It also shows the request starting with an SRS entry (thus the single
dash begins the input). The second line demonstrates the “spacing” style,
where spaces separate the inputs from the two dashes. It also shows the
request starting with a Route Optimizer entry (thus, there is no single dash
as the first input). Route Optimizer
06 ROUTE -SRS--RO--SRS--RO
- or -
06 ROUTE RO -- SRS -- RO -- SRS
• Do not duplicate waypoint names when switching from one selection tool
style to the other (SRS to Route Optimizer or Route Optimizer to SRS).
Example:
Explanation: Incorrect entry. The waypoint GAS is duplicated between the
two methods.
06 ROUTE -DHA A1 SIBLI--J,D,SIBLI,GAS,D--GAS V22 MAD
Explanation: Correct entry. Duplication is avoided.
06 ROUTE -DHA A1 SIBLI -- J,BOPAN,GAS -- V22 MAD

233
Route Commands
• When switching from SRS to Route Optimizer, the last SRS waypoint must
exist in one of the recognizable land mass route areas of the navigation
database that the Route Optimizer uses (Areas 1, 2, 3, 4, or 5). It cannot be a
latitude-longitude coordinate or a waypoint located in Area 0 of the Route
Optimizer navigation database.
Example:
Explanation: Incorrect entry. The last SRS waypoint, N3730E133, is in Area
0 according to Route Optimizer rules.
06 ROUTE -SEL G597 KAE N3730E133 -- J,GTC//J
Explanation: Correct entry. The last SRS waypoint, GTC, can be found in
Area 4.
06 ROUTE -SEL G597 KAE N3730E133 GTC -- J//J
• JetPlan automatically constructs a direct segment from the last Route
Optimizer waypoint to a subsequent SRS waypoint unless the first SRS
input is an airway name, in which case an airway segment is used. Do not
use a “D” input to direct the route from a Route Optimizer waypoint to an
SRS waypoint.
Example:
Explanation: Direct segment from MLD to MVA.
06 ROUTE J,MLD -- MVA MOD2
Explanation: Airway segment from MLD to MVA.
06 ROUTE J,MLD -- J158 MVA MOD2
Explanation: Incorrect use of “D” input.
06 ROUTE J,MLD,D -- MVA MOD2
Combination Routing Examples

The following examples illustrate how you can alternate between SRS and Route Optimizer
inputs in one combination route request.
If more than one line of route entries is required, a comma (,) or a backslash (\) can be used at
the end of the current line of input to establish a continuation.

234
Route Commands
Use a comma only if it is part of the route input, extending Route Optimizer inputs to the next
line. SRS inputs can only be ended with a comma and the next line started with a space.
NOTE Examples with next line inputs show more space than is realistic just to
emphasize the point.
Route Optimizer to SRS

Example:
02 POD KSFO
03 POA KJFK
06 ROUTE J,DVV -- J60 JOT J146 GIJ J554 JHW J70 AVP LENDY3
Example:
02 POD EHAM
03 POA RKSI
06 ROUTE J//J,GTC -- N3735E13559 N3710E13232 KAE G597 SEL MADOO
SRS to Route Optimizer
Example:
02 POD KSFO
03 POA KJFK
06 ROUTE -SHOR9 LIN J84 MVA -- J,DVV,LVZ
Example:
02 POD RKSI
03 POA KJFK
06 ROUTE -GOLF$32$ SEL G597 JEC -- J/P/J,IGN
Example:
02 POD RKSI
03 POA EHAM
06 ROUTE -GOLF$32$ SEL G597 JEC N3730E13300 N3749E13557 GTC -- J//J

235
Route Commands
SRS to Route Optimizer to SRS
Example:
02 POD KSFO
03 POA KJFK
06 ROUTE -SHOR9 LIN J84 MVA -- J,DVV -- J60 JOT J146 GIJ J554 JHW ,
J70 LVZ LENDY4
Example:
02 POD RKSI
03 POA EDDF
06 ROUTE -GOLF$32$ SEL G597 JEC -- J,GTC//J,SR,HEL -- UR1 SVD , UA905
HAM UG5 FUL
Route Optimizer to SRS to Route Optimizer
Example:
02 POD KSFO
03 POA KJFK
06 ROUTE J,EKR -- J116 DVV J60 JOT -- J,GIJ,JHW,LVZ
Example:
02 POD WIII
03 POA RKSI
06 ROUTE J,DKI,MAARI -- R471 HCN B591 APU -- J,CJU

236
Route Commands
Multiple Switch Examples
Example:
02 POD KSFO
03 POA KSFO
06 ROUTE J//J,BDO,PVO//J,GTC,CVC//J,ANC
(Route Optimizer example, for comparison only)
- or -
06 ROUTE J//J,BDO -- UP854 VAS UG44 HEL -- J,SPB//J,GTC,CVC//J,ANC
- or -
06 ROUTE J,6860N -- N68W050 N69W040 N69W020 N68W010 N66W000 N64E010

BDO -- J,PVO,SPB -- R30 METAT R30G UHT R30 ARELI B152 IVADA A333
UHHH R211 GTC -- J,CVC//J,ANC -- J804R MDO B453 KYLLE FOT GOLDN4
SRS Static Preferred Routes

There are several types of static Preferred Routes in JetPlan that are stored as SRS route
strings. These routings can be used through the use of special SRS/Combo route inputs.
Currently the following Preferred Route types are available in JetPlan:
• U.S./Canada High Altitude Preferred Routes

• U.S./Canada High Altitude RNAV Preferred Routes
• U.S. Coded Departure Routes (FAA CDRs)
• Australian Domestic Preferred Routes

237
Route Commands
Published Preferred Routing (High Altitude)

To invoke a U.S./Canadian/Australian preferred routes in SRS specify –PR*. To invoke a
U.S./Canadian RNAV preferred route, specify –RN*. If JetPlan generates a “RTDVRPRR”
error, a preferred route is not loaded in SRS between the POD and the POA.
Example
02 POD KSFO
03 POA KJFK
06 ROUTE –PR*
- or -
02 POD KDFW
03 POA KORD
06 ROUTE –RN*
Limited Navigational Capability Tracks

For aircraft that have limited navigational capability, canned track entries can be used to keep
the flight plan on published routes between Goose Bay, Newfoundland via Keflavik, Iceland,
and Stornoway, Scotland. Four SRS preferred route tracks are stored in JetPlan—two
eastbound and two westbound. You can enter these routes in the SRS portion of a combination
SRS-optimizer route input.
The four preferred route tracks are as follows:
Track Name Route
CHK (Eastbound) HOIST 5850N OZN 6140N 6330N EMBLA (AW/ATS) KEF R1
VM (AW/ATS) ALDAN 57STN ATSIX
CK1 (Westbound) ATSIX 57STN ALDAN (AW/ATS) VM R1 KEF (AW/ATS) EMBLA

6330N 6140N OZN 5850N HOIST
CK2 (Eastbound) HOIST 5850N OZN 6140N 6330N EMBLA
CK3 (Westbound) EMBLA 6330N 6140N OZN 5850N HOIST

238
Route Commands
Using the following input, you can use the track name as an SRS element:
CT*<track name>
Example
02 POD CYYR
03 POA BIKF
06 ROUTE HOIST -- CT*CK2 EMBLA
- or -
02 POD CYUL
03 POA EGLL
06 ROUTE J,HOIST –- CT*CHK ATSIX -- J

239
Route Commands
Route Line Editing for Route Optimizer and SRS
Route Line Editing for Route Optimizer

and SRS
Route line edit gives the ability to edit a typing mistake or some other error without having to
retype the complete route input.
Route Line Editing Commands

Edit a route input by entering @6C after any JetPlan prompt. The route must have been
successfully entered after 06 ROUTE. If the previous route input failed syntax checks, it is not
saved and needs to be reentered.
Example:
08 ETD @6C (same flight planning session/request)
01 OPTIONS LD1234
02 POD @6C (flight plan request previously computed)
JetPlan displays the route input with field numbers over each changeable field. Except for the
last field, the minimum field length is four characters—the three-character waypoint identifier
plus a final comma. Unless it is the last route element, a D is the first element in a field.
Fields are ended by one of four delimiters: a space, a comma, a period, or a forward slash. To
terminate a field edit, press the ENTER key with no input. JetPlan displays the following
prompt: 07 HOLD,ALTERNATE/DIST. Type GO, and JetPlan processes the revised route
input.
Changing a Field Entry

To change a field entry, specify the field number, a space, and the new input. One or several
fields can be changed in a single request.
Example:
Original Flight Plan Request:
02 POD KSEA
03 POA KBGR
06 ROUTE J,BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK
To overfly ABQ instead of ELP, enter @6C on any line.

240
Route Commands
JetPlan responds with:
1 2 3 4 5 6 7 8 9 10
J,BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK
Enter 6 ABQ.
1 2 3 4 5 6 7 8 9 10
J,BTG,LMT,EHF,PMD,BLH,ABQ,INK,SAT,IAH,LFK
Press ENTER.
JetPlan displays the 07 HOLD,ALTERNATE/DIST prompt.
Example:
Original Flight Plan Request:
02 POD KDFW
03 POA EGLL
06 ROUTE J/Z/J
To change the Area 1 route from a jet route to a preferred (NAR) route, enter @6C.
Then press ENTER.
1 2
J/Z/J
Enter 1 P/Z/.
1 2
P/Z/J
To change the Area 2 input to a “P,” enter 2 P.

241
Route Commands
1 2
P/Z/P
Press: ENTER
JetPlan prompts the 07 HOLD,ALTERNATE/DIST question.
Deleting a Field Entry

To delete a field entry, specify the field number alone. Delete only one field at a time;
however, more than one deletion can be made for each @6C input.
Example:
Original flight plan request:
02 POD KSEA
03 POA KBGR
06 ROUTE J,BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK
To delete BLH and SAT, enter @6C.
1 2 3 4 5 6 7 8 9 10
J,BTG,LMT,EHF,PMD,BLH,ELP,INK,SAT,IAH,LFK
Enter 5.
1 2 3 4 5 6 7 8 9
J,BTG,LMT,EHF,PMD,ELP,INK,SAT,IAH,LFK
Enter 7.

242
Route Commands
1 2 3 4 5 6 7 8
J,BTG,LMT,EHF,PMD,ELP,INK,IAH,LFK
Press ENTER.
Inserting a Field Entry

To insert a new route input between two consecutive fields, specify the following:
• The preceding field number, followed by a decimal point and the number 5
(X.5, where X is the preceding field number), and then a space and the new
route input. Using a comma after the new route input is optional.
To add a new route input after the last field number, specify the following:
• The last field number, followed by a decimal point and the number 5 (X.5),
two spaces, and the new route input.
NOTE The “change” technique can be used to add a new route input after the last
field number. Specify the last field number, retype the existing route input for that
field, and then add the new route input.
Example:
02 POD KSEA
03 POA KBGR
06 ROUTE J,BTG,LMT,EHF,LAX,BLH,ELP,INK,SAT,IAH,LFK
To insert the SLI VOR between LAX and BLH, enter @6C on any line.
JetPlan displays the following prompts:
1 2 3 4 5 6 7 8 9 10
J,BTG,LMT,EHF,LAX,BLH,ELP,INK,SAT,IAH,LFK

243
Route Commands
Enter 4.5 SLI, (or 4.5 SLI with no comma).
1 2 3 4 5 6 7 8 9 10 11
J,BTG,LMT,EHF,LAX,SLI,BLH,ELP,INK,SAT,IAH,LFK
Press ENTER.
If the flight plan is computed using this route input, JetPlan responds with KSEA NG, because
the Route Optimizer is limited to 10 consecutive waypoints. At this point, insert D between
one of the NAVAIDS, or delete one of the NAVAIDS. To insert D between field 8 and 9, for
example, enter: @6C
1 2 3 4 5 6 7 8 9 10 11
J,BTG,LMT,EHF,LAX,SLI,BLH,ABQ,INK,SAT,IAH,LFK
Enter 8.5 D, (or 8.5 D with no comma) JetPlan responds with:
1 2 3 4 5 6 7 8 9 10 11 12
J,BTG,LMT,EHF,LAX,SLI,BLH,ABQ,INK,D,SAT,IAH,LFK
Press ENTER.
Example:
02 POD KSJC
03 POA RJAA
06 ROUTE -OSI V25 PYE V27 ENI C1486 GUTTS GENCO GAVEL DUT G215 PLADO
A590 \ PABBA OTR6 KETAR OTR10 CVC
In this case, the requirement is to replace the route segment between the inputs, GAVEL and
OTR10, with the route segment “CDB A342 OLCOT NIPPI R220 NANAC”. This requires
both the insertion process and the deletion process.

244
Route Commands
Enter @6C. JetPlan responds with:
1 2 3 4 5 6 7 8 9 10 11 12 13
-OSI V25 PYE V27 ENI C1486 GUTTS GENCO GAVEL DUT G215 PLADO A590
14 15 16 17 18
PABBA OTR6 KETAR OTR10 CVC
Enter 10 CDB A342 OLCOT NIPPI R220 NANAC.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
-OSI V25 PYE V27 ENI C1486 GUTTS GENCO GAVEL CBD A342 OLCOT NIPPI R220
15 16 17 18 19 20 21 22 23
NANAC G215 PLADO A590 PABBA OTR6 KETAR OTR10 CVC
Delete fields 16 through 21 using the procedure specified above.

245
Route Commands
Runway-to-Runway Flight Planning and Preferred Runways
Runway-to-Runway Flight Planning and

Preferred Runways
IMPORTANT Do not confuse this Runway-to-Runway feature with the ERAD
runway-to-runway option used only in ERAD flight plan requests. To use runway-to-
runway flight planning in an ERAD flight plan, use the ERAD, S2R2R option. ERAD
flight plans do not use the Preferred Runways Database. See “ERAD 2.0 Runway-to-
Runway Flight Planning” on page 270.
When properly configured, JetPlan attempts to use your preferred POD and POA runways
when applying terminal SID and STAR procedures in flight plan computations. You can use
parameters in the Preferred Runways Database to define preferred POD and POA runways,
rank them, and specify maximum allowable crosswind and tailwind values for them. When
you submit a flight plan request, JetPlan looks in the Preferred Runways Database for
preferred runway records for the requested airport and fleet type combination. If preferred
runway records exist, JetPlan validates them against the predicted wind speed and direction in
the current Terminal Area Forecast (TAF) for the ETD or ETA. When computing the flight
plan, JetPlan uses your highest-ranked preferred POD or POA runway that passes the TAF-
validation check. For information on configuring the Preferred Runways Database, see
“Creating a Preferred Runway Record” on page 247.
If Preferred Runways Database records exist, JetPlan checks them whenever you request a
flight plan unless one of the following conditions is true:
• You enter a route that contains a runway for the SID or STAR.
• You enter a route with a SID or STAR that is runway-specific.
• You specify a route from the Customer Route Database
Also, JetPlan uses a system default runway instead of a preferred runway if any of the
following conditions is true:
• JetPlan cannot find a preferred runway record in the Preferred Runways

Database.
• JetPlan cannot find an acceptable runway for the weather conditions in the
Preferred Runways Database.
• The TAFCHECK customer preference is not set.

246
Route Commands
Overriding a Preferred Runway

You can override the preferred runway obtained from the Preferred Runways Database. On the
POD or POA command line, type the rwy=<runway> command, where <runway> is the one-
to-three character designator for the runway you want to use. For example:
02 POD kden,rwy=16L
03 POA kpit,rwy=10R
Preferred Runway Prerequisites

To use preferred runways in your flight plan computations, do the following:
• Use the Preferred Runways Database to define and rank your departure and
arrival runways for specific airport and fleet-type combinations. Set
maximum allowable crosswind and tailwind velocities in each preferred
runway record. For information, see “Creating a Preferred Runway Record”
on page 247.
• Ensure that the TAFCHECK customer preference is enabled for your
account. TAFCHECK must be set to 4. Contact your Jeppesen customer
support representative for information.
• Ensure that your flight plan format can display the preferred runway
information. Contact your Jeppesen customer support representative for
information.
Creating a Preferred Runway Record

You can create a Preferred Runways Database record using JetPlan.com or the JetPlan
command-line interface. The following sections briefly describe these two methods.
IMPORTANT Although the Preferred Runways Database is a separate database, it

is combined with the Airport Fleet database in JetPlan.com as a convenience to
customers. If you use JetPlan command-line, note that the 01 Option maintenance
command for the Preferred Runways Database is RWY. For complete information on
using the command-line interface to maintain Preferred Runways Database records,
see “Using the JetPlan Command-Line Interface to Manage Preferred Runway
Records” on page 249.

247
Route Commands
Creating a Preferred Runway Record in JetPlan.com
NOTE This section assumes that you have already created the airport fleet record
and are now adding preferred runways to the record. See the Airport Fleet database
Help file on JetPlan.com for detailed instructions on creating airport fleet records. For
complete information on the Preferred Runways Database parameters, see
Chapter 39, “Preferred Runways Database.”
In JetPlan.com, the preferred runway parameters appear in the “Runways” section of the
Airport Fleet database. You can add and rank multiple departure and arrival runways for each
airport and fleet type combination. Once you create an Airport Fleet record, you can add
preferred runways to the record. Figure 6.8 shows the Change Runways page in JetPlan.com.
Figure 6.8. Change Runways in Airport Fleet Page - JetPlan.com

248
Route Commands
You first need to designate a runway as either a departure or an arrival runway. In the
departure or arrival area of the Change Runways in Airport Fleet page, provide the
• Rank – (Required) The preference order for this runway. For

example, type 1 if this runway ranks number one in your preference
order. You can change this number at any time.
• Runway – (Required) The one-to-three character runway identifier.
Example: 34L
• Max Crosswind – The maximum acceptable crosswind for the
runway in knots. Example: 30.
• Max Tailwind – The maximum acceptable tailwind for the runway
in knots. Example: 10.
To add another runway, click Add to add a new row and provide the runway information.
NOTE For complete information on the Preferred Runways Database parameters,

see Chapter 39, “Preferred Runways Database.”
Using the JetPlan Command-Line Interface to Manage

Preferred Runway Records
If you use the JetPlan command-line interface, you can manage preferred runways using the
RWY command on the Options command line. The RWY command always precedes any
function command to save, change, delete, or display preferred runway records in the
database. For example, the command-line syntax for creating a preferred runway record is as
follows:
01 OPTIONS RWY,SAV,<ICAO>,<FLEET>,<A or D>,<rank>,RWY=<XXX>,

MT=<n>,MX=<n>
where
• RWY is the Preferred Runways Database maintenance command.

• SAV is the save function command.
• <ICAO> is the ICAO or IATA airport code. Example: KDEN
• <FLEET> is the aircraft fleet type name. Example: 777E
• <A or D> is an arrival runway (A) or a departure runway (D).

249
Route Commands
• <rank> is a number representing preference order. Example: 1

• RWY=<xxx> is the runway identifier. Example: RWY=15R
• MX=<n> is the maximum crosswind value in knots. Example: MX=30
• MT=<n> is the maximum tailwind value in knots. Example: MT=10
Example:
01 OPTIONS RWY,SAV,KDEN,B737,A,1,RWY=34L,MX=30,MT=10
NOTE For complete information on the Preferred Runways Database parameters

and on using the command-line interface to maintain the Preferred Runways
Database, see Chapter 39, “Preferred Runways Database.”

250
Route Commands
Using Customer Route Database Records

NOTE This section covers applying customer-defined routes that are stored in the
Customer Route Database (CRDB). For detailed information on creating and
managing customer route records, see Chapter 41, “Customer Route Database.”
The CRDB allows you to create and manage one or multiple route records for a given airport
pair. A CRDB record is created using standard JetPlan route inputs for the Route Optimizer,
SRS, or combination routing (SRS-Route Optimizer).
When you define a route, you assign it a unique record name that identifies it in the CRDB.
You can then enter the record name as the route input on a flight plan request. The airport pair
in the record you choose must match the airport pair in the flight plan request.
If you are unsure of which CRDB record to choose, you can direct JetPlan to select a record
from those available for the airport pair in the database. This method selects the optimal route
from the available choices. You can also add delimiting factors that narrow the search process.
The following examples provide inputs that allow JetPlan to find the optimal route:
• Find the optimal route stored between the POD and the POA.
Example:
Explanation: This input selects the optimum from all routes available
between the specified POD and POA.
06 ROUTE RT/ALL
• Find the optimal route stored between the POD and the POA from those
files stored under the specified group names.
Example:
Explanation: This input selects the optimum from only those groups
specified (groups “ALPHA” and “BRAVO”).
06 ROUTE RT/ALL,GP=ALPHA,BRAVO

251
Route Commands
• Find the optimal route stored between the POD and the POA that does not
come from the excluded groups.
Example:
Explanation: This input selects the optimum from all files except those
specified (groups “ALPHA” and “XRAY”).
06 ROUTE RT/ALL,GP=-ALPHA,-XRAY
• Find the specific route stored under the database record name given for the
specified POD and POA.
Example:
Explanation: This input selects route record P001. If the record exists, and if
the airport pair matches the pair in the flight plan request, the record is used.
06 ROUTE RT/P001
Route Line Editing of a CRDB Record

The route line edit feature described in “Route Line Editing Commands” on page 240 can be
applied to CRDB records when making a change to the route entries in the record. See the
example below.
Example:
01 OPTIONS RT,CHG,KSEA,KBGR/RT01
06 ROUTE @6C
JetPlan displays the following prompts:
1 2 3 4 5 6 7 8 9 10
J,BTG,LMT,EHF,LAX,BLH,ELP,INK,SAT,IAH,LFK
Make changes as necessary using the techniques demonstrated in “Route Line Editing
Commands” on page 240.

252
Route Commands
Using Coded Departure Route (CDR) Records
Using Coded Departure Route (CDR)

Records
NOTE CDR in the context of this section refers to FAA Coded Departure Routes,
not the European Conditional Routes (CDRs) used with the ERAD flight plan option.
For information on ERAD, see “Electronic Route Availability Document Option” on
page 256.
NOTE This section covers applying routes that are stored in the Customer Coded
Departure Route (CDR) Database. For detailed information on generating and
managing CDR records, see Chapter 35, “Coded Departure Routes Database.”
About Coded Departure Routes (CDRs)

Coded departure routes are predefined city-pair routes, complete from departure to arrival,
including terminal procedures. The FAA maintains coded departure routes and publishes a list
of the effective coded departure routes every 56 days.
To facilitate orderly routing around weather and other adverse conditions, Air Traffic Control
(ATC) might issue an advisory indicating that coded departure routes are in effect for flights
departing from specified airports or from any airport within an indicated FIR and flying to
specified airports or centers. ATC advisories indicate that the crew of an affected flight might
be asked to fly a coded departure route when requesting clearance to depart. However,
advisories do not indicate the particular coded departure routes to fly or state that the crew will
definitely be asked to fly a coded departure route, only that coded departure routes need to be
taken into account in planning.
An airline must respond operationally to a coded departure route advisory to prepare a crew
for a request to fly an unknown coded departure route. Prior to flight planning, the airline must
determine if it flies the indicated city pairs and if it has operational agreements to fly a coded
departure route with the centers involved. In addition, during flight planning, the airline must
determine which coded departure routes are flyable, given the aircraft’s navigational
capabilities and the planned amount of onboard fuel. The Customer Coded Departure Route
Database helps airlines meet these operational needs.

253
Route Commands
About the Customer Coded Departure Route Database

The Customer Coded Departure Route Database allows airlines to make the necessary
decisions about coded departure routes prior to and during flight planning. An updated list of
effective coded departure routes is downloaded from the FAA Route Management Tool every
56 days. The JetPlan Navigation Data (NavData®) team processes the downloaded coded
departure routes, validating that (1) they are compliant with JetPlan’s version of the latest
ARINC 424 navigation data and (2) that they are flyable routes according to JetPlan routing
routines. The coded departure routes downloaded from the FAA are stored in the generic
NavData Coded Departure Route Database, which is replaced every 56 days.
Using JetPlan.com, you can populate your initial Customer Coded Departure Route Database
with duplicates of coded departure route records in the current generic NavData Coded
Departure Route Database. The FAA code for the coded departure route becomes the record
name in your Customer Coded Departure Route Database. All coded departure routes in the
Customer Coded Departure Route Database are initially marked as OK to Use, meaning
JetPlan considers them as acceptable choices for flight planning, indicating you have the
operational prerequisites in place. You can change the OK to Use setting to No for selected
coded departure routes that you do not want JetPlan to use.
NOTE After you have created your initial Customer Coded Departure Route
Database, you need to manually reconcile it with the generic NavData Coded
Departure Route Database when needed. Your “OK to Use” settings are retained
during reconciliation.
For more information on working with Coded Departure Route Database records, see
Chapter 35, “Coded Departure Routes Database.”
Using a Coded Departure Route Database Record As a

Flight Plan Input
The name of the coded departure route record in the Customer Coded Departure Route
Database is the same as the FAA code for the route. The FAA coded departure route naming
convention is PODPOAxx, where POD and POA are the 3-character IATA airport identifiers
and xx are two alphanumeric characters that act as a secondary identifier. For example, a
coded departure route for the directional city pair KJFK/KORD is JFKORD60. The syntax for
the route input on the Route command line is: -CD*xx.

254
Route Commands
The following are examples of coded departure route records and the corresponding route
input syntax.
Coded Departure Route

Airport Pair Record Name Route Input
KMSP, KORD MSPORDE2 -CD*E2
KMSP, KORD MSPORDS1 -CD*S1
KLAX, KJFK LAXJFKB1 -CD*B1
Example:
Explanation: The following input specifies a coded departure route record named
MSPORDE3. The system uses the record if it can be found in the database, is active, and is
marked OK to Use. The airport pair in the record must also match the pair in the flight plan
request.
02 POD KMSP
03 POA KORD
06 ROUTE -CD*E3
NOTE When used with certain flight plan formats, Jeppesen Dispatch Control can
provide a summary report that allows you to compare multiple coded departure route
scenarios. For more information, consult the Jeppesen Dispatch Control User’s Guide
or contact your Jeppesen account manager.

255
Route Commands
Electronic Route Availability Document Option
Electronic Route Availability Document

Option
This section describes the Electronic Route Availability Document (ERAD) flight plan option,
which instructs JetPlan to create a multi-dimensional route that is optimized and fully
compliant with EUROCONTROL traffic flow restrictions. The ERAD option employs a route
selector that is designed only for flights using European airspace.
NOTE Additional regional route restrictions will be supported in future

enhancements of ERAD.
About the FlitePlan Core Route Optimizer

When you use the ERAD option in your request, JetPlan automatically employs the FlitePlan
Core route optimizer for flights in European airspace. FlitePlan Core provides superior
constrained optimization relative to the JetPlan route selector. FlitePlan Core selects multi-
dimensional, optimized routes that are fully compliant with routing constraints published by
EUROCONTROL and member states. These constraints include the RAD and other efficiency
schemes, such as the Airspace Use Plan/Updated Airspace Use Plan (AUP/UUP) (formerly
known as CRAM).
In addition, ERAD and FlitePlan Core support lowest fuel, time, or cost-based route
optimization, depending on the criteria specified by the user. For cost-based optimization, the
system accounts for cost as the sum of fuel, enroute charges, and time and also considers
altitude restrictions enforced by RAD and other ATC restrictions as part of the route-selection
process.
About 2HEAVY Errors

Under certain combinations of weather conditions and RAD rules, you might receive a
2HEAVY error in response to a flight plan request containing the ERAD flight plan option. If
this happens, try incrementally lowering the payload or zero fuel weight until a flight plan is
produced. If that approach is not acceptable, and the flight plan is a cost-index plan, try
reducing the cost index. If it is not a cost-index plan, try reducing the Mach speed. If these
approaches are unsuccessful or unacceptable, the only choice is to not use the ERAD flight
plan option and to try other means to achieve a EUROCONTROL-compliant flight plan.

256
Route Commands
Accessing ERAD 2.0

JetPlan automatically uses FlitePlan Core when you use the ERAD flight plan option in these
Jeppesen flight planning products: JetPlan.com (Basic Flight Planner or New Flight Planner),
Jeppesen Dispatch Control, JetPlanner, Legacy OpsControl, FlightPlan Online, and the
JetPlan interactive (Q and A) command-line interface.
In addition, ERAD flight plans support a few options that are currently available only in the
JetPlan command-line interface and the Basic Flight Planner in JetPlan.com. For more
information, see “ERAD 2.0 Flight Plan Options Supported Only in the Command-Line
Interface” on page 270.
Options and Inputs Supported with ERAD

For the most part, use of flight plan options and inputs with ERAD has not changed as a result
of the improvements to the route selector. However, some new and changed capabilities do
exist. The following sections describe supported options and explain when options are not
supported.
ERAD Point of Departure (POD) and Point of Arrival (POA)

Inputs
The route selector invoked by the ERAD flight plan option is designed only for flights that use
European airspace. Usually, the POD or the POA or both are in Europe, although some flights
that overfly European airspace also benefit from the ERAD option.
ERAD Route Inputs

With a few exceptions, route inputs do not change with ERAD 2.0. The following three tables
list supported, planned, and unsupported route inputs for ERAD flight plans.
Table 6-9 Route Inputs Supported with ERAD 2.0
Route Input Type Example Description

NOTE A blank space separates each waypoint, airway, SID (with transition), and STAR (with transition) entry.
No route input NA Optimum RAD-compliant route

via best combination of directs and
airways

257
Route Commands
Table 6-9 Route Inputs Supported with ERAD 2.0
Route Input Type Example Description

Waypoint(s) BANTO Optimum RAD-compliant route
BANTO UMBAG via specified waypoints
Waypoint(s) plus airway(s) BANTO UP155 UMBAG Optimum RAD-compliant route

NOTE If the ERAD FP option is
via specified waypoint and airway
not specified, the route optimizer
cannot use these inputs.
Waypoint Direct (DCT) Waypoint BANTO DCT UMBAG Optimum RAD-compliant route
NOTE If the ERAD FP option is constrained to fly BANTO direct
not specified, the route optimizer (DCT) to UMBAG
• SID followed by transition TNT3E TNT HON HON2A Optimum RAD-compliant route
• Transition followed by STAR constrained to fly the SID TNT3E
to TNT and the STAR HON2A
NOTE If the ERAD FP option is from HON
not specified, the route optimizer
Table 6-10 lists route inputs that will be supported in a future version of ERAD.
Table 6-10 Route Inputs Planned for a Future Version of ERAD
Input Type Notes

Westbound and eastbound North Atlantic Organized Not currently supported. Using these route inputs
Tracks (NATs) results in an error.
/A/ For detailed information, see “ERAD and the NATS”
/Z/ on page 259.
Preferred routing to or from NATs Not currently supported. Using these route inputs
results in an error.
• Pacific Organized Track System (PACOTS), Not currently supported. Using these route inputs
including Flex Tracks results in an error.
• Australian Organized Track Structure
(AUS OTS)

258
Route Commands
Table 6-11 lists route inputs that are either not supported or not recommended with ERAD 2.0.
Table 6-11 Route Inputs Not Supported or Recommended for Use with ERAD
Input Type Notes

SRS inputs and combination of optimizer and SRS These inputs are not supported with ERAD 2.0
inputs
• JetAirways (J) These inputs are acceptable but not recommended.

• Direct (D) ERAD applies rules to ensure that airways are
included as necessary and direct optimization is
always exploited whenever possible.
ERAD and the NATS

In ERAD 2.0 flight plan computations, the following logic applies to the NATs:
• FlitePlan Core only includes the optimum NAT in the route computation
when doing so results in the most optimum ATC-acceptable trajectory.
• If you include the westbound (/A/) or eastbound (/Z/) NAT in your ERAD
route input, an error will occur.
ERAD Flight-Level Input Options

ERAD 2.0 does not support VFR (V) or C flight-level (profile) input options. (C is used to
prevent a step climb when flight planning on the organized tracks.) Otherwise, ERAD 2.0
supports all user-entered flight-level instructions supported by JetPlan. FlitePlan Core applies
your flight-level constraints while determining an optimum route that is also compliant with
the RAD and European Conditional Route rules.
For details on user-entered flight level constraints, see Chapter 9, “Profile Commands.”

259
Route Commands
ERAD and European Conditional Routes
NOTE The acronym CDR in the context of this section refers to conditional routes in
Europe and not to FAA Coded Departure Routes (CDRs). For information on FAA
CDRs, see “Using Coded Departure Route (CDR) Records” on page 253.
In Europe, conditional routes are Air Traffic Service (ATS) routes or portions of routes that
are designated by the controlling ANSPs as non-permanent. Such routes or portions of routes
are often referred to as airways. They can be planned and used under specified conditions that
are time-based and altitude-based. These conditional routes are divided into three categories:
• Category 1 (CDR1): Normally available for planning in the same way as

permanent ATS routes but subject to short-notice closure by the daily
AUP/UUP (formerly CRAM) update document.
• Category 2 (CDR2): Normally unavailable for planning except when made
available by the daily AUP/UUP update document.
• Category 3 (CDR3): Never available for planning; usable on ATC
instruction only.
ERAD 2.0 uses the Conditional Route (CDR) Route-Segment Database. The records in this
database contain airway segment/time frame/flight level data derived from the combination of
data from the latest conditional route publications published by the ANSPs and data from the
daily AUP/UUP document. The AUP/UUP document applies to the 24-hour period starting at
0600Z the day after it is published. The CDR Route-Segment Database is updated every 24
hours upon receipt of the daily AUP or whenever a UUP is released.
Knowing how the relevant data is maintained on a daily basis is critical to understanding how
FlitePlan Core treats airways subject to conditional route designation. The ERAD CDR
Restrictions file is updated each day upon receipt of the latest AUP/UUP electronic document.
For each airway segment or sequence of segments that is subject to conditional route
designation, a set of records can be found in the CDR Restrictions file. The set of records
defines a complete schedule for the availability of the airway segments and flight levels and
can be thought of as a schedule block. The contents of the schedule block are determined
through a compositing of the AUP/UUP and the standard conditional route designations. Each
schedule block covers a two-week period starting at 0000Z on the current day.
Any given AUP/UUP document covers a 48-hour period, starting at 0600Z on its effective
date. Thus, the contents of the first 24 hours of a schedule block for any given airway
segment/flight level reflect the combination of the AUP/UUP and the standard conditional
route designation. After the first 48 hours, the contents reflect only the standard conditional
route designation.

260
Route Commands
When computing a flight plan, FlitePlan Core reads and processes the data from the CDR
Restrictions File to determine if a given combination of candidate airway segment and flight
level is open at the estimated time of entry. If the estimated time of entry is within the 48-hour
coverage window of the latest AUP/UUP, the impact of the AUP/UUP is accounted for as
composited with the standard conditional route designations. If the estimated time of entry is
beyond the 48-hour coverage window of the latest AUP/UUP, the latest AUP/UUP has no
impact, and only the standard conditional route designators have an impact.
For example, consider the A333 airway between AGUNI and LUTEL. For FL300 to FL530,
this section of A333 is designated CDR2 on weekdays and CDR1 on weekends. Assume that a
flight plan is run on a particular Wednesday, and for that day, the AUP/UUP caused this
section of A333 to be open for the 48-hour period extending from 0600Z on that day. FlitePlan
Core behaves as follows when computing this flight plan:
• If the flight plan’s ETD, aircraft performance, forecast winds and

temperatures, and so on, are such that the estimated time of entry to the
section of A333 between AGUNI and LUTEL is prior to 0600Z on Friday
of that week (and thus within the 48-hour coverage of the latest AUP/UUP),
that section is considered to be open.
• If the flight plan’s EDT, aircraft performance, forecast winds and
temperatures, and so on are such that the estimated time of entry to the
section of A333 between AGUNI and LUTEL is after 0600Z on Friday of
that week (and thus beyond the 48-hour coverage of the latest AUP/UPP),
that section is considered to be closed.
FlitePlan Core applies the following Flight Planning-relevant CDR (FP_CDR) classifications
dynamically when determining whether a particular combination of airway segment and flight
level is available for consideration in the optimum route and profile computation. Note that for
certain airway segment and flight-level combinations, the FP_CDR classification can depend
on the estimated time of entry in the flight plan computation.
FP_NOCDR The combination of airway segment and flight level is not subject to
conditional route designation.
FP_CDR0 The estimated time of entry for the airway segment and
flight-level combination is within the period of the latest AUP/UUP,
and the combination of the latest AUP/UUP and the standard
conditional route designations is such that the airway segment and
flight-level combination is considered open.

261
Route Commands
FP_CDR1 The estimated time of entry for the airway segment and flight-level
combination is beyond the period of the latest AUP/UUP and is at a
point in time that the airway segment and flight-level combination is
designated a CDR1.
FP_CDR2 The estimated time of entry for the airway segment and flight-level
combination is beyond the period of the latest AUP/UUP and is at a
point in time that the airway segment and flight level combination is
designated a CDR2.
FP_CDR3 The combination of airway segment and flight level is designated a

CDR3.
NOTE When you are using ERAD 2.0, the NOCRAM flight plan option does not turn
off processing of AUP/UUP (CRAM) files.
The following table summarizes how FlitePlan Core uses the FP_CDR classifications.
Table 6-12 FP_CDR Classifications
Command-Line Input Description Notes

FP,ERAD Consider airway flight level Consider only those airway
combinations that are determined segments that are explicitly known
to be FP_NOCDR, FP_CDR0 or to be open at the estimated point of
FP_CDR1. time of entry or are considered
probably open at the estimated
time of entry.
FP,ERAD,AX Consider airway flight level Consider any airway segment
combinations that are determined flight level combination that has
to be FP_NOCDR, FP_CDR0, the possibility to be open at given
FP_CDR1 or FP_CDR2. time of entry in the future within or
beyond the coverage of the current
AUP/UUP.
FP,ERAD,NX Consider only those airway Consider only those airway
flight-level combinations that are segments that have no CDR
determined to be FP_NOCDR. designation.

262
Route Commands
ERAD 2.0 Restricted Areas Options and Inputs

The following sections describe how the Restricted Area (RST) flight plan option and inputs
work with ERAD 2.0.
NOTE For detailed information on restricted area options, see Chapter 4,

“Restricted Area Commands.”
Avoiding Checkpoints and Airways

ERAD 2.0 supports JetPlan checkpoint and airway-avoid inputs entered with the RST flight
plan option. The syntax and rules for checkpoint avoid and airway avoid inputs using the
command-line interface are the same for FlitePlan Core as for the JetPlan route selector.
(Examples can be found in Chapter 4, “Restricted Area Commands.”)
Avoiding Checkpoints
FlitePlan Core processes an avoid checkpoint input similar to the way the JetPlan route
selector processes the input. FlitePlan Core computes the route so that it avoids any checkpoint
entered as an avoid checkpoint.
Avoiding Airways
Currently, FlitePlan Core processes an avoid airway input differently than the JetPlan route
selector does. The JetPlan route selector accepts input of a checkpoint, followed by an airway
name, followed by a checkpoint, and then ensures avoidance of the named airway only
between the two checkpoints. FlitePlan Core does not consider the checkpoints in such an
input. Instead, it avoids the entire airway. For example, the following command-line inputs
request FlitePlan Core to compute a route that avoids airway UL607. FlitePlan Core computes
a route that avoids UL607 completely, not just between KONAN and NTM.
01 OPTIONS FP,ERAD,RST/AW=KONAN UL607 NTM
The following command-line inputs request FlitePlan Core to compute the route so that it
avoids the UB4 airway. Again, FlitePlan Core computes a route that avoids UB4 completely,
not just between RLP and CTL.
01 OPTIONS FP,ERAD,RST
....
05 RESTRICTED AREA AW=RLP UB4 CTL

263
Route Commands
Avoiding Countries by ICAO Code

You can specify complete or partial ARINC 424 ICAO codes for countries to avoid during
route selection. For example, the following command-line inputs request FlitePlan Core to
compute a route from EGLL to VTBD that excludes the following: all waypoints within
Ukraine (UK), within the People’s Republic of China (Z), and within IRAN (OI).
01 OPTIONS FP,RST,ERAD
02 POD EGLL
03 POA VTBD
05 RESTRICTED AREA ICAO/UK Z OI
You can also specify a country to avoid on the 01 OPTIONS command line, as in the
following example:
01 FP,ERAD,RST/ICAO/OI
Note, however, that you cannot enter more than one ICAO country code on the 01 OPTIONS
command line.
Avoiding FIRs
You can specify one or more Flight Information Regions (FIRs) to avoid during route
selection. For example, the following command-line inputs request FlitePlan Core to compute
a route from EGLL to LIRA that excludes the LSAS FIR.
02 POD EGLL
03 POA LIRA
05 RESTRICTED AREA XIR=LSAS
Ignoring RAD Rules

ERAD 2.0 supports the ability to ignore individual RAD rules. In the JetPlan command-line
interface, the input for ignoring specific RAD rules is used with the RST option and adheres to
the following syntax:
05 RESTRICTED AREA IR/rule rule rule
where rule is the identifier of an individual RAD rule—for example, EG2345A. You can enter
as many RAD rules as can fit on the input line.

264
Route Commands
For example, the following command-line entries request FlitePlan Core to compute the route
so that it ignores the RAD rules EHEG1002B, EH2027B, and LF2471B:
....
05 RESTRICTED AREA IR/EHEG1002A EH2027B LF2471B
You can also combine checkpoint or airway avoid inputs with ignore RAD rule inputs. For
example, the following command-line inputs request FlitePlan Core to compute the route so
that it avoids the tulip checkpoint and ignores the EHEG1002 and EH2027 RAD rules.
....
05 RESTRICTED AREA CP=tulip,IR/EHEG1002 EH2027
RST Options Not Supported with ERAD

ERAD 2.0 does not currently support the JetPlan inputs for avoiding two-dimensional
(delineated boundary) restricted areas with the RST option. These restricted areas are
polygons or circles defined with coordinates. For example, the following command-line inputs
are not supported and result in an error:
01 OPTIONS FP,LP,RST,ERAD
....
05 RESTRICTED AREA 5700,05000,5700,01000,4800,02000,4800,05000

265
Route Commands
How ERAD Responds to Customer Controlled Avoid and Alert

Options
NOTE The Customer Controlled Avoid and Alert options (CCAA and CCAAN) are
allowed with ERAD 2.0, meaning an error does not occur if CCAA or CCAAN is used
with ERAD. However, FlitePlan Core does not consider the CCAA or CCAAN inputs.
FlitePlan Core does not consider CCAA or CCAAN entries in ERAD flight plan requests.
Therefore, ERAD used with CCAA might produce a route that traverses one or more avoid-
level restrictive airspaces. In such cases, flight plan formats that support alerting for such
traversals include the appropriate alerts.
When used with ERAD, both the CCAA option and the CCAAN option cause alerts for each
traversal of active avoid-level and alert-level restrictive airspaces. The alerts are included in
the output of flight plan formats that support all JetPlan alerts. For example, JetPlan accepts
the following command-line entries, and FlitePlan Core attempts to produce a route but does
not consider the CCAA entry:
01 OPTIONS FP,CCAA,ERAD,AA6
In this case, if the route traverses one or more active avoid-level restrictive airspaces, an alert
is included in the output for each traversal as well as for each traversal of an alert-level
restrictive airspace, because the AA6 format presents all JetPlan alerts.
NOTE For detailed information on the CCAA and CCAAN options, see Chapter 5,
“4D Avoid and Alert Restrictive Airspaces.”

266
Route Commands
Time, Fuel, and Cost Optimization Options

FlitePlan Core considers forecast winds and temperatures and altitude variations as part of its
overall methodology to determine one of the following:
• A shortest-time route
• A lowest-fuel route
• A lowest-cost route
The choice of determining a shortest-time route, lowest-fuel route, or lowest-cost route is

controlled by the user’s entries on the Performance Index command line (line 12). However, if
the user enters a cost index on the Cruise Mode line(line 11), FlitePlan Core determines a
lowest-cost route, regardless of the Performance Index entry on line 12.
For lowest-cost path determination, FlitePlan Core considers by default the cost of time and
the cost of fuel. These costs are determined from direct user entry, or extraction from the
CADB, or implicitly from the user-entered cost index.
Unlike the JetPlan route selector, FlitePlan Core lets the user request consideration of enroute
charges along with the costs of time and fuel in the lowest-cost path determination. In this
case, the user must ensure that the cost of time and the cost of fuel are entered directly as part
of the Performance Index entry (for example, M,067,6000) or are available via extraction from
the CADB. Determining the cost of time and the cost of fuel implicitly from cost index is not
compatible with including consideration of enroute charges in the lowest-cost path
determination.
The route of flight determined by FlitePlan Core is the only FlitePlan Core-specific result that
is displayed in the final flight plan output.
NOTE For detailed information on the Performance Index commands and time, fuel,
and cost optimization, see Chapter 9, “Profile Commands.”

267
Route Commands
ERAD Special Remarks in the Filing Strip

In ERAD flight plans, special remarks are appended to JetPlan Engine special remarks in the
filing strip by default. The following example shows the special remarks appended to the filing
strip.
(FPL-JBTFS2-IS
-B738/M-SDE2E3FGIJ1RWXY/LB1
-EDDV0500
-N0449F380 OSN8S OSN UM170 BAM UZ158 LNO/N0449F390 UZ707 RESMI
UN857 DISAK UQ237 LMG UN10 ENSAC UP181 NEA UL14 ADINO/N0448F380
DCT ELVAR DCT GENRO
-LPFR0301 LEJR
-PBN/B1D1O1S2 DOF/140913 REG/DAHFW
EET/EBUR0028 qLFFF0036 EBUR0037 LFFF0038 LECM0143 LPPC0230 OPR/TUI
PER/C
RMK/TAXI:10 DAL:D55PTOSN DAL:D121PTBAM DAL:D193PTLNO
DAL:D376PTRESMI DAL:D403PTDISAK DAL:D550PTLMG DAL:D671PTENSAC
DAL:D872PTNEA DAL:D1030PTADINO DAL:D1092PTELVAR DAL:D1215PTGENRO
DAL:D1242ADLPFR TOC:D114F360T0019 BOC:D121F360T0020
TOC:D140F380T0023 BOC:D193F380T0030 TOC:D205F390T0031
TOD:D1030F390T0222 BOD:D1033F380T0222 TOD:D1114F380T0233 TCAS
EQUIPPED PLAN 9703 ID JBTFS2 RVR/200)
Note that FlitePlan Core only includes the DAL/TOC/BOC portion of the special remarks
when both the POD and the POA are in regions where EUROCONTROL has sole control over
filings. In the command-line interface and the JetPlan.com Basic Flight Plan interface, you can
use the Include DAL/TOC/BOC flight plan option (DOTB) to include the DAL/TOC/BOC
portion of the special remarks in the filing strip, regardless of the location of the POD and
POA. For more information, see “Include DAL/TOC/BOC Option” on page 270.
Suppressing ERAD Special Remarks

In ERAD flight plans, ERAD special remarks are appended to JetPlan Engine special remarks
in the filing strip (with the DAL/TOC/BOC exception described in “ERAD Special Remarks
in the Filing Strip” on page 268.) A customer preference setting enables you to override this
default behavior. When this customer preference setting is in place, FlitePlan Core does not
append these special remarks to the filing strip. Contact your Jeppesen account manager for
more information.

268
Route Commands
ERAD Lateral Route Only

When used with the ERAD flight plan option, the ERAD Lateral Route Only (S2RTO) option
instructs JetPlan to process only the lateral route received from FlitePlan Core. JetPlan Engine
excludes the vertical profile calculations from FlitePlan Core and instead uses the JetPlan
Engine vertical profile calculations.
To use the ERAD Lateral Route Only option, type ERAD followed by S2RTO on the 01
Options command line. Separate the options with commas. For example:
01 OPTIONS FP,ERAD,S2RTO
ERAD Lateral Route Only Option in the Generic Aircraft Database
NOTE Jeppesen maintains the Generic Aircraft Database. For information about
viewing the contents of Generic Aircraft Database records, see Chapter 10, “Aircraft
Type Commands,” on page 347. For information about setting the S2RTO database
parameter, contact your Jeppesen account manager.
The S2RTO parameter in the Generic Aircraft Database can be set to control ERAD Lateral
Route Only processing.
When you use the ERAD flight plan option, JetPlan automatically checks the value of the
S2RTO parameter in the Generic Aircraft Database and does the following:
• If the S2RTO database parameter is blank (the default setting) or is set to

Y (Yes), JetPlan processes only the lateral route received from FlitePlan
Core. JetPlan excludes the vertical profile calculations received from
FlitePlan Core and instead uses the JetPlan Engine vertical profile
calculations.
• If the S2RTO parameter is set to N (No), JetPlan processes both the lateral
route and the vertical profile received from FlitePlan Core.
NOTE If the S2RTO parameter is set to N (No) in the Generic Aircraft Database,
you can override it by entering S2RTO on the 01 OPTIONS command line.

269
Route Commands
ERAD 2.0 Flight Plan Options Supported Only in the

Command-Line Interface
Currently, the following flight plan options are supported only in the JetPlan command-line
interface and in the Basic Flight Planner in JetPlan.com.
Include DAL/TOC/BOC Option

When you use the ERAD flight plan option, the system includes ERAD special remarks in the
filing strip with the following exception: the DAL/TOC/BOC portion of the special remarks is
included only when both the POD and the POA are in regions where EUROCONTROL has
sole control over filings. The DAL/TOC/BOC (DOTB) flight plan option lets you override this
behavior on an ad hoc basis. Entering DOTB on the 01 Options command line in an ERAD
flight plan request instructs JetPlan to append the DAL/TOC/BOC portion of the special
remarks to the JetPlan filing strip, regardless of the POD and POA.
ERAD 2.0 Runway-to-Runway Flight Planning
IMPORTANT Do not confuse the ERAD, S2R2R flight plan option with the non-
ERAD Runway-to-Runway feature (see “Runway-to-Runway Flight Planning and
Preferred Runways” on page 246.) ERAD flight plans do not use the Preferred
Runways Database, which is used by the non-ERAD Runway-to-Runway feature. To
use runway-to-runway flight planning in an ERAD flight plan, use the ERAD, S2R2R
option described in this section.
NOTE You can request that your customer preferences be set to turn on the
Runway-to-Runway functionality in all ERAD flight plans by default. This preference
setting allows you to use this functionality even if the client interface you are using
does not let you specify this option. For more information, contact your Jeppesen
Account Manager.
When used with the ERAD flight plan option, the ERAD Runway-to-Runway (S2R2R) option
requests FlitePlan Core to select the best runway automatically, based on the most recent TAF
and runway preference information for airports stored in the Jeppesen Navigation Database.
To use the Runway-to-Runway option, enter ERAD followed by S2R2R on the 01 Options
command line.

270
Route Commands
Dynamic SID/STAR Calculation
NOTE You can request that your customer preferences be set to turn on the
Dynamic SID/STAR Calculation functionality in all ERAD flight plans by default. This
preference setting allows you to use this functionality even if the client interface you
are using does not let you specify this option. For more information, contact your
Jeppesen Account Manager.
When used with the ERAD flight plan option, the Dynamic SID/STAR Calculation (S2PTHT)
option instructs FlitePlan Core to compute SID and STAR routings dynamically instead of
using the pre-calculated SID and STAR routings stored in the JetPlan Navigation Database.
The dynamic calculation performed with this option takes into account the aircraft used in the
flight plan request as well as the ARINC 424 data, resulting in a more accurate computation of
SIDs, STARs, and total distance.
No Internal EUROCONTROL Validation

When used with the ERAD flight plan option, the No Internal EUROCONTROL Validation
(S2VF) option instructs JetPlan to request FlitePlan Core to return a trajectory (route plus
profile) without first performing EUROCONTROL validation.
Internal EUROCONTROL validation is enabled in FlitePlan Core by default. The route

selector sends a request to the EUROCONTROL CFMU to validate a candidate optimum
trajectory. If EUROCONTROL responds with a rejection and one or more error messages,
FlitePlan Core attempts to re-optimize the trajectory using constraints derived from the error
messages. This process ensures that FlitePlan Core produces the most optimum
EUROCONTROL-compliant route.
However, in certain situations, obtaining a EUROCONTROL-compliant trajectory is not

necessary or beneficial. For example, JetPlan might request FlitePlan Core to dynamically
provide a route from a POA to one or more of its alternate airports. In this case, not only is
EUROCONTROL compliance not required, but requesting the route selector to internally
validate each route could lead to sub-optimal routes that provide no benefits compared to the
most optimum routes.
To use the No Internal EUROCONTROL Validation option, enter ERAD followed by S2VF
on the 01 Options command-line.

271
C HAPTER 7
Hold-Alternate
Commands
Hold-Alternate Commands
Hold-Alternate Command Line

The Hold-Alternate command line (07 HOLD,ALTERNATE/DIST) is a multi-functional
prompt that enables you to specify several inputs at one time. It is also an optional prompt on
the JetPlan system, meaning no input is absolutely necessary in the course of creating a flight
plan. However, it does provide a way to ensure that fuel is laded for the contingency of delay
or diversion.
You can use this line to specify a hold time, which in turn provides an extra fuel amount to the
total fuel carried. You can also use this line to specify up to four destination alternate airports
and a distance, route, or altitude (specific or range) to each.
Specifically, this command line allows the following information to be entered:
• Hold time at the Point-of-Arrival (POA). When entered without a

destination alternate airport, this input is applied to the POA.
• Hold time at a destination alternate airport. If a hold time and an alternate
are both entered, then the time is applied to the alternate rather than the
POA, and the amount of hold fuel is based on the aircraft’s weight at the
alternate (not the POA).
• Hold time at a primary alternate and one to three (1-3) secondary alternates.
The display of secondary alternate information in the flight plan output is
format-dependent.
NOTE A second destination alternate (if submitted) is included on the ATC filing
strip by default. A customer preference can be set to limit the number of destination
alternates in the filing strip to one, regardless of how many destination alternates exist
in the flight plan request. Please contact your Jeppesen account manager for more
information.
• Hold time that overrides default hold time information stored in your
ID/Password attribute file, Customer Aircraft Database (CADB), or
Customer Airport Database (CAPDB). If you have a default setting for hold
time in a database file, entering a hold time on the Hold command line
overrides that setting.
• Destination alternate airport(s) only with no hold time. One primary
alternate airport and up to three secondary alternates can be specified using
the following syntax:
07 HOLD,ALTERNATE/DIST <xxxx>
where xxxx is the ICAO code for the destination alternate.

275
• User-specified alternate distances. You can apply distance values to any or

all specified destination alternates.
The value you enter is used in the alternate calculation rather than the
standard great circle method for determining the alternate distance, unless a
route is stored in the Customer Alternate (CALT) database.
• User-specified alternate flight levels. You can apply a single flight level or a
range of flight levels to any or all specified destination alternates. When
applying a flight-level override, the minimum and maximum flight level
must be specified for a single flight level as well as for a range of flight
levels. See the examples in Table 7-1, “Hold-Alternate Command Line
Sample Inputs,” on page 285.
• A Customer Route Database (CRDB) file. You can use a pre-stored route
database file as information for the route and performance to a destination
alternate if the file contains the correct airport pair (the departure and arrival
airports in the file match the specified arrival and alternate airports in the
flight plan request). If the airports in the file do not match those specified in
the plan, JetPlan defaults to either the great circle or the CALT Database
distance and route information.
• AIR OPS-compliant destination alternate fuel uplift policy.
• The Dynamic Alternate Route (DAR) command, which instructs JetPlan to
calculate an optimal route to the destination alternate, instead of using great
circle routing or a customer database route.
The following paragraphs discuss the Hold-Alternate commands in more detail. For additional
examples, see Table 7-1, “Hold-Alternate Command Line Sample Inputs,” on page 285.
Hold-Alternate Fuel Considerations

The following section provides some of the factors used in the determination of Hold and
Alternate fuel. You have the option of further control over these factors through certain
parameter settings in your customer databases.
Hold Fuel
The Hold fuel calculation is generally based on the long-range cruise mode fuel flow and the
aircraft weight at the POA. Some factors that can provide more control over how this fuel is
calculated can be found in the CADB. Specifically, this database allows you to set parameters
that control the holding fuel flow, the hold altitude, the minimum amount of hold fuel, and
whether landing weight or Max Zero Fuel Weight (MZFW) is used to calculate hold fuel.

276
Alternate Fuel
Alternate fuel is the fuel required to fly from the point of intended landing (the POA) to the
alternate airport.
Depending on the output format, this can be determined by either a calculated “mini flight
plan” between the POA and the alternate, or a simple table look-up based on the great-circle or
user-specified distance to the alternate. These scenarios are described below.
In any case, the alternate fuel calculation is based on the aircraft weight at the POA. The
altitude profile and distance to the alternate airport is determined by the configuration of a
particular format setting (ALTPFM) and the existence of a stored route.
NOTE Contact your Jeppesen account manager to request a changes to format

settings.
Primary case 1: If a customer route from the POA to the alternate is stored in the
Stored route, CALT Database, JetPlan ignores the ALTPFM format setting and the
optimized altitude customer route is used. Altitude optimization calculations are
performed just as if JetPlan were computing a normal flight plan.
Long Range Cruise (LRC) data is used.
Primary case 2: If there is no stored route between the POA and the alternate, and
Great-circle ALTPFM is set to 2, then the great-circle distance to the alternate is
distance, used along with JetPlan’s normal altitude optimization calculations.
optimized altitude LRC data is used.
Standard case: If there is no stored route and ALTPFM is set to 0 or 1, then the great-
Great-circle or circle distance to the alternate airport is used. The optimum altitude is
user-specified not calculated, but rather selected based on altitude/distance tables
distance, altitude hard-coded into the aircraft performance data. LRC data is used for
selected from aircraft speed and fuel flow information. This generally applies to
table
older output formats that do not enumerate the checkpoints and flight
levels of an alternate route.
If you do not want to use great-circle distance, you can control the
distance factor in the standard case through a user-specified distance
input.

277
For example, assuming that no stored route exists from the POA to
KSCK, the following input uses a distance of 110 nm instead of the
great circle distance:
07 HOLD,ALTERNATE/DIST KSCK/110
Secondary This method applies to secondary alternates, and only when the
Alternate Case output format is designed to include this information. When a
particular secondary alternate has a route from the POA stored in the
CALT Database, the distance determined by that route file is used to
make performance calculations, including an optimum profile
calculation. For computation purposes, the route to this secondary
alternate is considered to be a single segment.
NOTE You can also use the Dynamic Alternate Route (DAR) option to instruct
JetPlan to automatically calculate the optimal route to the destination alternate. See
“Calculating an Optimal Route to a Destination Alternate” on page 280.
Uplift Option (AIR OPS)

If flying under AIR OPS regulations, two destination alternates are required. The fuel uplift
option (ALTF=n), which addresses the destination alternate policy, calculates departure fuel
based on whichever alternate needs the greater amount of fuel (from POA to alternate). The
ALTF parameter has a valid range of 0–4. The range value always matches the number of
alternates entered (for example, two alternates = uplift value of 2).
NOTE Application of this and any option related to AIR OPS requires that a special
parameter in your ID/Password attribute file be set. Contact your Jeppesen account
manager for more information.

278
Alternate Flight Level Restriction

You can request a maximum altitude value (MAv) setting in the Customer Preferences
database to limit the flight level of the alternate route.
NOTE The Customer Preferences database is an extension of your ID/Attribute File.

It allows you to specify certain preference settings that are unique to your operational
requirements. For example, customer preference settings can be defined for flight
level restrictions, reserve fuel calculations, and format, among other factors. Contact
your Jeppesen account manager to discuss your options regarding the Customer
Preferences database.
The maximum altitude value is used in the following formula to determine a maximum
alternate flight level: MAv x route distance = maximum flight level
The maximum altitude value is a percentage figure that provides a certain altitude (in
thousands of feet) when multiplied by the route distance to the alternate.
To elaborate, if the maximum altitude value is set to 150 in the Customer Preferences
database, the maximum altitude for any alternate calculation is 150% of the distance to the
alternate.
For example, assume that for a given flight plan the distance to the alternate is 120 nautical
miles. Using a maximum altitude value of 150 produces a maximum flight level of 18,000
feet.
150 x 120nm = 18,000’ or FL180
NOTE The Customer Preferences database setting does not override the limits set
for the aircraft in its generic data or in the CADB (FL parameter), nor does it override
user-specified flight levels entered on the Hold-Alternate command line.

279
Calculating an Optimal Route to a Destination

Alternate
You can use the Dynamic Alternate Route (DAR) command and the Dynamic Alternate Route
Optimized (DAROPT) flight plan command to calculate an optimal route to a destination
alternate.
NOTE Local JetPlan environments must be configured to support DAR and

DAROPT functionality. For more information, contact your Jeppesen account
manager.
Dynamic Alternate Route Optimized (DAROPT) functionality in client GUI applications
such as JetPlanner.
Using the DAR Command

The DAR command instructs JetPlan to automatically determine the route that is the most
optimal in terms of time, fuel, and cost.
NOTE If you specify a destination alternate but do not use the DAR command ([]),
JetPlan uses a great circle route or customer database route to the alternate.
The DAR command is as follows:
07 HOLD,ALTERNATE/DIST <xxxx>[]
where xxxx is the ICAO designator for the destination alternate airport, and the brackets ([])
instruct the system to calculate the optimal route to the alternate. For example:
07 HOLD,ALTERNATE/DIST LEMD[]
NOTE The DAR command cannot be used in conjunction with automatic alternate
selection.

280
Specifying a Route in DAR Commands

The DAR command instructs JetPlan to calculate an optimal route to a destination alternate.
You can also specify a route to the alternate by typing the route string inside the DAR
command brackets ([]). For example, the following syntax directs JetPlan to calculate a route
to the alternate for EDDG, using direct routing via waypoint DOMEG:
07 HOLD ALTERNATE/DIST EDDG[DCT DOMEG]
Using the DAROPT Flight Plan Option with DAR
Dynamic Alternate Route Optimized (DAROPT) functionality in client GUI applications
such as JetPlanner.
In command-line mode, you can use the DAR command together with the DAR Optimized
(DAROPT) flight plan option to calculate an optimized route to the destination alternate.
When you use the DAR command by itself, the route to the alternate generally adheres to
direct routing. The following flight plan output illustrates the route to HEBA that JetPlan
produces when you use the DAR command by itself:
ROUTE TO FIRST ALTERNATE - HEBA

-N0343F240 HECA..MENKU..HEBA
When the DAROPT flight plan option is used with the DAR command, JetPlan calculates an
optimized route that considers SIDs and STARs, waypoints, NAVAIDS, direct segment
routing, and airways. The following flight plan output illustrates the route to HEBA that
JetPlan calculates when you use the DAROPT flight plan option in conjunction with DAR:
ROUTE TO FIRST ALTERNATE - HEBA

-N0332F220 HECA..CVO A1 MENKU..HEBA
The DAROPT flight plan option must be used with the DAR command. For example:
01 FP,DAROPT
07 HOLD,ALTERNATE/DIST HEBA[]

281
Customer Alternate Database

The Customer Alternate (CALT) database allows you to store information for user-specified
destination alternate airports. You can define distances between POA airports and their
alternates or reference specific route records stored in the CRDB.
Once your CALT Database is developed, you do not need to do anything to invoke its use
other than include a POA airport and a destination alternate in your flight plan request. Upon
submission of your flight plan request, the JetPlan system automatically scans the CALT
Database for matching records. If your flight plan request contains a POA/alternate
combination that matches a record in the CALT Database, the stored data (distance value or
CRDB record) is applied to the calculation process.
This section reviews the type of records stored in the CALT and the methods available to
override these stored records. For information on managing the CALT, see Chapter 29,
“Customer Alternate Database.”
Distance Records
The CALT Database allows you to store a distance record for any POA/alternate combination.
JetPlan uses the stored distance value to calculate performance data (flight level, fuel burn) to
the alternate. This feature eliminates the need for repetitive inputs of alternate distances.
NOTE The following example omits extraneous inputs, such as POD, Route, and so
on.
Example:
Explanation: Assuming a distance value is stored in the CALT Database for the airport
combination (KJFK - KEWR), JetPlan automatically applies the distance to its alternate fuel
calculation.
03 POA KJFK
07 HOLD,ALTERNATE/DIST 30,KEWR
For more examples, see Table 7-1 on page 285.

282
Route Records
The CALT Database allows you to store a route record from the CRDB that defines the
routing between any two airports, specifically, a POA/alternate combination. JetPlan
automatically applies the stored route if the airport matches the POA/alternate combination in
the flight plan. The distance determined by the route file is used to calculate performance data
(flight level and fuel burn) to the alternate.
NOTE The display of a stored alternate route in the flight plan output is
format-dependent. Certain formats allow JetPlan to print out both an alternate route
summary and alternate waypoints. The route summary includes the airspeed and
altitude in an ICAO style output.
The following rules apply when using alternate route files:
• To view alternate route data in the flight plan, the output format must be
programmed to display this information. Otherwise, application is internal
and not displayed fully.
• Low-altitude performance data must be stored in the generic aircraft data
file, the basis for CADB records.
• A route record from the POA airport to the alternate must exist in the
CRDB.
– Each record name stored in the CRDB that is intended for use as an
alternate route must be added to the CALT Database. The route
record name in the CALT Database is the key to finding the actual
route string in the CRDB. Hence, for every route record name in the
CALT Database, there must be a matching record with the correct
airport pair combination in the route database.
• JetPlan uses the standard case for determining the alternate burn calculation
if:
– The POA/alternate airport combination in the flight plan has no
corresponding record in the CALT Database, or if it does, has no
corresponding record in the CRDB.
– A performance error is generated during the calculation of the
alternate route.
– An ad hoc alternate distance is entered after the alternate airport,
thereby nullifying the stored route.

283
Route Output
The following is an example of an output format that displays alternate route information. In
this case, a route from KLAX (POA) to KONT (alternate) is displayed. Alternate route output
is generally designed to display toward the end of a flight plan, right after the main body of the
plan and before any ATC filing information.
. ..flight plan body...
ALTERNATE DATA
-N0277F070 V23 SLI V8N PDZ DCT
CPT LAT LONG MCS DIST

HERMO N33516 W118 210 134 0006
SLI N33468 W118 030 094 0016
AHEIM N33492 W117 552 056 0007
OLLIE N33504 W117 486 064 0006
PDZ N33552 W117 318 057 0015
KONT N34036 W117 360 313 0009
...ATC filing inform ation...

REQUEST NO. 1234
CALT Database Overrides

You can override a CALT Database record (distance or route) in one of three ways:
• Enter a slash after the alternate airport identifier. This nullifies the stored
record and forces JetPlan to determine the distance based on great circle
routing to the alternate.
Example:
30,KEWR/
• Enter a slash and a new distance value after the alternate airport identifier.
This nullifies the stored record and force JetPlan to use the new distance
value.
Example:
30,KEWR/250

284
• Enter a slash and a CRDB record name after the alternate airport identifier.
This nullifies the stored record and force JetPlan to use the route defined in
the specified database file.
Example:
30,KEWR/A001
For more examples, see Table 7-1.
Hold-Alternate Command-Line Inputs

The following examples illustrate representative inputs on the Hold-Alternate command line
(07 HOLD,ALTERNATE/DIST).
Table 7-1 Hold-Alternate Command Line Sample Inputs
Sample Input Explanation

30 30 minutes of hold time at the POA.
30,4500 30 minutes of hold time at the POA, at 4,500 feet

above field elevation. The default holding altitude is
1,500 feet above field elevation. This value can be
changed in the CADB.
45 45 minutes of hold time at the POA; also, assuming a
default value of 30 minutes in your ID/Password
attribute file, this example is an override of that
default value.
30,EGLL 30 minutes of hold time at the alternate, EGLL.
30,KSJC,POAH,25 30 minutes of hold time at the alternate, KSJC, plus 25

minutes of hold time at the original POA.
(POAH=Point of Arrival Hold.)
30,KSJC,POAH,25,3500 30 minutes of hold time at the alternate, KSJC, plus 25
minutes of hold time at the original POA at an altitude
of 3,500 feet above field elevation (1,500 feet is the
default altitude).
30,POAHF=1000 30 minutes of hold time at the POA plus additional
POA hold fuel (POAHF) (weight value). Assuming
pounds is in effect for this example, the additional fuel
value is 1000 lbs.

285
Table 7-1 Hold-Alternate Command Line Sample Inputs (continued)

30,POAHF=1000,POAH=15 30 minutes of hold time at the POA plus 15 minutes of
hold time at the POA (POAH), plus additional POA
hold fuel (POAHF). Additional POA hold fuel can be
entered as both a time value (POAH) and a fuel value
(POAHF). In such cases, JetPlan adds the fuel and
time values.
30,KSEA,POAH=15,POAHF=1800 30 minutes of hold time at the alternate, KSEA, plus
15 minutes of hold time at the original POA, plus
1800 pounds of hold fuel at the original POA. JetPlan
adds the POA fuel and time values.
KABQ Alternate airport with no hold time. If the
ID/Password attribute file has a default hold time of
something other than zero, then this example would
also override the default hold time value.
KABQ [] An alternate airport with the Dynamic Alternate Route
(DAR) command ([]). JetPlan automatically
calculates an optimal route to the alternate.
See “Using the DAR Command” on page 280.
EDDG[DCT DOMEG] An alternate airport with the Dynamic Alternate Route
(DAR) command ([]) and a specific route string.
JetPlan calculates a route to the alternate using the
specified route.
See “Specifying a Route in DAR Commands” on
page 281.
30,EGLL/120 30 minutes of hold time at the alternate, EGLL;
distance from POA to EGLL is a user-specified value
of 120 nm.
30,EGLL,EGKK,EGCC,EGPK 30 minutes of hold time at the primary alternate,
EGLL; secondary alternates are defined as EGKK,
EGCC, and EGPK.
KAUS/100,KELP/200,KDAL/333,KDEN/1111 One primary alternate, KAUS, and three secondary
alternates; the distance from the POA to each alternate
is a user-specified value in nautical miles.
30,RCTP/A001 30 minutes of hold time at the primary alternate,
RCTP; use the route database file, A001, to provide
the route and performance information to the
alternate. This input overrides any information stored
in the CALT Database for the given airport pair, as
long as the airport pair in A001 matches the pair in the
flight plan (the POA and alternate).

286

KSFO/RT01/100/200 Use the CRDB record RT01, and fly between 10000ft
(FL100) and FL200 inclusive. The RT01 record
provides the route and performance information to the
alternate, overriding any information stored in the
CALT Database for the given airport pair (the POA
and alternate). Note the slashes around the minimum
and maximum flight levels after the route record
entry.
KSFO/50/180/240 Primary alternate airport (KSFO) with no hold time;
the distance from POA to KSFO is a user-specified
value of 50 nautical miles (or 50 am), and the flight
level is between FL180 and FL240 inclusive. Note the
slashes around the minimum and maximum flight
levels after the distance entry.
KSFO/50/200/200 Primary alternate airport (KSFO) with no hold time;
the distance from POA to KSFO is a user-specified
value of 50 nautical miles (or 50 km), and a single
flight level of FL200 is specified. You must specify
the minimum and maximum flight level whenever you
apply an altitude override, even for a single flight
level.
KSFO//200/200 Primary alternate airport with no hold time and no
user-specified distance and with a user-specified
altitude of FL200.
KSFO//060/120 Use the default distance value, which is the distance
value specified in the CALT Database. If there is no
distance value in the CALT Database, use the great
circle distance. Fly between 6000ft and 12000ft
inclusive.
KSFO//060/120/ Use the great circle distance, even if there is a distance
value in the CALT Database, and fly between 6000ft
and 12000ft inclusive. Note the trailing slash after
120.
30,EDDM,EDDF,ALTF=2 30 minutes of hold time at the primary alternate,
EDDM. The secondary alternate is defined as EDDF.
Alternate fuel (ALTF) is determined by an uplift
policy of 2, meaning fuel calculations for both
alternates are evaluated to determine the greater
amount, which is then applied to the departure fuel
total (AIR OPS requirement).

287
Automatic Alternate Selection

EXEMPT Some customers might need to state on a flight release
that a special exemption has allowed them not to
specify a destination alternate. The information to be
displayed on the release is format-specific and can
vary by operator. If not legally required, it might be
operationally required to avoid confusion by flight
crew when no alternate is specified.

In addition to the CALT Database, where alternate distance or route information is stored for
retrieval and application when the correct POA/ALT combination is submitted in your flight
plan request, JetPlan can also automatically select alternates based on other preset preferences
and conditions. In this case, no alternate airport needs to be submitted in the flight plan
request.
NOTE If you specify an alternate airport in your flight plan request, the Automatic
Alternate functionality is deactivated for that type of alternate airport.
Automatic selection can be used with destination, departure, and enroute alternates. The
criteria that JetPlan uses to select an alternate automatically is defined by you in your
Customer Airport Fleet Database (CAPFDB) and CAPDB. In these databases, you can set
parameters that help the system to determine a candidate alternate airport’s availability and
suitability. (For information on setting up the CAPFDB and the CAPDB for automatic
alternate selection, see “Setting Up the Customer Databases” on page 298.)
Availability refers to factors that make an airport appropriate for the aircraft type being used,
such as runway length, refueling facilities, passenger exchange, and so on. These factors must
be determined by you for the aircraft in question because simply including them in your
databases defines the airports as available.

288
Suitability refers to factors that limit airport operation, such as weather minima and hours of
operation. These factors are determined in a more dynamic fashion, though you are required to
provide guidelines that assist in the determination process.
NOTE The CALT Database also comes into play when an automatically selected
alternate creates a situation where the POA/ALT combination matches a record in the
CALT Database. In this case, the stored route or distance information found in the
CALT Database is applied to the flight plan calculation.
The following sections describe the automatic alternate selection feature in more detail.
Automatic Selection Criteria and Tests

Although the automatic selection criteria differs somewhat between takeoff, destination, and
enroute alternates, automatic selection is generally a function of the following considerations:
• The estimated time of operation (arrival) into the candidate alternate airport.
This time estimate is part of the calculation process, and it is used to secure
an accurate weather forecast as well for comparison to the candidate
airport’s hours of operation. It also supports ETOPS calculations, where
adjustable earliest/latest arrival time deltas (variations) factor into the divert
calculation.
• The candidate alternate airport’s hours of operation, as defined by the
following parameters in the CAPDB:
– Hours Operation - Open
– Hours Operation - Close
– Week Days
– UTC/Local Flag
For more information on these parameters, see Table 7-5, “CAPDB –
Alternate Airport Application,” on page 306.
• The candidate alternate airport’s terminal weather forecast (TAF). This
forecast is compared to the candidate’s minimum ceiling and visibility
settings stored in the CAPFDB or CAPDB in the following parameters:
– Non-Precision Approach Alternate Ceiling Minimum
– Non-Precision Approach Alternate Visibility Minimum

289
These parameters are in both the CAPFDB and the CAPDB. JetPlan first
checks the CAPFDB for the Non-Precision Approach Alternate
Ceiling/Visibility minimum values. If the values in the CAPFDB are zero,
JetPlan checks the CAPDB.
If you use the optional Precision Minima (PMIN) flight plan option, the
system uses the Precision Approach Alternate Ceiling and Visibility
Minimum values in the CAPFDB or the CAPDB, rather than the Non-
Precision Approach values, to check suitability of alternate airports.
NOTE A customer preference setting allows you to change the database (CAPFDB
or CAPDB) used as the default source of the Alternate Ceiling Minimum and Alternate
Visibility Minimum values. Contact your Jeppesen Account Representative for
information.
For more information on all the ceiling/visibility minima parameters, see

Table 7-4, “CAPFDB – Alternate Airport Application,” on page 301 and
Table 7-5, “CAPDB – Alternate Airport Application,” on page 306.
• The candidate alternate airport’s proximity to the departure or arrival
airport.
• Airline preference and operating practices. This consideration supports
airline specified combinations of acceptable divert airports along with the
allowable aircraft fleet types.
Criteria Tests at Compute Time

Airports that are considered candidates as alternates must pass criteria tests at plan compute
time. Failure to meet one of the three basic criteria listed below eliminates the airport as an
alternate candidate.
• Weather information for the airport (TAF). Failure occurs when TAF for a
candidate alternate is unavailable or incomplete.
NOTE The TAF Time Window customer preference extends the effectivity of TAFs.
For information, see “About the TAF Time Window (TAFWINDW) Customer
Preference” on page 291.
• Airport operational hours. Failure occurs when the flight’s estimated time of
arrival into the candidate’s alternate airport is outside the facility’s
scheduled hours of operation.

290
• Weather minima (ceiling and visibility). Failure occurs when the reported
minima are below the prescribed minima in the candidate alternate’s
CAPDB record.
NOTE JetPlan can provide a briefing of the alternates reviewed at the end of the
flight plan output. The briefing includes those alternates selected as well as those
eliminated due to some criteria failure. This briefing feature is format dependant.
Contact your Jeppesen account manager for more information.
About the TAF Time Window (TAFWINDW) Customer

Preference
NOTE For information about setting the TAF Time Window customer preference,
The optional TAF Time Window customer preference defines a time window—before or after
the effectivity of a given TAF—during which the TAF is applied to the automatic alternate
selection process, thus extending the effectivity of the TAF by the specified number of
minutes. The window value can be defined as anything from zero minutes to 720 minutes (12
hours). A value of zero provides for strict enforcement of TAF effective times.
When the TAF Time Window preference is set, the system applies the following functionality
during the automatic alternate selection process:
• An approximate time to arrive at the alternate is calculated, based on the

planned time to arrive at the POA and then a call to the alternate
performance calculation with the estimated arrival weight.
• The value of the TAF Time Window (TAFWINDW) customer preference is
used to establish start and end times (estimated arrival time - TAFWINDW
value) and (estimated arrival time + TAFWINDW value).
• TAF is checked all the way from the start time to the end time. If ceiling or
visibility fall below minimum anywhere in that time range, the airport is
eliminated from consideration.

291
Alternate Selection Process

As discussed above, the Automatic Alternate selection process requires the setup of specific
database parameters and the deliberate omission of an alternate airport entry in your flight plan
request. When you specify an alternate airport in your flight plan request, the Automatic
Alternate functionality is deactivated for that type of alternate airport. For example, if you
include a destination alternate in your flight plan request, the system does not apply the
automatic selection process to destination alternates. However, departure alternates could still
be automatically selected, given the proper database setup and plan scenario. (For information
on setting up the customer databases for automatic alternate selection, see “Setting Up the
Customer Databases” on page 298.)
The following sections describe the automatic alternate selection process for each type of
alternate.
NOTE In all cases mentioned below, the use of a record from the CAPFDB implies a
match in aircraft fleet type between the record and the flight plan request.
Departure (Takeoff) Alternates

If the POD has a preferred Takeoff Alternate Airport (TA) identified in its CAPFDB record
(for example, TA=KXXX), the process explained below is applied to the preferred takeoff
alternate. However, if the preferred airport does not meet the operational requirements based
on the hours of operation or weather minima, then the proximity search of possible departure
alternates begins.
Possible departure alternates come from a pool of airports stored in the CAPFDB. These
airports are identified as available for use as takeoff alternates by the following parameter
settings:
• Departure Alternate (DA)=Yes

• Type of Operations (TO)=Regular, Alternate, Refueling, or Provisional
From this candidate pool, JetPlan can perform a preliminary ranking of candidate departure
alternates based on proximity to the POD. This is performed using the departure airport’s
record in the CAPFDB, where the Max Distance to Takeoff Alternate (MA) parameter is
defined (for example, MA=50).

292
JetPlan filters out all candidate departure alternate airports that do not meet the operational
requirement established in the plan calculation. If a candidate’s hours of operation parameters
in the CAPDB do not support the possible divert time calculated in the flight plan, the
candidate is eliminated.
Then, JetPlan filters out those candidate departure alternates whose forecast weather is not
available or is below the minima established by the candidate’s ceiling and visibility minimum
values in the CAPFDB or the CAPDB. Using the remaining airports (those that survive the
criteria tests), JetPlan determines which airport provides the best results relative to the
optimization process.
See “Automatic Selection Criteria and Tests” on page 289 for more information about the
hours of operations and minimum ceiling/visibility parameters and the criteria tests.
Destination Alternates
Selection of a destination alternate is primarily based on airline preference. JetPlan checks the
POA record in the CAPFDB for Preferred Destination Alternate Airports (A1-A8). For each
preferred destination alternate, the system examines the criteria of the TAF, operating hours in
the CAPDB, and ceiling/visibility minima in the CAPFDB or the CAPDB. From the list of
preferred airports that meet the criteria, JetPlan selects the airport that provides the best results
relative to the optimization process.
If the POA does not have any preferred alternates stored in the CAPFDB, or if all the defined
preferred airports fail the criteria tests, JetPlan performs a proximity search based on the Max
Distance to Destination Alternate (MD) parameter in the CAPFDB. The proximity search is
for those airports identified as being available destination alternates by the following
parameters in the CAPFDB:
• Arrival Alternate (AA)=Yes

• Type of Operations (TO)=Regular, Alternate, Refueling, or Provisional
The system then selects the alternate that meets the operating hours, weather forecast, and
ceiling/visibility minima criteria and that delivers the best numbers in terms of optimization.
See “Automatic Selection Criteria and Tests” on page 289 for more information about the
hours of operations and minimum ceiling/visibility parameters and the criteria tests.

293
ETOPS/Overwater Driftdown Enroute Alternates (Diversion

Airports)
NOTE ETOPS and Overwater Driftdown flight plan calculations requires extensive
setup, beyond the scope of this section. For complete information on Overwater
Driftdown setup, see Chapter 22, “Overwater Driftdown and Terrain Analysis.” For
complete information on ETOPS, see the ETOPS User’s Guide: 2 Engine Aircraft on
the User Manuals page on JetPlan.com. For information on the Equal Time Point
(ETP) calculation, see Chapter 3, “Point of Departure and Point of Arrival
Commands.”
When creating an ETOPS or Overwater Driftdown flight plan, you can enter the diversion
airports manually on the POD and POA command lines. However, they can also be
automatically selected from a pool of airports stored in the CAPFDB and identified as
available for use in the automatic selection process by the Enroute Alternate in
ETOPS/Overwater Driftdown Operations parameter in the CAPFDB (ET=Yes).
Taking into account additional Overwater Driftdown, ETP, and/or ETOPS parameters
(depending on the type of flight plan), JetPlan can select airports from the pool of candidate
alternates and perform equal time point (ETP) calculations to determine appropriate enroute
alternates. JetPlan filters out potential enroute alternate airports that do not meet the
requirements for hours of operation or weather minimums. See “Automatic Selection Criteria
and Tests” on page 289 for more information.
AIR OPS Enroute Alternates

You can enter an AIR OPS enroute alternate (ERA) manually on line 16. The ERA input is
compliant with AIR OPS 1.255, which allows operators to reduce contingency fuel from 5
percent to 3 percent if they have a qualified enroute alternate. (For more information on the
manual ERA input, see Chapter 14, “Payload, POD/POA, Weight, and Fuel Commands.”)
JetPlan can also select ERAs automatically from a pool of airports identified in the CAPFDB
as available ERAs (EU=Y). A candidate ERA must pass the operating hours, TAF, and
weather/ceiling minima criteria tests. If the candidate also meets route distance and qualifying
circle requirements as specified in AIR OPS 1.255, the system qualifies the selected ERA as
meeting European Aviation Safety Agency (EASA) regulations and automatically reduces the
contingency fuel for the entire flight to 3 percent.
For more information on AIR OPS 1.255, see the Chapter 20, “Reclear Commands.”

294
Prerequisites
Before you can use this feature, the Automatic ERA customer preference must be set to “Yes”
and the EU (JAR)-OPS, International Reserve Fuel Policy, and Special Fuel attributes must be
set in your ID/Attribute file, in addition to other customer preference and format settings. For
complete information, contact your Jeppesen account manager.
NOTE You can override any International Reserve Fuel Policy setting in your
ID/Attribute file by entering the appropriate policy code in the flight plan request (on
line 16) or through the City Pair Fleet DB IR parameter. Successful ERA auto-
selection depends on a correct fuel policy entry. For information on International
Reserve Policies, see Chapter 14, “Payload, POD/POA, Weight, and Fuel
Commands.”
The following customer database settings are also required:
• The CAPDB and the CAPFDB must each contain a record for any airport
you want considered as an AIR OPS ERA.
• In the CAPFDB, the AIR OPS Enroute Alternate (EU) parameter must be
set to “Yes” for any airport you want considered as an AIR OPS ERA.
For more information on customer database setup, see “Setting Up the Customer Databases”
on page 298.
The Automatic AIR OPS ERA Process

When the Automatic ERA customer preference is set to “Yes,” JetPlan performs an automatic
search for an AIR OPS ERA in matching flight plans. JetPlan filters out potential airports that
do not meet the requirements of AIR OPS 1.255 or pass the TAF, operating hours, and weather
minima criteria (see “Criteria Tests at Compute Time” on page 290). Using the remaining
airports, JetPlan determines which ERA provides the optimum results.
When using the Automatic AIR OPS ERA feature, be aware of the following:
• If the Automatic ERA customer preference is present and set to “Yes,”

entering an ERA airport manually on the flight plan request switches off the
automatic ERA selection process.
• You can use the No Automatic Enroute Alternate (NOERA) flight plan
option to disable the automatic ERA search on a per-flight plan basis. For
more information on the NOERA option, see See Chapter 2, “Option
Commands.”

295
AIR OPS Qualification Output

When JetPlan identifies a qualified AIR OPS ERA, it automatically reduces the contingency
fuel to 3 percent. The following paragraphs illustrate this process.
Assume that the CAPFDB record for the Pulkovo airport (ULLI) is set up as follows:
• The Non-Precision Approach Alternate Ceiling Minimum parameter (N3) is

set to 1200 feet.
• The Non-Precision Approach Alternate Visibility Minimum parameter (N4)
is set to 1000 meters.
NOTE For more information on the approach parameters in the CAPDB and
CAPFDB and how they are used in automatic alternate selection, see “Setting Up the
Customer Databases” on page 298.
For purposes of illustration, assume the TAF check for ULLI is as follows:
TAF ULLI 031340Z 0315/0415 16005G10MPS 3000 SN BR BKN006

OVC010 TEMPO 0315/0324 0800 +SNRA FZRA BKN003 640000
BECMG 0400/0402 22005G10MPS TEMPO 0400/0415 1600 SHSN
BKN006 BKN010CB=
In this example, the AIR OPS Qualification output indicates that the automatic selection
process did not discover a qualifying ERA. Because no ERA was found, contingency fuel
remains at 5 percent, as shown in the Fuel Plan section in the following graphic.
EU OPS QUALIFICATION
ERA NO ALTERNATES FOUND

Fuel plan:
FUEL TIME
CONT 00350 00.06
However, if the Ceiling and Visibility Minimum values for ULLI are set to 200 feet and 600
meters respectively, ULLI passes the ceiling/visibility minima check. If it also passes the other
criteria for an ERA, including the AIR OPS 1.255 requirements, ULLI qualifies as an ERA
when the plan is recomputed. As the following output shows, contingency fuel is also reduced
to 3 percent.

296
EU OPS QUALIFICATION
ERA DIVERT PT CUMD MSA TTK DIST FL TIME ETA

ULLI N6048.4 0488 022 154 0067 220 0.10 1816
E02916.8
Fuel plan:
FUEL TIME
CONT 00210 00.03
NOTE The system respects the value of the Min. Contingency/RES Fuel (MC) and
the Min. Contingency/RES Time (MT) parameters in the CADB, even when an airport
qualifies for reduced 3 percent.
Automatic Alternate Setup

Use of the Automatic Alternate feature requires that customer database records be created for
the candidate alternate airports. The following list summarizes what is needed.
• POD – Requires a record in the CAPFDB for every departure airport that
you want considered as a takeoff alternate.
• POA – Requires a record in the CAPFDB for every arrival airport that you
want considered as a destination alternate.
• Candidate takeoff alternate – Requires a record in both the CAPFDB and the
CAPDB for every airport you want considered as a takeoff alternate.
• Candidate destination alternate – Requires a record in both the CAPFDB
and the CAPDB for every airport you want considered as a destination
alternate.
• Candidate ETOPS/Overwater Driftdown enroute alternate – Requires a
record in both the CAPFDB and the CAPDB for every airport you want
considered as an enroute alternate.
• Candidate AIR OPS ERA – Requires a record in both the CAPFDB and the
CAPDB for every airport you want considered as a an ERA.
NOTE An airport can be defined as a candidate for more than one alternate
scenario in the CAPFDB.

297
Setting Up the Customer Databases

The two main databases required for application of the Automatic Alternate selection
functionality are the CAPFDB and the CAPDB.
Customer Airport Fleet Database

The CAPFDB contains parameters that allow you to control the alternate information and
operating procedures for specific sets of aircraft when non-standard or emergency situations
(diverts) occur. Stored records are referenced by both the airport and the fleet type
(airframe/engine combination) in your flight plan request. For more information, see
Chapter 31, “Airport Fleet Database.”
As noted previously, records must be created in this database to support the Automatic
Alternate selection process. This includes records for airports used as departure airports and
arrival airports, as well as those airports you wish to include as possible alternates. The
following tables explain the necessary relationships to this database for each type of airport
application.
NOTE Because the CAPFDB is indexed by airport and fleet type, your flight plan
request must contain a POD (or POA) and aircraft that match a record in the
database for this application to work properly. Furthermore, only those airports
denoted as candidate alternates, with the correct aircraft fleet type, are considered in
the selection process.
Departure Airport (POD)

Any airport used as a POD must be stored in the CAPFDB if you want to apply the automatic
takeoff alternate selection process. If you have more than one type of aircraft in your fleet,
then multiple records can be required for a particular airport.
Table 7-2 CAPFDB – POD Application
Parameter Application/Reason
Airport ID (Required). The ICAO or IATA identifier of the
airport being stored. This entry is one of the two keys
that initiate the use of the CAPFDB. Ex. KLAX or
LAX
Fleet Type ID (Required). Typically the Jeppesen identifier of the

aircraft fleet type. This entry is the other key that
initiates the use of the CAPFDB. Ex. B747

298
Table 7-2 CAPFDB – POD Application (continued)
Takeoff Alternate (TA) (Optional). You can specify a takeoff alternate airfield
as the “preferred” alternate for a specific POD. When
the Automatic Alternate selection process begins, this
is the first airport checked for suitability. If the criteria
check fails (TAF is incomplete or missing, ETA is
outside airport operating hours, or weather is below
minimums), a proximity check is performed for
possible alternates by using the Maximum Allowable
Distance to Takeoff Alternate (MA) parameter.
Maximum Allowable Distance to Takeoff Alternate (Optional). You can specify a distance limit to the
(MA) proximity search for a takeoff alternate airfield (up to
4 digits, in NM or Km). This parameter is considered
only when the Takeoff Alternate (TA) parameter is
left blank or when the TA airport is disqualified due to
weather or curfew. The Automatic Alternate selection
process tests candidate airports within the distance
specified.
NOTE This proximity limit does not typically apply to
your TA parameter input. However, if you invoke the
Terrain Driftdown Approved parameter (TD=Y), the
proximity limit applies to the TA input.
Arrival Airport (POA)

Any airport used as a POA must be stored in the CAPFDB if you want to apply the automatic
destination alternate selection process. If you have more than one type of aircraft in your fleet,
then multiple records can be required for a particular airport.
Table 7-3 CAPFDB – POA Application
LAX


299
Table 7-3 CAPFDB – POA Application (continued)
Maximum Allowable Distance to Destination (Optional). You can specify a distance limit to the
Alternate (MD) proximity search for a destination alternate airfield
(up to 4 digits, in NM or Km). This parameter is
considered only when parameters A1 through A8 are
left blank or when these airports are disqualified due
to weather or curfew (unlikely if all 8 are employed in
the database). The Automatic Alternate selection
functionality tests candidate airports within the
distance specified.
NOTE This proximity limit does not apply to your
preferred destination alternate entries (parameters A1 -
A8). However, if you invoke the Terrain Driftdown
Approved parameter (TD=Y), the proximity limit applies
to the destination alternate entries.
Preferred Alternate Airports (A1...A8) (Optional). You can specify up to 8 preferred

destination alternate airfields for a specific POA. The
order of preference is numeric, with A1 being the first
preference and A8 being the last. When the Automatic
Alternate selection process begins, these airports are
the first checked for suitability. The entire list must be
exhausted before a proximity search for alternates is
begun. If the criteria check eliminates all of the
preferred alternates, a proximity check is performed
for possible alternates by using the MD parameter.

300
Alternate Airport (ALT)

Any airport you wish to have considered as a candidate alternate in the Automatic Alternate
selection process must be stored in the CAPFDB. If you have more than one type of aircraft in
your fleet, then multiple records can be required for these airports.
Table 7-4 CAPFDB – Alternate Airport Application
LAX

Departure Alternate (DA) (Optional). By invoking this parameter (DA=Y) you

designate the airport as a “suitable” takeoff alternate
for the aircraft fleet type identified. Thus, when
departing another airport with an aircraft of the fleet
type identified in this record, the Automatic Alternate
selection process considers this airport as a possible
takeoff alternate. Of course, this airport must be
“available” based on the criteria mentioned
previously.
NOTE Any airport designated as a departure
alternate might be eliminated from consideration for a
variety of reasons, most notably when the POD has a
preferred takeoff alternate assigned (TA parameter for
the POD airport), or when the POD has a maximum
allowable distance parameter (MA) that is less than the
distance between the POD and this departure alternate
airport.
Arrival Alternate (AA) (Optional). By invoking this parameter (AA=Y) you

designate the airport as a “suitable” destination
alternate for the aircraft fleet type identified. Thus,
when arriving at another airport with an aircraft of the
fleet type identified in this record, the Automatic
Alternate selection process considers this airport as a
possible alternate. Of course, this airport must be
“available” based on the criteria mentioned
previously.
NOTE Any airport designated as a arrival alternate
might be eliminated from consideration for a variety of
reasons, most notably when the POA has some
preferred alternates assigned (parameters A1-A8 for
the POA airport), or when the POA has a maximum
allowable distance parameter (MA) that is less than the
distance between the POA and this destination
alternate airport.

301
Table 7-4 CAPFDB – Alternate Airport Application (continued)
Enroute Alternate in ETOPS/Overwater Driftdown (Optional). This parameter activates the key airport as
Operations a possible enroute alternate in the automatic alternate
ET selection process when either the ETOPS or the Basic
(Overwater) Driftdown feature is employed in the
flight plan.
AIR OPS Enroute Alternate (Optional). Defines the key airport as available for
(EU/JAR Operations Alternate) use as an enroute alternate for automatic enroute
alternate selection. Applies to EU(JAR)-OPS only.
EU
ETOPS Approach NOTE This parameter is used only with ETOPS 2

flight plan options. Contact your Jeppesen account
ETOPS Ceiling Minimum
ECM
(Optional). This parameter defines the ceiling
minimum for the airport in feet or meters. It is used to
determine if an ETOPS alternate is suitable based on
the TAF weather between the Early Arrival Time and
later arrival time.
This parameter works in conjunction with the ETOPS
Ceiling Minimum parameter in the CAPDB. If there
is not a minimum value in the CAPFDB, JetPlan
checks for the minimum in the CAPDB. If there is no
minimum value in the CAPDB, JetPlan uses zero
ceiling.
ETOPS Approach NOTE This parameter is used only with ETOPS 2

ETOPS Visibility Minimum
EVM
(Optional). This parameter defines the visibility
minimum for the airport in feet or meters. This
parameter is used to determine if an ETOPS alternate
is suitable based on the TAF weather between the
Early Arrival Time and later arrival time.
This parameter works in conjunction with the ETOPS
Visibility Minimum parameter in the CAPDB. If there
is not a minimum value in the CAPFDB, JetPlan
checks for the minimum in the CAPDB. If there is no
minimum value in the CAPDB, JetPlan uses zero
visibility.

302
Non-Precision Approach NOTE The Precision Minima (PMIN) flight plan option
uses the Precision Approach Alternate Ceiling and
Alternate Ceiling Minimum
Visibility Minimum values to check suitability of
N3 alternate airports. See definitions of those parameters
below.
Defines the ceiling minimum for the airport in feet or
meters. This parameter is a weather criteria check in
the automatic alternate selection process. When
JetPlan checks the suitability of an airport as an
alternate (departure, enroute, or arrival alternate) it
might perform a TAF check on that airport. That is, it
compares the TAF forecast with the landing minimum
values for the candidate alternate airport.
By default, JetPlan first checks the CAPFDB for the
Non-Precision Approach Alternate Ceiling Minimum
value. If the value in the CAPFDB is zero, JetPlan
gets the value from the CAPDB.
NOTE A customer preference setting allows you to
change the database used as the default source of the
and Non-Precision Approach Alternate Visibility
Minimum values. Contact your Jeppesen Account
Representative for information.
Alternate Visibility Minimum
below.
Defines the visibility minimum for the airport in feet
or meters. This parameter is a weather criteria check
in the automatic alternate selection process. When
compares the TAF forecast with the landing minima
Non-Precision Approach Alternate Visibility
Minimum value. If the value in the CAPFDB is zero,
JetPlan gets the value from the CAPDB.

303
Precision Approach Defines the ceiling minimum for the airport in feet or
Alternate Ceiling Minimum meters.
P3 When the PMIN flight plan option is used, JetPlan
uses the Precision Approach Alternate Ceiling
Minimum and the Precision Approach Alternate
Visibility Minimum values to check the suitability of
alternate airports. (When the PMIN option is not used,
JetPlan uses the more conservative Non-Precision
Approach Alternate Ceiling and Visibility Minimum
values to check suitability of alternates.)
Precision Approach Alternate Ceiling Minimum
Precision Approach Alternate Ceiling Minimum and
Precision Approach Alternate Visibility Minimum
values. Contact your Jeppesen Account
Precision Approach Defines the visibility minimum for the airport in feet
Alternate Visibility Minimum or meters.
uses the Precision Approach Alternate Visibility
Ceiling Minimum values to check the suitability of

304
NOTE Even though each airport application (POD, POA, and ALT) is addressed
separately, and as if unique, a record for a particular airport could address all three
applications in the CAPFDB. In other words, you can create a record for a particular
airport/AC fleet type that sets all of the parameters necessary to make the airport
applicable in all situations of the automatic alternate selection process (as a POD, as
a POA, and as a candidate alternate).
Customer Airport Database

Along with numerous other parameters for other purposes, the Customer Airport Database
(CAPDB) contains parameters that allow you to control the factors that determine the
suitability of an airport in the Automatic Alternate selection process. Specifically, the CAPDB
is where you define the weather minima and operating hours criteria for individual airports.
For more information about all of the available parameter settings, see Chapter 30, “Customer
Airport Database.”
Any airport to be considered as a possible alternate in the Automatic Alternate selection

process must have a record in this database. The following table defines the parameters needed
to support the Automatic Alternate application.
NOTE The CAPDB can be used for several applications. An airport record can
include information that applies to the facility as a POD, a POA, or an alternate.
However, the information in the table below specifically applies to the Automatic
Alternate selection process.

305
Table 7-5 CAPDB – Alternate Airport Application
airport being stored. This entry is the key that initiates
the use of the CAPDB. Ex. KLAX
below.
Defines the ceiling minimum for the airport in feet or
meters. This parameter is a weather criteria check in
the automatic alternate selection process. When

306
Table 7-5 CAPDB – Alternate Airport Application (continued)
below.
Defines the visibility minimum for the airport in feet
or meters. This parameter is a weather criteria check
in the automatic alternate selection process. When
Non-Precision Approach Alternate Visibility
Minimum value. If the value in the CAPFDB is zero,
JetPlan gets the value from the CAPDB.
Precision Approach Defines the ceiling minimum for the airport in feet or
Alternate Ceiling Minimum meters.
uses the Precision Approach Alternate Ceiling
Visibility Minimum values to check the suitability of
Precision Approach Alternate Ceiling Minimum

307
Table 7-5 CAPDB – Alternate Airport Application (continued)
Precision Approach Defines the visibility minimum for the airport in feet
Alternate Visibility Minimum or meters.
uses the Precision Approach Alternate Visibility
Ceiling Minimum values to check the suitability of
Opening Hour of Operation (O1) (Optional). The O1 parameter allows you to define the
hour at which the airport opens (for example,
O1=0600). If no input is entered, 0000Z is assumed
by default.
Closing Hour of Operation (C1) (Optional). The C1 parameter allows you to define the
hour at which the airport closes (for example,
C1=1800). If no input is entered, 2400Z is assumed by
default.
Days of Week Open (W1) (Optional). The W1 parameter allows you to define
the days of the week the airport operates using the
hours defined by the O1 and C1 parameters (for
example, W1=23456). The default setting is 1234567,
or all seven days.
NOTE Monday is considered the start of the
operational week. Hence, 1=M, 2=T, 3=W, etc.
UTC/Local Flag (T1) (Optional). This parameter allows you to designate the
airport’s hours of operation as coordinated universal
time (UTC) or local time. The default setting is UTC.
Other Parameters (O2..O4, C2..C4, W2..W4, T2..T4) (Optional). These parameters allow you to define the
airport’s hours/days of operation if multiple settings
are necessary. For example, an airport might have
different operating hours on different days, or might
have midday closings.

308
C HAPTER 8
Estimated Time of
Departure Commands
Estimated Time of Departure Commands
ETD Command Line
ETD Command Line

The ETD command line is used for entering a flight’s Estimated Time of Departure (ETD),
which is a mandatory input.
The ETD input affects the performance calculation immensely. The ETD input directly
correlates to the forecast wind and temperature data that is applied in the computation of the
flight plan. For this reason, a large portion of this chapter is devoted to the various weather
databases that provide online winds to JetPlan.
In addition to ETD, the ETD command line supports the input of these options:
Required Arrival You can set a time for arriving at a specific point in the flight (enroute
Time option (RAT) fix or POA) and JetPlan adjusts the ETD to meet the required arrival
time. JetPlan uses your specified cruise mode. In this case, the cruise
mode input is a more or less fixed airspeed, forcing the change in the
ETD.
Required Arrival Using a cost index value as your cruise mode input, you can set a time
Time Cost Index for arriving at a specific point in the flight (enroute fix or POA)
option (RATCI) without affecting the defined ETD. In this case, the cruise speed
varies (increases or decreases) to meet the required arrival time while
the ETD remains fixed.
Orbit (ORB) You can orbit (hold at) a selected enroute point at a specified altitude
for a specific amount of time.
NOTE The RATCI and RAT options are mutually exclusive features. They cannot
be used together in the same flight plan. The ORB option, however, can be used in
conjunction with the RAT option, if needed.
The following sections describe all of the ETD command line options in detail.

311
The Standard ETD Input
The Standard ETD Input

An ETD input is a four digit, UTC value.
Example:
ETD 2230
The following considerations apply to the standard ETD input:
• 23 hours and 59 minutes from the current time is as far into the future that a
flight plan can be computed. For example, if the current time is 1000 UTC,
the latest the ETD input is 0959 for the next day.
• The ETD determines the forecast data (enroute winds and temperatures) on
which the flight plan is calculated.
• If the flight plan passes into a new forecast period (the length of the flight
exceeds the time range of the forecast data used to start the computation),
the remainder of the flight plan is computed using data from the next
forecast period.
NOTE JetPlan can accept an estimated date of departure (EDD).
Example:
08 ETD 1700/EDD,19APR07
NOTE Some front-end flight planning applications, such as JetPlanner, allow you to
enter a Scheduled Date of Departure (SDD) in your flight plan request. The SDD is
not factored into flight plan calculations. It is informational only and is output on
supporting flight plans.

312
Understanding the Wind and Temperature Database
Understanding the Wind and Temperature

Database
The ETD input correlates to the forecast wind and temperature data that is applied in the
computation of the flight plan. The following sections describe the forecast weather data used
in flight plan calculations.
“PROGS” Time Output on Flight Plans

Every flight plan computed on the JetPlan system includes the valid time of the weather
forecast data used in the calculation of that flight plan. Forecast data refers to the wind and
temperature aloft information stored in and accessed from a special database. The valid time is
a day/time stamp typically displayed on the second line of the header information in the flight
plan output. It is always identified by the label “PROGS.”
The PROGS day/time stamp indicates the collection date and time of the forecast data. For
example, the day/time stamp, 2212ADF, indicates that the weather data was collected on the
22nd day of the month and is the 1200Z update of the ADF file. Database updates are
expressed in Zulu [UTC] time.
The Aviation Digital Format (ADF) database updates twice in a 24-hour period: at 0000Z and
1200Z. The high-resolution National Weather Service (NWS) and United Kingdom
Meteorological Office (UKMO) forecast weather databases update four times in a 24 hour
period: at 0000Z, 0600Z, 1200Z, and 1800Z. The PROGS day and time stamp defines the
relative recentness of the forecast information used in the flight plan calculation.
Online Winds – Sources and Formats

Forecast weather data is collected, compiled, and sent from a major meteorologic gathering
agency to Jeppesen four to seven hours after the noted collection time. Jeppesen validates the
integrity of the data transmission and updates JetPlan generally within one hour of receiving
the information.
Each update creates a new weather database file that is valid for the period extending until the
next update. The information within an update spans approximately 30 hours of flight
planning capability, depending on which database you use. This means that you can plan
flights that extend 30 hours into the future on any of the forecast databases.

313
JetPlan has two sources for recently gathered forecast wind and temperature aloft data: the
UKMO (also known as the UK Met Office Weather Service) in England and the NWS in the
U.S. From these two sources Jeppesen provides three different forecast models for the
application of weather to the flight plan computation: ADF, NWS, and UK. Typically, the
ADF weather model is the default format. However, you can select any one of these three as
your default format by requesting the setting of one in your ID/Attribute File. The default
format can be overridden on any individual flight plan by entering the option that selects
another weather database on the Options command line.
NOTE For information on changing your default forecast weather model, contact
your Jeppesen account manager.
ADF Format (Default)

The ADF database file is the default forecast weather model if no other choice is made on the
Options command line and if no other format is set as the default in your ID/Attribute File.
The ADF file is usually updated twice a day (0000Z and 1200Z) and is generally composed of
reformatted NWS GRIB (gridded binary) data, although it can also be taken from UKMO
GRIB data if necessary. In either case, the data originates from a high-resolution forecast
weather file and is converted to this older, lower resolution format to create a separate file.
Information in the ADF file is compiled into a grid with points every 2.5 degrees of latitude
and longitude between 20N to 70N and between 20S to 70S. Between 20N and 20S, and on the
extreme poles, the grid points are placed every 5 degrees of latitude and longitude.
Information about wind direction, wind velocity, and temperature for a given set of mandatory
altitudes is collected for each grid point.
ADF provides faster processing times than either of the other two formats, though the
difference is minimal. The data within the ADF file extends approximately 30 hours into the
future. Any plan that goes beyond that window receives data that is reexamined and applied
from earlier in the update. While this ensures the completion of the flight plan (no error is
promulgated due to a lack of data), it does affect the quality of the information within it.
Whether it is the default format or user-defined at the time of plan creation, “ADF” generally
appears after the day/time stamp on the flight plan output (for example, 0500ADF). To select
the ADF format, enter WXADF on the Options command line anywhere after the FP
command.
Example:
FP,WXADF

314
NWS Format
The NWS GRIB format provides a high-resolution database file. It uses advanced numerical
models for wind and temperature aloft forecasting. The data for this format is compiled into a
grid with points every 1.25 degrees of latitude and longitude (more than doubling the lateral
amount of data available compared to ADF). In addition to the greater number of lateral grid
points, NWS GRIB collects extra intermediate readings in the vertical direction too. This
provides more precise information about the wind direction, velocity, and temperature at a
given altitude, especially compared to the standard atmosphere levels of data collected for
ADF.
The NWS format is updated four times a day (0000Z, 0600Z, 1200Z, and 1800Z) and provides
a weather window that extends approximately 48 hours into the future (preferable for long
flights being planned a day in advance).
Whether it is the default format or user-defined at the time of plan creation, the letters “NWS”
generally appears after the day/time stamp on the flight plan output (for example, 1018NWS).
To select this format, enter WXNWS on the Options command line anywhere after the FP
command.
Example:
FP,WXNWS
UKMO Format
The UKMO GRIB format is a high-resolution model that is similar in data compilation to that
of the NWS format. Like the NWS format, it is updated four times a day (0000Z, 0600Z,
1200Z, and 1800Z). However, this file only provides a 30-hour weather window.
Whether it is the default format or user-defined, the letters “UK” generally appear after the
day/time stamp on the flight plan output (for example, 0500UK). To select this format, enter
WXUK on the Options command line anywhere after the FP command.
Example:
FP,WXUK
UK MET Office Historical Winds

The UK Met Office Historical Winds Database is a weather model that provides historically
likely wind and temperature aloft figures for any given month of the year. The UK Met Office
Historical Weather Database uses a 30-year history of average monthly wind values. The

315
historical winds are a statistical average from the period 1960–1990. Each grid point uses the
average wind direction and wind speed from each day in the month to come up with a monthly
average grid point value at each standard altitude for that month. This database is a helpful
“What if?” option for planning possible flights in the future.
To select this database, enter WHXX, where “XX” is a number value for the desired month of
the year (01–12), on the Options command line anywhere after the FP command. For example,
to specify UK Met Office historical data for the month of December, enter:
Example:
FP,WH12
JetPlan displays the three-letter abbreviation for the selected month in the header of the flight
plan output, right after PROGS (see output sample below).
PLAN 7027 EGKK TO LIRF MD11 LRC/F IFR 08/17/06

NONSTOP COMPUTED 1659Z FOR ETD 0000Z PROGS DEC LBS
*** JEPPESEN HISTORICAL AVERAGE WINDS HAVE BEEN USED. ***
Reliability Equivalent Winds

The Reliability Equivalent Winds option enables you to apply a statistical reliability value to
the historical weather data that you use for planning purposes. For example, the historical
weather data might indicate that August winds are historically light in a given region.
However, you expect stronger winds than usual in that region this August. You can increase
the expected wind speed by applying a lower statistical reliability value to the historical data.
The following paragraphs describe the historical weather database and the confidence level in
more detail.
National Center for Atmospheric Research (NCAR) Database

The Reliability Equivalent Winds option enables you to plan using monthly, seasonal, or
annual data stored in the NCAR database. The NCAR database is a compilation of 40 years
(1960–1999) of upper-level wind and temperature data. The data is based on daily
computerized analyses provided by the U.S. National Weather Service. The NCAR database
contains higher-resolution historical wind and temperature data than is available in the UK
Met Office Historical Winds database. The NCAR data is also available for any airport and
any latitude/longitude.

316
Confidence Level
The confidence level value is a percentage that represents the statistical likelihood that the
wind speeds recorded in the NCAR database will occur in a given time period in the future.
You can specify a confidence-level value from 1 to 99%, with 50% being the statistical
average.
CAUTION Jeppesen recommends using a confidence level of no more than 50%.

Higher confidence levels can underestimate wind speeds.
You can apply the confidence level value to data gathered for any single month or for a range
of up to 12 months. For example, the NCAR database contains 40 monthly average readings
for November from the years 1960–1999. A 50% confidence level means that flight plan
headwind component values for November will not exceed the values gathered in 50% of the
monthly values.
Using the Reliability Equivalent Winds Option

Anywhere after FP on the Options command line, type the Reliability Equivalent Winds
command, using one of the following formats:
• FP,WS##,R##
where WS## is a calendar month, expressed as a two-digit value from 01-
12, and R## is a confidence level expressed as a percentage. For example,
November is expressed as WS11, and 50% is expressed as R50.
• FP,WS####,R##
where #### is a range of months, expressed as a four-digit value, and R## is
a confidence level expressed as a percentage. For example, December (12)
through March (03) is expressed as WS1203, and 50% is expressed as R50.
CAUTION Jeppesen recommends using a confidence level of no more than 50%.

Higher confidence levels can underestimate wind speeds.

317
Required Arrival Time
The following examples illustrate different time periods and the recommended confidence
level input:
Time Period and Confidence Level Command Line Values

November with 50% confidence WS11,R50
Summer (June to August) with 50% confidence WS0608,R50
Winter (January to March) with 50% confidence WS0103,R50
Annual period (January to December) with 50% confidence FP,WS0112,R50

NOTE The Required Arrival Time and the Required Arrival Time – Cost Index
options are mutually exclusive.
This section describes the Required Arrival Time - Cost Index (RATCI) and the Required
Arrival Time (RAT) options. These options enable you to define a fixed arrival time at just
about any enroute point or at the destination. You cannot use the two options together because
each option has an opposite effect on the ETD. The main determiner of which option to use is
whether or not the ETD can be changed. The two options are:
Fixed ETD (RATCI JetPlan varies the airspeed by adjusting a cost index (CI) cruise mode
option) until the required arrival time input is met. The original ETD is
maintained. In most cases, a cost index cruise mode input is
mandatory. For more information on cost index cruise mode inputs,
see Chapter 12, “Cost Index Commands.”
Variable ETD (RAT JetPlan adjusts the ETD to make the required arrival time while
option) applying a cruise mode that is relatively constant. In this case, a cost
index cruise mode cannot be used. However, cruise modes such as
ECO, CMC, and LRC are acceptable. For more information on cruise
modes, see Chapter 11, “Cruise Mode Commands.”
The following sections describe the RATCI and RAT options in more detail.

318
RATCI (Fixed ETD)
NOTE You must set certain parameters in the Customer Aircraft Database or
include a cost index cruise mode input on the Cruise Mode command line for this
option to work. See “RATCI and the Customer Aircraft Database” on page 320 and
Chapter 12, “Cost Index Commands.”
The RATCI feature generates a flight plan based on a set arrival time at either the POA or an
enroute fix. JetPlan varies the aircraft speed to make the required arrival time while
maintaining the original ETD.
To invoke the RATCI option, enter your estimated time of departure value on the ETD
command line. Follow that with a slash (/), the RATCI option, an enroute fix or the POA, and
a required arrival time.
Example:
Explanation: The estimated time of departure is 0100Z, the required arrival time point is
RKSI, and the required arrival time is 1207Z.
08 ETD 0100/RATCI,RKSI,1207
NOTE You also must enter a cost index cruise mode on the Cruise Mode command
line.
RATCI Considerations
The following considerations apply to the RATCI option:
• The time constraint input must be achievable, considering the aircraft’s

minimum and maximum speeds.
• If a waypoint is designated as the required arrival time point, it must be
located after Top of Climb (TOC) and before Top of Descent (TOD).
• The required arrival time point (POA or enroute waypoint) must be entered
in ICAO format only.

319
• The RATCI option can be used with JetPlan’s Reclear feature, but only for
an enroute waypoint that is located at or before the reclear fix. The Reclear
POA cannot be specified as the RATCI point.
• The display of the cost index value used in a flight plan can usually be found
on the top line of the flight plan output (the header section), before the
forward slash that separates the cruise mode stamp from the performance
index stamp. The required arrival time is displayed in the ARRIVE column
of the flight plan output. However, the display of this information depends
on your output format.
RATCI and the Customer Aircraft Database

The Customer Aircraft Database contains five parameters that are used to control the RATCI
process. They are:
Min RAT Cost Minimum RATCI value

Index (CI1)
Max RAT Cost Maximum RATCI value

Index (CI2)
Default Cost Index First CI value tried in the RATCI process

(CI3)
Lowest Cost Index Lowest Mach number to use in cost index (not just RATCI) flight
Mach (LM) plans
Highest Cost Index Highest Mach number to use in cost index (not just RATCI) flight
Mach (HM) plans
If these parameters are set, and the RATCI option is invoked, JetPlan performs an iterative
process that determines the CI cruise mode necessary to attain the required arrival time. The
iterative process is as follows:
• JetPlan first computes the flight plan using the cruise mode specified in the
flight plan request on the Cruise Mode command line. If this calculation
satisfies the requested arrival time (the RAT point is reached on time), the
iterative process is stopped, and the plan is output.

320
• If the cruise mode from the flight plan produces a flight that arrives at the
RAT point early, JetPlan reviews the cruise mode input to determine if it is a
constant mach value.
– If it is a constant mach value, JetPlan reviews the LM parameter
setting in the aircraft database. If the input value and the LM
parameter setting are equal, JetPlan uses this value, stops the
iterative process and produces the plan output. In this case, JetPlan
can do no more because the LM setting prevents any attempt at a
slower airspeed.
– If it is not a constant mach value, JetPlan determines a cost index
value.
• If the cruise mode from the flight plan is not a cost index value and not a
constant Mach value, JetPlan determines the cost index by starting with the
default value in the CADB (CI3). In this case, test CI values are tried until
one works and a plan is produced or until one of the CI limits (CI1 or CI2) is
reached and the time is determined to be unattainable.
• Otherwise, the cruise mode from the flight plan is a cost index value, in
which case, JetPlan starts searching for the right cost index value by
applying one of the four methods listed below:
– If the user-specified cost index value is higher than the default value
in the CADB (CI3) and the plan is early, JetPlan starts the search by
applying CI3.
– If the user-specified cost index value is higher than the default value
in the CADB (CI3) and the plan is late, JetPlan starts the search by
applying the maximum CI value from the CADB (CI2).
– If the user-specified cost index value is lower than the default value
in the CADB (CI3) and the plan is early, JetPlan starts the search by
applying the minimum CI value from the CADB (CI1).
– If the user-specified cost index value is lower than the default value
in the CADB (CI3) and the plan is late, JetPlan starts the search by
applying CI3.
• Continue search until the iterations converge (when the arrival time is within
three minutes from the RAT—early or late).
Since these iterations can be time consuming, there are many checks to stop them early. For
example, if the maximum allowable CI is used, and the arrival time is still late, then the search
is terminated because there is no greater speed, based on your own CADB inputs.

321
RAT (Variable ETD)

The RAT option allows you to generate a flight plan based on a set arrival time at either the
POA or an enroute fix. JetPlan determines the departure time based on the fixed airspeed.
NOTE You must enter an estimated time of departure value on the ETD command
line. This value needs to be a reasonable estimate of the departure time so that
JetPlan can access the correct blocks of forecast data (winds and temperatures) for
the flight computation.
To invoke the RAT option, enter your estimated time of departure value on the ETD command
line. Follow that with a slash (/), the option (RAT), an enroute fix or the POA, and finally a
required arrival time.
Example:
Explanation: The estimated time of departure is 1200Z. This estimate is used to access the
correct forecast weather data. The required arrival time point is RKSI, and the required arrival
time is 1825Z.
08 ETD 1200/RAT,RKSI,1825
RAT Considerations
The following considerations apply to the RAT option:
• If the required arrival time input results in a departure time that is past the
day’s current time, a processing error results.
• If a waypoint is designated as the required arrival time point, it must be
located after TOC and before TOD.
• The required arrival time point (POA or enroute waypoint) must be entered
in ICAO format only.
• This option can be used with JetPlan’s Reclear feature, but only for an
enroute waypoint that is located at or before the reclear fix. The Reclear
POA cannot be specified as the RAT point.
• The RAT option and the Orbit (ORB) option can be used together.
• JetPlan displays the following statement on the third line of the flight plan:
REQUIRED ARRIVAL TIME AT <XXXX HHMM>, where XXXX is the RAT
point identifier, and HHMM is the coordinated universal time of the arrival.

322
The following examples illustrate the RAT option. Sample flight plan outputs are included to
show what to expect based on the example input.
Example:
Explanation: The estimated time of departure is 1900Z (to access forecast weather data). The
RAT point is the POA, LIRF, and the arrival time is set to 2130Z. The sample output
illustrates the results of this input.
02 POD EGKK
03 POA LIRF
08 ETD 1900/RAT,LIRF,2130
Sample output:
PLAN 7061 EGKK TO LIRF MD11 M85/F IFR 08/17/06

NONSTOP COMPUTED 1740Z FOR ETD 1953Z PROGS 1700ADF LBS
REQUIRED ARRIVAL TIME AT LIRF 2130Z
Example:
Explanation: The estimated time of departure is 1900Z (to access forecast weather data). The
RAT point is the enroute waypoint, LASBA, and the arrival time is set to 2030Z. The sample
output illustrates the results of this input.
02 POD EGKK
03 POA LIRF
08 ETD 1900/RAT,LASBA,2030
Sample output:
PLAN 7099 EGKK TO LIRF MD11 M85/F IFR 08/17/06

NONSTOP COMPUTED 1709Z FOR ETD 1935Z PROGS 1700ADF LBS
REQUIRED ARRIVAL TIME AT LASBA 2030Z

323
ORBIT
ORBIT
The Orbit (ORB) option allows you hold at a waypoint for a specific length of time, airspeed,
and flight level. This can be used to burn excess fuel (or time), to rendezvous with another
aircraft, or to meet any requirement you deem necessary.
To invoke the ORB option, enter your estimated time of departure value on the ETD command
line. Follow that with a slash (/), the orbit option (ORB), the orbit point, the hold time, the
orbit airspeed (cruise mode), and the orbit altitude.
Example:
08 ETD departure time/ORB,checkpoint,time,speed,flight level
ORB Considerations
The following considerations apply to the ORB option:
• JetPlan does not make climb/descent performance calculations between the

enroute cruise altitude and the orbit altitude.
• This option can be used with the JetPlan Reclear feature, but only for an
enroute waypoint that is located at or before the reclear fix.
• This option can be used with the RAT option (but not RATCI).
• JetPlan inserts the checkpoint, ORB01, (and the associated performance
data) in the flight plan body prior to the user-defined orbit fix. ORB01 is
deemed “collocated” with the orbit fix.
• JetPlan displays the performance data (distance, time, and burn) from the
immediately previous enroute waypoint to the orbit fix on the ORB01 line.
Since ORB01 and the orbit fix are collocated, JetPlan generates zero
distance from ORB01 to the orbit fix. JetPlan displays the orbit time and
fuel burn on the same line as the orbit fix.
Example:
Explanation: Depart at 1900Z. Orbit the enroute waypoint, LASBA, for 45 minutes at long
range cruise, at an altitude of 37,000 feet.
02 POD EGKK
03 POA LIRF
08 ETD 1900/ORB,LASBA,45,LRC,370

324
ORBIT
Example:
Explanation: Multiple orbit points can be entered as shown. Depart at 1900Z. Orbit SFO for 20
minutes at long range cruise, at an altitude of 25,000 feet. Orbit XIDIL for 20 minutes at long
range cruise, at an altitude of 21,000 feet. Orbit TOP for 10 minutes at long range cruise, at an
altitude of 23,000 feet.
08 ETD 1900/ORB,SFO,20,LRC,250,XIDIL,20,LRC,210,TOP,10,LRC,230
The following sample flight plan output illustrates the expected results when the ORB option
is invoked. Three points are shown for clarification: 1) the fix prior to ORB01; 2) the ORB01
point; and 3) the orbit fix. Column headers are included at the top of the sample for ease of
interpretation.
CPT COORDINATES / FIR TRP SR DIST TIME FUEL

F/L TMP WIND T/C T/H AW/MH TAS G/S ZD CD ZT CT ZF CF
FIR N46084 E006024 / LFFF FIR 42 2
370 M03 31053 133 133 UG32 457 510 002 0411 0/00 0/45 000 0121
ORB01 N45447 E006387 42 2
370 M03 31053 133 133 UG32 457 510 035 0446 0/04 0/49 007 0128
LASBA N45447 E006387 42 2
370 M03 31056 133 133 UG32 484 540 000 0446 0/45 1/34 078 0206
ORB and RAT Options

The ORB and RAT options can both be entered on the ETD command line if needed. The use
of both does not necessarily tie the two together in a joint purpose, but the two can be applied
to coordinate a specific mission. For example, the RAT option could be applied to one enroute
point as a rendezvous, where timing is critical, while the ORB option could be applied to the
next enroute point for the purpose of completing some requirement.
The order in which these options are added to the ETD command line is irrelevant. The
following examples illustrate this point.
Example:
Explanation: Estimated time of departure is 1900Z. The required arrival point is the POA
station, LIRF, and the arrival time is set for 2230Z. An orbit is set for the enroute point,
LASBA, for 45 minutes using long range cruise at an altitude of 33,000 feet.
02 POD EGKK
03 POA LIRF
08 ETD 1900/RAT,LIRF,2230/ORB,LASBA,45,LRC,330

325
ORBIT
Example:
Explanation: Same as above.
02 POD EGKK
03 POA LIRF
08 ETD 1900/ORB,LASBA,45,LRC,330/RAT,LIRF,2230

326
C HAPTER 9
Profile Commands
Profile Commands
Overview
Overview
JetPlan is designed to automatically attain the best flight profile for a given aircraft within a
given airspace for any situation. The Profile command line provides user control over this
designed optimization. With it, you can manage the:
• Altitude Flight Rule Selection

• Altitude Control Options
You must enter at least one Flight Rule option on the Profile command line to complete a
flight plan request. Altitude Control options are optional; they can be included with your flight
rule input if necessary.

329
Profile Commands
Altitude Flight Rule Selection

An altitude flight rule is applied using the following Profile command line options.
Table 9-1 Flight Rules Options
Option Explanation
I Selects the optimal IFR altitudes based on your performance index
setting.
NOTE The performance index setting is entered in the flight plan
request on the Performance Index command line (line 12) or stored
as the default setting in your Aircraft Database file (see the
“Performance Index (Fuel, Time, and Cost) Optimization” on
page 342 for more information).
If the flight plan request includes routing via one of the organized
track structures, the I option allows step climbs/descents between
designated track altitudes, provided the aircraft weight and
ambient temperature are conducive to such a maneuver. The I
option considers all MEA airway restrictions. For information on
organized tracks, see Chapter 6, “Route Commands.”
I, M Selects the optimal IFR altitudes (as explained above) and also
considers MAA airway restrictions. This option prompts a check
of the altitude profile against MEAs and constrains the profile to
MAAs. If JetPlan cannot find a valid altitude, or if you specify an
altitude below the MEA or above the MAA, an MEAMAA01 error
is generated.
I, T Selects the optimal IFR altitudes (as explained above) and uses
GRID MORA data to ensure that flight levels clear all obstacles
along a given route area (grid region). If a selected flight level is
below the recommended clearance level, JetPlan generates a
MORALT01 error.
Output formats designed for this information prints the GRID
MORA data in the flight plan body.
NOTE GRID MORA is the Minimum Off Route Altitude within a
section–outlined by the latitude and longitude lines (the grid)–that
clears the tallest obstacle within that section. Jeppesen values clear
all terrain and man-made structures by 1,000’ in areas where the
highest elevations are 5,000’ MSL or lower, and by 2,000’ in areas
where the highest elevations are 5,001’ MSL or higher.
I, M, T Selects the optimal IFR altitude (as explained above) and considers
MEAs, MAAs, and GRID MORA data. If a route segment is on an
airway, JetPlan checks for stored MEA/MAA information first. If
no MEA or MAA value is found, then a check is done against the
GRID MORA data. If a route segment is not on an airway (an
optimized direct segment), the only check is against the GRID
MORA data.

330
Profile Commands
Table 9-1 Flight Rules Options (continued)
Option Explanation
C Same as the I option except that it restricts step climbs/descents
while on the following organized track structures: North Atlantic
and PACOTS. If the PACOTS include one or more segments on
the NOPAC, this does not apply.
V Selects the optimal VFR altitudes.

NOTE Must be used in conjunction with the low or mid altitude
databases to be applicable.
I,xxxxx/V This is used for flight plans that begin as IFR and transition to VFR
(described as “Y” type flight plans in ICAO 4444 Air Traffic
Management, 14th Ed. 2001). The transition fix is entered
followed by /V to indicate a transition to VFR altitudes.
EXAMPLE:
Explanation: IFR to VFR transition at MALOT.
09 PROFILE I,MALOT/V
NOTE This functionality is not applicable in the United States with
FAA flight plans. It is applicable only to ICAO flight plans.
V,xxxxx/I This is used for flight plans that begin as VFR and transition to IFR
(described as “Z” type flight plans in ICAO 4444 Air Traffic
Management, 14th Ed. 2001). The transition fix is entered
followed by /I to indicate a transition to IFR altitudes.
EXAMPLE:
Explanation: VFR to IFR transition at MALOT.
09 PROFILE V,MALOT/I
NOTE This functionality is not applicable in the United States with
FAA flight plans. It is applicable only to ICAO flight plans.
Other Considerations
The following considerations apply to the selection of optimal altitudes:
• Up to twenty-nine different altitudes can be output on each flight plan. The

altitude changes can occur to minimize fuel, time, or cost, and to conform to
the appropriate cruising altitude for the direction of flight.
• All non-hemispherical altitudes are loaded in the airway information of the
navigation database. Flight plans step climb/descend between hemispherical
and non-hemispherical altitudes provided there is at least a 60 nm segment
distance for which the new altitude is effective.
• The appropriate metric equivalent flight level(s) are output in the FIR/UIR
boundaries where applicable.

331
Profile Commands
Altitude Control
• If a flight plan cruise altitude is above the highest altitude of an organized

track structure prior to the transition onto the track structure, the profile does
not descend to a designated track altitude when the flight rule option “C” is
entered on the Profile command line.
• Hawaiian Tracks R-463, R-465, and R-577 have a non-published “track”
altitude of FL420 loaded into the route database, which is 2,000' above the
highest published track altitude for these tracks. Additionally, R-465 and R-
577 have FL440 loaded in the database. Within the constraints of aircraft
performance, this allows the system to consider additional altitude(s) which
might be assigned by ATC.
Altitude Control
Altitude control refers to the flight planner's option to constrain the profile one or more times,
or to invoke 2,000' step climbs while enroute. You can change the flight’s profile using up to
ten sets of altitude restrictions. A restriction can be entered as either a single altitude value or a
range of altitudes. Where the restriction takes effect in the flight depends on the constraint
points (waypoints) specified by the planner. Restrictions can be specified to occur after the
crossing of an enroute waypoint or by the time the waypoint is reached.
Auto Step Climb

The unique command to invoke 2,000' step climbs is the input, 920. This option can be applied
to the entire flight or to a specific route segment.
NOTE For those organized track structures (OTS) that allow it (the North Atlantic
tracks), JetPlan automatically applies 2,000' step climbs, if applicable.
To invoke 2000’ step climbs, enter “920” on the Profile command line.
Example:
Explanation: Apply IFR rules and 2,000’ step climbs for the entire flight.
09 PROFILE I,920

332
Profile Commands
Altitude Control
Example:
Explanation: Apply IFR rules to the flight. Step climb, in 2,000’ increments, between BAE
and ENM.
09 PROFILE I,BAE,920,ENM
Changing Flight Levels

Up to ten sets of flight level restrictions and associated altitude constraint points can be
specified on a Profile command line.
To enter flight level changes, you must specify waypoints from the route of flight as constraint
points for each change event. The examples below illustrate the correct way to enter profile
changes, including the constraint points.
Example:
Explanation: Apply IFR rules. Fly at flight level 260 to DBQ, 280 to ONL, 310 to CYS, and
350 the rest of the way (until Top of Descent).
09 PROFILE I,260,DBQ,280,ONL,310,CYS,350
Example:
Explanation: Apply IFR rules. Fly at flight level 260 to DBQ, 280 to ONL, 310 to CYS, 350 to
OAL, and optimize the flight level the rest of the way (no input after OAL).
09 PROFILE I,260,DBQ,280,ONL,310,CYS,350,OAL
Unlike the examples above, it is a good practice to provide a flight level range as your
restriction rather than a single “hard” altitude. This allows JetPlan to consider climbs/descents
when non-hemispherical airways are encountered. It also generally provides better
optimization and avoids “2 Heavy” errors which increase in likeliness when a single flight
level is specified. Consider the following example.
Example:
Explanation: Apply IFR rules. Fly anywhere between the flight levels 290 and 350 (inclusive)
until the waypoint, BAE. Select optimal altitudes the rest of the flight.
09 PROFILE I,290,350,BAE

333
Profile Commands
Altitude Control
Waypoints As Constraint Parameters

As stated earlier, where the change in profile occurs can be controlled. A descent or climb can
be specified to occur after crossing a waypoint or by the time the waypoint is reached.
Altitude Change After Waypoint

When entering multiple profile changes, note that unless explicitly defined otherwise, changes
in flight level occur after the specified constraint point is reached. This is illustrated in the
following example.
Example:
09 PROFILE I,M,260,DBQ,280,ONL,310,CYS,350,OAL
This input applies a change in flight level from 260 to 280 after reaching the waypoint DBQ.
Likewise, each subsequent flight level change occurs after crossing the defined waypoint.
Altitude Change at Waypoint

Altitudes that must be attained by a specific waypoint, rather than after crossing the waypoint,
can be entered in two ways:
• By entering a minus sign (-) in front of the flight level. In this case, the
comma separation is retained (for example, AVE,-280).
- or -
• By entering the waypoint and flight level as a single unit, separated by an
“at” symbol (@). In this case, the comma is omitted (for example,
AVE@280).
For example, assume a flight from TPA to LAX overflying the waypoint, IAH. In this
hypothetical flight, the required profile is flight level 350. However, the aircraft must be at
flight level 280 by IAH. This probably could be attained by specifying 280 and the waypoint
that immediately precedes IAH. However, that waypoint is not presently known. For that
reason, an input that utilizes IAH as the constraint point is required.

334
Profile Commands
Altitude Control
The two possible profile entries are:
Example:
09 PROFILE I,350,IAH,-280
- or -
09 PROFILE I,350,IAH@280
Had the standard input (I,350,IAH,280) been entered, the flight level, 280, would have been
attained, but only after crossing IAH (by the next waypoint).
Constraint Rules
When specifying a waypoint as a constraint point, adhere to the following rules:
• All waypoints referenced as constraint points must be on the route of flight.

Therefore, it is good practice to include these waypoints in your route input.
• Altitude controls work with all flight rule options. However, if the flight rule
option, C (no step climb rule), is applied, constraints are only recognized
when the route is not on an organized track structure (do not apply flight
level changes to points on an organized track with this option).
• Both the charted identifier and the internal identifier (in Areas 1 through 5
of the Route Optimizer navigation database) are acceptable inputs when
specifying a waypoint as a constraint.
• Both the charted identifier and the internal four-character identifier (in Area
0 of the Route Optimizer navigation database) are acceptable inputs when
specifying a waypoint as a constraint.
• For a latitude/longitude waypoint, the four-digit identifier for this point must
be used. Typically, this identifier is the first two digits of the latitude and the
second and third digits of the longitude.
NOTE JetPlan internally generates four-digit identifiers to define lat/long waypoints.

These identifiers can be found in the flight plan output (in the route summary line and
the flight plan body).
• For a SRS waypoint, the charted (output) name must be used.

• A fix/radial/distance (FRD) waypoint must be specified as it prints out on
the route summary line.

335
Profile Commands
Altitude Control
Altitude Control Examples

The examples below illustrate the various types of altitude control entries. POD, POA and
Route command line inputs are included to provide better understanding.
Example:
Explanation: Apply IFR rules. Fly at flight level 290 up to and including the waypoint MAN.
Fly optimal IFR flight levels after MAN.
02 POD EGLL
03 POA OEJN
06 ROUTE J,MAN
09 PROFILE I,290,MAN
Example:
Explanation: Apply IFR rules. Fly at FL295 (metric equivalent) up to and including BH, then
FL361 (metric equivalent) to LNO. Fly optimal IFR altitudes after LNO.
02 POD VHHH
03 POA OMSJ
06 ROUTE J
09 PROFILE I,295,BH,361,LNO
Example:
Explanation: Apply IFR rules. Select altitudes between FL290 and FL370. Retain initial track
altitude for the entire track structure portion of the flight.
02 POD RJAA
03 POA KSFO
06 ROUTE J/OE/J
09 PROFILE C,290,370
Example:
Explanation: Apply IFR rules. While on track structure, retain initial track altitude until the
last track fix. Fly optimal altitudes to BOI, optimize between FL290 and FL330 to SLC. After
SLC, only fly FL330 to JNC, then optimize between FL370 and FL410 the rest of the way.
02 POD RJAA
03 POA KDFW
06 ROUTE J/OE/J
09 PROFILE C,BOI,290,330,SLC,330,JNC,370,410

336
Profile Commands
Altitude Control
Example:
Explanation: Apply IFR rules. Constrain the profile to any MAAs encountered in the route.
02 POD VHHH
03 POA OMDB
06 ROUTE J//J
09 PROFILE I,M
Example:
Explanation: Apply IFR rules. Check the profile against GRID MORA data.
02 POD KSFO
03 POA KDEN
06 ROUTE D
09 PROFILE I,T
Example:
Explanation: Apply IFR rules. Fly FL290 up to and including the waypoint 5050N (SRS
syntax for the point identified on the Route command line), then fly FL330 the rest of the way.
02 POD CYQX
03 POA EINN
06 ROUTE D/5000,05000/D
09 PROFILE I,290,5050N,330
Maximum Altitude Restrictions

Using one or more of the following techniques restricts the maximum flight level applied to
the flight plan profile:
• Specify a flight level value or a minimum and maximum flight level range
value on the Profile command line. The following example demonstrates the
min/max range concept.
Example:
09 PROFILE I,100,170

337
Profile Commands
Altitude Control
• Use the Customer Aircraft Database (CADB) file to set a maximum flight
level (FL parameter) for all performance calculations. This is a permanent
restriction applied to a single aircraft that is typically used to define a “never
to exceed” flight level value. The following example demonstrates how to
set FL390 as a “never to exceed” maximum altitude in the CADB.
Example:
01 OPTIONS AC,CHG,12345,FL=390
• Set a maximum altitude value as a function of route distance in the
Preferences database.
NOTE The Preferences database is an extension of your ID/Attribute File. It allows

you to specify certain preferred settings that are unique to your operational
requirements. This includes flight level restriction factors, reserve fuel calculation
factors, format preference factors, and other useful settings. Contact your Jeppesen
account manager to discuss your options regarding the Preferences database.
This is a method that is applicable to short flights, where optimal cruise altitudes might not be
practical. The maximum altitude value you provide is used in the following formula:
MAv x route distance = maximum flight level
The maximum altitude value is a percentage figure that provides an altitude (in thousands of
feet) when multiplied by the flight’s route distance.
For example, if your maximum altitude value is set to 150 (150%) in the Preferences database,
and the flight distance is 120 nm, then the maximum altitude for the flight is:
150 x 120nm = 18,000’ or FL180
NOTE This feature does not override the limits set for the aircraft, either in its
generic data or in the CADB (Max Flight Level parameter).
Climb and Descent Altitude Constraints

When altitude constraints are requested during climb and descent, the system needs to change
the climb and descent speed profile to satisfy the constraints. The First Principles Aircraft
Model (FPM) Climb and Descent aeroperformance calculation provides the flexibility
required to change the climb and descent speeds.

338
Profile Commands
Altitude Control
When the flight plan request includes climb or descent altitude constraints, and the requested
aircraft is supported by FPM, JetPlan attempts to satisfy the constraints by changing the climb
or descent speed automatically using FPM. The system displays an alert when the climb or
descent speed has changed and also displays an alert if it cannot satisfy the altitude constraints.
FPM Climb and Descent Settings

This section describes the settings that the system requires to activate the FPM climb and
descent calculation and apply it to the automatic climb and descent speed change to satisfy
altitude constraints.
Required FPM Data

A file with FPM climb and descent data must exist in the generic aircraft record for the aircraft
used in the flight plan request. You can check the Generic Aircraft ID (GAID) record for the
presence of an FPM file with climb and descent data. For information, see “Searching Generic
Aircraft Records for FPM and OUTFLT Information” on page 718 in Chapter 27, “Customer
Aircraft Database.”
Required FPM Climb and Descent Method Parameter Settings

In the “Miscellaneous” section of the CADB, the climb and descent method parameters must
be set to use FPM as follows:
• Climb Method (CM) – (G) Mach CAS Schedule (FPM)

• Descent Method (DM) – (G) Mach CAS Schedule (FPM)
For more information on these parameters, see Chapter 27, “Customer
NOTE If the Climb Method or Descent Method parameter is not set to G in the
CADB, the system does not use FPM to recalculate the speed profile as necessary to
satisfy a climb or descent profile constraint.

339
Profile Commands
Altitude Control
Initial Climb and Descent Speed Schedule Settings

You can set custom climb and descent speeds in the Customer Airport Fleet Database, or you
can use climb and descent speed schedules in the generic aircraft file.
NOTE Climb and descent speed settings in the Customer Airport Fleet Database
override the speed schedules in the generic aircraft file.
To specify custom initial climb speeds, set one or both of the following in the Customer
Airport Fleet Database:
• CASC – Climb speed in Calibrated Airspeed (CAS)

• MACHC – Climb speed in MACH
To specify custom initial descent speeds, set one or both of the following in the Customer
Airport Fleet Database:
• CASD – Descent speed in CAS

• MACHD – Descent speed in MACH
For more information on these parameters, see Chapter 31, “Airport Fleet Database.”
If you do not set custom climb and descent speeds in the Airport Fleet Database, JetPlan uses
the climb and descent speed schedules in the generic aircraft record. To view the climb and
descent schedule information in the generic file, use the AC,<JEPPID>,CRZ command on the
Options command line. For information, see “Determining an Aircraft’s Cruise Modes” in
Chapter 9, “Profile Commands.” See also Chapter 10, “Aircraft Type Commands.”
Requesting Climb and Descent Altitude Constraints

If you request an altitude constraint at a specific climb or descent waypoint, the system
attempts to ensure that the aircraft is at or above the altitude when it reaches the waypoint. To
satisfy the altitude constraint, JetPlan uses FPM to automatically recalculate the climb and
descent speed profile as necessary. JetPlan alerts you if the system climb or descent speed
profile changes or if the altitude constraint cannot be satisfied.
For example, if the aircraft must be at or above a specific altitude when it reaches a given
climb or descent waypoint, you can enter the flight level constraint as follows:
09 PROFILE I,UMKAL@260

340
Profile Commands
Altitude Control
In this example, IFR rules are applied. UMKAL is the waypoint, and 260 is the minimum
flight level the aircraft must reach by UMKAL. If necessary, the system uses FPM to
recalculate the climb and descent speed profile to satisfy this altitude constraint.
If the aircraft must be below a specified altitude when it reaches a climb or descent waypoint
or must stay within a range of altitudes between waypoints, you can enter the profile constraint
as follows:
09 PROFILE I,<Waypoint 1>,180,200,<Waypoint 2>
In this example, IFR rules are applied. Upon reaching Waypoint 1, the aircraft must be
between flight levels 180 and 200 feet (inclusive) and must remain within that range until
arriving at Waypoint 2. If the aircraft cannot attain the required altitude at Waypoint 1 with its
initial speed profile, the system uses FPM to automatically recalculate the climb and descent
speed profile to satisfy the altitude constraint if possible.
Requesting MEA,MAA and GRID MORA Data Constraints

You can also apply MEA,MAA and GRID MORA data constraints to climb and descent
waypoints using FPM. Enter the following command:
09 PROFILE I,M,T
JetPlan automatically checks MAA and MEA altitude constraints and checks the profile
against the GRID MORA data. The system uses FPM to automatically recalculate the climb
and descent speed profile to satisfy minimum and maximum altitude limits at the climb or
descent waypoint.
SID/STAR Profile Constraints Customer Preference

The SID/STAR Profile Constraints customer preference activates FPM for SID/STAR profile
constraints. If JetPlan detects SID/STAR profile constraints, the system automatically uses
FPM to reset the climb and descent speeds to satisfy checkpoint profile constraints if possible,
and displays an alert message if the constraint cannot be satisfied.
The SID/STAR Profile Constraints functionality has the same settings as those listed in “FPM
Climb and Descent Settings” on page 339. In addition, the SID/STAR Profile preference must
be active in your customer preference file. Output of SID/STAR profile constraint information
is format-dependent. Contact your Jeppesen Account Manager for more information.

341
Profile Commands
Performance Index (Fuel, Time, and Cost) Optimization
Using the FPM Secondary Climb and Descent Option

You can also change the climb and descent speed schedule manually using the FPM
Secondary Climb and Descent option. See “First Principles Aircraft Model Secondary Climb
and Descent Options” in Chapter 11, “Cruise Mode Commands.”
Flight Plan Output

Output of climb and descent altitude constraints with FPM information on the flight plan is
format-dependent. The output includes information on the cruise, climb, and descent methods
and the speeds and profiles used in climb and descent. Also included is the origin of the speed
data. For example, the output indicates if the climb and descent speed is derived from the
Airport Fleet Database, from the generic aircraft file, or from a secondary climb input on the
Cruise command line in the flight plan request. The output also indicates whether or not FPM
automatically recalculated the speed. Contact your Account Manager for more information.
Performance Index (Fuel, Time, and Cost)

Optimization
In JetPlan, Performance Index (PI) refers to the type of optimization factor used to calculate an
altitude profile. PI is a code that tells JetPlan how to compute the flight plan in order to meet
the desired objective of increasing performance to reduce cost. In all performance index cases,
JetPlan evaluates the profile within the context of the submitted primary cruise mode(s), and
determines the most advantageous altitude profile, using the most favorable wind conditions
given certain logical restrictions, such as distance and general direction.
For flight plans that do not use the Cruise Mode Cost Index (CI) input, you can choose
between three performance index parameters: fuel, time, or money (overall cost). In JetPlan,
you enter the PI information on the Performance Index command line (Line 12). You can also
store your preference for one of these parameters in the Customer Aircraft Database (CADB)
so that it is applied automatically (see Chapter 27, “Customer Aircraft Database.”) However,
the CADB PI setting can always be overridden by a value entered on the Performance Index
command line.The display of the cost information on the flight plan output is format-
dependent.
NOTE If the flight plan is run using a Cost Index cruise mode, including Require
Arrival Time Cost Index (RATCI), the PI is automatically determined by JetPlan. In
this case, any PI value in the CADB or input by the user on the Performance Index
command line is ignored.

342
Profile Commands
Fuel Optimization
In the fuel optimization (or save fuel) scenario, JetPlan calculates performance to determine
the most advantageous altitude profile for minimizing fuel consumption.
In comparison with the other performance indices, fuel optimization produces a minimum fuel
burn at the cost of a longer flight time.
To select fuel optimization, enter the letter “F” on the Performance Index command line.
Example:
12 PRFM INDEX F
Time Optimization
In the time optimization (or save time) scenario, JetPlan calculates performance to determine
the most advantageous altitude profile for minimizing the enroute time. Some examples of
time-based costs are: aircraft and engine lease rates, crew pay, and time-dependent
maintenance costs.
In comparison with the other performance indices, time optimization produces a minimum
enroute time at the cost of a larger enroute fuel burn.
To select time optimization, enter the letter T on the Performance Index command line.
Example:
12 PRFM INDEX T
Cost Optimization
In the cost optimization (or save money) scenario, JetPlan optimizes the flight plan profile to
minimize the total cost of the flight. To determine the total cost, you must provide fuel and
operating (time) cost values.
NOTE This feature produces a total cost figure in the flight plan output, even if you
run the plan using a different cost index.

343
Profile Commands
To select cost optimization, enter the letter “M” (for money), followed by a fuel cost value and
an operating cost value, on the Performance Index command line. Separate each item with a
comma.
Example:
12 PRFM INDEX M,$$$,$$$$
The fuel cost input is the price per U.S. gallon of fuel. It is a three or four-digit input without
any decimal points (for example, 110 = $1.10/USG).
The operating cost figure is a four or five-digit input (no decimal point), representing the total
price per hour of variable factors such as the cost of operating the aircraft, the crew salaries,
and maintenance fees (for example, 1250 = $1,250/hr).
Example:
Explanation: Fuel cost is $1.10/USG, and operating cost is $1,250/hr.
12 PRFM INDEX M,110,1250
If you want to omit the operating cost figures to determine fuel costs only, include a minimum
operating cost of one dollar per hour as part of the input.
Example:
Fuel cost is $1.10/USG, and operating cost is $1.00/hr.
12 PRFM INDEX M,110,0001

344
Profile Commands
Order of Precedence
It is important to understand the order of precedence JetPlan applies to fuel prices and
Performance Index values. A fuel price entered on the Performance Index command line and
the value of the PI parameter in the CADB can each be overridden by other values. The order
of precedence for fuel price is:
• JetPlan first uses any fuel price entered on the 02 POD command line.
• If no fuel price is entered on the 02 POD command line, JetPlan uses the
fuel price entered with the parameter “M” on line 12 PRFM INDEX.
• If no fuel price is entered on line 12 PRFM INDEX, JetPlan uses the value
of the Fuel Price (FP) or Bonded Fuel price (BP) parameter in the Customer
Airport database (CAPDB). Which price is used is determined by the setting
of the Bonded Fuel indicator parameter in the City Pair Database (CPDB).
• If the FP (or BP) parameter in the CAPDB is not set, JetPlan uses the fuel
price associated with the parameter “M” and stored for the PI parameter in
the CADB.

345
C HAPTER 10
Aircraft Type
Commands
Aircraft Type Commands
Overview
Overview
JetPlan requires the input of an aircraft before any flight plan can be computed. To do this, you
must type the ID of a generic aircraft from the JetPlan Aircraft Library or the record name of
an aircraft stored in your Customer Aircraft Database (CADB) on the Aircraft Type command
line.
Example:
10 A/C TYPE/REGN <GENERIC ID or CADB RECORD NAME>
JetPlan applies the information from these input sources to calculate performance data in the
flight plan computation.
Using the JetPlan Aircraft Library

(Generic Aircraft)
The JetPlan Aircraft Library is the source of all Aircraft Type command line inputs, including
CADB files. This library is developed, built, and maintained by Jeppesen. It contains weight
and performance data for hundreds of aircraft from many different manufacturers.
Each aircraft in the library is referred to as a “generic aircraft” load because the information
stored is enough to meet basic flight plan requirements. Enough basic weight and performance
data are contained within each generic aircraft record to provide JetPlan with the climb, cruise,
descent, hold, and weight information needed for flight plan computations.
In some cases, there are multiple versions of the same generic aircraft in the library. The
addition of these extra models to the library depends on factors such as certain manufacturer
redesigns or reconfigurations (for example, an engine upgrade) and customer requirements.
A generic aircraft load incorporates the following forms of data:
Weight Figures Data includes various weight settings, such as maximum takeoff,
maximum landing, maximum zero fuel, maximum payload weight,
and weight range limits for customer adjustments.
Cruise Data Cruise data consists of aircraft performance data on airspeeds and
fuel flows as a function of temperature, altitude, and weight and up to
five cruise modes for each generic aircraft identifier.

349
Using the JetPlan Aircraft Library (Generic Aircraft)
Climb Data Climb data consists of aircraft performance data on climb fuel, time,
and distance as a function of temperature, altitude, and weight.
Descent Data Descent data consists of an adjustable profile to simulate your descent
schedule
Hold Data Hold information is characteristic of the aircraft type and can be
modified to your requirements.
Alternate Data Alternate information is characteristic of the aircraft type and can be
modified to your requirements
Retrieving Library Information

You can retrieve library information from JetPlan to determine the availability of an aircraft
model (airframe/power plant combination). The type of information available includes lists of
the following:
• Manufacturers
• Aircraft from particular manufacturers
• All aircraft loads for particular ICAO identifiers
• All aircraft by their Jeppesen identifiers
You can view these lists by using the INFO command on the Options command line.
To view a list of manufacturers in the library

To view a list of manufacturers with aircraft loaded in the JetPlan Aircraft Library, type
INFO,ACQREF on the Options command line.
Example:
01 OPTIONS INFO,ACQREF

350
The information displayed includes the manufacturer code and the ICAO code for each
aircraft.
NOTE The following example is intended as an illustration only and is not

necessarily complete or current. In addition, certain proprietary information is
represented by placeholder text <xxxx>.
NAME CODE ICAO

------ ------ ----------------------------------
AERITALIA: AERITALI AT42 AT43 AT45 AT72 AY22
AEROSPATIALE: AEROSPAT S210
AIRBUS INDUSTRIES: AIRBUS <xxxx> <xxxx>
BRITISH AEROSPACE: BAC BA11 H25A H25B H25C HS25 VC10 BA46
JS31 JS41 BA46 A748 HS74 ATP
BEECH: BEECH B350 BE10 BE20 BE30 BE33 BE35 BE36
BE55 BE60 BE9L STAR BE58 BE40
BOEING: BOEING B701 B703 B707 B712 B720 B721 B722
B727 B732 B733 B734 B735 B736 B737
B738 B739 B73A B73S B741 B742 B743
B744 B747 B74F B74S B752 B753 B757
B762 B763 B764 B767 B772
CANADAIR: CANADAIR CARJ CL44 CL60 GLEX
CASA: CASA CS12
CESSNA: CESSNA C172 C177 C182 C208 C210 C402 C406
C421 C425 C441 C500 C501 C525 C550
C560 C56X C650 C750
CONVAIR: CONVAIR CVLT
DASSAULT: DASSAULT F2TH F900 FA10 FA20 FA50
DEHAVILLAND: DEHVLAND DH8A DH8B DH8C DH8D DHC6 DHC7
DORNIER: DORNIER D328
MCDONNELL DOUGLAS: DOUGLAS C17 DC10 DC8 DC85 DC86 DC87 DC8S
DC9 DH8C MD11 MD80 MD90
EMBRAER: EMBRAER E110 E120 E135 E145
FAIRCHILD: FARCHLD FA4 SW3 SW4
FOKKER: FOKKER F100 F28 F50 F60 FK28 FK50 FK7
FK70
GATES LEARJET: LEARJET LJ24 LJ25 LJ31 LJ35 LJ36 LJ45 LJ55
LJ60 LR24 LR31
GULFSTREAM: GLFSTRM AC95 G159 GLF2 GLF3 GLF4 GLF5
ILYUSHIN: ILYUSHIN IL62 IL76 IL86
ISRAEL: ISRAEL AJ25 ASTR GALX JC21 WW23 WW24
LOCKHEED: LOCKHEED C130 C140 L101 L188 L29B L329 L382
P3 P3C
MITSUBISHI: MTSBISHI MU2 MU3
MOONEY: MOONEY M02K
PIPER: PIPER P32R PA28 PA31 PA46 PAY2 PAY3 PAY4
ROCKWELL: ROCKWELL AC90 AC95 N265 SBR1 SBR2
SAAB/SCANIA: SAAB SB20 SF34
TUPOLEV: TUPOLEV T134 T154
MISCELLANEOUS: MISCELL PC12 SH36

351
To view a list of aircraft from a particular manufacturer

To view a list of aircraft from a particular manufacturer, type the manufacturer code after the
INFO command on the Options command line. The sample output above shows the
manufacturer codes.
Example:
01 OPTIONS INFO,BOEING
The information displayed in this request appears in the following sample output.
NOTE The following sample output is abbreviated for space. Each manufacturer
code is associated with a list of aircraft, and each aircraft can have several generic
aircraft loads.
767D 470 B767/H BOEING GE CF6-80A

767-200ER BOEING 767 OPS.MAN. 6-L34A SEPT 82 / SEP 87 *
BASIC OPTWT MXTOWT MXVRF MXLDWT MXZFWT
181000 LBS 351000 113000 278000 253000
MIN.OPWT ETP AS/LVL-DRIFT CLIMB = 250/290/.78M
80000 365KT/FL230
CRUISE/ALTITUDE RANGE: LRC-070,430 *LRC UNDER FL250
M74-070,430* M80-070,430* M81-070,430* M82-070,430* M84-070,410*
HOLD = 1500 FT/ISA
DESCENT = DEFAULT: .78/290/250 AUX: (M79)-.79/290
ALTERNATE= ALTERNATE PLANNING CHART PG 23.10.33 / BASED ON LRC
* SAME PERFORMANCE FIGURES AS 767B BUT WITH EXT. RANGE CONF.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
777A 714 B772/H BOEING P W 4077/84
BOEING B777-200 OPERATIONS MANUAL
BASIC OPTWT MXTOWT MXVRF MXLDWT MXZFWT
315000 LBS 535500* 208000* 445000* 420000*
MIN.OPWT ETP AS/LVL-DRIFT CLIMB = 250/310/.84M
175000 1LE-370KT/FL190
CRUISE/ALTITUDE RANGE:
LRC-100,430 M84-100,430 (325IAS UNDER FL250)
HOLD = 1500 FT FLAPS UP *WEIGHT LIMITS BASED ON (A) MARKET
DESCENT = M84/310/250 CONFIGURATION
ALTERNATE = ALTERNATE PLANNING CHART AT LRC
ALTITUDE CAPABILITY BASED ON MCT AND 1.4G BUFFET
To view a list of all aircraft for a particular ICAO identifier

To view the list of all aircraft loads for a particular ICAO identifier, type the aircraft ICAO
code after the INFO command on the Options command line.

352
Example:
01 OPTIONS INFO,B767
NOTE The output for the INFO,<ICAO Code> option is similar to the output that
shows the list of manufacturers (see “To view a list of manufacturers in the library” on
page 350).
The output includes the Jeppesen identifier for each aircraft listed. The identifier is the four-
character code in the top left corner of each section of the aircraft output. For example, in the
previous output example, the Jeppesen identifiers for the two aircraft are 767D and 777A. You
can use the Jeppesen identifiers to look up more information about an individual version of
this generic aircraft.
Retrieving Generic Aircraft Information

You can use the AC command on the Options command line to retrieve more information
about a generic aircraft. The following commands provide a more detailed view of default
information stored in the generic aircraft file.
To view basic weight and speed schedule information

To view the basic weight and speed schedule information of a generic aircraft, type
AC,<JEPPID>,CRZ on the Options command line.
Example:
01 OPTIONS AC,747H,CRZ
NOTE The JeppID and CRZ option can be entered in reverse order without
changing the outcome (for example, AC,CRZ,747H).

353
The output shows the default weights for the selected aircraft and its speed schedules for the
various stages of flight.
EXAMPLE (AC,JEPPID,CRZ)
-------------------- 747H INFO -----------------------------

B743(ICAO) 747-300 engine: JT9D-7R4G2
MAX TOW MAX LAND WT MAX ZFW MAX FUEL CAP
833000 605000 535000 361700 lbs
377800 274400 242700 164100 kg
-------------------- FLIGHT SCHEDULES ----------------------
CLB AAA . . . . . . . . 330/.84
CRZ 1LE . . . . . . . . ENGOUT LRC
270 . . . . . . . . 270KIAS FL050 - FL390
GDC . . . . . . . . GEAR DOWN CRUISE
LRC . . . . . . . . LONG RANGE CRUISE
M84 . . . . . . . . ALT 110 450 M84 >210
M85 . . . . . . . . ALT 110 450 M85 >210
M86 . . . . . . . . ALT 240 450 M86 >240
M88 . . . . . . . . ALT 280 450 M88 >280
CUTOFF 13G . . . . . . . . 1.3G
14G . . . . . . . . 1.4G
15G . . . . . . . . 1.5G
AAA . . . . . . . . MCT
To view Cost Index FMC data
You can look for Cost Index (CI) FMC data in the generic aircraft file. CI FMC data is
contained in Jeppesen New Cost Index Method (NCIM) files. To view this information, type
AC,<JEPPID>,CRZ on the Options command line.
Example:
01 OPTIONS AC,773L,CRZ
If an NCIM file is available in the generic aircraft record, JetPlan displays the NCIM file name
and location, followed by the first line of the NCIM file.
NCIM AVAILABLE:/OnSight/jetplan/data/release/fpmfiles_test/NCIM_777-
300ER_GE90-115BL
NCIM SOURCE:773bl2.dat Version Number 1.6 Dated 22 DECEMBER 2010
If an NCIM file is not available in the generic aircraft record, but NCIM hard-coded data is
available, JetPlan displays the following message: NCIM AVAILABLE.

354
To view cruise modes loaded for a generic aircraft

To view just the cruise modes loaded for a generic aircraft, type AC,<JEPPID>,INF on the
Options command line.
NOTE The JeppID and INF option can be entered in reverse order without changing
the outcome (for example, AC,INF,747H).
Example:
01 OPTIONS AC,747H,INF
EXAMPLE (AC,JEPPID,INF)
CRUISE MODES
1LE 270 GDC LRC M84 M85 M86 M88
ETOP/DRIFTDOWN CRUISE MODES FOR 303E
1LE
2LE
WEIGHT CUTOFF TABLES
13G 1.3G
14G 1.4G
15G 1.5G
AAA * MCT
* THIS TABLE IS ALWAYS CONSIDERED
To view the aircraft’s default constants

The aircraft’s default constants are the parameter settings you would start with if you saved
this aircraft to a CADB record without changing anything. To view the default constants in a
layout similar to the CADB, type AC,<JEPPID> on the Options command line.
Example:
01 OPTIONS AC,747H

355
EXAMPLE (AC,JEPPID)
CUSTOMER AIRCRAFT DATA FILE APRIL 30, 2007

FOR
FILE NAME A/C TYPE 747H
-- WEIGHTS
TO MAX T/OFF WT 0833000 LBS LA MAX LNDNG WT 0605000 LBS
ZF MAX ZF WT 0535000 LBS OP OP WT 0000000 LBS
MP MAX PAYLOAD 0150000 LBS RW MAX RAMP WT 0000000 LBS
NW NAV CHGS WT 0000000 LBS MW MIN FLIGHT WT 0000000 LBS
-- FUELS
ZT ZERO FUEL TBL N HC HOLD CALC ZF N
FC MAX FUEL CAP 361700 LBS HF HOLDING FF 000000 LBS
MF MIN FUEL 000000 LBS MH MIN HOLD FUEL 000000 LBS
MD MIN DEP FUEL 000000 LBS MA MIN ALT FUEL 000000 LBS
SF STEP CLMB FUEL 000000 LBS RF RESERVE FUEL 000000 LBS
AF APPROACH FUEL 000000 LBS MC MIN CONT/RES 000000 LBS
FW FOD WARNING 000000 LBS MT MIN C/R TIME 000000 MIN
TX TAXI FF 000000 LBS MX MAX CONT/RES 000000 LBS
FE MN EMRGNC FUEL 000000 LBS RH RES+HLD/CTG 000000 LBS
DT TAXI OUT 000000 LBS AT TAXI IN 000000 LBS
ST SITUATION CODE
BR APU BURN RATE 0000 LBS/HR
-- MISC
PI PERF INDX F EP PRI ETOPS N
FL MAX FLT LVL 450 BK PRI BRACKETS N
AD MIN ALT DIST 000 NM CW PRI ALT CAP TB N
SI SITA ADDRESS DD PRI DRIFTDOWN N
OI PROFILE OPT INTERVAL 000 NM HA HOLD ALT 00000 FT
FD FUEL DISTR TBL LC LIMITED CI N
NZ NOISE CATEGORY IX INDEX
WU WEIGHT UNIT
Applying a Generic Aircraft to a Flight Plan

To apply a generic aircraft to your flight plan request, type the Jeppesen ID for the aircraft on
the Aircraft Type command line.
Example:
10 A/C TYPE/REGN 747H
You can add ICAO or FAA domestic ATC information (a filing strip) to the bottom of the
flight plan output by typing a forward slash (/) after the aircraft entry. However, to ensure
proper identification, include the aircraft’s registration number when using this feature.
Example:
10 A/C TYPE/REGN 747H/N12345

356
Using the Customer Aircraft Database
Using a generic aircraft file as your Aircraft Type input dictates the need to provide other
information before a flight plan can be computed. For example, the generic file does not
include an operational weight setting. A weight range is stored in the file, but not a specific
setting. You must input an operational weight setting before JetPlan can process a flight plan.
You can avoid extra inputs and save time by saving your generic aircraft selection in the
CADB. There, you can set the required parameters and bypass extra inputs when creating
flight plans.

The Customer Aircraft Database (CADB) allows you to store generic aircraft files and
customize the parameter settings of each file for your repeated use on the JetPlan system. In
this way, you simplify the input process by providing a single record name on the Aircraft
Type command line that provides the information that JetPlan requires. The record name you
specify references both the original generic data and a host of optional, user-defined
information.
Because a CADB record is a child of the JetPlan Aircraft Library, it inherits all of the
parameter settings and default performance characteristics of its generic parent. However, you
can then modify this record with a set of characteristics that meet your requirements. This
customized aircraft record is yours to manage.
For more information about CADB capabilities and management, see Chapter 27, “Customer
To use a CADB record as your Aircraft Type input, prefix the record name input with the
dollar symbol ($).
Example:
10 A/C TYPE/REGN $RECORDNAME
NOTE A CADB record name is the identifier of the generic aircraft you saved and
modified in the Customer Aircraft database.
You can add ICAO or FAA domestic ATC information (filing strip) to the bottom of the flight
plan output by typing a forward slash (/) after the aircraft entry.
Example:
10 A/C TYPE/REGN $AC12/

357
If you do not have the aircraft’s registration number stored in the database file, include the
number after the forward slash. This ensures that the registration number is included in the
ATC filing strip.
Example:
10 A/C TYPE/REGN $AC12/N12345
NOTE The File Strip feature can be set in your ID/Attribute File for permanent
inclusion in all flight plan output. Contact your Jeppesen account manager for
information.

358
C HAPTER 11
Cruise Mode Commands

Overview
Overview
JetPlan requires input of an accurate cruise mode for the aircraft specified on the flight plan
request. The Cruise Mode command line enables you to enter up to seven primary airspeeds in
your request. You can apply changes to the aircraft’s cruising speed seven times in a given
flight, as long as the entered values are valid for the selected aircraft.
You can also use the Cruise Mode command line to enter any of the following:
• Auxiliary cruise mode

• Secondary climb and descent schedules
• Bias information
• Minimum Equipment List (MEL) data

361
Determining an Aircraft’s Cruise Modes

Before applying any airspeed inputs, you need to determine the available cruise mode
designations for the aircraft you are planning to use. This information is stored in the aircraft’s
generic record, which you can view if you know the four-character Jeppesen ID for the
aircraft. (If you do not know the Jeppesen ID, you can use the ICAO identifier for the aircraft
to help determine the Jeppesen ID.)
To determine the cruise modes for an aircraft, enter AC,JEPPID,CRZ or AC,JEPPID,INF on

the Options command line. The INF option provides a basic list of available cruise modes
only, while the CRZ option provides additional airspeed and weight information.
The input order of these command options does not affect the output information. The CRZ or
INF option can precede or follow the aircraft’s JEPPID, without changing the outcome.
However, the AC command always precedes these inputs.
Example:
01 OPTIONS AC,747H,CRZ
-------------------- 747H INFO -----------------------------

B743(ICAO) 747-300 engine: JT9D-7R4G2
MAX TOW MAX LAND WT MAX ZFW MAX FUEL CAP
833000 605000 535000 361700 lbs
377800 274400 242700 164100 kg
-------------------- FLIGHT SCHEDULES ----------------------
CLB AAA . . . . . . . . 330/.84
CRZ 1LE . . . . . . . . ENGOUT LRC
270 . . . . . . . . 270KIAS FL050 - FL390
GDC . . . . . . . . GEAR DOWN CRUISE
LRC . . . . . . . . LONG RANGE CRUISE
M84 . . . . . . . . ALT 110 450 M84 >210
M85 . . . . . . . . ALT 110 450 M85 >210
M86 . . . . . . . . ALT 240 450 M86 >240
M88 . . . . . . . . ALT 280 450 M88 >280
CUTOFF 13G . . . . . . . . 1.3G
14G . . . . . . . . 1.4G
15G . . . . . . . . 1.5G
AAA . . . . . . . . MCT
-------------------- AUXILIARY SCHEDULES -------------------
CLB AAA aux. 302E (2LE) 290/.76
AAA aux. 303E (1LE) TABLE IS FROM FILE 6
CRZ 1LE aux. 303E (1LE) TABLE IS FROM FILE 6
2LE aux. 302E (2LE)
LRC aux. 302E (2LE)
LRC aux. 303E (1LE) TABLE IS FROM FILE 6

362
Example:
01 OPTIONS AC,747H,INF
CRUISE MODES
1LE 270 GDC LRC M84 M85 M86 M88
1LE
2LE
WEIGHT CUTOFF TABLES
13G 1.3G
14G 1.4G
15G 1.5G
AAA * MCT
* THIS TABLE IS ALWAYS CONSIDERED
For more information on accessing generic aircraft data, see Chapter 10, “Aircraft Type
Commands.”
Standard Cruise Mode Designations

The JetPlan system uses a three-character airspeed designation standard for most cruise mode
inputs. Only cost index cruise mode inputs deviate from this standard (see “Cost Index Cruise
Mode” on page 368.) Otherwise, you can enter one of the designations stored in the aircraft’s
generic record, or apply a non-stored, intermediate cruise mode value.
Stored Cruise Modes

Generally, most aircraft records in the JetPlan Aircraft Library include performance data that
include up to five cruise modes. These stored cruise modes are typically the sources for your
primary, auxiliary, and multiple cruise mode inputs.
The following table lists the most commonly referenced cruise modes by their designators.
Table 11-1 Cruise Mode Designators
Cruise Mode Designator Definition

M<##>, where <##> is the Mach Airspeed Cruise at Mach number <##> (for example,
number M84)
CMC Constant Mach Cruise
ECO Economy Cruise
HSC High Speed Cruise

363
Table 11-1 Cruise Mode Designators (continued)
Cruise Mode Designator Definition

LRC Long-Range Cruise
MSR Maximum Specific Range
MRC Maximum Range Cruise
MCT Maximum Cruise Thrust
MSC Maximum Speed Cruise
NCT Normal Cruise Thrust
925 925 TIT Cruise
945 945 TIT Cruise
1LE 1 Less Engine
2LE 2 Less Engines
ECP Economy Cruise Power
MCP Maximum Cruise Power
RCP Recommended Cruise Power
Non-Stored Cruise Modes

In addition to stored cruise modes, the JetPlan system accepts certain constant Mach number
values as your cruise mode input, even if these values are not loaded in the aircraft’s generic
record. However, the following requirements apply to the use of this input type:
• The aircraft’s generic record must have performance data loaded for at least
three constant Mach cruise schedules (for example, M78, M80, and M82).

364
Primary Cruise Mode
• Your input must be a constant Mach number value that falls between the
constant Mach values loaded in the generic record. For example, if your
aircraft’s generic record has performance data loaded for the cruise modes
M78, M80, and M82, you can apply the non-stored value M79 or M81 as a
non-stored cruise mode entry in the flight plan request.
JetPlan uses the stored information to interpolate the non-stored inputs.
However, the interpolation does not work for any input that is outside the
range of the loaded Mach numbers or if fewer than three Mach numbers are
stored in the aircraft’s generic record.
NOTE If you run a plan using a non-stored cruise mode and then change the aircraft
for some reason, the cruise mode input might become invalid.
Primary Cruise Mode

You can specify the primary cruise mode, the main airspeed for the enroute portion of the
flight: top of climb (TOC) to top of descent (TOD). JetPlan uses the primary cruise mode to
calculate the flight plan fuel figures for this phase of the flight. If necessary, you can specify
additional primary cruise modes. You can enter a maximum of seven primary cruise modes on
the Cruise Mode command line. For more information, see “Multiple Primary Cruise Modes”
on page 366.
To specify a single primary cruise mode, enter the three-character, alphanumeric designation
on the Cruise Mode command line.
Example:
Explanation: The following input requests the constant Mach airspeed of Mach 0.80 for the
entire flight.
11 CRZ MODE M80
Example:
Explanation: The following input requests LRC for the entire flight.
11 CRZ MODE LRC

365
Primary Cruise Mode
Multiple Primary Cruise Modes

The ability to change the aircraft’s airspeed to meet ATC or other flight requirements provides
flexibility in the planning process. JetPlan allows up to seven primary cruise mode inputs in a
flight plan request. This feature is called multiple primary cruise modes.
To indicate a cruise mode change, you must specify not only the new cruise mode but also the
enroute position where the change in airspeed is to occur. Therefore, you must include enroute
waypoints in the additional cruise mode inputs to define the ending of one airspeed and the
beginning of another.
To apply multiple primary cruise modes, enter the initial primary cruise mode followed by a
slash (/), and then a waypoint and cruise mode combination that defines where and what the
change is. The slash (/) is the trigger character that invokes the multiple primary cruise mode
feature. You can add up to six waypoint and cruise mode combinations after the slash,
defining the remaining primary cruise inputs.
Example:
Explanation: The following input requests an initial primary cruise of Mach 85 to Coaldale
(OAL), and then Mach 84 the rest of the way.
11 CRZ MODE M85/OAL,M84
Example:
Explanation: The following input requests an initial primary cruise of Mach 85 to Coaldale
(OAL), and then Mach 84 to Blue Mesa (HBU), Mach 82 to Lamar (LAA), and LRC the rest
of the way.
11 CRZ MODE M85/OAL,M84,HBU,M82,LAA,LRC
Follow these rules when using multiple primary cruise modes:
• A primary cruise mode change can be made anywhere along the route of
flight, as long as it is between the TOC and the TOD.
• Always enter the initial primary cruise mode input before the slash and the
subsequent primary cruise mode inputs after the slash.
• Separate each input after the slash with a comma, including each waypoint
and cruise mode combination and each primary input.
• Enter charted waypoints using the charted identifiers for the points.

366
Primary Cruise Mode
• Enter uncharted waypoints—such as the latitude/longitude points generated

by JetPlan while over water or fix/radial/distance waypoints—using either
the JetPlan method for naming these types of identifiers or the ARINC 424
standard.
The JetPlan method for naming the internal identifier of a latitude/longitude
point is to combine the first two digits of the latitude with the second and
third digits of the longitude. For example, the coordinate point N4800,
W17500 is identified as 4875.
Because the ARINC 424 standard for this type of point is often output in the
flight plan body, it can be helpful to run a flight plan with a single primary
cruise mode and then review the route output for the identifier names.
Examples of the ARINC 424 standard are 44E70 (for N4400, E17000) and
44N40 (for N4400, W14000).
Fix/radial/distance waypoints are entered as ECA125035 (for ECA 125
radial at 35nm).
The following example illustrates the use of four primary cruise modes based on a flight from
Tokyo (RJAA) to Los Angeles (KLAX). The aircraft is an MD11, which has four cruise
modes loaded: M85, M83, M82, and LRC. The three waypoints used as constraints for
changing the primary cruise are 4870 (N4800, E17000), 4240 (N4200, W14000), and OSI.
Example:
Explanation: The following input requests an initial primary cruise of Mach 85 to coordinate
point 4870, Mach 83 to coordinate point 4240, Mach 82 to Woodside (OSI), and LRC for the
remainder of the flight.
11 CRZ MODE M85/4870,M83,4240,M82,OSI,LRC
The output for multiple primary cruise information is similar, in most formats, to the following
sample output from the previous example.
MULTI CRZ M85/4870 M83/4240 M82/OSI LRC
You can also specify a waypoint using a fix/radial/distance.

367
Primary Cruise Mode
Example:
Explanation: The following input requests an initial primary cruise of Mach 85 to the point
described as the 246 radial from GTF at 44 nm, and then Mach 83 for the remainder of the
flight.
11 CRZ MODE M85/GTF246044,M83
Cost Index Cruise Mode

In addition to standard cruise mode values, JetPlan accepts cost index cruise mode values as
the primary cruise inputs on the Cruise Mode command line.
NOTE For more information on cost index, see Chapter 12, “Cost Index
Commands.”
To specify a cost index cruise mode, enter CI followed by the cost index number on the Cruise
Mode command line.
Example:
Explanation: The following input requests a cost index of 108 as the primary cruise mode for
the entire flight.
11 CRZ MODE CI108
The following requirements apply to the use of cost index values as primary cruise mode
inputs:
• The aircraft used in the flight plan must have a minimum of three cruise
modes loaded in its generic record, two of which must be constant Mach
numbers (for example, M80, M82).
If only three cruise modes are loaded, the only non-Mach number cruise
mode that is acceptable is LRC. For example, a generic aircraft record that
has LRC, M84, and M85 loaded qualifies for cost index planning. An
aircraft that has LRC, CMC, and M84 does not qualify.
• The cost index calculation increases in accuracy with every extra constant
Mach number loaded in the aircraft’s generic record.
• The minimum cost index value is zero (0); the maximum is 9999.

368
Primary Cruise Mode
• As in the case of LRC, when a cost index cruise mode is used, JetPlan does
not force a constant Mach airspeed over certain route segments to conform
with ATC requirements.
NOTE It is the responsibility of the flight planner to apply a constant Mach cruise
mode to these types of route segments.
• To apply actual cost figures, enter fuel and operating cost values on the
Performance Index command line (using the M option), or store these
figures in the Customer Airport and Airport Fleet Databases.
Multiple Primary Cost Index Cruise Modes

You can apply cost index values as multiple primary cruise mode inputs using the same rules
described in “Multiple Primary Cruise Modes” on page 366.
Example:
Explanation: The following input requests a cost index of 200 as the initial primary cruise to
the GTF waypoint. After GTF, CI150 is applied until YTH. CI100 is the primary cruise for the
rest of the flight.
11 CRZ MODE CI200/GTF,CI150,YTH,CI100

369
Auxiliary Cruise Mode Option

In addition to primary cruise mode inputs, the Cruise Mode command line also accepts an
auxiliary cruise mode input. This option is for comparison purposes. It provides cruise data
(fuel, time, distance information) based on one of the following two hypothetical choices:
• A cruise mode that is the same as the primary cruise mode but uses only the
initial level-off altitude to determine fuel burn.
- or -
• A cruise mode that differs from the primary cruise mode but uses the same
flight levels as computed for the primary cruise mode.
NOTE In either case, the auxiliary cruise mode option is format-dependent,

meaning it requires an output format that can handle the inclusion of this type of
scenario information.
As stated above, the computation of auxiliary cruise data is determined by a comparison to the
primary cruise mode input, as follows:
• If the auxiliary cruise mode input is the same as the primary cruise mode
input, the auxiliary cruise data (fuel, time, and distance) is calculated using
the initial cruise altitude for the entire flight. This generates a comparison
that might be indicative of a step climb restriction by ATC.
• If the auxiliary cruise mode input differs from the primary cruise mode
input, the auxiliary cruise data is calculated using the profile determined by
the primary cruise flight plan computation (the set of altitudes flown using
the primary cruise airspeed). The data generated by this setup provides a
simple comparison of one cruise mode to another.
NOTE JetPlan does not output auxiliary cruise data if it cannot calculate aircraft
performance at the flight levels the primary cruise mode uses.
NOTE A cost index cruise mode cannot be used as an auxiliary cruise mode.
To apply an auxiliary cruise mode, enter the auxiliary value immediately after the primary
cruise mode value, and separate the two with a comma.

370
Example:
Explanation: The following input specifies a primary cruise mode of Mach 85 and an auxiliary
cruise mode of Mach 85 (shown in bold). Auxiliary cruise data is calculated using the initial
(level-off) flight level.
11 CRZ MODE M85,M85
Example:
Explanation: The following input specifies a primary cruise mode of Mach 85 and an auxiliary
cruise mode of Mach 83 (shown in bold). Auxiliary cruise data is calculated using the
complete flight level profile.
11 CRZ MODE M85,M83
Auxiliary Cruise with Multiple Primary Cruise Modes

You can specify an auxiliary cruise mode value in a Cruise Mode command line input that also
applies multiple primary cruise values. The initial primary input is followed by the auxiliary
input, which is followed by a slash and the additional primary values (waypoint and cruise
mode combinations).
The following example adds an auxiliary cruise mode to the inputs for the example flight from
Tokyo (RJAA) to Los Angeles (KLAX) discussed in “Multiple Primary Cruise Modes.” The
auxiliary cruise mode is included in the second input position.
Example:
Explanation: The following inputs specify an initial primary cruise of Mach 85 to coordinate
point 4870, Mach 83 to coordinate point 4240, Mach 82 to Woodside (OSI), and LRC the rest
of the flight. In addition, auxiliary cruise data is requested by the inclusion of Mach 85 (shown
in bold) after the initial primary cruise.
11 CRZ MODE M85,M85/4870,M83,4240,M82,OSI,LRC

371
Climb and Descent Schedule Options

An aircraft in the JetPlan Aircraft Library might have multiple climb and descent schedules
(airspeeds) loaded in its generic data record, depending on the information available at the
time of the file’s inception or some other factor, such as customer preference. If an aircraft has
more than one climb or descent schedule loaded, one schedule is defined as the primary
(default) airspeed for that phase of flight, while all other schedules are considered secondary.
You can switch to a secondary schedule in your flight plan request by using the Climb
Schedule and/or Descent Schedule options on the Cruise Mode command line.
NOTE To determine if your aircraft has more than one climb and/or descent
schedule, use the AC,JEPPID,CRZ command illustrated in “Determining an Aircraft’s
Cruise Modes” on page 362.
First Principles Aircraft Model Secondary Climb and

Descent Options
If the generic file for the aircraft you are using includes First Principles Aircraft Model (FPM)
climb and descent data, you can specify FPM secondary climb and descent schedules on the
Cruise Mode command line. FPM data files provide coefficients for computing
aeroperformance using First Principles equations. You can check the generic aircraft record
for the presence of FPM cruise, climb, and descent data. For information, see “Searching
Generic Aircraft Records for FPM and OUTFLT Information” on page 718 in Chapter 27,
“Customer Aircraft Database.”
Specifying FPM secondary climb and descent schedules on the Cruise Mode command line
also requires certain parameter settings in the Customer Aircraft Database (CADB). For more
information, see “FPM Secondary Climb Option” on page 373 and “FPM Secondary Descent
Option” on page 375.
NOTE FPM secondary climb and descent entries on the Cruise Mode command line
override any settings for FPM secondary climb and descent in the Customer Airport
Fleet Database or in the generic data files. For more information, see “Airport Fleet
Database” on page 855.

372
Secondary Climb Option

To specify a secondary climb schedule on the Cruise Mode command line, enter a dash (-)
followed by the designation for the secondary schedule. This input is the first entry on the
Cruise Mode command line, preceding the input for the required primary cruise mode.
Example:
11 CRZ MODE -climb,primary,auxiliary/additional primary
For example, assume a generic aircraft has the climb schedules 320/M84 and 340/M84 loaded.
The designations for these schedules are 320 and 340 respectively. The following example
illustrates the inputs if the default climb schedule is 320, but you want to use 340 for this flight
plan.
Example:
11 CRZ MODE -340,primary cruise,remainder of input
The next example applies the same climb schedule change but includes a multiple primary
cruise input and an auxiliary cruise input.
Example:
Explanation: Change the climb schedule to 340 (340/M84), then initial primary cruise Mach
85 to coordinate point 4870, Mach 83 to coordinate point 4240, Mach 82 to Woodside (OSI),
and LRC the rest of the flight. In addition, the inclusion of Mach 85 after the initial primary
cruise requests an auxiliary cruise mode.
11 CRZ MODE -340,M85,M85/4870,M83,4240,M82,OSI,LRC
FPM Secondary Climb Option

Specifying an FPM climb schedule in a flight plan request has the following prerequisites:
• The generic aircraft record must include an FPM file with climb data. If you
are specifying FPM climb with cost index, the generic aircraft record must
contain both FPM climb data and FPM FMC (Flight Management
Computer) data. See “Searching Generic Aircraft Records for FPM and
OUTFLT Information” on page 718 in Chapter 27, “Customer Aircraft
Database.”
• The Climb Method (CM) parameter in the CADB must be set to the
appropriate FPM method. (For more information, see the “Miscellaneous
Parameters” section in Chapter 27, “Customer Aircraft Database.”)

373
To specify an FPM secondary climb speed schedule on the Cruise Mode command line,
separate the climb speed entries with the underscore ( _ ) character.
Example:
The following example of an FPM secondary climb input assumes that the Climb Method
parameter in the CADB is set to Mach Calibrated Airspeed (CAS) Schedule (CM=G). The
underscore character ( _ ) in the input separates climb speeds.
11 CRZ MODE -250_10000_300_0.78, LRC
Explanation: Climb from takeoff to 10,000 feet at 250 knots CAS. At 10,000 feet, accelerate to
300 knots CAS until reaching 0.78M. Continue climbing at a constant 0.78M until initial
cruise flight level.
The next example illustrates specifying an FPM secondary climb with CI.
Example:
The following example of an FPM secondary climb input with CI assumes that the Climb
Method parameter in the CADB is set to (F) Cost Index: FMS Matching (FPM). JetPlan uses
the FPM cost index method to calculate the optimal climb CAS for an aircraft with an FMC.
11 CRZ MODE -CI20, CI40
Explanation: Climb with CI=20 (and then cruise at CI=40). JetPlan calculates the initial climb
speed based on the takeoff weight to achieve a cost index of 20, not to exceed 250 knots CAS
below 10,000 ft. JetPlan picks the final climb Mach number to match the cruise speed
corresponding to cruise CI=40 at optimal cruise altitude.
Secondary Descent Option

To specify a secondary descent schedule, enter the prefix DE=, followed by the designation
for the secondary schedule on the Cruise Mode command line. You can enter this input
anywhere on the Cruise Mode command line, although it makes sense for it to follow the
primary cruise input.
Example:
11 CRZ MODE primary,auxiliary/additional primary,DE=descent

374
For example, assume a generic aircraft has the descent schedules 340/M84 and 360/M84
loaded. The designations for these schedules are 340 and 360, respectively. The following
example illustrates the inputs if the default descent schedule is 340, but you want 360 for this
flight plan.
Example:
11 CRZ MODE primary cruise,DE=360
The next example applies the same descent schedule change but includes a multiple primary
cruise input and an auxiliary cruise input.
Example:
Explanation: The following inputs indicate an initial primary cruise of Mach 85 to coordinate
point 4870, Mach 83 to coordinate point 4240, Mach 82 to Woodside (OSI), and LRC the rest
of the flight. The inclusion of Mach 85 after the initial primary cruise requests an auxiliary
cruise mode. The descent schedule is changed to 360 (360/M84).
11 CRZ MODE M85,M85/4870,M83,4240,M82,OSI,LRC,DE=360
FPM Secondary Descent Option
Specifying an FPM descent schedule in a flight plan request requires the following:
• The generic aircraft record must include an FPM file with descent data.
Also, if you are specifying FPM climb with CI, the generic aircraft record
must contain both the FPM descent data and FPM FMC data.
• The Descent Method (DM) parameter in the CADB must be set to the
appropriate FPM method. (For more information, see the “Miscellaneous
Parameters” section in Chapter 27, “Customer Aircraft Database.”)
To specify an FPM secondary descent speed schedule on the Cruise Mode command line,
separate the descent speed entries with the underscore ( _ ) character.
Example:
The following example of FPM secondary descent inputs assumes that the Descent Method
(DM) parameter in the CADB is set to Mach Calibrated Airspeed (CAS) Schedule (CM=G).
11 CRZ MODE -CI20,DE=0.80_320_10000_240

375
Bias Options
Explanation: Descend from cruise speed at 0.80M until 320 knots CAS. Continue the descent
at a constant 320 knots CAS to 10,000 ft. Decelerate to 250 knots CAS until established on
approach or ATC advises.
The next example illustrates specifying an FPM secondary descent schedule with CI.
Example:
The following example of an FPM secondary climb input with CI assumes that the Descent
Method (DM) parameter in the CADB is set to (F) Cost Index: FMS Matching (FPM). JetPlan
uses the FPM cost index method to calculate the optimal descent CAS for an aircraft with an
FMC.
11 CRZ MODE -CI20, CI40, DE=CI15
Explanation: Climb at CI20, and then cruise at CI=40 and descend at CI=15. JetPlan picks the
initial descent Mach to match the final cruise Mach for a CI=40 at cruise altitude. JetPlan
calculates the descent CAS based on landing weight at CI=15.
Bias Options
The Cruise Mode command line accepts a variety of bias inputs aimed at various phases of
flight (for example, climb, cruise, and so on) for the purpose of adjusting the fuel, time, or
distance calculations, if needed. These bias options are ad hoc and intended to meet the
specific needs of an individual flight plan.
Ad hoc biases are available for the following flight performance phases:
• Climb
• Cruise
• Descent
• Alternate
Bias Input Syntax

An ad hoc bias is specified as either a percentage change (in decimal form) or a whole number
value that defines an increased or decreased amount. Whatever the value is, the input must be
preceded by a unique parameter code and an equal sign (=). The parameter code generally

376
Bias Options
defines the phase of flight for which the input is applicable (for example, c=climb, d=descent,
and so on) and the factor being biased (for example, f=fuel, t=time, or d=distance). The equal
sign separates the parameter code from the bias value.
Example:
Parameter Code=Bias Value (percentage or integer)
The following table lists all of the bias parameter codes and defines the phase of flight and bias
factor.
Table 11-2 Ad Hoc Bias Parameters
Parameter Code Definition (Phase/Factor)

CF Climb Fuel
CT Climb Time
CD Climb Distance
DF Descent Fuel
DT Descent Time
DD Descent Distance
AF Alternate Fuel
AT Alternate Time
AD Alternate Distance
FF Cruise Fuel Flow
AS Cruise True Airspeed
The following rules apply to all bias value inputs:
• A percentage bias must be entered in a decimal form. It is based on the

assumption that the standard is 100% functionality. Therefore, a percentage
change in functionality is a decimal expression centered on the number one.
Example:
CF=1.03 (1+.03 = 3% increase)
CF=.97 (1-.03 = 3% decrease)

377
Bias Options
• An integer bias is entered in some whole number value. It is the amount of

fuel, time or distance that is increased or decreased to define the expected
gain or loss. For negative values, the number must be preceded by the minus
sign (-).
Example:
CF=500 (500 pound increase in climb fuel)
AS=-10 (10 knot decrease in cruise true airspeed)
• For cruise mode biases, FF and AS, the three-letter input DEF can be used
as a substitute for all of the cruise modes available in the aircraft’s generic
file. When used, this code applies the bias to all cruise modes specified as
primary in the flight plan request. For example, if you were to enter M84,
M85 and LRC in your flight plan as the primary cruise modes (multiple
primary cruise modes), and you needed to apply the same fuel flow bias to
each of these airspeeds, you could enter one bias for each cruise mode (for
example, FFM84=.99, FFM85=.99, and FFLRC=.99), or use the DEF
(default) input to apply the bias to all three (for example, FFDEF=.99). Both
methods provide the same results, but the DEF substitute minimizes your
typing.
NOTE In regard to cost index inputs, DEF must be used to define the cruise mode
bias. This is due to the fact that cost index calculations are based on all of the
available cruise modes in the aircraft’s generic file, and the only way to reference all
of those cruise modes at one time is to use the DEF input.
• Although bias inputs can be entered anywhere after the initial primary cruise
mode input, Jeppesen recommends that these inputs be entered at the end of
the cruise mode string, after all other inputs.
Climb Biases
A climb bias is specified using one or more of the following parameters.
CF – Climb Fuel Parameter

After CF, enter an equal sign and the bias value. If you are using the integer method, note that
the value is expressed as a weight (lb or kg).
Example:
Explanation: Add 500 lbs/kgs to climb fuel.

378
Bias Options
11 CRZ MODE M86,M85,CF=500
Explanation: Increase climb fuel by 3%.
11 CRZ MODE M86,M85,CF=1.03
CT – Climb Time Parameter

After CT, enter an equal sign and the bias value. If you are using the integer method, note that
the value is expressed in minutes.
Example:
Explanation: Add 5 minutes to climb time.
11 CRZ MODE M86,M85,CT=5
Explanation: Increase climb time by 0.7%.
11 CRZ MODE M86,M85,CT=1.007
CD – Climb Distance Parameter

After CD, enter an equal sign and the bias value. If you are using the integer method, note that
the value is expressed in nautical miles.
Example:
Explanation: Flatten the climb profile by 20 nm.
11 CRZ MODE M86,M85,CD=20
Explanation: Flatten the climb profile by 5%.

379
Bias Options
11 CRZ MODE M86,M85,CD=1.05
NOTE The Climb Distance bias flattens out the climb profile by the bias amount. It
moves the Top of Climb point, but does not add mileage to the flight plan. On the
other hand, the following types of biases add mileage to the flight plan by the bias
amount, but do not affect the climb profile:
- A distance bias specified in the flight plan request on the Departure Bias command
line
- A distance bias stored in a Customer Route Database file (the DD parameter)
- A distance bias stored in a Customer Aircraft Database (CADB) file (the DB

parameter)
Cruise Biases
The cruise biases are expressed using the parameter codes, FF and AS. These codes do not
follow the convention described above, but are descriptive of what they affect: fuel flow and
airspeed. When using these codes, you must include a cruise mode designation after the
parameter code and before the equal sign.
Only the primary cruise mode(s) can be biased. To reduce typing time, the cruise mode
substitute, DEF, can be used in place of specific cruise modes.
NOTE The DEF input must be used to bias a cost index cruise mode.
FF – Fuel Flow Parameter

After FF, enter a cruise mode designation or DEF, an equal sign, and the bias value. This bias
must be a percentage input.
Example:
Explanation: Increase M86 fuel flow by 0.5%.
11 CRZ MODE M86,M85,FFM86=1.005
Explanation: Decrease M86 fuel flow by 1.0%.

380
Bias Options
11 CRZ MODE M86,M85,FFM86=0.99
Explanation: Increase cost index fuel flow by 1.5%.
11 CRZ MODE CI80,FFDEF=1.015
AS – True Airspeed Parameter

After AS, enter a cruise mode designation or DEF, an equal sign, and the bias value. If you are
using the integer method, note that the value is expressed in knots.
Example:
Explanation: Decrease M86 true airspeed by 10 knots.
11 CRZ MODE M86,M85,ASM86=-10
Example of combined inputs of FF and AS:
Example:
Explanation: Increase the fuel flow of the cost index by 1.5%, and decrease the true airspeed
by 8 knots for all primary cruise modes.
11 CRZ MODE CI102,M82,FFDEF=1.015,ASDEF=-8
Descent Biases
A descent bias is specified by the use of one or more of the following parameters.
DF – Descent Fuel Parameter

After DF, enter an equal sign and the bias value. If you are using the integer method, note that
Example:
Explanation: Add 500 lbs/kgs to descent fuel.
11 CRZ MODE M86,M85,DF=500
Explanation: Increase descent fuel by 3%.

381
Bias Options
11 CRZ MODE M86,M85,DF=1.03
DT – Descent Time Parameter

After DT, enter an equal sign and the bias value. If you are using the integer method, note that
Example:
Explanation: Add 5 minutes to descent time.
11 CRZ MODE M86,M85,DT=5
Explanation: Increase descent time by 0.7%.
11 CRZ MODE M86,M85,DT=1.007
DD – Descent Distance Parameter

After DD, enter an equal sign and the bias value. If you are using the integer method, note that
Example:
Explanation: Flatten the descent profile by 20 nm.
11 CRZ MODE M86,M85,DD=20
Explanation: Flatten the descent profile by 5%.
11 CRZ MODE M86,M85,DD=1.05
NOTE This bias value flattens out the descent profile by the bias amount. It moves
the Top of Descent point, but does not add mileage to the flight plan. On the other
hand, the following types of biases add mileage to the flight plan by the bias amount,
but do not affect the descent profile.
- A distance bias specified in the flight plan request on the Arrival Bias command line
- A distance bias stored in a Customer Route Database file (the AD parameter)
- A distance bias stored in a CADB file (the AB parameter)

382
Bias Options
Alternate Biases
An alternate bias is specified by the use of one or more of the following parameters.
AF – Alternate Fuel Parameter

After AF, enter an equal sign and the bias value. If you are using the integer method, note that
Example:
Explanation: Add 500 lbs/kgs to alternate fuel.
11 CRZ MODE M86,M85,AF=500
Explanation: Increase alternate fuel by 3%.
11 CRZ MODE M86,M85,AF=1.03
AT – Alternate Time Parameter

After AT, enter an equal sign and the bias value. If you are using the integer method, note that
Example:
Explanation: Add 5 minutes to alternate time.
11 CRZ MODE M86,M85,AT=5
Explanation: Increase alternate time by 0.7%.
11 CRZ MODE M86,M85,AT=1.007
AD – Alternate Distance Parameter
After AD, enter an equal sign and the bias value. If you are using the integer method, note that
Example:
Explanation: Add 20 nm to alternate distance.

383
Bias Options
11 CRZ MODE M86,M85,AD=20
Explanation: Increase alternate distance by 5%.
11 CRZ MODE M86,M85,AD=1.05
Combined Inputs
The following examples illustrate some bias input combinations.
Example:
Explanation: Bias the climb fuel by 1.5%, cruise fuel flow by 1.5%, and descent fuel by 1.5%.
11 CRZ MODE CI102,M85,CF=1.015,FFDEF=1.015,DF=1.015
Example:
Explanation: Bias the cruise fuel flow by a negative 2%, and increase cruise true airspeed by 5
knots.
11 CRZ MODE M83,M82,FFM83=0.98,ASM83=5

384
Applying MEL Data
Applying MEL Data

You can apply MEL information to the flight plan computation by entering the name of a
Customer MEL database record on the Cruise Mode line. JetPlan applies whatever biases or
degradations are stored in the MEL database record.
NOTE An MEL database record can contain a variety of settings aimed at limiting or
degrading certain performance characteristics of a specific aircraft type. To learn
more about creating and managing MEL database records, see Chapter 38,
“Minimum Equipment List Database.”
MEL Input Syntax

You can include more than one MEL database record name in a flight plan, but each record
entry must be preceded by the MEL= prefix. All MEL record entries follow any primary
and/or auxiliary cruise mode inputs. The syntax you use to enter the MEL database record
name depends on the definition of the Degradation Type parameter in the database record. The
following table lists the degradation types and the corresponding syntax.
Table 11-3 MEL Record Name Input
Degradation Type in MEL DB Record Input on Cruise Mode Line

Minimum Equipment List (MEL) <CRUISE MODE>MEL=M,<RECORD NAME>
- or -
MEL=<RECORD NAME>
NOTE For “MEL” degradation types, you can omit
“M,” before the record name.
Configuration Deviation List (CDL) <CRUISE MODE>MEL=C,<RECORD NAME>
Deferred Maintenance Item (DMI) <CRUISE MODE>MEL=D,<RECORD NAME>
The following examples invoke MEL database records with the “MEL” degradation type.
Because “MEL” is the default degradation type, you can opt to put the database record name
immediately after the equal sign (MEL=RECORD NAME), or you can use the full syntax for
the entry (MEL=M,RECORD NAME). The MEL record entry must follow any primary
and/or auxiliary cruise mode inputs.

385
Applying MEL Data
Example:
11 CRZ MODE M84,MEL=ABCD
- or -
11 CRZ MODE M84,MEL=M,ABCD
Example:
11 CRZ MODE M85,M85/4870,M83,4240,M82,OSI,LRC,MEL=ABCD
Example:
Explanation: The following example invokes the application of two MEL database records.
The degradation type in the first record is “MEL,” and the degradation type in the second
record is “CDL.”
11 CRZ MODE M80, MEL=ABCD, MEL=C,EFGH
Example:
Explanation: The following example illustrates a combination input on the Cruise Mode
command line, including an MEL database record entry.
11 CRZ MODE M85,M85/4870,M83,4240,M82,OSI,LRC,MEL=ABCD,FFDEF=1.02
Note the following when applying biases from various sources, including MEL records, to the
flight plan request:
• When an MEL database record that contains a specific bias is included in a

flight plan, and a corresponding bias exists in the aircraft’s CADB record,
the two biases are combined in effect. For example, assume that your
aircraft input is a CADB record that has a fuel flow bias set at 2.5% for the
cruise mode M84, and you enter an MEL record on the Cruise Mode
command line that includes a fuel flow bias of 1.3%. The total fuel flow bias
applied to the flight plan is plus 3.8%
(2.5% + 1.3% = 3.8%).
When an MEL fuel flow bias and an ad hoc fuel flow bias (see “Bias Options” on page 376)
are both added to the same flight plan, JetPlan combines the two biases. However, an ad hoc
bias overrides any corresponding bias stored in the aircraft’s CADB record.

386
C HAPTER 12
Cost Index Commands

Cost Index Commands
Overview
Overview
Cost indexing is the practice of evaluating the effect of one cost factor to another in the hopes
of minimizing the sum of those factors.
Many commercial jet aircraft are equipped with performance computers for the purpose of
determining the best speed at which to travel (the “economy speed”) in order to minimize the
total operating cost of the flight. To do this, the flight management computer (FMC) needs
information about time-related costs and fuel cost.
Time-related costs are typically those factors that increase in cost as the flight progresses, such
as the service of the flight and cabin crews and certain maintenance outlays. Fuel costs are
based on the price and amount of fuel needed to complete the flight plus contingencies and/or
reserves. Rather than enter these individual factors into the onboard FMC, most airlines use a
ratio of the time-related cost to fuel cost to determine the economy speed for a given flight on
a given day. This ratio is called the Cost Index (CI), and it determines the economy speed for a
flight by minimizing the total cost of aircraft operation.
In JetPlan, this practice is applied to the optimization process through the Cost Index (CI)
cruise mode option.
NOTE This chapter covers the CI Cruise Mode option. For information on
Performance Index, see Chapter 9, “Profile Commands.”
Cost Index Cruise Mode

The CI cruise mode is a ratio value determined by the relationship of time-related costs
(dollars per flight hour) to fuel costs (cents per pound). It is expressed by the following
formula:
NOTE This ratio is valid for any currency, provided that the fuel cost is converted to
a “per pound” basis.

389
Cost Index Commands
Overview
You can specify this ratio value as a primary cruise input on the Cruise Mode command line
(static method), or set the necessary parameters in your customer databases and let JetPlan
determine the proper CI value during the flight plan computation (dynamic method). In either
case, JetPlan regulates both the flight plan profile and true airspeed to meet the objective set by
the cost index, thus minimizing the flight’s total cost.
The CI cruise mode is very useful because it is a measure of the relative effects of time and
fuel on the total operating cost of the aircraft. If the CI is small, time-related costs are
relatively small, and the resulting economy speed is close to the minimum fuel speed. If the CI
is large, time becomes important and the resulting economy speed is high.
Accurately determining the CI value for a given flight on a given day produces benefits from a
speed profile that minimizes the total cost for that flight.
Cost Index Methodology

JetPlan is designed to perform both airspeed and vertical optimization based on the input of a
CI cruise mode. The index value sets the relative cost of time and fuel, and this defines the
speed schedule and profile that JetPlan selects to minimize total cost.
Speeds are defined to the thousandths of Mach on a segment-by-segment basis, and profile is
optimized using standard JetPlan procedures. For each segment of the flight, JetPlan’s
optimization algorithm uses the altitude and cruise speed that minimizes the total cost for the
entire flight. Specifically, a range of altitudes, up and down, is exposed to the economy speed
analysis dictated by the CI value. The altitude that is ultimately selected is the one for which
the segment cost, as a function of mach number, is the lowest.
In essence, JetPlan performs the same economy speed analysis that an onboard flight
management computer (FMC) does. However, JetPlan applies forecasted (or user-defined)
winds and temperature data to the down-range portion of the flight, providing better down-
range fuel and weight information on which to base the current and future profile optimization.
The onboard FMC is limited to the wind and temperature measurements it reads as the flight
progresses, no information down range. Since the flight’s immediate economy speed analysis
is based, in part, on what the aircraft situation is further along in the flight, JetPlan’s Cost
Index feature provides superior economy speed optimization, relative to an onboard FMC.

390
Cost Index Commands
Overview
General Requirements and Characteristics

A minimum set of requirements must be met before JetPlan calculates a cost index flight plan.
They are:
• The aircraft’s generic file must have a minimum of three cruise modes
loaded in the performance data, two of which must be constant mach
designations. The only non-mach cruise mode that is acceptable is LRC.
Hence, a generic aircraft load with LRC, M84, and M85 qualifies for cost
index flight planning. However, a generic load with LRC, CMC, and M85
does not qualify.
• The minimum cost index is 0, and the upper limit is 9999.
Other characteristics include:
• Cost index accuracy improves with the more constant mach designations
loaded in the aircraft’s generic file. The three constant mach minimum
provides a cruise spectrum by which numbers are interpolated. Obviously,
the more constant mach cruise modes loaded, the more accurate the
interpolation is.
• As in the case of LRC, when a cost index cruise mode is used, JetPlan does
not force a constant mach airspeed over certain route segments in order to
conform with ATC requirements. It is the responsibility of the user to
provide a constant mach cruise mode for these segments.
• The range of cost index values over which the highest variability occurs
depends on many factors, such as aircraft type, aircraft weight,
winds/temperatures, altitude constraints, and trip distance. For typical two-
engine narrow and wide body aircraft, not much variation can occur beyond
a cost index of 900. However, for large aircraft it is possible to have
variability upwards to a cost index of 5000.
For a given aircraft, the performance sensitivity to cost index:
– Decreases with increased weight at typical cruise altitude
– Decreases as cruise altitude increases
– Decreases as a tail wind component increases
– Decreases with reduced distance between POD and POA
– Increases with reduced weight at typical cruise altitude
– Increases as cruise altitude decreases
– Increases as a head wind component increases
– Increases with greater distance between POD and POA

391
Cost Index Commands
Overview
Cost Index Application (Static Method)

As stated above, you can opt to specify a CI value as a primary cruise input on the Cruise
Mode command line. In this case, you must predetermine the value for the flight. This means
the flight’s operating cost (time-related costs) must be defined and then divided by the fuel
price (in cents per pound) for the flight. The resulting ratio is then entered into the flight plan
request as the CI value. The input must be preceded by the letters, CI, to be acknowledged as a
cost index cruise mode. For example, assume the flight hour cost is $3,500 USD and the fuel
cost is $1.65/USG; then the CI is 142.
NOTE Remember, to get the fuel cost factor (cents/lb), you must divide the price per
gallon by the fuel density (in this case 6.7lbs/gallon).
Example:
11 CRZ MODE CI350
Cost Index Application (Dynamic Method)

JetPlan can also determine the most efficient CI value without a specific input (dynamically)
during the flight plan computation. For this to happen, you must set certain parameter values
in your Customer Airport Database (CAPDB) and Customer Aircraft Database (CADB).
In the CAPDB, you must set the Fuel Price (FP) and/or Bonded Fuel Price (BP), the Fuel
Currency Code (FC), and the Fuel Density (FD) parameters.

392
Cost Index Commands
Overview
Table 12-1 CAPDB CI Parameters
Parameter Code Definition

Fuel Price FP Enter the appropriate fuel price for the airport:
- or - - or - • Fuel Price (FP) is assumed to be the non-bonded
Bonded Fuel Price BP price that includes all taxes and fees required for
domestic flights.
• Bonded Fuel Price (BP), generally used for
international flights, is the non-bonded
(domestic) price minus any taxes and customs
fees.
The price needs to reflect the monetary unit specified
by the Fuel Currency Code (FC). See below.
Ex. FP=3.30 ($3.30 USD)
Fuel Currency Code FC Enter the appropriate ISO code.

Ex. FC=USD or FC=JPY
Fuel Density FD Optional. Enter a fuel density value only if the airport
altitude dictates a non-standard requirement.
Otherwise, JetPlan applies the default standard value
of 6.7 lbs/gal.
Example: FD=6.8
For more detailed information on these parameters, see Chapter 30, “Customer Airport
Database.”
In the CADB, you must set the Operational (time-related) Cost parameter. The Operational
Cost parameter is actually the time-related cost field in the Performance Index parameter (PI)
of the CADB. This is the same field you would use if you were to apply the PI Cost
Optimization option (for example, M,$$$,$$$$) as your performance index through the
CADB. Since fuel optimization is typically preferable, your setting input would be

393
Cost Index Commands
Overview
F,$$$,$$$$. However, the fuel price field is irrelevant in the dynamic CI process because the
fuel price figure from the CAPDB has precedence. See “Performance Index (Fuel, Time, Cost)
Optimization” in Chapter 9, “Profile Commands.”
NOTE While the Performance Index fuel price parameter might be irrelevant in the
dynamic CI process, a reasonable value needs to be entered on the off chance that
the departure airport is not loaded in the CAPDB.
Table 12-2 CADB CI Parameter

Performance Index PI Enter the operational cost (time-related costs) in the field
PI or PI= provided. Typically, fuel optimization is preferred (and
recommended under this scenario). The fuel price field is
Example: PI=F
irrelevant as long as a price is set for the departure station
Example: PI=T in the CAPDB.
Example: Example: PI=F,110,2000 (Fuel optimization, $1.10 fuel
PI=M,115,1850 price, $2000 operational cost setting)
NOTE The Operational Cost you enter is always presumed to be in the monetary
unit of U.S. Dollars (USD).
To invoke the dynamic CI process, enter CI on the Cruise Mode command line. No value is
necessary, as JetPlan computes the optimal cost index value for you.
Example:
11 CRZ MODE CI
The following guidelines apply to these cost index features:
• If you enter a value after CI (for example, CI750) or any other cruise mode
input (for example, M85, LRC, MRC) on the Cruise Mode command line,
the dynamic CI process is ignored and the entered cruise mode is applied.
• For CI or CI### Cruise Modes, an ad hoc request for CI optimization
overrides any conflicting optimization criteria in the CADB file:
– The leading letter (F, T, or M) has no effect.
– If the Cruise Mode input is CI, then the CADB fuel price has no
effect unless the CAPDB fuel price is not available.

394
Cost Index Commands
Overview
– If the Cruise Mode input is CI### (for example, CI350), then the
entire performance parameter is ignored. This also applies to
RATCI (described in“Related JetPlan Features” on page 406).
• For Non-CI Cruise Modes, performance is based on the letter value of the PI
field:
– PI=F,088,2500 is a minimum fuel plan. Cost information has no
effect on optimization.
– PI=T,088,2500 is a minimum time plan. Cost information has no
effect on optimization.
– PI=M,088,2500 is a minimum cost plan. Cost information has the
same effect as the legacy money option.
Cost Index vs. Other Economy Schedules

The following list shows the relationship between cost index and other JetPlan economy speed
schedules.
MRC (Maximum MRC effectively equates to a cost index of zero (0).

Range Cruise)
LRC (Long Range Since LRC performance is typically close to MRC performance, LRC
Cruise) airspeeds are consistent with low CI values, falling somewhere in the
range of CI0 (zero) to CI250.
Cost Optimization When used in conjunction with a fixed airspeed (for example,
(save money) M,088,6200 and M85), the legacy Cost Optimization (Performance
Option with Fixed Index) option provides vertical optimization similar to that used in CI
Speed flight planning. However, fixed speeds tend to prevent more effective
cost optimization.
Cost Optimization When used in conjunction with a Cost Index value (for example,
(save money) with M,088,6200 and CI500), the legacy Cost Optimization option offers
Cost Index redundant information. In general, these two options should not be
used together. If they are, ensure that the Cost Optimization ratio
(time/fuel cost) is equal to the specified CI value. JetPlan always uses
the CI value as the basis for the optimization calculations. In other
words, when the Cruise and Performance entries contradict, JetPlan

395
Cost Index Commands
Overview
optimizes the profile and true airspeed in accordance with the Cruise
Mode input, while providing total flight cost information based on the
Performance Index input.
Minimum Adjusted Extends CI methodology to include crew costs and lateness costs. See
Cost Index (MACI) “Minimum Adjusted Cost Index Cruise Mode.”
Minimum Adjusted Cost Index Cruise Mode

This section covers the Minimum Adjusted Cost Index (MACI) method. As explained above,
the CI cruise mode process uses the ratio of hourly time costs to fuel costs to determine the
lowest cost flight plan. The ratio can be provided as part of the CI cruise mode input (CI60) or
calculated from user-provided time cost rate and fuel price information stored in the CADB
and CAPDB. MACI extends CI by factoring flight-specific time-based costs into the cost
minimization criteria used to determine an effective cost index. In addition to the hourly time
cost from the CADB, the user can specify a fixed aircraft cost, crew costs, and the cost of
being early or late, referred to in this document as “Lateness Costs.”
Other than calculating the final cost as required for MACI, there is no difference between a CI
and an MI plan. The additional costs are included in the total cost computation for a flight
plan. JetPlan then chooses the optimal speed schedule and profile that minimizes total cost.
To invoke the MACI process, enter MI on the Cruise Mode command line. No value is
necessary, as JetPlan computes the effective cost index value for you.
Example:
11 CRZ MODE MI
The MACI output shows the total cost and CI value.
MACI and Required Arrival Time Methods

Either Required Arrival Time method can be requested (Q8 RAT or RATCI) along with
MACI. When both MACI and RATCI are requested, the plan required to achieve the arrival
time is considered the best plan.
Both RATCI and MACI use the Minimum and Maximum RAT Cost Index values in the
CADB. Setting these parameters to meaningful values for the aircraft reduces the processing
time for these plans. A meaningful Maximum RAT Cost Index value is particularly important.
See “CADB Parameters” on page 399.

396
Cost Index Commands
Overview
Any RATCI limitation also applies to MACI. MACI plans differ from RATCI plans in these
ways:
• In RATCI plans, the system replaces a CI that is too high to be achievable

with a lower CI, even if the original CI was requested by the user. The
system does not do this for MACI plans, even if it means a plan is not
created.
• If needed to achieve the desired arrival time, RATCI functionality overrides
user-specified cruise modes. The MACI method does not do this.
MACI Costs
In a MACI flight plan computation, the system chooses the optimal speed schedule and profile
that minimize total cost. The MACI-specific costs can be broken into five categories:
Fuel cost Fuel cost is the cost of the fuel burned, and decreases with time as the
less fuel is burned the slower the aircraft flies. Fuel cost is stored in
the CAPDB, and can also be entered ad hoc.
Aircraft Maintenance costs include a fixed operating cost and a per-hour

maintenance costs operating cost, so maintenance costs increase with time. Maintenance
costs apply only during the flight (non-taxi) time. Maintenance costs
are stored in the CADB.
Crew costs Crew costs also increase with time, but have two rates: the initial on-
schedule rate that is paid until the default block time has elapsed, and
the hourly over-schedule rate. Crew costs apply from OUT time to IN
time. Crew costs and the default block time are stored in the CPFDB.
Crew costs can also be defined in the Customer Airport Fleet
Database (CAPFDB) and the Aircraft Fleet Database (ACFDB). The
CAPFDB values are used only if no crew cost values are defined in
the CPFDB. If the CAPFDB also does not contain crew cost values,
the system uses the values in the ACFDB record. No values equals no
crew cost.
Lateness costs As with maintenance costs, lateness costs include a fixed portion and
a time-based portion. Unlike maintenance costs, lateness costs can
vary with how late (or early) the flight is. In the CPFDB, you can
define five lateness time segments, each of which has its own fixed

397
Cost Index Commands
Overview
and variable cost. For example, you can define a time-based cost so
that, within a “late” lateness segment, the lateness costs increase with
time, while within an “early” lateness segment, the lateness costs
decrease with time. Conversely, you can define an early lateness
segment so that the lateness costs increase with time.
Enroute Charges Included only when requested on the flight plan.
With the exception of fuel cost and the hourly portion of the maintenance costs (the CADB
hourly time cost), any of these costs can be zero. Aircraft operating costs and a POD fuel price
must be defined for MACI to be calculated.
The MACI cost computation is arrived at as shown in the following table.
Table 12-3 MACI Cost Computation

Total Cost = Fuel Cost + Crew Cost + Maintenance Cost + FIR Charges + Lateness Charges
Crew Cost = Flight Crew Cost + Cabin Crew Cost
• Flight Crew Cost = Number of Flight Crew * ((Cockpit Crew On-Schedule Rate * Default
Block Time) + (Cockpit Crew Over-Schedule Rate * Hours Over Schedule))
• Cabin Crew Cost = Number of Cabin Crew * ((Cabin Crew On-Schedule Rate * Default
Block Time) + (Cabin Crew Over-Schedule Rate * Hours Over Schedule))
• The number crew members is derived from the flight plan request. If no
number is provided in the flight plan request, JetPlan uses the default crew
count stored in the City Pair Fleet Database (CPFDB).
• Crew on and over-schedule rates can be stored in the CPFDB, the Customer
Airport Fleet Database (CAPFDB), and the Aircraft Fleet Database (ACFDB).
JetPlan looks first in the CPFDB for the values. If they are not there, JetPlan
looks for them in the CAPFDB. If the CAPFDB also does not contain crew
cost parameter values, the system uses crew cost values in the ACFDB record.
No values = no crew cost.Hours Over-Schedule Time = Scheduled IN Time -
Default Block Time. Hours Over-Schedule Time cannot be a negative value.
• Default Block Time = Block (OUT to IN) time. The Default Block Time value
is stored in the CPFDB. Default Block Time cannot be a negative value.
Maintenance Cost = Aircraft operating cost * estimated time enroute (flying time only not taxi times) +
Fixed Aircraft Operating Costs
• Aircraft operating cost = The time-based value in the Performance Index (PI)
parameter in the CADB.
• Fixed Aircraft Operating Costs = The value of the Fixed Operating Cost (OC)
parameter in the CADB.

398
Cost Index Commands
Overview
Table 12-3 MACI Cost Computation (continued)

Lateness Cost = Late Time * Lateness Rate + Fixed Lateness Cost
• Late Time = Planned ETA - Lateness Range (segment)

• Lateness segment = Defines a range of “lateness” in minutes. Negative values
(early) are valid. Lateness segments store a start time, end time, a lateness
rate/minute, and a fixed lateness cost. A sequence of up to five lateness
segments is possible.
• Lateness Rate = The dollar-per-minute value applied to a given lateness time
segment, as defined in the CPFDB. If the Lateness Rate cannot be found in the
CPFDB, JetPlan uses zero as the lateness cost.
Fuel Cost = Cost of fuel burn based on fuel price at POD. Must use the correct bonded/non-bonded fuel
price based on the flight. Fuel price is stored in the CAPDB.
NOTE The POD fuel price is used in the computation, even when the engine is performing a tankering
computation.
Configuring Customer Databases for MACI

The MACI method requires that certain customer database parameters be set. The following
section describes these parameters.
NOTE Operating costs in the Performance Index (PI) parameter (in the CADB) and
the POD fuel price (which can be set by multiple methods) must be defined, or
JetPlan returns an error when you try to run a MACI plan.
If crew costs are not defined in the CPFDB, APFDB, or ACFDB, the flight plan
indicates that crew costs were not included in the cost calculation. If a lateness table
in the CPFDB is not in effect, or there is not a lateness entry corresponding to the
time, the lateness cost is zero.
If none of MACI-specific costs (lateness and crew) are defined in the customer
databases, the dynamic CI is used instead.
CADB Parameters
The CADB enables you to store values for two parameters related to operating costs. Both of
these values are included in the MACI calculation:
• A fixed operating cost that captures fixed maintenance costs per flight per
aircraft, measured in monetary units (dollars). This value is stored in the
Fixed Operating Cost parameter in the “Modes” section of the CADB.

399
Cost Index Commands
Overview
• (Required) An operating cost per flight hour per aircraft, measured in

monetary units per unit of time (dollars/hr). This value is stored in the time-
related operational cost field of the Performance Index parameter in the
“Miscellaneous” section of the CADB.
Table 12-4 CADB Operating Cost Parameters

Performance Index PI NOTE The time portion of this parameter must be set for
MACI flight plans.
PI or PI=
ex. PI=F Enter the operational cost (time-related costs) in the field
provided. Typically, fuel optimization is preferred (and
ex. PI=T
recommended under this scenario). The fuel price field is
ex. PI=M,115,1850 irrelevant as long as a price is set for the departure station
in the CAPDB.
Ex. PI=F,110,2000 (Fuel optimization, $1.10 fuel price,
$2000 operational cost setting).
Fixed Operating Cost OC This parameter allows you to specify a fixed operating cost
(dollars/hour). The fixed operating cost is typically used to
capture fixed maintenance costs per flight. Example: 200
In addition to the operating costs parameters above, it is recommended that the Aircraft
Minimum and Maximum RAT CI values be set to meaningful values, for both MACI and
RAT/RATCI methods. For more information, see “MACI and Required Arrival Time
Methods” on page 396.
Table 12-5 CADB RAT Max/Min CI Parameters

Min RAT Cost Index CI1 This parameter sets the lower cost index airspeed limit in
the Required Arrival Time – Cost Index (RATCI)
calculation. The input value is a valid cost index number.
Example: 010.
For more information, see the “ETD Commands” chapter.
Max RAT Cost Index CI2 This parameter sets the upper cost index airspeed limit in
the Required Arrival Time – Cost Index (RATCI)
calculation. The input value is a valid cost index number.
Example: 1000
For more information, see the “ETD Commands” chapter.

400
Cost Index Commands
Overview
CAPDB Parameters
You must set the fuel price, currency code, and fuel density in the CAPDB for the POD
airport, or specify them on the flight plan request. These values are used in the MACI
calculation.
Table 12-6 CAPDB MACI Parameters

Fuel Price FP Enter the appropriate fuel price for the airport:
- or - - or - • Fuel Price (FP) is assumed to be the non-bonded
Bonded Fuel Price BP price that includes all taxes and fees required for
domestic flights.
• Bonded Fuel Price (BP), generally used for
international flights, is the non-bonded
(domestic) price minus any taxes and customs
fees.
The price needs to reflect the monetary unit specified
by the Fuel Currency Code (FC). See below.
Ex. FP=3.30 ($3.30 USD)
Fuel Currency Code FC Enter the appropriate ISO code.

Ex. FC=USD or FC=JPY
Fuel Density FD Optional. Enter a fuel density value only if the airport
altitude dictates a non-standard requirement.
Otherwise, JetPlan applies the default standard value
of 6.7 lbs/gal.
Ex. FD=6.8
CPFDB Parameters
The CPFDB contains the following parameters used in MACI calculations:
• Default Block Time

• Lateness Time Segments
• Crew Costs

401
Cost Index Commands
Overview
Default Block Time

The value of the Default Block Time parameter is the standard Out to In time for the fleet
type/city pair combination. It is used to calculate crew costs for a given flight.
Table 12-7 CPFDB Default Block Time Parameter

Default Block Time DBT The DBT indicates the standard amount of time from
Out to In time for the fleet type/city pair combination.
The DBT is added to ETD for use in taxi-time
adjustment look up.
DBT is also used by the Minimum Adjusted Cost
Index (MACI) process to determine crew costs when a
scheduled time isn't available.
This parameter is used by the front-end system
(OPSControl, JetPlan.com, and so on) to
automatically determine an ETA when a flight is
created manually.
Input value: 0–2359. Default is 0000. Enter the value
as hhmm. For example, an entry of 1015 means 10
hours and 15 minutes.
NOTE DBT must be set to a value greater than zero
for the CPFDB or CAPFDB taxi time values to be used.
Crew Cost Parameters

You can define values for both a default cabin crew count and a default cockpit crew count in
the CPFDB. Cost is also stored for both cabin and cockpit crews. Each crew type must have an
on-schedule rate and an over-schedule rate as follows:
On Schedule Cost of cockpit and cabin crew members measured in monetary

Rates units/time, such as dollars/hour. The on-schedule cost for the crew
member is calculated by multiplying the default block time in the
CPFDB* the on-schedule rate. On-schedule costs are calculated
based on default block time, and are not reduced even if the estimated
flying time is less than the original default block time.
Over Schedule Cost of cockpit and cabin crew members measured in monetary
Rates units/time, such as dollars/hour. The over-schedule cost for a crew
member is calculated by multiplying the estimated time over-
schedule time * the over-schedule rate. These costs are stored for
cockpit crew and cabin crew.

402
Cost Index Commands
Overview
If crew costs are not defined in the CPFDB, APFDB, or ACFDB, the flight plan indicates that
crew costs were not included in the cost calculation. Alert messages appear in the output if you
are using a format that supports alerts.
When no crew count has been defined, the output includes the following alert:
MACINOCW
CREW COSTS NOT INCLUDED AS NO CREW
When no crew costs have been defined, the output includes the following alert:
MACINOCC
CREW COSTS NOT INCLUDED AS COST NOT SET
Table 12-8 CPFDB Crew Costs Parameters

Default Cockpit Crew NCOD Sets the default cockpit crew count; used when computing
Number total cost if no crew count is passed in the flight plan
request.
Input value: 0–99
Cockpit Crew Cost On OSRO Sets the fixed cost for the cockpit crew for on-time arrivals.
Schedule Input value: Dollars/hour, range=0–10,000
Cockpit Crew Cost VSRO Sets the fixed cost for the cockpit crew for late arrivals.
Over Schedule Input value: Dollars/hour, range=0–10,000
Default Cabin Crew NCAD Sets the default cabin crew count; used when computing
Number total cost if no crew count is passed in the flight plan
request.
Input value: 0–99
Cabin Crew Cost On OSRA Sets the fixed cost for the cabin crew for on-time arrivals.
Cabin Crew Cost Over VSRA Sets the fixed cost for the cabin crew for late arrivals.
Lateness Time Segments

You can store five lateness time segments for each fleet/POD/POA combination in the
CPFDB. The city pairs are directional. For example, the city pair for DFW->JFK is different
from JFK->DFW. Each lateness segment for a city pair is designated with a lateness sequence
number, starting with 0 (zero).

403
Cost Index Commands
Overview
The lateness time segments for a city pair consist of a start time, a lateness rate/minute, and a
fixed lateness cost. The fixed lateness cost for each lateness time segment has a range of valid
values from $0-$99,999. The start or end times for each segment can be negative numbers; for
example, there are cases where a penalty can be applied even if the scheduled ETA is met.
Lateness costs are based on the flight’s scheduled arrival time, not when the flight actually
arrives (ETA + Taxi In time). Thus, JetPlan must be aware of the scheduled ETA when a
MACI flight plan is computed.
The following table shows sample lateness segment data for the city pairs DFW->JFK and
JFK->DFW. As an example, a flight that is seven minutes late from DFW to JFK represents a
lateness sequence number of 1.
Table 12-9 Sample Lateness Segments
Fixed
Start Time Lateness Lateness
Sequence POD POA (min) Rate ($/min) Cost ($)
0 DFW JFK –1 0 1000
1 DFW JFK 5 50 2000
2 DFW JFK 8 0 3000
3 DFW JFK 15 0 0
0 JFK DFW 0 0 0
1 JFK DFW 5 50 400
2 JFK DFW 10 0 1100
3 JFK DFW 14 0 1100
The following table lists the Lateness Segment parameters in the CPFDB.
Table 12-10 CPFDB Lateness Segment Parameters

Late Band Effective LBEB In JetPlan command-line interface, this parameter activates
Begin the Lateness Segments. The effective start/end time values
are a “time of day” range during which the band times are
active, stored as hhmm.

404
Cost Index Commands
Overview
Table 12-10 CPFDB Lateness Segment Parameters (continued)

Late Band Effective LBEE In JetPlan command-line interface, this parameter de-
End activates the Lateness Segments. The effective start/end
time values are a “time of day” range during which the
band times are active, stored as hhmm.
Lateness Time LB0B–LB4B The Lateness Time Segments start/end times define a range
Segments–Sequence of “lateness” in minutes. Negative values (early) are valid.
Start Time A sequence of up to five lateness segments is possible.
(Sequence 0–4) The Start Time parameter indicates the number of minutes
past the scheduled arrival time at which the given lateness
sequence becomes effective.
Input value: -9999–9999 for begin and end time
Lateness Time LB0E–LB4E The Lateness Time Segments start/end times define a range
Segments–Sequence of “lateness” in minutes. Negative values (early) are valid.
End Time A sequence of up to five lateness segments is possible.
(Sequence 0–4) The End Time parameter indicates the number of minutes
past the scheduled arrival time at which the given lateness
time segment ceases to be effective.
Lateness Rate (Per LB0R–LB4R This parameter is the dollar-per-minute value that is
Minute) applied to the given lateness time segment. A sequence of
(Sequence 0–4) up to five lateness segments is possible.
Input value: Whole dollars 0-9999
Fixed Lateness Cost LB0F–LB4F This parameter is the fixed dollar value that is applied to
(Sequence 0–4) the given lateness time segment. A sequence of up to five
lateness segments is possible.
CAPFDB and ACFDB Parameters

As explained above, crew costs are defined in the CPFDB, but they can also be defined in the
CAPFDB and the ACFDB. JetPlan looks first in the CPFDB for the values. If they are not
there, JetPlan looks for them in the CAPFDB. If the CAPFDB also does not contain crew cost
parameter values, the system uses crew cost values in the ACFDB record. If the system can
find no crew cost values in any of these databases, crew costs are counted as zero, and alerts
are output if the format supports them. See “CPFDB Parameters” on page 401.

405
Cost Index Commands
Related JetPlan Features

The Cost Index Cruise Mode has applicability in the following flight planning features:
RATCI One of the primary applications of Cost Index is the ability to

(Destination) exercise better control over flight plan arrival times. Aircraft
operators are constantly confronted with the issue of meeting
scheduled arrival times in the face of departure delays. Since basic CI
essentially solves the problem of what speed/altitude combination is
cost optimal, the Required Arrival Time (RAT) problem can be
translated as follows: What CI achieves the required arrival time? The
answer is provided by JetPlan’s RATCI option. For more
information, see Chapter 8, “Estimated Time of Departure
Commands.”
RATCI (Enroute Similar to the destination RATCI functionality described above. This
Waypoint) option is applicable to those situations where an aircraft operator
must plan a specific time to reach a specific enroute waypoint
(possibly for a rendezvous) before proceeding on with a more cost
efficient speed schedule. For more information, see Chapter 8,
“Estimated Time of Departure Commands.”
Cost Index Method As discussed above, cost index flight planning and operations are
(Non-FMC usually associated with an onboard FMC. However, the CI concept
CI/RATCI) and functionality can be applied to aircraft lacking an FMC through
the Cost Index Method parameter (LC) in the “Miscellaneous”
section of the CADB. This parameter allows you to select the method
JetPlan uses to determine the economy airspeed for a given cost index
value. To use this parameter correctly, you must enter a cost index
value in the flight plan request or ensure that one is automatically
determined for you.
When this parameter is set, and a cost index cruise mode is entered on
the Cruise Mode command line, JetPlan calculates the flight plan
based on the CI input and then uses the data from this calculation to
determine the cruise mode (from those available for the aircraft) that
most closely duplicates the initial data. The plan is then recalculated

406
Cost Index Commands
using the selected cruise mode. This provides some cost optimization
while avoiding the constant throttle adjustments that only an onboard
computer can make.
NOTE Using the Traditional JetPlan cost index method with the MACI cost index
method is not recommended because the newer cost index methods are faster and
more accurate.
RATCI and Reclear The RATCI option described above is designed to work with
JetPlan’s Reclear feature. This includes support for special fuel
efficient speed schedule planning along the non-time critical leg to
the reclear airport.
Climb/Descent The Climb and Descent Method parameters in the “Miscellaneous”

Methods section of the CADB allow you to select a method to compute climb
and descent with cost index or with a user-specified climb/descent
profile (speed schedule).
Climb and Descent CI-based climb and descent operation can also be applied in a limited
Schedules fashion.
(Bracket Modes)
NOTE The relatively limited availability of manufacturer supplied climb and descent
schedule data necessitates a hybrid approach within JetPlan to model CI climb and
descent flight planning performance.
This approach allows for sets of CI ranges to be established in the

“Bracket Modes” section of the CADB. Here, default climb and
descent speed schedules can be explicitly defined for each CI range.
This method allows you to associate the more time-aggressive climb
and descent speed schedules with the higher CI ranges, and closely
emulates FMC performance.
The following sample illustrates how climb and descent speed

schedules can be defined by cost index ranges.

407
Cost Index Commands
-- BRACKET MODES (UP TO 6)

BK1 FROM CI0 TO CI70 CLIMB AAA DSCNT AAA
BK2 FROM CI71 TO CI200 CLIMB 340 DSCNT 320
BK3 FROM CI201 TO CI9999 CLIMB 360 DSCNT 340
Based on the information shown, any flight plan computed with a CI

value between 0 (zero) and 70 uses the AAA (default) climb and
descent schedules (modes). A plan computed with a CI value between
71 and 200 uses climb mode 340 and descent mode 320, and a plan
computed with a CI value above 200 uses climb mode 360 and
descent mode 340.
NOTE Use of this feature can be overridden on any flight plan by entering a climb
and/or descent mode on the Cruise Mode command line (for more information, see
Chapter 11, “Cruise Mode Commands.”)

408
C HAPTER 13
Operational Weight
Commands
Operational Weight Commands
Overview
Overview
The Operational Weight command line allows you to specify the aircraft's basic operating
weight (or operating empty weight). This is a requirement before any flight plan can be
computed. However, you can set an aircraft’s operational weight in the Customer Aircraft
Database (CADB) by saving the value to the OP parameter. See Chapter 27, “Customer
Aircraft Database.” If you set this value in the CADB, then no input is necessary on the
Operational Weight command line. Of course, you can always override the stored setting by
entering a different value on the Operational Weight command line.
Example:
13 OPERATIONAL WT 382000

411
Operational Weight Commands
Operational Weight Considerations
Operational Weight Considerations

The following considerations apply to Operational Weight inputs:
• Input values are specified in pounds or kilograms, depending on the unit of

measure you have selected for flight planning.
• JetPlan compares the aircraft's maximum zero fuel weight to the sum of the
entered operational weight and payload. If the operational weight input
results in the maximum zero fuel weight being exceeded, an error is
generated.
• When using a CADB file as your aircraft type input, the sum of the
Operational Weight (OP) and Max Payload (MP) values must be at or below
the Maximum Zero Fuel Weight (ZF) value. If they exceed the maximum
zero fuel weight, the excess amount is printed out in an error message.
NOTE JetPlan attempts to recalculate the flight plan if the Autoweight option (AW) is
exercised on the Options command line (or if the Autoweight option is stored in your
ID/Attribute File).
• Setting the Operational Weight value equal to the zero fuel weight value is
not recommended. However, if this technique is used, be sure to set the
payload value to zero.

412
C HAPTER 14
Payload, POD/POA,
Weight, and Fuel
Commands
Payload, POD/POA, Weight, and Fuel Commands
Overview
Overview
This chapter covers the Fuel/Weight and Payload options in this chapter because these options
affect one another. For example, an aircraft’s absolute weight limits restricts how much load
can be placed on the aircraft and on how the load affects the flight’s performance. Maximizing
range tends to require more fuel and less payload. Maximizing payload tends to limit range.
Flight plan results are predicated on these performance factors.
Payload inputs are entered on the Payload command line (Line14). Fuel or aircraft weight
inputs are entered on the POD or POA Fuel (or Weight) command line (Line 16).
Whether fuel or weight is the desired load factor you want to apply depends generally on what
type of input you enter on the Payload command line. Whether your fuel or weight input is a
departure or arrival value depends on what you want from JetPlan. If you submit an arrival
value, JetPlan determines the departure weight and fuel load that meets your arrival
specifications. If you submit a departure value, JetPlan simply takes the weight or fuel load
you provide and calculates the plan. In either case, the plan results are dictated by your inputs,
the capability of the aircraft, and the effects of weather on the flight.
In addition, this chapter contains information on some flight plan (FP) options entered on the
Options command line (Line 01). These FP options are included in this chapter because they
invoke functionality related to fuel policies and calculations.

415
Load Performance Scenarios
Load Performance Scenarios

JetPlan is designed to compute flight plans under a variety of load scenarios. These scenarios
fall within two basic categories: departure case planning and arrival case planning.
Departure case planning occurs when a departure fuel or weight load is predetermined and
specified in the flight plan request. In this case, JetPlan simply computes the flight plan based
on the known information. Any fuel remaining (in excess of contingency fuels such as hold,
alternate, and other reserves) or shortfall is a result of the departure amount specified.
Arrival case planning occurs when no departure condition is specified. It is the default method
used by JetPlan. In this case, JetPlan must determine departure loads based on the specified
arrival condition. For example, if you submit a request where zero extra pounds of fuel is
needed upon arrival at the destination (not including contingency fuel amounts), JetPlan
calculates the proper departure fuel amount needed to meet that zero extra fuel requirement.
Within these two basic conditions, you have the option of entering a specific payload figure or
allowing JetPlan to automatically maximize payload. To maximize payload, JetPlan uses the
various weight limit figures stored in the aircraft’s generic or customer database record and the
departure or arrival load value you apply in the flight plan request.
Five basic load performance scenarios enable you to do the following:
• Submit a flight plan with a known departure or a known arrival fuel value
and a known payload value.
• Submit a flight plan with a known departure or a known arrival fuel value
and let JetPlan maximize payload based on a zero fuel weight (maximum or
user-specified).
• Submit a flight plan with a known departure or a known arrival weight value
and let JetPlan maximize payload.
• Submit a flight plan with a known departure or a known arrival weight value
and a known payload value and let JetPlan calculate tanker fuel.
NOTE The method described in the preceding bullet point is an older method of fuel
tankering, not to be confused with JetPlan’s Single-Leg Tankering feature (TANK1,
TANK2 options).
• Submit a flight plan with a known departure fuel value and let JetPlan
maximize payload.

416
Payload, Fuel, and Weight Options
Two more scenarios exist, but these are not considered basic because of the application of the
JetPlan Single-Leg Tankering feature:
• Submit a flight plan with the Single-Leg Tankering option. JetPlan

determines whether tankering fuel is warranted.
NOTE Two Single-Leg Tankering cases exist: one is based on a fuel index
(TANK1), and the other is based on actual fuel cost (TANK2).
• Submit a flight plan using the Multi-Sector Tankering option. Based on the
results from a referenced flight plan, JetPlan automatically tankers the fuel
necessary for the second leg of a flight operation.

The following options illustrate the application of the various load performance scenarios. The
type of payload input you enter generally defines the type of load factor (weight or fuel) you
intend to apply. A user-defined payload (a quantitative amount such as 50,000 lbs) defines a
load factor of fuel by default.
In addition, when entering the load factor, you must specify whether the flight plan is a
departure case or an arrival case, which in turn significantly influences the performance
calculation results.
NOTE Other (secondary) options shown in the following sections also have
fuel/weight and payload implications.
Payload Commands
The following paragraphs describe the commands that you can enter on the Payload command
line (Line 14).
xxxxx (Specify Actual Payload Amount – Fuel)

This input specifies an actual payload amount. The input leaves the case (departure/arrival)
input open to your discretion, but presumes a fuel (not weight) load factor.

417
Example:
14 PAYLOAD 50000
16 POD OR POA FUEL A5000
Explanation: Request 50,000 lbs of payload and 5,000 lbs of arrival fuel (above and beyond
contingency fuels).
xxxxx,T (Specify Actual Payload Amount – Weight)

This input specifies an actual payload amount. The input leaves the case (departure/arrival)
input open to your discretion, but presumes a weight (not fuel) load factor. Excess weight is
identified as extra fuel, which can be considered a tankered amount.
Wxxxxxx/nnnnn (Waypoint Arrival Fuel)

This input enables you to arrive over a requested waypoint with a requested amount of fuel
onboard. Enter an actual payload amount on the Payload command line.
Example:
14 PAYLOAD 5000
16 POD OR POA FUEL W2000/GUP
Explanation: Request 5,000 lbs of payload and arrive over the waypoint GUP with 2,000 lbs of
fuel.
NOTE The alert message “ALERT TAG WPARFU ALERT MSG OPTION XXXX” is
suppressed for Waypoint Arrival Fuel case, where “XXXX” is one of following options:
AW, ETOP(X), DRFT(X), TANK1(X), TANK2(X), TANK3, RF, RC(C), or ORB.
W (Maximize the Payload Amount)

This input requests JetPlan to maximize the payload amount. Enter a departure or arrival
weight value on the POD or POA Weight command line (Line 16).
Example:
14 PAYLOAD W
16 POD OR POA WT D150000
Explanation: Request max payload based on a departure (takeoff) weight of 150,000 lbs.

418
ZW (Maximize the Payload Amount)

This input requests JetPlan to maximize the payload amount. Enter a departure or arrival
weight value on the POD or POA Weight command line (Line 16).
NOTE ZW is only available for use with an aircraft stored in the CADB. ZW ensures
the maximum payload amount cannot be exceeded.
Example:
14 PAYLOAD ZW
16 POD OR POA WT A140000
Explanation: Request max payload and an arrival (landing) weight of 140,000 lbs.
F (Maximize the Payload Amount)

This input requests JetPlan to maximize the payload amount. Enter a departure fuel value on
the POD or POA Fuel command line.
NOTE The F option only works on a departure case flight plan.
Example:
14 PAYLOAD F
Explanation: Request max payload and a departure fuel of 25,000 lbs.

419
ZF (Maximize the Payload Amount)

This input requests JetPlan to maximize the payload amount. Enter a departure or arrival fuel
value on the POD or POA Fuel command line.
NOTE ZF is only available for use with aircraft stored in the CADB. ZF invokes this
functionality: Initially, the payload amount starts as the difference between the
operational weight and the maximum zero fuel weight (MZFW). This difference can be
decreased (payload is decreased) to meet the calculated fuel requirements (for
example, on long flights).
Example:
14 PAYLOAD ZF
Explanation: Request max payload and an arrival fuel of 0 lbs.
xxxxx,Z (Zero Fuel Weight)

This input requests JetPlan to determine payload based on a specified zero fuel weight. This
input leaves the case (departure/arrival) input open to your discretion, but presumes a fuel (not
weight) load factor.
NOTE The value entered here is not a payload amount, but a zero fuel weight
amount. The option, Z, invokes this differentiation. The payload amount is the
difference between the operational weight and the specified zero fuel weight.
Example:
14 PAYLOAD 130000,Z
Explanation: Request payload to be the difference between the operational weight and the zero
fuel weight (130,000 lbs). Request arrival fuel of 0 lbs.

420
PAXxxx (Passenger Count)

The PAX input specifies the number of passengers. The number of passengers is multiplied by
an estimated weight value for each passenger plus his or her bags. The estimated weight value
is 170 pounds per passenger. This input leaves the case (departure/arrival) input open to your
discretion.
NOTE The PAX value is independent of the payload.
Example
14 PAYLOAD 30000,PAX120
16 POD OR POA FUEL A0,D45
Explanation: 30000 is the payload, and 120 is the number of passengers.
The output of the PAX value is format-specific. On plain flight plan formats, the PAX value is
purely informational. It is not included in the weight or fuel-burn computation. For example:
WEIGHT AND FUEL-ALL IN LBS

TOTAL PAX 120 EST PLD 30000
When the flight plan output is formatted or reformatted for a Sperry or Litton Flight
Management System (FMS), the PAX weight value is used to determine the excess weight,
which is reported in the Flight Management Data as cargo. The difference between the total
payload and the PAX weight is output as cargo weight.
When the flight plan output is formatted or reformatted for a Sperry or Litton FMS, and the
payload input is less than the PAX weight value (number of passengers x 170), there is no
excess weight to report, and the PAX output is purely informational.
NOTE FMS formatted or reformatted flight plan output can be uploaded to the
onboard FMS. For information about the FMS options, see Chapter 2, “Option
Commands.”

421
POD or POA WT Fuel Commands

The POD or POA Weight (or Fuel) command line requires an input of one of the options listed
below. In addition, there are several secondary options and reserve fuel options that be
appended to the required input. These secondary options are discussed in the subsections
below.
Dxxxxx (Departure Case)

The D indicates a departure case. Specify the takeoff fuel or weight value.
Example:
Axxxxx (Arrival Case)

The A indicates an arrival case. Specify the landing fuel, weight value, or time.
Example:
Explanation: Arrive with 5,000 lbs of fuel.
Example:
16 POD OR POA FUEL A20M
Explanation: Arrive with 20 minutes of fuel (from holding charts in aircraft data).
DM (Departure Case, Maximum Load)

The D indicates a departure case. The M requests a maximum load. The plan calculation is
based on the maximum takeoff fuel or weight for the aircraft.
Example:
16 POD OR POA FUEL DM
Explanation: Depart with the max amount of fuel for the aircraft.

422
Example:
16 POD OR POA WT DM
Explanation: Depart at the maximum takeoff weight for the aircraft.
AM (Arrival Case, Maximum Load)

The A indicates an Arrival case. The M requests a maximum load. This option applies only to
a weight load factor. The plan calculation is based on the maximum landing weight for the
aircraft.
Example:
16 POD OR POA WT AM
POD or POA WT Fuel Secondary Options

The following options can be entered after specifying the case (departure or arrival) and load
factor (fuel or weight) input.
NOTE Be sure to enter a comma between the primary (case/load factor) input and
any of these secondary options.
MFODxxxx (Minimum Fuel On Destination)

The MFODxxxx option applies to any combination of payload, case, and load factor. This
option ensures that a specific amount of fuel is available on landing. If the sum of the hold,
alternate, reserve, and requested extra fuels (contingency fuels) is less than the specified
MFOD value, extra fuel is added. JetPlan accepts excess contingency fuel with this option.
You can enter the MFOD value as either a weight or time value. JetPlan converts the time
value to a weight value and uses the weight value for processing.
NOTE You cannot include both MFOD and Minimum Fuel at Gate (MFAG) in the
same flight plan request.

423
Example:
16 POD OR POA FUEL A0,MFOD6000
Explanation: Request zero pounds of arrival fuel and specify an MFOD value of 6,000 pounds.
Example:
16 POD OR POA FUEL A0,MFOD55M
Explanation: Request zero pounds of arrival fuel and specify an MFOD value of 55 minutes.
MFAGxxxx (Minimum Fuel at Gate)

The MFAGxxxx option applies to any combination of payload, case, and load factor. This
option ensures that a specific amount of fuel is available when the aircraft arrives at the gate. If
the sum of the hold, reserve, and requested extra fuels (contingency fuels) is less than the
specified MFAG value, extra fuel is added. JetPlan accepts excess contingency fuel with this
option.
NOTE You can enter the MFAG value only as a weight value.
NOTE You cannot include both MFOD and MFAG in the same flight plan request.
Example:
16 POD OR POA FUEL A0,D45,MFAG=10000
Explanation: Request zero pounds of arrival fuel and specify an MFAG value of 10,000
pounds.
MFALTxxxx (Minimum Fuel At Alternate)

The MFALTxxxx option applies to any combination of payload, case, and load factor. This
option ensures that a specific amount of fuel is available on landing at the primary alternate. If
the sum of the hold, reserve, and requested extra fuels (contingency fuels) is less than the
specified MFALT value, extra fuel is added. JetPlan accepts excess contingency fuel with this
option.

424
NOTE You can enter the MFALT value only as a weight value.
Example:
16 POD OR POA FUEL A0,MFALT6000
Explanation: Request zero pounds of arrival fuel, and specify an MFALT value of 6,000
pounds.
AFxxxx (Arrival Fuel)

This option enables you to specify an arrival fuel when the load factor is a weight value.
Example:
16 POD OR POA WT A150000,AF2000
Explanation: Request an arrival (landing) weight of 150,000 lbs and an Arrival Fuel of 2,000
lbs.
NOTE This option cannot be used with a departure weight scenario (16 POD OR
POA WT D150000,AF2000 is not a valid input).
FC=xxxxx (Fuel Capacity)

This option applies to aircraft stored in the CADB only. It restricts the maximum fuel capacity
of the aircraft to the amount specified by overriding the value stored in the CADB record. You
can enter this option with or without the equal sign between the option and the value (for
example, FCxxxxx or FC=xxxxx).
Example:
16 POD OR POA WT D150000,FC=45000
Explanation: Request a departure (takeoff) weight of 150,000 lbs and a max Fuel Capacity of
45,000 lbs for the CADB record N12345.

425
FD=x.xx (Fuel Density)

This option applies to aircraft stored in the CADB only. It changes the fuel capacity of the
aircraft for an individual flight plan by changing the fuel density. Fuel density is specified in
pounds per gallon (lbs/gal).
For output formats that use kilograms as the preferred weight unit, JetPlan determines the
volume and convert the output appropriately. You can enter this option with or without the
equal sign between the option and the value (for example, FDx.xx or FD=x.xx).
Example:
16 POD OR POA WT D150000,FD=6.83
Explanation: Request a departure (takeoff) weight of 150000 lbs and change the Fuel Density
to 6.83 lbs/gal for the CADB record N12345.
TO=xxxxxx (Takeoff Weight)

This option applies to aircraft stored in the CADB only. It restricts the max takeoff weight of
the aircraft to the amount specified by overriding the value found in the CADB record. You
can enter this option with or without the equal sign between the option and the value (for
example, TOxxxxx or TO=xxxxx).
Example:
16 POD OR POA WT A140000,TO=168000
Explanation: Request an arrival (landing) weight of 140,000 lbs and limit the max Takeoff
Weight to 168,000 lbs for the CADB record N12345.
LA=xxxxxx (Landing Weight)

This option applies to aircraft stored in the CADB only. It restricts the maximum landing
weight of the aircraft to the amount specified by overriding the value found in the CADB
record. You can enter this option with or without the equal sign between the option and the
value (for example, LAxxxxxx or LA=xxxxxx).
Example:
16 POD OR POA WT D150000,LA=140000

426
Explanation: Request a departure (takeoff) weight of 150,000 lbs and limit the max Landing
Weight to 140,000 lbs for the CADB record N12345.
ERA=xxxx (Enroute Alternate)

This option applies to customers with specific output formats only. The format must be
capable of displaying enroute alternate information in the flight plan output. The option value
must be a valid ICAO or IATA airport identifier.
NOTE This option is AIR OPS compliant.
Example:
16 POD OR POA FUEL A0,ERA=EGLL
Explanation: Request an arrival fuel of 0 lbs and the enroute alternate, EGLL.
Bxxxxx (Ballast Fuel)

This option applies to customers with specific output formats only. The format must be
capable of displaying a ballast fuel figure in the flight plan output. The option value is the
amount of ballast fuel in pounds or kilograms.
Example:
16 POD OR POA FUEL A0,B9500
Explanation: Request an arrival fuel of 0 lbs, but carry 9,500 lbs ballast.
ADJ=xxx (Adjustment Fuel Amount)

The adjustment fuel amount accounts for additional fuel over and above the required
minimums. The option value is the amount of extra fuel in pounds or kilograms. This option
applies to customers with specific output formats only. The format must be capable of
displaying the fuel adjustment figure in the flight plan output.
Example:
16 POD OR POA FUEL A0,ADJ=300
Explanation: Request an arrival fuel of 0 lbs, but carry an extra 300 lbs of fuel.

427
MAXT=xxxxx (Maximum Tanker Fuel)

This option is used with the Single-Leg Tankering option. It limits the tanker quantity to the
amount specified, which can be verified by summing the alternate, hold, reserve and extra fuel
totals. The only exception to a MAXT restriction is when the flight needs more fuel to meet
legal requirements. In this case, the MAXT amount is overridden. The MAXT option can also
be applied to Multi-sector Tankering.
Example:
16 POD OR POA FUEL D50000,MAXT=12000
Explanation: Request a departure fuel of 50,000 lbs and tanker no more than 12,000 lbs of
fuel.
MCHT=xxx (Minimum Contingency Holding Time)
NOTE This option is used only in EU OPS flight plans.
The MCHT option compares the flight’s calculated contingency fuel to a holding fuel figure
that is based on the time specified by MCHT (Hold Fuel Flow Rate x the MCHT value).
JetPlan uses the greater of the two amounts as the flight’s contingency fuel total. The MCHT
option value is specified in minutes.
NOTE When calculating EU OPS flight plans, JetPlan uses the highest of the
following values: the calculated contingency fuel, the MCHT, the Minimum
Contingency Cruise Time (MCCT), or the Min. Contingency/RES Time (MT) in the
CADB.
Example:
16 POD OR POA FUEL A0,i,MCHT=5
Explanation: Request an arrival fuel of 0 lbs and compare the flight’s calculated contingency
fuel total to a holding fuel figure based on the minimum contingency holding time of five
minutes.

428
MCCT=xxx (Minimum Contingency Cruise Time)
NOTE This option is used only in EU OPS flight plans.
The MCCT option compares the flight’s calculated contingency fuel to a cruise fuel figure that
is based on the time specified by MCCT (Cruise Fuel Flow Rate x MCCT value). The fuel
flow rate used to calculate the cruise fuel figure is generally the final fuel flow rate prior to the
Top of Descent point (TOD). JetPlan uses the greater of the two amounts as the flight’s
contingency fuel total. The option value is specified in minutes.
NOTE When calculating EU OPS flight plans, JetPlan uses the highest of the
following values: the calculated contingency fuel, the MCCT, the Minimum
Contingency Holding Time (MCHT), or the Min. Contingency/RES Time (MT) in the
CADB.
Example:
16 POD OR POA FUEL A0,MCCT=180
Explanation: Request an arrival fuel of 0 lbs and compare the flight’s calculated contingency
fuel total to a cruise fuel figure based on the minimum contingency cruise time of 180 minutes.
PN=1234 (Multi-Sector Tankering)

This option supplies JetPlan with the departure fuel requirements from the referenced flight
plan (number) for the purpose of tankering that amount on another flight plan. Typically, this
would apply to turnaround operations where the fuel price, or the time factor, dictates
tankering enough fuel for the return leg of the operation. See “Multi-Sector Tankering” on
page 466.
NOTE All options that adjust the aircraft’s maximum values (for example, max
takeoff, landing, fuel volume) must have inputs that fall within the range limits loaded
for the aircraft.

429
Domestic, International, and Island Reserves

You can specify reserve fuel rules and amounts as options on the POD or POA Fuel Weight
command line (Line 16).
The following options can be entered after specifying the case (departure or arrival) and load
factor (fuel or weight) input.
NOTE Be sure to enter a comma between the case/load factor input and any of
these sub-options.
Dxxx (Domestic Reserves)

This option calculates reserve fuel based on the number of minutes specified. The time value is
multiplied by the fuel flow rate of the last level cruise segment before Top of Descent (TOD).
Example:
16 POD OR POA FUEL A0,D45
Explanation: Request an arrival fuel of 0 lbs and 45 minutes of reserve fuel.
Ixxx (Island Reserves)

The I option followed by a time value defines the input as island reserves. Island reserve totals
are determined in the same manner as domestic reserves (the time value is multiplied by the
fuel flow for the last level cruise segment).
Example:
16 POD OR POA FUEL A0,I120
Explanation: Request an arrival fuel of 0 lbs and 120 minutes of reserve fuel.

430
I (International Reserves)
The I option by itself indicates a request for international reserve fuel based on a specific fuel
policy. The lack of a time value distinguishes this input from Island reserves.
NOTE This manual uses the term “International Reserve Fuel” to describe
functional calculations made by JetPlan. For U.S. Federal Aviation Regulations, these
calculations always include: enroute fuel, alternate fuel, enroute reserve fuel (based
on 10% of the enroute time), and international reserve fuel (30 minutes hold). The
B43 international reserve policy is an alternative calculation. For more information,
see “B43X=xx (B43 International Reserve Policy)” on page 433.
Example:
Explanation: Request an arrival fuel of 0 lbs; calculate reserve fuel based on a default
international policy.
NOTE A specific international reserve policy can be set in your ID/Attribute record
so that it is automatically invoked every time an international flight plan is computed.
Otherwise, JetPlan applies a default policy. The JetPlan default policy for
international reserve fuel is based on U.S. Federal Aviation Regulations (FARs),
which define specific calculations based on the type of aircraft (for example, turbojet
or turboprop). The JetPlan default policy for turbojet aircraft is ten percent (10%) of
the enroute time to the destination. The policy for turboprop aircraft is fifteen percent
(15%) of the enroute time to destination and alternate plus 30 minutes. Refer to FAR
121 and 125.
International reserve policies are categorized as either reserve or contingency. When a policy
is defined as reserve, the calculated reserve fuel is included in the landing weight. When a
policy is defined as contingency, the calculated reserve fuel is not included in the landing
weight. How this applies to your operation depends on your requirements or other restrictions.
xxx (International Reserve Policy)

This option overrides any stored or default policy. A policy is a three- digit code that identifies
a specific formula for calculating reserve fuel. The first number of the code defines the
formula, while the remaining two numbers define the applicable percentage rate. For example,
the international reserve policy, 105, suggests the following: use the formula defined for
policy code 1, and apply a 5% calculation rate.

431
The most common international reserve fuel policies are listed in Table 14-1.
Table 14-1 Common International Reserve Policy Formulas
Policy Description
1xx xx% of enroute time, output in RES. Multiplies last
cruise segment fuel flow by time.
2xx xx% of enroute burn, output in RES. xx% of

alternate burn, output in ALT. Same as policy 8, but
this is a “contingency” policy.
3xx xx% of both enroute burn and alternate burn,

output in RES.
4xx xx% of enroute burn, output in RES. Same as

policy 6, but this is a “contingency” policy.
5xx RAAF and AAF Reserves Reserve Policy 5.

Reserve burn and time are 10% of enroute
burn/time. Add in fixed reserves—always 3500 lbs
for RESDOM 5 and 4300 lbs for RESDOM 38.
6xx xx% of enroute burn, output in RES. Same as

policy 4, but this is a “reserve” policy.
7xx xx% of enroute burn, alternate burn and hold fuel,

output in RES.
8xx xx% of enroute burn, output in RES. xx% of

alternate burn, output in ALT. Same as policy 2, but
this is a “reserve” policy.
Example:
Explanation: Request an arrival fuel of 0 lbs. Calculate reserve fuel based on policy number
eight, at a rate of ten percent.
16 POD OR POA FUEL A0,810
NOTE You can also set the International Reserve (IR) parameter in the City Pair
Fleet database (CPFDB) to a valid JetPlan code for an international fuel reserve
policy. JetPlan then applies that policy by default to any flight for the city pair and fleet
type, overriding the system default. For more information, see Chapter 34, “City Pair
Fleet Database.”

432
B43X=xx (B43 International Reserve Policy)

This option enables you to request the B43 International Reserve Policy. JetPlan determines
the B43 Areas of Operation (AOO) and the B43 required reserve fuel and also displays the
B43 reserve fuel in the flight plan output. The following paragraphs cover the B43 reserve
policy and JetPlan’s solution in more detail.
About the B43 Reserve Policy

FAA Standard Operations Specification section B43 allows reduced enroute reserves for
international flights for Part 121 operators that have received approval from the FAA. The B43
reserve policy is based on the following assumptions:
• Navigation errors are unlikely when the aircraft is in Class 1 airspace,

receiving signals from ground-based navaids.
• Fuel reserves can be safely and reasonably reduced to account for the time
the aircraft is in Class 2 airspace, outside the range of navaid signals, where
navigation errors are most likely.
The B43 reserve policy stipulates that:
• Enroute reserves can be calculated only for portions of the route where the
aircraft is in Class 2 airspace and is more than an hour away from Class 1
airspace along the route.
• Enroute reserves can be calculated at 10%, 5%, or 3% by agreement with the
FAA and based on aircraft capabilities.
• Destination reserves must be increased from 30 minutes to 45 minutes. The
destination reserves are computed the same as domestic reserves–at final
segment fuel flow, as opposed to “hold” over most distant airport
(destination or farthest alternate).
How JetPlan Supports B43 Flight Plans

JetPlan provides the following capabilities:
• Enables you to enter the B43 policy and percentage to apply. In JetPlan
command-line mode, this information is entered on line 16 POD OR POA.

433
• Automatically determines the B43 AOO based on available navaid signals,

either on the route or near the route.
Class 1 airspace is defined as that area along the route of flight in which
radio signals from ground-based navaids can be received. These navaids can
be either on the route of flight or in the vicinity of the route of flight. A
segment on the route of flight is considered outside of Class 1 airspace if:
– It is more than 130 nautical miles (nm) from any H VOR in the
JetPlan database on or off-route.
– It is more than 75 nm from any NDB in the JetPlan database on or
off route. The NDB is not considered if its ARINC power rating is
“blank” (50 to 1999 watts).
• Enables you to indicate navaids that are out of service. In JetPlan command-
line mode, this information is entered on line 16 POD OR POA FUEL.
• Takes the one-hour rule into account, returning reserves only when the
aircraft is at least one-hour distant from Class 1 airspace along the route.
• Displays an alert on the flight plan when no B43 AOOs exist.
• Provides “special reserves” output information on the flight plan, as
specified by the customer’s flight plan format.
• Provides a diagnostic extended flight plan output that supports detailed
validation of the calculations, including entry and exit points for B43 AOOs.
NOTE You must add the 45 minutes of flying time to the destination required for the
B43 policy. JetPlan does not automatically add this to the calculation.
B43 Flight Plan Inputs and Output

The following example illustrates using command line mode to apply the B43 reserve policy
to a flight plan request.
Example:
16 POD OR POA FUEL A0,D45,B43X=10/HPB,NSE/
Explanation:
• Arrive with zero extra fuel (A0).

• Calculate domestic 45 minutes reserve fuel (D45). (Mandatory when
invoking the B43 reserve policy.)

434
• Calculate 10% B43 reserves (B43X=10).

• Output the B43 Diagnostic Log at the end of the flight plan (B43X=10).
• Exclude waypoints HPB and NSE from consideration in the determination
of Class 1 airspace coverage while making the B43 reserve calculations
(/HPB,NSE/).
Example:
16 POD OR POA FUEL A0,D45,B43X=10
The following illustrations show excerpts of output from a sample flight plan (abbreviated)
resulting from these inputs.
NOTE The output of B43 Entry and Exit points in the flight plan body is only for
those B43 segments that are more than 1 hour of flying time. The output of B43 Entry
and Exit points in the B43 Diagnostic Log is for all B43 segments.

435
The following flight plan excerpt shows the B43 special reserve fuel.
IFR /03 772/B772LR KORD/ORD EDDF/FRA

ALTN NONE
MIN T/O FUEL121904 RLS FUEL 127404
TOT BRN 105378 PLAN ARR FUEL 016526 01HR/18MIN
MEL/CDL 5500
RTE
FF KZAUZQZX CZYZZQZX CZULZQZX CZQXZQZX EUCBZMFP EUCHZMFP
EGGXZOZX
(FPL-B772LR-IG
***Abbreviated for space***
RWT 544853 PLD 065000 GND / LRC SKD /

BIAS 0000 AVG WIND DIR/COMP 278/P062 AVG TD P008
PLAN ARR FUEL 016526 0118
---------------------------------------------------------------
ARPT FUEL TIME DIST NAM
ENRT BRN FRA 105378 0717 3892 3462
---------------------------------------------------------------
SP/RSV 01316 0006 **10% B43 SPECIAL RESERVES USED**
RSV 09710 0045
ALTN NONE 00000 0000 0000
HOLD 00000 0000 BUFR 00000
MEL/CDL 05500
---------------------------------------------------------------
T/O FUEL 121904 MIN T/O 121904
---------------------------------------------------------------
TAXI 00000
------
TOTAL 121904
EXTRA 005500 0027
RLS FUEL ORD 127404
ENDURNC 0744 ADJ 00 MINS/1000 LBS
***Abbreviated for space**

436
The following flight plan excerpt shows the B43 entry and exit points.
---------------------------------------------------------------
N52132 W053221 084 840 531 P07 0113 0013 0031
HECKK 370 35 24042 P042 086 032 489 TBD 2335 0300 0763
---------------------------------------------------------------
N53000 W050000 089 839 540 P09 0132 0014 0035
5350N 370 35 23053 P049 092 010 491 TBD 2203 0314 0728
---------------------------------------------------------------
B43 ENTRY 1 N5500 W03959
N55000 W040000 089 838 567 P08 0374 0040 0093

5540N 370 40 22089 P078 093 010 489 TBD 1829 0354 0635
---------------------------------------------------------------
N55000 W030000 105 838 578 P05 0345 0036 0082
5530N 370 40 28093 P092 104 010 486 TBD 1484 0430 0552
---------------------------------------------------------------
B43 EXIT 1 N5440 W02544
N54000 W020000 111 836 610 P06 0355 0034 0079

5420N 370 39 30141 P124 105 010 486 TBD 1129 0504 0473
---------------------------------------------------------------
N53000 W015000 117 836 580 P09 0189 0020 0044
MALOT 370 35 30095 P091 115 010 489 TBD 0940 0524 0428
---------------------------------------------------------------

437
The following flight plan excerpt shows the B43 diagnostic log.
B43 DIAGNOSTIC LOG

SEGMENT DST COVERAGE
1 KORD - EBAKE 42 GIJ=42
2 EBAKE - WISMO 43 OBK=43
3 WISMO - POSTS 47 PMM=47
4 POSTS - PADDE 25 GRR=25
5 PADDE - SVM 40 CRL=40
6 SVM - YEE 211 CRL=81 YEE=130
7 YEE - YXI 113 YEE=130 YXI=130
8 YXI - YMW 76 YXI=130
9 YMW - YLQ 149 YXI=54 YUL=95
10 YLQ - VBS 71 VBS=130
11 VBS - YYY 128 VBS=130 YYY=130
12 YYY - PN 167 YYY=130 YGP=37
13 PN - YNA 103 YNA=130
14 YNA - YAY 229 YNA=130 YAY=130
15 YAY - HECKK 113 YAY=130
16 HECKK - 5350N 132 YAY=17 CLASS2=115
* CLASS2 Entry 1
17 5350N - 5540N 374 CLASS2=374 B43=0
* B43 Entry 1 (3600 sec after CLASS2 Entry)
18 5540N - 5530N 345 B43=345
19 5530N - 5420N 355 B43=149 CLASS2=206
* B43 Exit 1 (3600 sec before CLASS2 Exit) (Duration: 3669 sec)
20 5420N - MALOT 189 CLASS2=189
21 MALOT - GISTI 36 CLASS2=36
22 GISTI - BANBA 291 CLASS2=58 SHA=233
* CLASS2 Exit 1 (Duration: 10869 sec)
23 BANBA - KONAN 312 BCN=242 BIG=70
24 KONAN - KOK 25 KOK=130
25 KOK - FERDI 39 KOK=130
26 FERDI - BUPAL 38 KOK=38
27 BUPAL - REMBA 13 KOK=13
28 REMBA - SPI 29 KOK=29
29 SPI - DITEL 31 SPI=130
30 DITEL - BENAK 3 SPI=3
31 BENAK - POBIX 13 SPI=13
32 POBIX - AKIGO 8 SPI=8
33 AKIGO - OSMAX 12 SPI=12
34 OSMAX - EPINO 5 SPI=5
35 EPINO - LAGES 11 SPI=11
36 LAGES - ROKIM 17 SPI=17
37 ROKIM - FFM 23 SPI=23
38 FFM - MTR 16 FFM=130 MTR=130
39 MTR - EDDF 18 MTR=130
Total flying time of B43 AOO * 10% (flying time > 1 hr): 366
Fuel flow rate used to compute the SP/RSV value: 12946

438
China Civil Aviation Regulation 121 (CCAR-121) R5 Fuel Policy

(R5xx)
IMPORTANT When included in a flight plan request, the CCAR-121 R5 fuel policy
overrides any other fuel policy, such as an International Reserve Policy entered on
Line 16 or a customer-specific default policy. Before using the CCAR flight plan option
in combination with any other reserve fuel options, such as a 07 HOLD, ALTERNATE
hold value, contact Jeppesen Customer Support or your Jeppesen Service Manager.
The CCAR-121 R5 fuel policy defines formulas for calculating contingency and reserve fuel
for operators flying under Chinese Civil Aviation Regulations. The CCAR-121 R5 fuel policy
is invoked by the R5xx 01 Option, where xx is a percentage of trip fuel from 3–10 percent,
represented by 03, 04, 05, 06, 07, 08, 09, or 10. For example, the following command specifies
five percent of the trip fuel:
01 OPTION FP,R505
Contingency Fuel and Time Calculations

When the flight plan request includes the R5xx flight plan option, JetPlan computes
contingency fuel as the greater of the following amounts:
• The specified percentage of trip fuel, from 3–10 percent, inclusive.

- or -
• Fifteen minutes of hold at the POA based on the landing weight at the POA,
an altitude of 1500 feet above the POA, and the ISA temperature.
IMPORTANT Reclear plans do not support use of the R5xx option with three or four
percent trip fuel. If you use R503 or R504 in a Reclear request, JetPlan displays an
error.
Contingency time is computed using the following formula: [contingency fuel] /[fuel flow
based on the POA landing weight, 1500 feet above the POA, and ISA].

439
Reserve Fuel Calculations
When the request includes the R5xx option, JetPlan computes reserve fuel as follows:
• When no destination alternate is associated with the flight plan, reserve fuel
is computed as 30 minutes hold at the POA based on the landing weight at
the POA, an altitude of 1500 feet above the POA, and the ISA temperature.
• When a destination alternate is associated with the flight plan, reserve fuel is
computed as 30 minutes hold at the destination alternate based on the
landing weight at the alternate, an altitude of 1500 feet above the alternate,
and the ISA temperature.
Output
The contingency fuel and time and the reserve fuel and time are included in the output in
supporting formats. (If you have any questions about formats, contact your Jeppesen Service
Manager or Jeppesen Customer Support.)
Additional Options that Affect Payload, Fuel, and

Weight
The following options affect the flight performance by adjusting the balance between fuel,
weight and payload.
Hold Option
The Hold option enables you to make changes to the flight plan using command lines that are
typically omitted when a CADB record is used. Enter the Hold option on the Options
command line anywhere after the flight plan command (for example, FP,HOLD). The Hold
option enables you to access the Reserve and Max Fuel command lines when these options
would not typically be available.
When the Hold option is applied after all normal questions are answered, JetPlan displays the
following prompt: “ENTER QUESTION NUMBER OR GO.” At this prompt, enter @17 to
display Question 17.
What Question 17 prompts for depends on the flight performance case you have entered in the
flight plan request. If you have specified an arrival case, Question 17 prompts for “Max Fuel.”
If you have specified a departure case, Question 17 prompts for “Reserve” fuel.

440
The applicability of these items is explained below.
Reserve This is the expected change item when the Hold option is applied in a
departure case flight plan. For the departure fuel case (for example,
depart with 45,000 lbs of fuel), a reserve fuel input has no bearing on
the flight plan computation and results. Avoid this input in this case.
For the departure weight case (for example, depart at a takeoff weight
of 150,000 lbs) a reserve fuel input changes the flight plan in the
following way: the plan results are the same as if no reserve is entered
except that the reserve input amount is displayed in the XTRA fuel
block, and the payload is reduced by that exact amount. Hence, this
input shows extra fuel, but robs payload to do so. Avoid this input
unless this result is deemed useful.
NOTE To add arrival fuel to a departure weight case flight plan, use the secondary
input option, AFxxxxx. See above.
Max Fuel This is the expected change item when the Hold option is applied in
an arrival case flight plan. For either arrival fuel case (fuel or weight),
a max fuel input simply changes the aircraft’s fuel capacity, which
can be done using the secondary input option FC=xxxxx. Hence, this
is to be avoided as well.
Reserve Inputs
When using a generic aircraft as your Aircraft Type command line input, the Reserve
command line (17 RESERVE) is prompted if a departure case flight plan is specified. The
amount you enter is in addition to any hold, alternate, and domestic or international reserve
fuel calculated. However, this amount is taken from what could be carried as payload. To
avoid this, enter zero on the Reserve command line (for example, 17 RESERVE 0). Amounts
can be entered in lbs or minutes. To indicate minutes, enter a two-digit value followed by “M.”
Example:
17 RESERVE 30M

441
Explanation: 30 minutes of extra reserve fuel.
NOTE If arrival taxi fuel is included in the flight plan request or stored in the aircraft’s
CADB record, JetPlan subtracts that amount from the reserve fuel. For example,
assume a 5,000 pound reserve fuel. If 500 pounds of arrival taxi fuel is included in the
flight plan, the reserve fuel output is 4,500 pounds.
Max Fuel Inputs

When using a generic aircraft as your Aircraft Type command line input, the Max Fuel
command line (17 MAX FUEL) is prompted if an arrival case flight plan is specified. The
amount you enter sets the fuel capacity for the flight plan computation. In most cases, this is
the maximum tank fuel available at rotation/takeoff.
Automatic Weight Reiteration (Autoweight)

The Automatic Weight Reiteration feature (autoweight) allows JetPlan to recalculate the flight
plan when either a weight limit or the maximum fuel capacity is exceeded. Typically, to find a
solution to an excess weight problem, the autoweight process adjusts the payload or the flight
case (departure/arrival) until a viable answer is determined. JetPlan can also be set to adjust
extra fuel, while maintaining the specified payload.
The autoweight feature is invoked in a flight plan by entering the AW option on the Options
command line.
Example:
01 OPTIONS FP,AW
NOTE Jeppesen recommends the use of this option. The autoweight feature can be
set in your ID/Attribute record so that it is invoked regularly. You can choose to have it
set the standard way, where payload and/or flight case is adjusted; or have it set so
that payload is maintained and extra fuel is adjusted. Contact your Jeppesen account
manager for assistance.

442
Application of Load Performance Scenarios
Application of Load Performance

Scenarios
As stated earlier, there are five load performance scenarios. Applying these scenarios to the
JetPlan system leads to the conclusion that there are seven basic combinations available in
which you can enter payload, fuel, weight, reserves, and maximum fuel to get a flight plan.
These combinations are illustrated below. They show the relationship between the various
load factors and the flight performance cases.
NOTE JetPlan requires a Reserve or Max Fuel input only if a CADB record name is
not used (when a generic aircraft is used). With departure case flight plans, a Reserve
input provides extra (pad) fuel (at a cost to payload). With arrival case flight plans,
extra fuel is specified on the POA Fuel command line (for example, A5000).
“Comparing Max Fuel Capacity Plans with MFOD Inputs” on page 450 discusses the
characteristics of the JetPlan system when the MFOD option is applied in a flight plan that
requests maximum fuel capacity.
Arrival Fuel Case/Known Payload Flight Plans

An Arrival Fuel Case flight plan calculates the required departure fuel when the payload is a
known value. If a CADB record is used, JetPlan requires a Payload and Arrival Fuel input. If a
generic aircraft is used, JetPlan requires Payload, Arrival Fuel and Max Fuel inputs.
Table 14-2 Arrival Fuel Case/Known Payload Basics
Prompt (Keyword) Input Remarks

14 PAYLOAD (//PLD) xxxxx Actual Payload value
xxxxx,Z Actual ZFW value (maximize payload)
ZF ZF code (maximize payload - CADB)
16 POA FUEL (//AFL) Axxxxx Arrival case, arrival fuel amount
17 MAX FUEL (//MVR) xxxxxx Fuel capacity value (generic AC)
Example:
14 PAYLOAD ZF
16 POD OR POA FUEL A0,D45,FC137800
17 MAX FUEL 137800 (generic AC)

443
Explanation: Calculate flight plan using the aircraft’s CADB record value for max zero fuel
weight (MZFW). Maximize payload based on that weight. Arrive with no extra fuel (A0)
beyond contingencies (hold, alternate or reserve fuel). Calculate 45 minutes of domestic
reserve fuel (D45), and restrict the fuel capacity to 137,800 lbs (FC137800).
NOTE The Max Fuel command line would be used to specify the fuel capacity if the
aircraft were a generic record rather than a CADB record.
Example:
14 PAYLOAD 50000
16 POD OR POA FUEL A5000,I,TO327400
Explanation: Requests 50,000 lbs of payload. Arrive with 5,000 lbs extra fuel (A5000),
calculate international reserve fuel (I), and restrict maximum takeoff weight to 327,400 lbs
(TO327400).
Example:
14 PAYLOAD 174000,Z
16 POD OR POA FUEL A3500,I120
Explanation: Calculate flight plan at a zero fuel weight value of 174000 lbs. Arrive with 3500
lbs extra fuel (A3500), and calculate 120 minutes of island reserve fuel (I120).
Example:
14 PAYLOAD ZF
16 POD OR POA FUEL A0,I,MFOD23000,FD=6.95
Explanation: Calculate flight plan using the aircraft’s CADB record value for max zero fuel
weight (MZFW). Maximize payload based on that weight. Arrive with zero extra fuel (A0).
Ensure a minimum fuel on landing of 23,000 lbs (MFOD23000). Use a fuel density value of
6.95 lbs/gal (FD=6.95) – increasing the maximum fuel capacity.
Departure Fuel Case/Known Payload Flight Plans

A Departure Fuel Case flight plan with a known payload calculates the required fuel when
both the payload and the takeoff fuel values are known. If a CADB record is used, JetPlan
requires a Payload and Departure Fuel input. If a generic aircraft is used, JetPlan requires

444
Payload, Departure Fuel and Reserve inputs. If a CADB record is used and the Hold option is
specified on the Options command line (for example, FP,HOLD), a Reserve amount can be
entered to add extra fuel to the flight plan (at the price of less payload).
NOTE A reserve fuel can be added to flight plans (without the Hold option) when the
plan is submitted as a Schedule Database record and the aircraft input within the
record is a generic identifier.
Table 14-3 Departure Fuel Case/Known Payload Basics

14 PAYLOAD (//PLD) xxxx Actual Payload value
xxxxxx,Z Actual ZFW value (maximize payload)
ZF ZF code (maximize payload - CADB)
16 POD FUEL (//DFL) Dxxxxxx Departure case, takeoff fuel amt
17 RESERVE (//RES) xxxxx Reserve fuel value
Example:
14 PAYLOAD 50000
16 POD OR POA FUEL D110000,I,MFOD25000
Explanation: 50,000 lbs payload. Depart with 110,000 lbs fuel (D110000) and calculate
international reserve fuel (I). Minimum fuel on landing is 25,000 lbs (MFOD25000).
Example:
01 OPTIONS FP,HOLD (other optional commands can also be entered)
14 PAYLOAD 75000
16 POD OR POA FUEL D200000,108
ENTER QUESTION NUMBER OR GO 17
17 RESERVE 5000
Explanation: 75,000 lbs payload. Depart with 200,000 lbs fuel (D200000) and calculate
international reserve fuel using reserve policy number one (1) at an eight percent (8%) rate
(108). Add an additional reserve (extra) fuel of 5,000 lbs.

445
Arrival Weight Case/Unknown Payload Flight Plans

An Arrival Weight Case flight plan calculates the maximum allowable payload when the
landing weight is a known value. If a CADB record is used, JetPlan requires a Payload and
Arrival Weight input. If a generic aircraft type is used, JetPlan requires Payload, Arrival
Weight and Max Fuel inputs.
Two entries can be selected for payload: W or ZW. Both tell the system to calculate the
maximum payload; however, ZW can be used only with a CADB record. If the sum of the
basic operating weight plus the payload exceeds the maximum zero fuel weight, the ZW input
causes a transfer of the excess weight to extra fuel. It is possible to select both an arrival
weight value and an arrival fuel value. This gives the capability to specify extra fuel, just as in
the Arrival Fuel Case.
Table 14-4 Arrival Weight Case/Unknown Payload Basics

14 PAYLOAD (//PLD) ZW ZW code (maximize payload - CADB)
W W code (maximize payload)
16 POA WT (//AWT) Axxxxxx Arrival case, landing weight

AM Arrive at max landing weight
Example:
14 PAYLOAD ZW
16 POD OR POA WT AM,D45
Explanation: Calculate maximum payload. Arrive at the maximum landing weight stored in
the CADB record (AM), and calculate 45 minutes of domestic reserve fuel (D45).
Example:
14 PAYLOAD ZW
16 POD OR POA WT A247000,I,AF5000
Explanation: Calculate maximum payload. Arrive at 247,000 lbs (A247000), calculate

international reserve fuel (I), and add an arrival fuel of 5,000 lbs as extra reserve fuel
(AF5000).
Example:
14 PAYLOAD W
16 POD OR POA WT A421000,I120
17 MAX FUEL 240000

446
Explanation: Calculate maximum payload. Arrive at 421,000 lbs (A421000), calculate 120
minutes island reserve fuel (I120). Restrict total fuel to 240,000 lbs (MVR = 240000). CADB
record is not used.
Departure Weight Case/Unknown Payload Flight Plans

A Departure Weight Case flight plan calculates the maximum allowable payload when the
takeoff weight is known. If a CADB record is used, JetPlan requires a Payload and Departure
Weight input. If a generic aircraft type is used, JetPlan requires Payload, Departure Weight
and Reserve inputs.
Two entries can be selected for payload: W or ZW. Both direct JetPlan to calculate the
maximum payload; however, ZW can only be used with a CADB record. If the sum of the
basic operating weight plus the payload exceeds the maximum zero fuel weight (MZFW)
value in the CADB, the ZW input switches excess weight to the extra fuel category.
Table 14-5 Departure Weight Case/Unknown Payload Basics

14 PAYLOAD (//PLD) ZW ZW code (maximize payload - CADB)
W W code (maximize payload)
16 POD WT (//DWT) Dxxxxxx Departure case, takeoff weight

DM Depart at max takeoff weight
Example:
14 PAYLOAD ZW
16 POD OR POA WT DM,I
Explanation: Calculate maximum payload. Depart at the maximum takeoff weight stored in
the CADB record (DM), and calculate international reserve fuel (I).
Example:
14 PAYLOAD ZW
16 POD OR POA WT D800000,I
Explanation: Calculate maximum payload. Depart at 800,000 lbs (D800000) and calculate
international reserve fuel (I).

447
Example:
14 PAYLOAD W
16 POD OR POA WT D355000,I120
17 RESERVE 0
Explanation: Calculate maximum payload. Depart at 355,000 lbs (D355000) and calculate 120
minutes of island reserve fuel (I120). No additional reserve fuel selected. CADB record is not
used.
Example:
01 OPTIONS FP,HOLD (other optional commands can also be entered)
14 PAYLOAD ZW
16 POD OR POA WT D155000
17 RESERVE 5000
Explanation: Calculate maximum payload. Depart at 155,000 lbs (D155000) and calculate
reserve fuel of 5,000 lbs. CADB is used.
Departure Fuel Case/Unknown Payload Flight Plans

A Departure Fuel Case flight plan calculates the maximum allowable payload when the
takeoff fuel value is known. Both this case and the Departure Weight Case calculate the
maximum payload that can be carried. If a Departure Weight Case flight plan results in an
“Exceeds Max Fuel” error (XMFXXXXX), the flight plan request can be switched to this
case. The switch increases the chances of getting a flight plan without error.
If a CADB record is used, JetPlan requires a Payload and Departure Fuel input. If a generic
aircraft type is used, JetPlan requires Payload, Departure Fuel and Reserve inputs.
Table 14-6 Departure Fuel Case/Unknown Payload Basics

14 PAYLOAD (//PLD) F F code (maximize payload)
16 POD FUEL (//DFL) Dxxxxxx Departure case, takeoff fuel amt

DM Depart with max fuel
Example:
14 PAYLOAD F
16 POD OR POA FUEL DM,I,MFOD10000

448
Explanation: Calculate maximum payload. Depart with the maximum fuel capacity stored in
the CADB record (DM), calculate international reserve fuel (I), and arrive with a minimum
fuel on landing of 10,000 lbs (MFOD10000).
Departure Weight Case/Tanker Fuel Flight Plans

A Departure Weight Case/Tanker Fuel flight plan calculates the extra fuel which can be
carried until a weight limit is reached. This case is similar to the Departure Weight Case flight
plan, except that a known payload value is specified. The difference between the known
payload and the maximum allowable payload is output as extra fuel. The letter T after the
payload invokes this case.
If a CADB record is used, JetPlan requires a Payload and Departure Weight input. If a generic
aircraft type is used, JetPlan requires Payload, Departure Weight and Reserve inputs.
Table 14-7 Departure Weight Case/Tanker Fuel Basics

14 PAYLOAD (//PLD) xxxxx,T Actual payload value, tanker fuel
16 POD WT (//DWT) Dxxxxxx Departure case, takeoff weight

DM Depart at max takeoff weight
Example:
14 PAYLOAD 50000,T
Explanation: Calculate the extra fuel which can be carried with 50,000 lbs of payload. Depart
at the maximum takeoff weight stored in the CADB record (DM) and calculate international
reserve fuel (I).
Example:
14 PAYLOAD 50000,T
16 POD OR POA WT D355000,I
Explanation: Calculate the extra fuel which can be carried with a 50,000 lbs of payload.
Depart at 355,000 lbs (D355000) and calculate international reserve fuel (I).

449
Arrival Weight Case/Tanker Fuel Flight Plans

An Arrival Weight Case/Tanker Fuel flight plan calculates the amount of extra fuel which can
be carried until a weight limit is reached. This case is similar to the Arrival Weight Case flight
plan, except that a known payload value is specified. The difference between the known
payload and the maximum allowable payload is output as extra fuel. The letter T after the
payload value invokes this case.
If a CADB record is used, JetPlan requires a Payload and Arrival Weight input. If a generic
aircraft type is used, JetPlan requires Payload, Arrival Weight and Max Fuel inputs.
Table 14-8 Arrival Weight Case/Tanker Fuel Basics

14 PAYLOAD (//PLD) xxxxx,T Actual payload value, tanker fuel
16 POA WT (//AWT) Axxxxxx Arrival case, landing weight

AM Arrive at max landing weight
Example:
14 PAYLOAD 50000,T
16 POD OR POA WT AM,I
Explanation: Calculate the extra fuel which can be carried with a 50,000 lbs of payload. Arrive
at the maximum landing weight stored in the CADB record (AM) and calculate international
reserve fuel (I).
Comparing Max Fuel Capacity Plans with MFOD Inputs

When comparing flight plan requests with both a maximum fuel capacity implication and an
MFOD option, note that the amount of fuel available for enroute burn does not typically vary
with different route inputs. This functionality also applies when the Autoweight feature
changes a departure weight case flight plan or a maximum zero fuel weight flight plan into a
maximum fuel capacity flight plan.
The following example illustrates a request for a maximum zero fuel weight flight plan.
Example:
01 OPTIONS FP,AW
14 PAYLOAD ZF
16 POD OR POA FUEL A0,I,MFOD23000,FD=6.8

450
If, due to the length of the flight, JetPlan cannot calculate the flight plan at the MZFW value,
the Autoweight feature tries to calculate the flight plan based on one of the following cases:
• Maximum takeoff weight

• Maximum landing weight
• Maximum fuel capacity
If JetPlan finds that it can only calculate the flight plan at maximum fuel capacity, then the
amount of fuel available for enroute burn is the difference between the maximum fuel capacity
available at takeoff (as amended by fuel density) and the MFOD value. This can be expressed
as:
MAX FUEL CAPACITY - TAXI FUEL - MFOD = AMOUNT FOR ENROUTE BURN
The following data illustrates a fuel block for a flight plan run at maximum fuel capacity. The
fuel values are in pounds.
POA RCTP 233600

ALT RCKH 007500
HLD 007100
RES 007000
REQ 255200
XTR 001400
TOT 256600
TAXI 001500
RAMP 258100
JetPlan adds an extra fuel amount (1,400 lbs) to raise the MFOD to 23,000 lbs:
ALT + HOLD + RES = VALUE + XTR = MFOD
7500 + 7100 + 7000 = 21600 + 1400 = 23000
Assuming that the sum of alternate, hold, and reserve fuel does not exceed the specified
MFOD value (23,000 lbs in this case), the amount of fuel available for enroute burn is:
RAMP - TAXI - MFOD = AMOUNT FOR ENROUTE BURN
258100 - 1500 - 23000 = 233600
This concept is important to keep in mind when comparing different flight plans run with
maximum fuel capacity and the MFOD option. Assuming that all input parameters stay the
same (except for the route input), the amount of enroute burn fuel available remains constant.
However, the payload (and takeoff weight) vary according to the nautical air miles.

451
Single-Leg Tankering
The Single-Leg Tankering feature is designed to make a tankering/no tankering determination
based on either a known fuel cost or a fuel index. The basic functionality is predicated on the
comparison of two different flight plans: one carrying fuel as defined by the basic flight plan
inputs, the other carrying as much fuel as possible (subject to structural limitations such as
takeoff weight, landing weight, and fuel capacity). This feature requires the application of
certain parameters within the CADB and the Customer Airport Database (CAPDB).
To invoke the Single-Leg Tankering feature, enter one of the following options on the Options
command line:
TANK1 Fuel index tankering. JetPlan tankers fuel if certain criteria are met.
TANK1X Fuel index tankering and analysis. JetPlan tankers fuel if certain
criteria are met. In addition, an analysis prints out at the bottom of the
flight plan. It includes the following: POD fuel index, POA fuel
index, aircraft database fuel index, and the dynamically computed
flight index. Also, if tankering is warranted, the tanker amount and
transport amount are printed.
TANK2 Fuel cost tankering. JetPlan tankers fuel if certain criteria are met.
TANK2X Fuel cost tankering and analysis. JetPlan tankers fuel if certain criteria
are met. In addition, an analysis prints out at the bottom of the flight
plan. It includes the following: POD and POA information: fuel price,
fuel units, fuel currencies, and price/lb (or price/kg). A tanker cost
comparison is printed, and if tankering is warranted, the savings is
printed.
TANK3/TANK3X Fuel cost tankering analysis. This option displays results for tankering
different amounts of fuel (20%, 40%, 60%, 80%, and 100%). This
option can be useful if you are deciding whether to tanker the
maximum amount of fuel or a lesser quantity.

452
Fuel Index Tankering: TANK1 and TANK1X

If fuel price information is sensitive to your operation’s competitiveness, JetPlan enables you
to conceal actual fuel cost information by using a fuel index method for defining fuel price
data. The index method defines fuel prices relative to some standard, such as the cost of fuel at
your home base of operations. This enables you to specify fuel costs in a relative manner
without revealing the actual prices paid.
Database Requirements
Certain database parameters must be set before you can apply this method of the Single-Leg
Tankering feature. The following table lists the required (and optional) parameters.
Table 14-9 Fuel Index Tankering - Database Requirements
Parameter Database Information

Tanker Index (TI) CADB The Tanker Index value is a ratio that conveys a
Optional measure of relative fuel prices (between the
departure and arrival stations) corrected for time.
This value can be different for each aircraft in
your fleet. When computing a flight plan, JetPlan
compares the TI value to the dynamically
calculated Flight Index (FI) value. When the
Tanker Index is less than or equal to the
dynamically computed ratio, fuel tankering is
warranted.
NOTE The Tanker Index value for each aircraft
must be determined by the operator. It is generally
arrived at through experimentation. Theoretically, it
is the point at which tankering fuel is economically
viable for a given time/distance, when the fuel cost
difference (between the two airports – departure
and arrival) is known.
Fuel Index (FI) CAPDB The fuel index value for a particular station is
Required. based on a fuel price standard (typically the fuel
price at your home base of operation). Setting the
standard to a fuel index value of 100 enables you
to define other airport fuel prices as a percentage
increase or decrease from the standard. For
example, if an airport has fuel prices 20% higher
than the standard, it can be given a fuel index
value of 120 (100 + 20). If fuel prices are 6%
lower, then the index value is 94 (100-6).
A fuel index value must be set for every airport
used (departure or arrival) with this feature.

453
Table 14-9 Fuel Index Tankering - Database Requirements (continued)

Tanker Landing Weight (TL) CADB Limits the amount of fuel that can be tankered
Optional based on a specific landing weight. For example,
assuming a tanker landing weight of 480,000 lbs,
if the flight’s calculated landing weight (without
tankering) is 475,000 lbs, the flight is limited to
tanker 5,000 lbs extra fuel (480,000 - 475,000).
This option does not affect the aircraft’s max
landing weight.
Tanker Fuel Maximum (TM) CADB Sets a limit on the maximum amount of fuel to
Optional tanker.
NOTE Can be entered on an ad hoc basis using
the MAXT option on the Arrival Fuel command line.
To set the CADB parameters, use the AC,CHG command.
Example:
01 OPTIONS AC,CHG,acfilename,TI=10.5,TL=152000,TM=12000
To set the CAPDB parameter, use the AP,CHG (or SAV) command.
Example:
01 OPTIONS AP,SAV,airportID,FI=150

454
Flight Index
The method employed in Fuel Index tankering is simply to compare your preset Tanker Index
value to some other figure that measures the relative fuel prices between the departure and
arrival stations. This other figure is the Flight Index. The flight index is a value calculated
during the flight plan computation. It is derived from the fuel index values set for the departure
and arrival airports in your CAPDB and the calculated flight time.
The Flight Index value is dynamically calculated using the following formula:
FI = (AI - DI) / T
where:
• FI = Flight Index
• AI = POA fuel index (stored in your CAPDB)
• DI = POD fuel index (stored in your CAPDB)
• T = Flight time, in hours (from the flight plan computation)
Decision to Tanker
When the dynamically calculated Flight Index is greater than the Tanker Index stored in your
CADB record, fuel tankering is applied to the flight plan calculation. JetPlan automatically
recomputes the flight plan to tanker the maximum amount of fuel from the POD to the POA
without violating any structural limits (or specified tankering thresholds).
If the TANK1X option is specified, JetPlan provides extended information that shows the
respective airport fuel index data at the bottom of the flight plan. When tankering is warranted,
JetPlan prints out both the tanker amount and the transport amount (the amount necessary to
carry the extra tanker weight).
The following examples illustrate the extended information supplied by the TANK1X option.
Example:
In this example, the output suggests that tankering is warranted because the flight index (FLT-
I) is greater than the tankering index (A/C-I). The amount of fuel tankered is shown, as well as
the amount of fuel needed to carry the extra weight (transport fuel).
TANK 1: POD-I POA-I FLT-I A/C-I TANKER TRANSPORT

130.00 180.00 029.41 010.50 068404 004179

455
Example:
In this example, tankering is not warranted because the flight index (FLT-I) is less than the
tankering index (A/C-I):
TANK 1: POD-I POA-I FLT-I A/C-I TANKER TRANSPORT

180.00 130.00 -027.50 010.50 000000 000000
In performing the analysis, JetPlan preserves the user-specified payload. Hence, the value
must be known when the flight plan is requested. Therefore, the Single-Leg Tankering feature
is only valid in the Arrival Fuel Case scenarios.
Maximum Tanker Value

If you wish to cap the amount of fuel tankered to a maximum quantity, you can set the Tanker
Fuel Maximum parameter (TM) in your CADB record or use the MAXT option. The MAXT
option is applied to the individual flight plan on the Arrival Fuel command line (Line 16).
Example:
16 POA FUEL A0,I,MAXT=6000
Explanation: For this flight, the maximum amount of fuel that can be tankered is set to 6,000
lbs/kgs.
NOTE The TM parameter setting is a more permanent solution if that is what you
need.

456
Fuel Cost Tankering: TANK2, TANK2X, TANK3, and

TANK3X Options
The fuel cost tankering option assumes that fuel prices are known to JetPlan. It is based on the
concept of a tankering cost threshold, where you define the minimum amount of monetary
savings that must be achieved before JetPlan tankers extra fuel.
Database Requirements
The fuel cost method requires certain database parameters to be set before applying this
option. The following table lists the required (and optional) parameters:
Table 14-10 Fuel Cost Tankering - Database Requirements

Tanker Threshold (TT) CADB The Tanker Threshold value sets the minimum
Required savings before tankering extra fuel is
warranted. Any calculation which arrives at a
figure that is less than the tanker threshold
value defines a “no tanker” situation.
For example, assuming a tanker threshold of
$100, JetPlan only tankers fuel when the
tankering plan produces a savings of $100 or
more over the non-tankering flight plan.
The default value is zero, meaning any
tankering amount that saves money is
warranted.
Tanker Currency (TC) CADB The tanker currency code is the ISO code that
Required defines the monetary unit you wish to use.
Any fuel savings/shortfall printed in the
extended information at the end of the flight
plan is in this currency.
NOTE A list of codes and exchange rates can
be found using the option, JPIII, on the Options
command line.
Tanker Landing Weight (TL) CADB Limits the amount of fuel that can be tankered
Optional based on a specific landing weight. For
example, assuming a tanker landing weight of
480,000 lbs, if the flight’s calculated landing
weight (without tankering) is 475,000 lbs, the
flight is limited to tanker 5,000 lbs extra fuel
(480,000 - 475,000).
This option does not affect the aircraft’s max
landing weight.

457
Table 14-10 Fuel Cost Tankering - Database Requirements (continued)

Tanker Fuel Maximum (TM) CADB Sets a limit on the maximum amount of fuel to
Optional tanker.
NOTE Can be entered on an ad hoc basis
using the MAXT option on the Arrival Fuel
command line.
Fuel Price (FP) CAPDB Defines the cost of fuel at the individual
Required airport. This must be set for the departure and
arrival station. This value needs to be in line
with the specified Fuel Currency (FC) code.
Fuel Price equates to the “non-bonded price”
that includes all taxes and fees required for
domestic flights (as opposed to the bonded
fuel price that can be used for international
flights. See Bonded Fuel Price below).
Bonded Fuel Price (BP) CAPDB Tankering calculations. Bonded Fuel Price is
Optional the domestic (non-bonded) price minus any
taxes and customs fees. Under certain
circumstances, taxes and customs fees can be
avoided if a flight can be classified as
international.
Fuel Currency (FC) CAPDB Defines the ISO currency unit by which the
Required fuel is purchased. This code needs to be in line
with the specified Fuel Price (FP) setting.
NOTE A list of codes and exchange rates can
be found using the option, JPIII, on the Options
command line.
Fuel Units (FU) CAPDB You can set this to gallons (GAL) or liters
Optional (LTR). The default is GAL.
Fuel Density (FD) CAPDB Fuel density is automatically assumed to be

Optional 6.70 lbs/gal unless specified otherwise with
this parameter.
NOTE All volume/weight/price calculations
are performed automatically by JetPlan.
Differing currency code/fuel units can be used
for different airports.

458
Table 14-10 Fuel Cost Tankering - Database Requirements (continued)

Bonded Fuel Indicator City Pair NOTE This parameter is used only by certain
(CPDB) front-end dispatch software applications.
BFI
Contact your Jeppesen account manager for
ex. BFI=B more information.
ex. BFI=NB Indicates a default the system uses when
determining the fuel price (bonded or non-
bonded) to use in cost index and tankering
analysis for the city pair. This indicator can be
overridden on the flight plan request via the
flight planning front end. The fuel price types
are defined as followed:
• Bonded – The Bonded fuel price is
equivalent to the domestic (Non-Bonded)
fuel price minus any taxes and customs
fees, which can be avoided if a flight can
be classified as International from a tax
perspective.
• Non-Bonded – The Non-Bonded fuel
price is equivalent to the cost “at the
pump” in either USD/Gallon or in the
user’s currency/user’s units and includes
all applicable federal, state, and local
taxes.
Input values:
B – Bonded Fuel
N – Non-bonded Fuel (the default)
To set the CADB parameters, use the AC,CHG command.
Example:
01 OPTIONS AC,CHG,acfilename,TT=250,TC=USD,TL=152000,TM=12000
To set the CAPDB parameter, use the AP,CHG (or SAV) command.
Example:
01 OPTIONS AP,SAV,airportID,FP=1.50,FC=USD,FU=GAL,FD=6.75

459
Decision to Tanker
JetPlan compares the cost of acquiring the tanker fuel at the POD (including the cost of the
fuel needed to transport the tanker fuel), to the cost of acquiring fuel (the tankered amount) at
the POA. The total cost determination is calculated using the following formula:
TC = ((TF + KF) x Pd) - (KF x Pa)
where:
• TC = Total fuel cost.

• TF = Trip fuel. The fuel necessary to fly from POD to POA.
• KF = Tanker fuel. The amount of fuel to be tankered (including transport
fuel).
• Pd = Fuel price at POD. The fuel price can be bonded or non-bonded.
• Pa = Fuel price at POA. The fuel price can be bonded or non-bonded.
If the total cost of the tankering plan is lower than the non-tankering plan, then the tankering
plan is selected. JetPlan automatically recomputes the flight plan to carry the extra fuel.
TANK2/TANK2X Options
If the TANK2X option is specified, JetPlan prints out the cost comparison at the bottom of the
flight plan and shows the determining figure (savings or loss). This extended information
includes a tanker fuel value (positive or negative) whether a savings is realized or not.
Example:
In the following examples, tankering and output of the cost comparison are requested. JetPlan
uses the Fuel Price (non-bonded) value set in the CAPDB unless you specify otherwise.
01 OPTIONS FP,TANK2X
02 POD RKSS
03 POA RJAA

460
In the CADB, the Tanker Currency parameter is set to USD, and the Tanker Threshold is set to
$50.00. In the following case, the cost comparison indicates that tankering is warranted.
TANK2 INPUT: RKSS RJAA

FUEL PRICE 1303.00 0234.00
FUEL UNIT GAL GAL
FUEL CURRENCY KRW JPY
PRICE/LB (USD) 00.2477 00.3358
COST COMPARISON:
TANKER EXTRA 060126 060126
TRANSPORT 003711 0
TOTAL FUEL 063837 060126
FUEL COST (USD) 015815 020192 SAVINGS = +004377 (USD)
THRESHOLD 50 (USD)
SAVINGS = 000146 (USD) PER TON
EXCHANGE RATES RELATIVE TO USD:
KRW 0785.0000
JPY 0104.0000
USD 0001.0000
Example:
In the following case, the cost comparison indicates that tankering is not warranted. The
Tanker Currency parameter (TC) in the CADB is set to USD.
TANK2 INPUT: RJAA RKSS

FUEL PRICE 0234.00 1303.00
FUEL UNIT GAL GAL
FUEL CURRENCY JPY KRW
PRICE/LB (USD) 00.3358 00.2477
COST COMPARISON:
TANKER EXTRA 062245 062245
TRANSPORT 003228 0
TOTAL FUEL 065473 062245
FUEL COST (USD) 021987 015421 SAVINGS = -006566 (USD)
THRESHOLD 50 (USD)
SAVINGS = 000000 (USD) PER TON
EXCHANGE RATES RELATIVE TO USD:
JPY 0104.0000
KRW 0785.0000
USD 0001.0000

461
In performing the tankering analysis, JetPlan preserves the user-specified payload. Hence, its
value must be known when the flight plan is requested. Therefore, the Single-Leg Tankering
feature is valid only in the arrival fuel case scenario.
NOTE The Savings figure in the fuel cost tankering output prints out a negative or
positive value. In addition, the Savings figure is listed on a per tonne basis if the
standard weight unit used is kilograms rather than pounds.
TANK3/TANK3X Options
The TANK3 and TANK3X options are similar to TANK2 and TANK2X, except that in
addition to running the tankering analysis for the maximum tankered fuel (limited either by the
structural and capacitive limits of the aircraft or by the POA departure fuel in Multi-Sector
Tankering), cost analyses are also run on five different percentages (100%,80%,60%,40% and
20%) of the maximum tankered fuel.
JetPlan first calculates 100% tankering that is the same as in the TANK2/TANK2X options,
and then reduces the tankering amount by 20% until 20% of total tankering is reached. The
corresponding extra time, extra fuel to carry, and profit are calculated for the different
percentages of tankering. The optimum amount is determined based on profit/loss analysis.
TANK3 and TANK3X provide analysis only; no fuel is uplifted.
Example:
The following example shows the output of the TANK3 cost comparison.

462
ECONOMICS OF CARRYING EXTRA FUEL
MAX 80PC 60PC 40PC 20PC OPT

EXTRA TIME 0035 0028 0021 0014 0007 0035
EXTRA FUEL 001353 001082 000812 000542 000271 001353
FUEL TO CARRY 000080 000064 000048 000031 000015 000080
PROFIT/LOSS 000014 000011 000009 000006 000004 000014
TANKERING ANALYSIS
TANKERING CRITERIA 00010.7142

FUEL COST DIFFERENCE 00.0391
OPTIMUM TANKERING AMOUNT 001353
ESTIMATED ENDURANCE TIME 0035
ADDITIONAL B/O DUE TANKERING 000080
AT 100.0PC MAX. TANKERING

REQUEST NO. 4122
Using Bonded Fuel Prices in Tankering Calculations

If you have defined a Bonded Fuel Price value for an airport in the CAPDB, you can use it in
the tankering calculation.
Example:
OPTIONS FP,TANK2X
02 POD KSEA,FI=B
03 POA KPHX
Explanation:
To specify use of the bonded fuel price, enter FI=B for the appropriate airport.
You can also use the “G” option in the Flight Brief database to create a Flight Brief record that
specifies which CAPDB fuel price (bonded or non-bonded) is to be used for flight plans with a
specific flight number or other key parameters. For more information see Chapter 36, “Flight
Brief Database.”
In addition, certain front-end flight planning applications allow you to use the Bonded Fuel
Indicator parameter in the CPDB to determine the default fuel price used in tankering analysis
for the city pair. For more information, see “Database Requirements” on page 457.

463
If you want to override the use of the non-bonded fuel price on a given flight plan, you can
enter FI=NB for the airport.
OPTIONS FP,TANK2X
02 POD KSEA,FI=B
03 POA KPHX,FI=NB
Maximum Tanker Value

See “Maximum Tanker Value” on page 456.
Tanker Limiting Factors

When determining the tanker amount, JetPlan must check a variety of factors to ensure that
certain defined limits are not exceeded. These limits can be either the structural limits of the
aircraft, such as the maximum takeoff and landing weights and the maximum fuel capacity, or
the user-specified limits set in the databases and/or on the plan request itself.
For tankering plans run with the TANK2X option, the factor that limits the amount of extra
fuel carried is automatically reported at the end of the extended information output (after the
Exchange Rate information). The following table lists all of the possible limiting factors.
Table 14-11 Tanker Limiting Factors – Output Messages
Tanker Restriction Explanation

Max Takeoff Weight xxxxxx lbs/kgs The tankered amount was limited by the maximum
(ACDB) takeoff weight setting (TO parameter) in the CADB.
Max Landing Weight xxxxxx lbs/kgs The tankered amount was limited by the maximum
(ACDB) landing weight setting (LA parameter) in the CADB.
Fuel Capacity xxxxxx lbs/kgs The tankered amount was limited by the maximum
(ACDB) fuel capacity setting (FC parameter) in the CADB.
Tanker Landing Weight xxxxxx lbs/kgs The tankered amount was limited by the tanker
(ACDB) landing weight setting (TL parameter) in the CADB.
Max Tanker Fuel xxxxxx lbs/kgs The tankered amount was limited by the tankering
(ACDB) maximum setting (TM parameter) in the CADB.
Max Tanker Fuel xxxxxx lbs/kgs The tankered amount was limited by the MAXT input
(Dispatch) entered on the POA Fuel command line.
Max Landing Weight xxxxxx lbs/kgs The tankered amount was limited by the LA input

464
Table 14-11 Tanker Limiting Factors – Output Messages (continued)
Tanker Restriction Explanation

Max Takeoff Weight xxxxxx lbs/kgs The tankered amount was limited by the TO input
Max Tanker Fuel xxxxxx lbs/kgs The tankered amount was limited by the sector fuel
(Dispatch) requirement (PN option) entered on the POA Fuel
command line.
NOTE See “Multi-Sector Tankering” in this chapter.
Max Takeoff Weight xxxxxx lbs/kgs The tankered amount was limited by the maximum
(MEL) takeoff weight setting (TO parameter) in the Customer
MEL Database.
Max Landing Weight xxxxxx lbs/kgs The tankered amount was limited by the maximum
(MEL) landing weight setting (LA parameter) in the
Customer MEL Database.
Fuel Capacity xxxxxx lbs/kgs The tankered amount was limited by the maximum
(MEL) fuel capacity setting (FC parameter) in the Customer
MEL Database.
NOTE The display of the Tanker Limiting Factor output is also available with the
TANK2 option. However, you must have your output format modified (a simple
keyword addition) to include this information. This feature does not apply to the
TANK1 or TANK1X options.
Fuel Savings Calculations

The monetary savings for both Single-Leg Tankering methods can be calculated as follows:
S = (M1 - M2)
where:
• S = Savings
• M1 = The money needed to attain the net amount of fuel transported from
the POD, at the POA price.
• M2 = The money needed to attain and transport the net amount of extra fuel
delivered to the POA via use of the Single-Leg Tankering feature.

465
• M1 = Net x FPa
• M2 = (Net + Tr) x FPd
where:
• Net = Net amount of fuel transported to the POA as reported by JetPlan
when Single-Leg Tankering is invoked.
• Tr = Extra fuel required to transport the Net amount to the POA as reported
by JetPlan when Single-Leg Tankering is invoked.
• FPa = Actual fuel price (per pound or kilo) at the POA.
• FPd = Actual fuel price (per pound or kilo) at the POD.
NOTE In the fuel index-based tankering scenario, actual fuel prices are withheld
from JetPlan due to the sensitive nature of this data. In these cases the “Net” and “Tr”
figures give you the information required to compute the actual fuel savings in their
own monetary units.
Multi-Sector Tankering
Multi-sector tankering refers to transporting enough tanker fuel on the departure leg of a
turnaround flight operation so as to avoid refueling the aircraft for the return leg.
One way JetPlan supports this concept is through the use of the MAXT option, which is
applied on the POA Fuel command line. By entering a maximum tankering fuel quantity on
the departure leg flight plan – enough to meet the departure fuel requirements for the return leg
(for example, MAXT=50000) – you provide reasonable assurance to the flight operation for
the return trip. Unfortunately, this is awkward because the return leg flight plan must be run
first (to determine the fuel requirements) before the outbound leg can be properly supplied
with accurate information.
A simpler method for ensuring enough tanker fuel for a second flight is JetPlan’s Multi-sector
Tankering feature. This option still requires the return leg plan to be run first, but instead of
you determining the return leg departure fuel requirements and transferring that information
over to the outbound plan, you simply supply JetPlan with the plan number from the return leg
computation and let JetPlan extract the data automatically.
NOTE While the use of the term “return leg” is made here, the second leg of the
flight operation need not necessarily return to the original (outbound) departure
station.

466
To use this feature, run the return (or second) leg plan first and note the plan transaction
number (found at the bottom of the computed output). Then, enter the inputs for the outbound
plan and include the return leg plan number. This is done with a secondary input on the POA
Fuel command line.
Example:
16 POA FUEL A0,D45,PN=4386
Explanation: In this example, the departure fuel from plan number 4386 would be applied as
the maximum tanker quantity.
Errors or incorrect output figures can occur for the following reasons:
• If the plan number is entered incorrectly

• If the POA from the outbound leg does not match the POD from the second
leg.
• If the aircraft used in the outbound leg plan does not match the aircraft
entered on the second leg.
• If you attempt to incorporate both multi-sector tankering methods on the
same plan (for example, MAXT=value, PN=value). In this case, the more
restrictive of the two fuel values is used by JetPlan (the smaller amount is
tankered).
Example:
16 POA FUEL A0,D45,PN=4386,MAXT=23000
Explanation: In this example, assuming plan number 4386 has a departure fuel of 22560, the
plan amount is tankered because it is less than the MAXT value. If the plan number value is
more than the MAXT value, then the MAXT value would be tankered.

467
Automatic Weight Reiteration

The automatic weight reiteration option (autoweight) instructs JetPlan to recalculate the flight
plan if one or more of the aircraft’s structural limits are exceeded. JetPlan attempts several
iterations to produce a valid plan. If all recalculations prove unproductive, JetPlan finally
returns an error message that explains the problem. The AW option is entered on the Options
command line (Line 01)as follows: FP,AW.
Example:
01 OPTIONS FP,RC,AW,CS/JD123,CPT/S RAWLUK,DSP/S LEE,.FLT123/15.
NOTE If you want this feature applied all the time, the AW option can be stored in
your ID/Attribute record.
The following sections illustrate the standard iteration process of the autoweight feature. The
examples show the basic internal flow JetPlan uses to recalculate flight plans which have
exceeded a fuel/weight limit. Each flight case/load factor is examined individually with the
original flight plan inputs shown, followed by the subsequent internal iterations.
NOTE You can request that Jeppesen set your autoweight function in a non-
standard manner, where payload is maintained and extra fuel is the factor that is
adjusted. The examples below do not cover non-standard scenarios. Contact your
Jeppesen account manager for assistance.
Arrival Fuel Case

Example:
14 PAYLOAD XXXXXX or ZF
16 POD OR POA FUEL AXXXXX,(RES)
If plan exceeds landing weight (XLW), then:
Example:
14 PAYLOAD W
16 POD OR POA WT AM,(RES)
If plan exceeds max fuel (XMF), then:

468
Example:
14 PAYLOAD F
16 POD OR POA FUEL DM,(RES)
If plan exceeds takeoff weight (XTW), then:
Example:
14 PAYLOAD W
16 POD OR POA WT DM,(RES)
If plan exceeds zero fuel weight (XZFW), then:
N/A
If plan needs more burnable fuel (MBF), then:
N/A
Arrival Weight Case

Example:
14 PAYLOAD W or ZW
16 POD OR POA WT AXXXXXX,(RES) or AM,(RES)
If plan exceeds takeoff weight (XTW), then:
Example:
14 PAYLOAD W
If plan exceeds max zero fuel weight (XZFW), then:
Example:
14 PAYLOAD ZW
- or -
16 POD OR POA WT AXXXXXX,(RES)

469
Example:
14 PAYLOAD F
N/A
N/A
Departure Fuel Case

Example:
14 PAYLOAD XXXXX or ZF
16 POD OR POA FUEL DXXXXXX,(RES) or DM,(RES)
Example:
14 PAYLOAD W
Print error and stop
If plan exceeds zero fuel weight (XZFW), then:
N/A
N/A

470
Departure Weight Case

Example:
14 PAYLOAD W or ZW
16 POD OR POA WT DXXXX,(RES) or DM,(RES)
Example:
14 PAYLOAD W
If plan exceeds max zero fuel weight (XZFW), then:
Example:
14 PAYLOAD ZF
Example:
14 PAYLOAD F
Example:
14 PAYLOAD F
Print error and stop

471
Reclear Flight Plans And Landing Burnoff

The following items are pertinent to reclear flight plans when the automatic weight reiteration
feature is invoked:
LBO formats The landing burnoff calculation takes precedence over the automatic
weight recalculation. If one or both of the reclear flight plans exceed
the maximum landing weight, the excess weight is printed out as fuel
to be burned off in order to lower the landing weight to the maximum
landing weight.
Non-LBO formats The automatic recalculation feature allows JetPlan to calculate and
output reclear flight plans which would otherwise produce an “exceed
landing weight” (XLW) error. In this case, the following statement is
printed under the affected reclear flight plan(s).
*** WARNING LBO ASSUMED IN LANDING WEIGHT

CALCULATION *** 003456
Long range flight planning considerations for maximum payload: the first flight plan is
recalculated based on the maximum fuel capacity if a “2 HEAVY” or an “XMFXXXXXX”
error is generated without the automatic weight reiteration feature. However, the reclear plans
are calculated based on the maximum or specified takeoff weight if this gives a greater
payload.
Flight plan initially requested with inputs similar to the following inputs:
Example:
14 PAYLOAD ZW
- or -
14 PAYLOAD ZF
If JetPlan calculates a “2 HEAVY” or “XMFXXXXXX” error, then the flight plan is

automatically recalculated based on the following input.

472
Example:
14 PAYLOAD F
16 POD OR POA FUEL DM,I
The reclear flight plans can be recalculated using the maximum takeoff weight (or specified
takeoff weight) if this results in a higher payload than using a maximum fuel case.
Example:
14 PAYLOAD ZW

473
C HAPTER 15
Fuel Off/On and Payload

Off Commands
Fuel Off/On and Payload Off Commands
Overview
Overview
You can use the RF flight plan option to offload or onload fuel and to offload payload (cargo)
at one enroute waypoint. When you include the RF option on the 01 Options command line,
JetPlan automatically displays the 15 FUEL OFF/ON prompt, so you can provide the
waypoint and fuel or payload value. The following paragraphs describe these options in more
detail.
NOTE The RF flight plan option does not support onloading payload.
Offloading and Onloading Fuel

The RF flight plan option enables you to offload or onload fuel at one enroute waypoint.
Offloading Fuel
On the Fuel Off/On command line, type the name of the enroute waypoint, followed by a
comma and the fuel offload value expressed in hundreds of pounds or kilograms, depending
on your weight measure preference. Always precede the offload fuel value with a minus sign.
For example, -030 indicates that you want to offload 3,000 pounds (or kilograms) of fuel.
Example
Explanation: This example illustrates using the RF option to offload 5,000 pounds (or
kilograms) of fuel at the AVE waypoint.
01 OPTIONS FP,RF
15 FUEL OFF/ON AVE,-050
Onloading Fuel
On the Fuel Off/On command line, type the name of the enroute waypoint, followed by a
comma and the fuel onload value expressed in hundreds of pounds or kilograms, depending on
your weight measure preference. For example, 030 indicates that you want to onload 3,000
pounds (or kilograms) of fuel.

477
Fuel Off/On and Payload Off Commands
Offloading and Onloading Fuel
Example
Explanation: This example illustrates using the RF option to onload 5,000 pounds (or
kilograms) of fuel at the AVE waypoint.
01 OPTIONS FP,RF
15 FUEL OFF/ON AVE,050
Offloading Payload
You can also use the RF flight plan option to offload payload. The process of offloading
payload is just like the process of offloading fuel described on page 477, except that the letter
P must precede the offload payload value. For example, P-020 indicates that you want to
offload 2,000 pounds (or kilograms) of payload.
Example
Explanation: This example illustrates using the RF option to offload 5,000 pounds (or
kilograms) of payload at the AVE waypoint.
01 OPTIONS FP,RF
15 FUEL OFF/ON AVE,P-050

478
C HAPTER 16
Departure and Arrival

Bias Commands
Departure and Arrival Bias Commands
Overview
Overview
JetPlan provides several ways to bias the results of a flight plan. Most of the bias options can
be invoked for a specific flight by entering a value in the flight plan request. Of these options,
several have duplicate parameters in various customer databases that can be set for a more
permanent application.
Among the options available for biasing a flight are the departure and arrival biases that can be
set on the Climb Bias command line and the Descent Bias command line.These command
lines are Questions 18 and 19 in JetPlan line mode.
There are three types of departure and/or arrival biases: fuel, time, and distance. Each type can
be entered alone or combined with the other biases. If entering more than one bias value, the
order is not a concern. Typically, a multi-type departure or arrival bias input would be entered
as shown in the example below.
Example:
18 CLIMB FUEL,TIME,DIST BIAS fuel bias,time bias,distance bias
19 DESCENT FUEL,TIME,DIST BIAS fuel bias,time bias,distance bias
Departure and Arrival Biases and the Customer

Aircraft Database
Fuel, time, and distance biases for the climb and descent phases of flight can be set in the
Customer Aircraft database (CADB). The parameters AB and DB accept settings that address
all three types of biases. When a CADB record is entered on the A/C Type/Regn command
line, the bias settings in the database are used, and prompts for Questions 18 and 19 are not
displayed.
You can add to the CADB record settings by using the @ command at any question prompt to
call up Questions 18 and 19. For example, entering @18 takes you to the Question 18 prompt.
Inputs on these command lines add to the database settings for the flight plan. For example, if
a Departure Distance Bias of 100 nm is stored in the CADB, and a Question 18 command line
Departure Distance Bias (Climb Bias) of 100 nm is entered, the total Departure Distance bias
applied to the flight plan is 200 nm. For more information on databases and biases, see
“Combining Bias Inputs” on page 487. For more information on Flight Plan shortcuts, see
Chapter 2, “Option Commands.”

481
Climb/Descent Biases
The following sections review each bias type for the climb and descent phases of flight.
Climb/Descent Fuel Biases

When a fuel bias value is entered, there is a cost of carrying extra fuel weight that must be
considered in the flight plan calculation. In the case of a departure bias, the fuel totals for the
climb portion of the flight are not only increased by the bias amount, but also by the amount
necessary to carry the extra fuel. For example, a particular aircraft with a departure bias of
1,000 lbs can require an additional 30 lbs to carry it to TOC. In the case of an arrival bias, the
same holds true, except that the descent fuel total is increased by both the bias and the penalty
amount. Likewise, the fuel total for the enroute cruise portion of the flight is also affected
negatively.
NOTE The contention of an added fuel weight penalty can be proven by comparing
“arrival case” flight plans calculated with and without a bias. Use a format which does
not round-off segment fuel burn, such as the ZJ6 format, for this test.
To add a fuel bias to the climb and/or the descent phase of the flight, enter the letter, F,
followed by the fuel amount (in lbs or kgs) on the Bias command line.
Example:
Explanation: A departure fuel bias of 1,000 lbs/kgs.
18 CLIMB FUEL,TIME,DIST BIAS F1000
Explanation: An arrival fuel bias of 1,000 lbs/kgs.
19 DESCENT FUEL,TIME,DIST BIAS F1000
Climb/Descent Time Biases

When a departure time bias is entered, the amount is added to the climb table time. In turn, it is
also added to the cruise and descent time totals.
When an arrival time bias is entered, the amount is added to the descent table time. In turn, it is
also added to the climb and cruise time totals.

482
To add a time bias to the climb and/or the descent phase of the flight, enter the letter, T,
followed by a time value (in minutes) on the Bias command line.
Example:
Explanation: A departure bias of 10 minutes.
18 CLIMB FUEL,TIME,DIST BIAS T10
Explanation: An arrival bias of 10 minutes.
19 DESCENT FUEL, TIME, DIST BIAS T10
Climb/Descent Distance Biases

Distance biases affect the flight in a very specific way, depending on the computed distance
between the station (departure or arrival), the Top of Climb (TOC) or Top of Descent (TOD)
point, and the closest waypoint to the station. For this reason, the two flight phases (climb and
descent) are discussed separately.
Climb Distance Biases

When a climb distance bias is entered, the departure airport is “extended” from the first
waypoint by the bias amount. This bias value does not change the distance to Top of Climb
(TOC), but it does add the bias amount to the total flight plan distance.
Three climb bias scenarios are discussed below. In the first scenario, TOC occurs before the
first waypoint. In the second scenario, TOC occurs after the first waypoint. In the third
scenario, a percent or integer bias is applied to the climb distance to “flatten” the climb profile
without adding additional distance to the flight plan.
NOTE In order to flatten a climb profile without adding distance to the flight plan, the
distance bias must be entered on the Cruise Mode command line instead of the Climb
Fuel, Dist, Time Bias command line. See Chapter 11, “Cruise Mode Commands.”

483
Climb Bias - TOC Before First Waypoint

To illustrate the first scenario, assume a particular flight plan computes a 70 nautical mile (nm)
distance between the departure station and TOC. It is another 30 nm to the first waypoint.
Thus, the total distance to the first waypoint is 100 nm.
TOC Waypoint #1
POD
70 30
100
If a 50 nm climb distance bias is entered:
Example:
18 CLIMB FUEL,TIME,DIST BIAS D50
The departure airport is “extended” 50 nm from the first waypoint; hence, it is now 150 nm to
the first waypoint. Since TOC still occurs after 70 nm, the distance between TOC and the first
waypoint is now 80 nm – an increase of 50 nm.
Waypoint #1
TOC TOC old
POD (distance bias)

50 70 30
70 80
150

484
Climb Bias - TOC After First Waypoint

To illustrate the second scenario, assume a particular flight plan computes a 70 nm distance
between the departure station and TOC. The first waypoint is 10 nm from the departure airport
and the second waypoint is 100nm from the departure airport. The distance between the first
waypoint and TOC is 60 nm, and the distance from TOC to the second waypoint is 30 nm.
TOC Waypoint #2
Wa ypoint #1
POD
10 60 30
70
100
If a 50 nm departure bias is entered (see previous example), the departure airport is “extended”
50 nm from the first waypoint; hence, it is now 60 nm to the first waypoint. Since TOC still
occurs after 70 nm, the distance between the first waypoint and TOC is now 10 nm. The
distance between TOC and the second waypoint is now 80 nm – an increase of 50 nm.
Waypoint #2
TOC TOC old
Waypoint #1
10
POD (distance bias)

50 70 30
70 80
150
Climb Bias - Flattening Climb Profile

To illustrate the third scenario, use the waypoint and TOC distances from the second scenario.
In this scenario, however, the desired result is to “flatten” the climb profile without adding
distance to the flight plan. This is accomplished by biasing the climb distance either by a
percentage or an integer amount of the normal climb distance. For this illustration, the climb is
biased by an additional 20 nm.

485
This is the profile without the additional 20 nm bias:
TOC Waypoint #2
Wa ypoint #1
POD
10 60 30
100
When the climb profile is flattened by 20 nm, TOC occurs 20 nm further down the route of
flight. No other distances, relative to the non-biased profile, are changed. Thus, the distance
between the first waypoint and TOC is now 80 nm instead of 60 nm, and the distance between
TOC and the second waypoint is now 10 nm instead of 30 nm. The total distance from the first
and second waypoint do not change.
Example:
11 CRZ MODE M85,CD=20
Waypoint #2
TOC old TOC
Wa ypoint #1
20
(distance bias)
POD
10 80 10
100
Descent Distance Biases

When a descent distance bias is entered, the arrival airport is “extended” by the amount of the
bias from the last waypoint before Top of Descent (TOD). It does not change the distance
between TOD and the arrival airport. However, it does add the bias amount to the total flight
plan distance.

486
To illustrate an arrival distance bias, assume a particular flight plan computes a 120 nm
distance between TOD and the arrival airport. Without an arrival bias, it is 10 nm from a
waypoint to TOD. It is 60 nm from TOD to the last waypoint, and it is another 60 nm from the
last waypoint to the arrival airport.
Waypoint X
TOD
Wa ypoint Y
POA
10 60 60
120
If a 50 nm descent distance bias is entered...
Example:
19 DESCENT FUEL,TIME,DIST BIAS D50
The waypoint preceding TOD (Waypoint X) is now 60 nm to TOD. Now it is only 10 nm from
TOD to the next waypoint, and it is 110 nm from this waypoint to the arrival airport. The total
distance from TOD to the airport has not changed.
Waypoint X Waypoint Y
TOD old TOD
10
POA
60 60 50
10 (distance bias)
60 110
120
Combining Bias Inputs

Departure and arrival biases can be combined to comply with your operational requirements.
Illustrated below are examples of combining bias inputs.

487
Interaction Between Bias Database Settings
Example:
Explanation: Departure biases of 1,000 lbs/kgs, 10 minutes time, and 30 nm distance.
18 CLIMB FUEL,TIME,DIST BIAS F1000,T10,D30
Explanation: Arrival biases of 750 lbs/kgs fuel, 5 minutes time, and 10 nm distance.
19 DESCENT FUEL,TIME,DIST BIAS F750,T5,D10
Interaction Between Bias Database

Settings
As stated previously, certain biases can be set in particular customer databases to produce the
expected results anytime the database file is applied in a flight plan request. There are bias
parameters in the MEL Database, the CADB, the Route Database (CRDB), and the Schedule
Database (CSDB).
NOTE The biases set in the Schedule database are typically those biases applied in
a flight plan request on an ad hoc basis. Therefore, these biases are not really
parameter settings as much as they are previously stored flight plan request settings.
The following rules define the interaction between bias settings in different databases when
applied to a flight plan request.
NOTE Typically, ad hoc bias inputs (those inputs for a single plan request) are
generally cumulative to any database setting.
• When both a CADB file and a CSDB file are entered into a flight plan
request on the Options command line, the biases stored in the CADB file are
added to the biases in the CSDB file. The CADB bias information does not
override or delete the CSDB bias information.
Example:
01 OPTIONS SC,FLT,SKEDDB,$ACFTDB, (plus any other inputs)

488
Interaction Between Bias Database Settings
• When a CADB file is entered on the Aircraft Type command line, the biases
stored in the CADB file override any biases built into a CSDB file. This
includes the case where the CADB file contains no bias information at all. In
this case, no bias information is passed to the flight plan request.
Example:
01 OPTIONS SC,FLT,SKEDDB
10 A/C TYPE/REGN $ACFTDB
11 CRUISE MODE LRC
• When a CADB file and a MEL database file containing bias information are
used in the same flight plan request, the bias values from the MEL database
are added to the corresponding bias values in the CADB to produce a sum
bias amount that might be more than anticipated. For example, if a CADB
file has a fuel flow bias (such as the Holding Fuel Flow parameter, HF) of
2.5% and a MEL file has a fuel flow bias of 1.3%, the total fuel flow bias for
the flight plan if both database files are applied, is 3.8% (albeit for the
Holding portion of the flight calculation).

489
C HAPTER 17
Message Commands
Message Commands
Creating Messages
Creating Messages
JetPlan provides a messaging capability which allows you to compose a textual message for
transmission by itself or as part of a package of products from JetPlan. (For information on
transmitting messages (or any other non-graphic JetPlan product), see Chapter 18, “Forward
Plans and Messages.”)
To invoke JetPlan’s message composer program, type the command, MG, on the Options
command line and press ENTER. JetPlan responds with the Enter Message command line,
which includes a number that identifies the transaction. Immediately below the Enter Message
command line is the first input line (line 1 of your message). This is the spot where you begin
typing your message.
You can type up to 68 characters, including spaces, per input line. If you exceed that character
total, the line of text is ignored, and the message composer is terminated. If this happens, any
text entered on previous input lines that did not exceed the character limit is saved as the
message transaction, whether it is a complete message or not. If you exceed the character total
on the first input line, the text is ignored and the message composer is terminated without
anything saved at all.
After typing a line of text (not to exceed 68 characters, including spaces), press the ENTER
key. JetPlan responds with the next input line. You can continue this process until your
message is complete (not to exceed 55 lines). Once done, you can terminate the message
composer by pressing ENTER at the beginning of the next input line (before typing any
characters). The message is saved, and you can retrieve the contents by referencing the
transaction number. The following example illustrates a proper message transaction. User
inputs are highlighted.
Example:
01 OPTIONS MG <ENTER>
02 ENTER MESSAGE 1234
1- ATTN DEN OPS <ENTER>
2- FROM SMITH/JFK DISPATCH <ENTER>
3- PLEASE ADV OUTBOUND FLT123 CREW THAT<ENTER>
4- NMBR 2 AUTOPILOT OTS <ENTER>
5- REGARDS SMITH <ENTER>
6- <ENTER>
END OF JEPPESEN DATAPLAN REQUEST NO. 1234
01 OPTIONS (JetPlan is ready for next product request)
NOTE Messages are limited to a maximum of 55 lines of text. Lines of text are
limited to a maximum of 68 characters, including spaces.

493
Message Commands
Creating Messages
Packaging JetPlan Products in Messages

Previously composed message transactions, flight plans, and weather briefings (any non-
graphic JetPlan product) can be appended to any new message transaction by using the
/INCLUDE option. To do this, type the input, /INCLUDE ####, on any message input line.
The value after the /INCLUDE option is a JetPlan product transaction number. Finish the new
message by pressing ENTER on the next empty input line. The saved message is whatever text
is written and the contents of the referenced inclusions. You can print the new message to see
all of the contents or transmit the message as a package of information.
For example, assume you have computed a flight plan (transaction #1450) and a weather
briefing (#1477) and now want to package these products within a new message. Use the
/INCLUDE option to reference those products as inclusions to the new message.
Example:
01 OPTIONS MG
1- ATTN DEN GATE AGENT
2- FROM SMITH/JFK DISPATCH
3- PLEASE DELIVER FOLLOWING FLT PLN
4- AND WX BRIEF TO FLT CREW FOR JD123
5- REGARDS SMITH
6- /INCLUDE 1450
7- /INCLUDE 1477
8- <ENTER>
COMPLETED
To print the contents of message transaction #1520, use the Print (transaction) Number
command on the Options command line.
Example:
01 OPTIONS PN1520
The contents of message #1520 shows whatever text message you created plus the contents
(output) from flight plan #1450 and weather briefing #1477.
Likewise, when message #1520 is forwarded via a communications network (for example,
SITA or AFTN), the text message, flight plan, and weather briefing are transmitted as a
package of information.

494
Message Commands
Creating Messages
Combining Products Using the MG Option

Similar to the /INCLUDE option described above, you can append a message to the end of
another JetPlan non-graphic product, such as a flight plan, by adding the transaction number of
that product to the MG command and then typing your message.
NOTE Appending a text message to the end of another product tends to result in the
message being overlooked. Hence, the /INCLUDE option is a better method for
packaging products.
To add a message to the end of a flight plan (or other product), type the MG command
followed by the plan (or other product) transaction number (and then type your message).
Example:
01 OPTIONS MG9222
02 ENTER MESSAGE
1- PLEASE HOLD FOR CAPT. RUDY WITH JDI AIRWAYS
2- REGARDS
3- SMITH / JFK DISPATCH
4- <ENTER>
COMPLETED
JetPlan does not assign a separate transaction number to this message, because the message is
now part of another transaction (for example, flight plan #9222).
Similarly, any non-graphic JetPlan product can be appended to other products by using the
MG command. For example, assume you have computed a weather briefing (#5678), and you
want to append that briefing to a previously computed flight plan (#1234). Use the MG
command to package the two products together as shown below.
Example:
01 OPTIONS MG1234,5678
COMPLETED
NOTE Transactions are packaged in the order listed. In the above example, the
contents of transaction #5678 are added to the end of the contents of transaction
#1234.

495
Message Commands
Creating Messages
Message No Number - MGNN

You can suppress the message transaction number by adding the “No Number” option, NN, to
the MG command. This option is useful with certain message trafficking facilities that lack the
capability to recognize JetPlan transaction numbers. Eliminating the transaction number
allows these facilities to process transmitted messages without getting stuck on
unrecognizable numbers. A transaction number is still created, but is not displayed when the
message is printed or forwarded.
Example:
01 OPTIONS MGNN
1- 5GL SA 2250 M60 BKN 95 OVC 7RW- 170/64/61/2406/003/RB35
2- <ENTER>
COMPLETED

496
C HAPTER 18
Forward Plans and

Messages
Forward Plans and Messages
Overview
Overview
JetPlan’s forwarding capability provides the means to transmit any recently computed non-
graphic JetPlan product—including flight plans, messages, and text weather briefings—via
any of three standard aviation communication networks (AFTN, ARINC, and SITA),
facsimile, or ACARS uplink.
NOTE Transmission via email is available through various user interfaces such as
JetPlanner and JetPlan.com
AFTN, ARINC, and SITA Designators and

Priority Codes
The designators for the AFTN, ARINC, and SITA networks are option commands that define
the service by which data is to be transmitted. These designators are the opening input on the
Options command line. The designator input is typically followed by the transaction number
of the product you wish to transmit, the priority code, and the network address or addresses to
which the product is to be sent.
Example:
01 OPTIONS NetworkDesignator(xactn #),PriorityCode Address1 Address2
NOTE If you specify more than one line of network addresses (destinations), the
current line must end with a space followed by a comma, and the next line must begin
with a space. You can begin the next line with the letter “A,” followed by a space, to be
consistent with flight plan filing.

499
AFTN, ARINC, and SITA Designators and Priority Codes
The table below shows the network designators for AFTN, ARINC and SITA.
Table 18-1 Network Designators (AFTN, ARINC, SITA)
Command Network
AF AFTN
AR ARINC
SI SITA
Priority codes define the timeliness of the transmission (how quickly the data or message
reaches the destinations). SITA and ARINC have priority codes in common, AFTN accepts
slightly different priority codes. These codes and their definitions are shown below.
Table 18-2 Priority Codes (SITA, ARINC)
Code Definitions
QU Urgent message. SITA guarantees delivery within 1
hour. SITA charge is twice normal.
QN or QK Normal message. SITA guarantees delivery within 3

hours.
QD Deferred message. SITA guarantees delivery within

24 hours. SITA charge is 2/3 normal.
Table 18-3 Priority Codes (AFTN)
Code Definitions
DD Priority operations and circuit control data
FF Administrative data of a directive nature; flight

movement and control messages
GG Administrative data of a routine nature;

meteorological and notam data
AFTN Circuit
When forwarding data via an AFTN circuit, a maximum of six addresses can be specified. To
transmit a JetPlan transaction via AFTN, enter the following on the Options command line: the
network designator (AF) immediately followed by the transaction number of the JetPlan
product you wish to send, a comma, the priority code followed by a space, and finally, one or

500
more addresses (each separated by a space). In the example below, transaction number 1234 is
transmitted via AFTN using the administrative directive priority to the three addresses
specified.
Example:
01 OPTIONS AF1234,FF KSFOXLDI EGKKJPNX KBGRXHYR
ARINC Circuit
When forwarding data via an ARINC circuit, a maximum of 18 addresses can be specified. To
transmit a JetPlan transaction via ARINC, follow the conventions established above. Be sure
to use the ARINC designator (AR) and the correct priority code. In the example below,
transaction number 1245 is transmitted via ARINC as an urgent message to the two addresses
specified.
Example:
01 OPTIONS AR1245,QU PAOYRXH LGWMKXH
SITA Circuit
When forwarding data via an SITA circuit, a maximum of 18 addresses can be specified.
Follow the previous input conventions to transmit a JetPlan transaction via SITA. Be sure to
use the SITA designator (SI) and the correct priority code. In the example below, transaction
number 1234 is transmitted via SITA as an urgent message to the four specified addresses.
Example:
01 OPTIONS SI1234,QU PAOJD7X DENJS7X LGWJD7X NRTJD7X
Fax Forwarding
JetPlan’s Fax Forwarding feature provides expanded capabilities over forwarding transactions
via one of the standard aviation networks. Among these features are the capability to transmit
several products at one time and the ability to include graphic weather products (maps) in the
transmission.

501
To forward JetPlan transactions via fax, enter the following on the Options command line:
• Fax designator (FX)

• Fax phone number (include the international calling code, country code and
city code, area code, or whatever is necessary and applicable)
• JetPlan transaction number(s)
• Any other applicable option (see below)
Commas separate each entry. One fax number and as many JetPlan transaction numbers that
can fit on the Options command line (240 characters including spaces) can be specified in a
single request.
NOTE To obtain detailed instructions on the use of Fax Forwarding, type INFO,FAX
on the Options command line. To obtain a list of all weather maps available for
forwarding via fax, type INFO,MAPS on the Options command line.
Basic Fax Forwarding Input

The examples below illustrate the use of the basic Fax Forwarding commands.
Example:
Explanation: U.S. Domestic. Fax number includes area code.
01 OPTIONS FX,3037844416,5678,5679,US10,NA10,.NAME.
Example:
Explanation: International. Fax number includes international calling code, country and city
code.
01 OPTIONS FX,011469996831897,5678,5679,US10,NA10,.NAME.
The following list identifies all of the inputs shown in the above examples.
• FX – Fax Forwarding command.

• 011469996831897 – Complete fax number. International numbers must
begin with 011, followed by country code, city code, and number.

502
• 5678,5679 – Two sample JetPlan transaction numbers. These could identify

computed flight plans, non-graphic weather briefings, and/or user-generated
messages.
• UA10,NA10 – Two sample graphic weather map codes.
• .NAME. – Optional identification input. You can enter a name up to 30
characters long that appears on the fax cover sheet.
NOTE The optional identification input must be contained within two periods (for
example, .John Smith.) A single page fax can display two maps by using a slash (/)
between the map code entries instead of a comma.
Enhanced Fax Forwarding Input

Fax Forwarding provides other features which allow you to more clearly identify and control
the composition of the information you are sending. These features give you the following
capabilities:
• Data/information composition or order

• Cover sheet suppression
• Custom cover sheet inclusion
• Fax status querying (also available for basic fax)
• Multiple recipient (phone number) transmissions
• Expanded (free form) text capability for phone numbers, recipients, flight
plans, text weather reports, maps, and messages using appropriate/valid
keywords (prefix codes)
The following syntax rules are unique to the enhanced Fax Forwarding input:
• Blank spaces are equivalent to commas as delimiters.

• A single page fax can display two maps by using a slash (/) between the map
code entries instead of a comma.
• Both blank spaces and commas are allowed within the recipient's name and
title.
• The name/title keyword TO= is terminated by a period or another keyword.

503
• To support terminals that do not have an equal sign (=), a hyphen (-) is
equivalent to an equal sign for all keywords.
• Flight plans, non-graphic weather, and messages can be specified after the
FLIGHT and FP keywords. The MESSAGE, MG, and MS keywords can be
used interchangeably with the FLIGHT and FP keywords.
The following table lists keywords that you can apply when using the Enhanced Fax
Forwarding feature.
Table 18-4 Fax Forwarding Keywords
Keyword Type Purpose Keywords

Recipient Name/Title Specifies the name or name and • TO=
title of the recipient. Enter the • TO-
information after one of the
keywords.
Flight Plan Specifies transaction number(s) for • FLIGHT=
flight plans, text weather reports, • FP=
and messages. Enter the number or
• FP-
numbers after one of the
keywords.
Message Specifies the same transaction • MESSAGE=
types as listed above for Flight • MG=
Plan. Enter the number or numbers
• MG-
after one of the keywords.
• MS=
• MS-
Weather Map Specifies maps. Enter the map • MAPS=

identifier(s) after one of the • MAPS-
keywords.
• MAP=
• MAP-
Phone Number Specifies a phone number. Enter • PHONE=

the phone number after one of the • PHONE-
keywords.
• PH=
• PH-
Cover Sheet Suppress Suppresses the printing of the Fax • COVER=NO

Forwarding cover sheet. Enter NO • COVER-NO
after one of the keywords.

504
Table 18-4 Fax Forwarding Keywords (continued)
Keyword Type Purpose Keywords

Cover Sheet Specifies a custom cover sheet. • COVER=
Enter the cover sheet name after • COVER-
one of the keywords.
• CV=
• CV-
• CS=
• CS-
NOTE Custom cover sheets must
be provided by you to Jeppesen so
that it is on file for this purpose.
Contact your Jeppesen account
Fax Query Allows you to enquire about a FX QUERY

previously sent fax. After the
keyword, enter the transaction
number provided by JetPlan when
the fax is forwarded.
The following examples illustrate the use of the keywords defined in the preceding table:
Example:
01 OPTIONS FX PHONE=4088665648 TO=CAPT DON SMITH JEPPESEN
MAPS=USRA/US10 MESSAGE=4379 FLIGHT=2432
Example:
01 OPTIONS FX,PH-011469996831,PH-3037844112,TO-CAPT. JIM SMITH,
JEPPESEN,TO-FLT OPS/DEN,FP-2345,FP-2347,COVER-NO
Example:
01 OPTIONS FX QUERY=12345 (where 12345 is the fax transaction number)

505
ACARS Uplink
ACARS Uplink
The ACARS Uplink feature allows you to forward flight plans or messages directly to the
aircraft via an ACARS network.
NOTE Presently, special services must be set up or in place before you can uplink a
flight plan. Please contact your Jeppesen account manager for more information. The
uplink of messages does not require any special setup.
To forward a JetPlan transaction using the ACARS Uplink feature, use the following input
syntax on the Options command line:
01 OPTIONS ul,[dn],1234,[fm],[rg=tail#]
where:
• ul is the ACARS Uplink command.

• dn is the uplink network, either (AR)INC or (SI)TA.
• 1234 represents a JetPlan transaction number. In this case, 1234 is the
example transaction number.
• fm is the (Flight Management System) FMS type aboard the aircraft. This
input is optional if you preset the FMS type parameter in the Customer
Aircraft Database (CADB) for the aircraft being used (for example,
FY=UF). The three choices are:
– UF = Universal Unilink FMS
– SF = Smith Industries FMS
– HF = Honeywell FMS
• rg=tail# is the aircraft’s registration or tail number. When uplinking flight
plans, this input is optional only if you preset the Registration Number
parameter in the CADB for the aircraft being used (for example,
RN=n12345). However, if the aircraft does not have a preset registration
number or is not in the CADB at all, you must include this option.
NOTE If you omit the registration number when it is required, JetPlan prompts you
for the information.

506
ACARS Uplink
The following examples demonstrate the various entries you can make with the ACARS
Uplink feature.
Example:
Explanation: This is a free-text message example. A message is first created on the JetPlan
system. The transaction number is then used in the uplink input. Note that the network is not
specified, meaning that the uplink is via ARINC.
01 OPTIONS mg
1- test of uplink message method
2-
END OF JEPPESEN DATAPLAN REQUEST NO. 1234
.........
01 OPTIONS ul,1234,uf,rg=ntest
20 COMPUTING
.........
MESSAGE 1234
TEST OF UPLINK MESSAGE
.........
MESSAGE #1234 HAS BEEN FORWARDED VIA ARINC FOR UPLINK TO NTEST
Example:
Explanation: Uplink of the same message as in the previous example but without the “rg=”
option. In this case, JetPlan prompts for the tail number.
01 OPTIONS ul,1234,uf
02 TAIL NUMBER ntest
20 COMPUTING
.........
MESSAGE 1234
TEST OF UPLINK MESSAGE
.........
MESSAGE #1234 HAS BEEN FORWARDED VIA ARINC FOR UPLINK TO NTEST

507
ACARS Uplink
Example:
Explanation: This is a flight plan example. The flight plan1234 is uplinked via ARINC
ACARS to an aircraft that uses a Universal FMS, and has a tail number, NTEST.
01 OPTIONS ul,ar,1234,uf,rg=ntest
20 COMPUTING
..........
FPN/RP:DA:KSFO:AA:KBOS:F:LIN,N38045W121002.J84..OBK,N42133W087571.
J584..CRL,N42029W083275.J554..JHW,N42113W079073.J82..ALB,
N42448W073482:A:GDM2.ALB
.........
PLAN #1234 HAS BEEN FORWARDED VIA ARINC FOR UPLINK TO NTEST
Example:
Explanation: Same as previous example except that the FMS type and registration number
information comes from the aircraft’s CADB record.
01 OPTIONS ul,1234
20 COMPUTING
..........
FPN/RP:DA:KSFO:AA:KBOS:F:LIN,N38045W121002.J84..OBK,N42133W087571.
J584..CRL,N42029W083275.J554..JHW,N42113W079073.J82..ALB,
N42448W073482:A:GDM2.ALB
.........
PLAN #1234 HAS BEEN FORWARDED VIA ARINC FOR UPLINK TO NTEST

508
Character Length Control
Character Length Control

When using the forwarding option, you can specify the number of characters that JetPlan
sends with each flight plan, weather request, and message. JetPlan stores default character
numbers for each communication service. However, these can be changed in your password
attribute file as long as the numbers do not exceed the maximum or minimum length. A non-
default value can be specified during a print and forward request by indicating the character
control number after the last address for each communication service.
Example:
01 OPTIONS SI4577,QU DENJS7X PAOJD7X/2300
Example:
01 OPTIONS AF4578,FF KSFOXLDI EGKKJPNX/1600
The default, maximum, and minimum character counts are listed in the following table.
Table 18-5 Character Length Control Limits
Comm Service Default Value Maximum Value Minimum Value

AFTN 1200 1800 800
ARINC 2900 3500 1000
SITA 2500 3500 1000

509
C HAPTER 19
ATC Filing
ATC Filing
Overview
Overview
IMPORTANT The Jeppesen cutover to the ICAO 2012 Filed Flight Plan (FPL)
format occurred on November 14, 2012 at 14:00Z. All flight plans filed with Jeppesen
flight planning products are now filed in the ICAO 2012 format by default.
IMPORTANT This document assumes a working knowledge of the “Procedures for

Air Navigation Services — Air Traffic Management, Fifteenth Edition (PANS-ATM,
DOC 4444),” which describes the ICAO 2012 FPL requirements in detail. Also, see
“ICAO 2012 Flight Plan Filings” on page 535.
This chapter discusses the commands, options, and databases available on JetPlan for the
purpose of filing flight plan information with Air Traffic Control facilities.
Two kinds of fight plan filings are possible:
ICAO 2012 filings This became JetPlan’s standard format for ICAO filings when
Jeppesen cut over to the ICAO 2012 FPL format on November 14,
2012. All flight plans filed with Jeppesen flight planning products are
now filed in the ICAO 2012 format by default.
U.S. Domestic The default filing format within the USA is domestic (NAS FP). Your
filings account must be configured to allow you to file in the ICAO filing
format inside the USA. Contact your Jeppesen account manager for
more information.
NOTE The NAS FP was not impacted by the cutover to the ICAO 2012 FPL format.
The following sections provide more information about using JetPlan to file flight plans:
• “JetPlan Automatic Filing Program” on page 514

• “ICAO 2012 Flight Plan Filings” on page 535
• “Domestic U.S. Filing” on page 553

513
ATC Filing
JetPlan Automatic Filing Program

format occurred on November 14, 2012. All flight plans filed with Jeppesen flight
planning products are now filed in the ICAO 2012 format by default.
The automatic filing command, FI, allows you to submit flight plans to the proper ATC
authorities for both U.S. Domestic and ICAO flights.
Filing a Flight Plan

To file a flight plan, type FI followed by the flight plan number (transaction number) on the
Options command line. In the following example, a flight plan with the number 1234 is filed.
01 OPTIONS FI1234
NOTE The command and the transaction number are not separated by comma or
space.
Entering the File (FI) command initiates the JetPlan Automatic Filing Program, which
presents a series of command prompts that require your response with specific information
about the flight. Much of the information requested at the prompts can be derived from the
CADB or other repositories. (See “Database Support for the Filing Program” on page 530.)
Some of the information is transferred from the flight plan. In either case, JetPlan can retrieve
the needed information automatically and, thus, preempt your manual input. You always have
the option of overriding stored information if necessary. The possible prompts are:
02 AIRCRAFT ID OR CALL SIGN

04 TYPE OF FLIGHT
07 WAKE TURBULENCE CATEGORY
09 EQUIPMENT
12 PROPOSED DEPARTURE TIME
18 REMARKS/GENERAL INFORMATION
20 1ST ALTERNATE AIRPORT
21 2ND ALTERNATE AIRPORT
24 ENDURANCE
25 PERSONS ON BOARD
26 COLOR OF AIRCRAFT
27 EMERGENCY RADIO
28 SURVIVAL EQUIPMENT
29 LIFE JACKETS

514
ATC Filing
30 DINGHIES
31 FILED BY
33 DEPARTURE CENTER
NOTE The command prompts listed above are for ICAO 2012 filings. The command
prompts for Domestic flight plans vary somewhat. See Table 19-1, “JetPlan Automatic
Filing Program Command Prompts,” on page 516.
The Filing Program Command Prompts

Table 19-1, “JetPlan Automatic Filing Program Command Prompts,” on page 516 lists the
command prompts and the source of the associated data.

515
ATC Filing
Table 19-1 JetPlan Automatic Filing Program Command Prompts
Command Prompt Data Source and Notes

02 AIRCRAFT ID OR CALL For U.S. Domestic flights, you can store the domestic call sign in the
SIGN (ICAO Item 7) CADB (DO parameter). If you use the Call Sign option (CS/xxxxxx) in
the flight plan request, the filing program retrieves the sign from the
flight plan, regardless of the type of filing (U.S. domestic or ICAO).
NOTE ARTCCs/ACCs accept no more than 7 characters.
04 TYPE OF FLIGHT (ICAO (Required) Specifies the type of flight the aircraft typically performs.
Item 8) This information is derived from the CADB, if a value is available in the
Type of Flight (TF) parameter. Otherwise, enter the appropriate
information.
06 TYPE OF AIRCRAFT Specifies the Aircraft ICAO code of the aircraft. This information is
(ICAO Item 9) derived from the CADB, if a value is available in the Aircraft ICAO
Code (KO) parameter.
07 WAKE TURBULENCE Typically not prompted because the category value is set in the aircraft’s
CATEGORY (ICAO Item 9) generic file and is included in the filing form automatically. It can also be
derived from the Aircraft ICAO Code (KO) parameter in the CADB. You
can also edit the value manually using this command prompt.
08 SPECIAL EQUIPMENT NOTE This command prompt is not used for ICAO filings. It applies only
(U.S. Domestic) to U.S. Domestic filings.
(Required for Domestic filings) Identifies the aircraft’s special Nav/Com
capabilities. This information is derived from the USA Equipment Suffix
(EQ) parameter in the CADB.
09 EQUIPMENT (ICAO Item Lists the (10a) radio communication, navigation, approach aid equipment
10a/b) and capabilities, as well as the (10b) surveillance equipment and
capabilities of the flight.
Item 10a/b changed significantly for ICAO 2012 filings. There are new
codes for Items 10a and 10b, and new dependencies between Item 10 and
Item 18. See individual ICAO 2012 indicator descriptions in this table.
See also “ICAO 2012 Changes to Item 10a/b and Item 18” on page 536
and for data input restriction information.

516
ATC Filing
Table 19-1 JetPlan Automatic Filing Program Command Prompts (continued)

09 EQUIPMENT (ICAO Item Input values: Codes selected from the lists below. 10a Equipment codes
10a/b) are entered as a single, concatenated string before the “/” indicator and
10b Surveillance Equipment codes are entered after the “/” indicator. If
“S” is used in 10a, it is listed first.
Example:
SABCDHJ2KM2RT/CHU2
With a few exceptions (noted below), Item 10a/b is automatically
populated by the 10a/b EQUIPMENT (NC2) parameter in the “ICAO
2012 Certification and Equipment” section of the CADB.
NOTE The application of degradations to RNAV, RVSM, RNP, and
MNPS (NAT HLA) in the MEL database overrides the settings for these
items in the CADB and removes their designators from Item 10a of the
ICAO filing strip. See the Help file for the MEL DB on JetPlan.com or see
Chapter 38, “Minimum Equipment List Database.”
NOTE If the plan is sent to an AFTN center, the 10a/b EQUIPMENT
parameter is limited to the first 69 characters (including the / indicator).
EQUIPMENT 10a codes
• S – Standard COM/NAV/approach aid equipment is carried and

serviceable.
Standard Equipment is considered to be:
V (VHF) + O (VOR) + L (ILS)
NOTE If “S” is used, it is listed first in the EQUIPMENT field. Otherwise,
the flight plan might be rejected. For example, SDGI.
NOTE Code “S” or code “O” is required in Item 10a when Item 18 PBN/
contains certain descriptors. See “ICAO 2012 Changes to Item 10a/b and
Item 18” on page 536.
• N: No COM/NAV/ approach aid equipment or the equipment is

unserviceable.
NOTE If N is present, no other equipment is accepted.
• A – GBAS
Refers to GBAS landing system
• B – LPV
Refers to LPV (APV with SBAS)
• C – LORAN C
NOTE “C” is required in Item 10a when Item 18 PBN/ contains certain
descriptors. See “ICAO 2012 Changes to Item 10a/b and Item 18” on
page 536.

517
ATC Filing

EQUIPMENT 10a codes • D – DME
(continued) NOTE “D” is required in Item 10a when Item 18 PBN/ contains certain
page 536.
• E1 – FMC WPR ACARS
• E2 – D FIS ACARS
• E3 – PDC ACARS
• F – ADF
• G – GNSS
NOTE “G” is required in Item 10a when Item 18 PBN/ contains certain
descriptors. When “G” is in Item 10a, additional types of external
augmentation, if any, can be specified in item 18 following NAV/ and
separated by a space. See “ICAO 2012 Changes to Item 10a/b and Item
18” on page 536.
• H – HF RTF
• I – Inertial Navigation
NOTE “I” is required in Item 10a when Item 18 PBN/ contains certain
page 536.
• J1 – CPDLC ATN VDL Mode 2
• J2 – CPDLC FANS 1/A HFDL
• J3 -CPDLC FANS 1/A VDL Mode A
• J4 – CPDLC FANS 1/A VDL Mode 2
• J5 – CPDLC FANS 1/A SATCOM (INM)
• J6 – CPDLC FANS 1/A SATCOM (MTS)
• J7 – CPDLC FANS 1/A SATCOM (IRID)
• K – MLS
• L – ILS
NOTE L – ILS is considered Standard Equipment (S).
• M1 – ATC RTF SATCOM (INMARSAT)
• M2 – ATC RTF (MTSAT)
• M3 – ATC RTF (Iridium)

518
ATC Filing

EQUIPMENT 10a codes • O – VOR
(continued) NOTE O – VOR is considered Standard Equipment (S).
NOTE “O” is required in Item 10a when Item 18 PBN/ contains certain
page 536.
• Required Communication Performance: P1, P2, P3, P4, P5, P6, P7,
P8, and P9
• R – PBN Certified
Indicates that the aircraft has Performance Based Navigation (PBN)
capabilities. “R” is inserted in Item 10a when the PBN Certified (I1)
parameter in the “ICAO 2012” section of the CADB is set to “Yes.”
IMPORTANT The insertion of “R” in field 10a requires that the PBN
levels must also be specified after the PBN/ indicator in Item 18.
Otherwise, the flight plan might be rejected. See the Performance-Based
Navigation Manual (ICAO Doc 9613) for guidance on application of PBN
levels. See “ICAO 2012 Changes to Item 10a/b and Item 18” on page 536.
NOTE The application of a degradation to PBN certification in the ICAO
2012 section of the MEL Database overrides the R - PBN Certified value in
the CADB and removes the “R” designator from Item 10a in the ICAO filing
strip. For more information, see the Help topic for the MEL Database in
JetPlan.com or Chapter 35, “Minimum Equipment List Database.”
• S – See “S – Standard Equipment” above.
• T – TACAN
• U – UHF RTF
• V – VHF RTF
NOTE V – VHF RTF is considered Standard Equipment (S).
• W – RVSM
This field is populated from the RVSM Certified (RV) parameter in
the “Certified” section of the CADB.
• X – MNPS (NAT HLA) Approved

This field is populated from the MNPS Equipped (ME) parameter in
the “Certified” section of the CADB.
NOTE MNPS Equipped is being renamed “NAT HLA” in 2016.
• Y- VHF with 8.33 KHz channel spacing capability

This field is populated from the 8.33 KHz Communication (83)
parameter in the “Equipment” section of the CADB.

519
ATC Filing

EQUIPMENT 10a codes • Z – Other Equipment Carried or Other Capabilities
(continued) Indicates the presence of other equipment or capabilities not
specified in Item 10a.
“Z” is automatically inserted into Item 10a on the filing strip if the
Other Equipment (OE) parameter in the “ATS Plan” section of the
CADB is populated.
IMPORTANT If you enter code “Z” in Item 10a, you also must specify the
other equipment carried or other capabilities in Item 18, preceded by
COM/, NAV/, or DAT/, as appropriate. See “ICAO 2012 Changes to Item
10a/b and Item 18” on page 536.
NOTE NAV/ is automatically populated from the Other Equipment (OE)
parameter in the “ATS Plan” section of the CADB.
EQUIPMENT 10b Codes

NOTE The maximum number of characters allowed by the ICAO for 10b is 20. Item 10b input options are
restricted to codes selected from the following lists of transponder and ADS codes.
Equipment 10b Transponder Codes:

NOTE Only one transponder code is used.
• N – None
No surveillance equipment for the route to be flown is carried, or the
equipment is unserviceable.
• A – Transponder - Mode A (4 digits – 4 096 codes)
• C – Transponder - Mode A (4 digits – 4 096 codes) and Mode C
• E – Transponder - Mode S, including Aircraft Identification,

Pressure-Altitude and Extended Squitter (ADS-B) Capability
• H – Transponder - Mode S, including Aircraft Identification,

Pressure-Altitude and Enhanced Surveillance Capability
• I – Transponder - Mode S, including Aircraft Identification, but no

Pressure-Altitude Capability
• L – Transponder - Mode S, including Aircraft Identification,

Pressure-Altitude, Extended Squitter (ADS-B) and Enhanced
Surveillance Capability
• P – Transponder - Mode S, including Pressure-Altitude, but no

Aircraft Identification Capability
• S – Transponder - Mode S, including both Pressure-Altitude and

Aircraft Identification Capability

520
ATC Filing

EQUIPMENT 10b Codes • X – Transponder - Mode S with neither Aircraft Identification nor
(continued) Pressure-Altitude Capability
Equipment 10/b ADS Codes:

NOTE Only one type of each ADS-B code is used: B1 or B2, U1 or U2,
V1 or V2.
• B1 – ADS-B with dedicated 1090 MHz ADS-B “out” Capability
• B2 – ADB-B with dedicated 1090 MHz ADS-B “out” and “in”

Capability
• U1 – ADS-B “out” Capability using UAT
• U2 – ADS-B “out” and “in” Capability using UAT
• V1 – ADS-B “out” Capability using VDL Mode 4
• V2 – ADS-B “out” and “in” Capability using VDL Mode 4
• D1 – ADS-C with FANS 1/A Capabilities
• G1 – ADS-C with ATN Capabilities
12 PROPOSED DEPARTURE This information is derived from the flight plan. However, you can
TIME (ICAO Item 13) change the time, if necessary, using this command prompt.
18 REMARKS/GENERAL ICAO 2012 introduced new and changed indicators and descriptors for
INFORMATION (ICAO Item Item 18, as well as new dependencies between Item 18 and Item 10. In
18) addition, information entered at the 18 REMARKS/GENERAL
INFORMATION command prompt overwrites field 18 data from the
computed plan when using @18 at filing time. For more information, see
“ICAO 2012 Flight Plan Filings” on page 535.
IMPORTANT The IFPS requires the registration number (REG/######)
in Item 18 on the ICAO flight plan. If the registration number is not present,
the IFPS might reject the flight plan. If you add the registration number to
the “ATS Plan” section of your CADB record, JetPlan automatically adds
the number to Item 18.
NOTE The Short Autofile feature can be applied by having remarks set in
your ID/Attribute File (see “Short Autofile Feature” on page 552 below).

521
ATC Filing

Item 18 Indicators
Leave all indicator fields blank if no Item 18 indicators are used.
IMPORTANT In ICAO 2012 filings, when Item 18 is populated from the customer database, the entries are
automatically entered into the FPL in the prescribed order. If you manually enter the Item 18 indicators, you must
retain the correct order. Use only numbers and letters.
STS/ – Special handling information

Reason for special handling by ATS.
This field can be populated by a matching Flight Brief Type “A” record
with STS/ in the FBDB.
IMPORTANT Non-standard STS is indicated in RMK/.
Input Values – One or more of the following descriptors, separated by a
space:
• ALTRV – Used for a flight operated in accordance with an altitude
reservation
• ATFMX – Used for a flight approved for exemption from ATFM
measures by the appropriate ATS authority
• FFR – Used for fire-fighting
• FLTCK – Used for flight check for calibration of Navaids
• HAZMAT – Used for a flight carrying hazardous material
• HEAD – Used for a flight with Head of State status
• HOSP – Used for a medical flight declared by medical authorities

• HUM – Used for a flight operating on a humanitarian mission
• MARSA – Used for a flight for which a military entity assumes
responsibility for separation of military aircraft
• MEDVAC – Used for a life critical medical emergency evacuation
• NONRVSM – Used for a non-RVSM capable flight intending to
operate in RVSM airspace
NOTE JetPlan automatically adds STS/NONRVSM to Item 18 of the
ICAO 2012 FPL format when the RVSM parameter in the CADB is set to
Exempt.
• SAR – Used for a flight engaged in a search and rescue mission
• STATE – Used for a flight engaged in military, customs or police

522
ATC Filing

Item 18 Indicators (continued) PBN/ – Performance Based Navigation
Indication of RNAV and/or RNP capabilities.
This field is populated from the Item 18 PBN/ (I2) parameter in the
“ICAO 2012” section of the CADB. The PBN Certified (I1) parameter in
the CADB must also be set to Yes when Item 18 PBN/ (I2) is populated.
IMPORTANT The insertion of R in field 10a requires that the PBN levels
must also be specified after the PBN/ indicator in Item 18. Otherwise, the
flight plan might be rejected. See “ICAO 2012 Changes to Item 10a/b and
Item 18” on page 536.
IMPORTANT The current ICAO limit is eight Performance Based
Navigation codes (16 characters) in the PBN/ indicator. If the allowed
maximum (currently eight codes) is exceeded, your flight plans might be
rejected.
NOTE The application of a degradation to the Item 18 PBN/ parameter in
the ICAO 2012 section of the MEL Database overrides the PBN/
parameter value in the CADB and removes the CADB output from Item 18
PBN/ in the ICAO filing strip. For more information, see the Help topic for
the MEL Database on JetPlan.com or Chapter 38, “Minimum Equipment
List Database.”
Input Options:
Item 18 PBN/ input options are restricted to a total of eight codes (16
characters) from the following lists of RNAV and RNP Certification
codes. Example: A1B2C2D2LIS1T204
PBN/ RNAV Specification Codes
• A1 – RNAV 10 (RNP 10)
• B1 – RNAV 5 All Permitted Sensors
NOTE ICAO guidance indicates usage of B1 is acceptable even when
you have all sensors except LORANC.
• B2 – RNAV 5 GNSS
• B3 – RNAV 5 DME/DME
• B4 – RNAV 5 VOR/DME
• B5 – RNAV 5 INS or IRS
• B6 – RNAV 5 LORANC
• C1 – RNAV 2 All Permitted Sensors
• C2 – RNAV 2 GNSS
• C3 – RNAV 2 DME/DME
• C4 – RNAV 2 DME/DME/IRU
• D1 – RNAV 1 All Permitted Sensors
• D2 – RNAV 1 GNSS
• D3 – RNAV 1 DME/DME
• D4 – RNAV 1 DME/DME/IRU

523
ATC Filing

Item 18 Indicators (continued) PBN/ RNP Specification Codes
• L1 – RNP 4
• O1 – Basic RNP 1 All Permitted Sensors
• O2 – Basic RNP 1 GNSS
• O3 – Basic RNP 1 DME/DME
• O4 – Basic RNP 1 DME/DME/IRU
• S1 – RNP APCH
• S2 – RNP APCH with BARO-VNAV
• T1 – RNP AR APCH with RF (special authorization required)
• T2 – RNP AR APCH without RF (special authorization required)
NAV/ – Navigation equipment

Significant data related to navigation equipment, other than specified in
PBN/ as required by the appropriate ATS authority.
This field is automatically populated from the Other Equipment (OE)
parameter in the “ATS Plan” section of the CADB
“Z “is automatically inserted in 10a if the Other Equipment (OE)
parameter in the “ATS Plan” section of the CADB is populated. If a “Z”
is in Item 10a, the other equipment or other capabilities must be specified
in Item 18, preceded by COM/, NAV/, and/or DAT/, as appropriate.
When “G” is in Item 10a, additional types of external augmentation, if
any, can be specified in Item 18 following NAV/ and separated by a
space. See “ICAO 2012 Changes to Item 10a/b and Item 18” on
page 536.

524
ATC Filing

Item 18 Indicators (continued) COM/ – Communication applications or capabilities
Indicates additional communications applications or capabilities for the
aircraft that are not covered by the codes for Item 10a.
This field is populated from the Item 18/ COM (I3) parameter in the
“ICAO 2012” section of the CADB.
Input value: EUROCONTROL accepts only 50 characters
IMPORTANT “Z “is automatically inserted in 10a if the Other Equipment
(OE) parameter in the “ATS Plan” section of the CADB is populated. If “Z”
is in Item 10a, the other equipment or other capabilities must be specified
in Item 18, preceded by COM/, NAV/, or DAT/, as appropriate. See “ICAO
2012 Changes to Item 10a/b and Item 18” on page 536.
NOTE ANSP/ Air Services Australia indicates satcom phone numbers
can be entered here. No special characters are allowed. Example:
8889993123.
NOTE If the 8.33 KHz Communication (83) parameter is set to Permit (P)
or Exempt (E) in the “Equipment” section of the CADB, EXM833 is inserted
in Item 18 COM/.
NOTE The application of an override to the Item 18 COM/ parameter in
the “ICAO 2012” section of the MEL Database overrides the Item 18 COM/
parameter value in the CADB and removes the CADB value from Item 18
COM/ in the ICAO filing strip. For more information, see the Help topic for
the MEL Database in JetPlan.com or Chapter 38, “Minimum Equipment
List Database.”
DAT/ – Data applications and capabilities

Indicates additional data applications or capabilities for the aircraft that
are not covered by the codes for Item 10a.
This field is populated from the Item 18/ DAT (I4) parameter in the
Input value: EUROCONTROL accepts only 50 characters
IMPORTANT The letter Z is automatically inserted in 10a if the Other
Equipment (OE) parameter in the “ATS Plan” section of the CADB is
populated. If the letter Z is in Item 10a, the other equipment or other
capabilities must be specified in Item 18, preceded by COM/, NAV/, and/or
DAT/, as appropriate (and vice versa). See “ICAO 2012 Changes to Item
10a/b and Item 18” on page 536.

525
ATC Filing

Item 18 Indicators (continued) SUR/ – Surveillance applications and capabilities
Indicates surveillance applications or capabilities for the aircraft that are
not covered by the codes for Item 10b.
This field is populated from the Item 18/ SUR (I5) parameter in the
Input value: EUROCONTROL accepts only 50 characters.
NOTE Per the FAA Aeronautical Information Manual, “SUR/ indicates
surveillance capabilities not specified in 10b, when requested by an Air
Navigation Service Provider. If ADS-B capability filed in Item 10 is
compliant with RTCA DO-260B, include the item 260B in SUR/. If ADS-B
capability filed in Item 10 is compliant with RTCA DO-282B, include the
item 282B in SUR/.”
EXAMPLE:
1. SUR/260B
2. SUR/260B 282B
For the latest FAA information on the above, see the Aeronautical
Information Manual on the FAA Web site.
NOTE The application of an override to the Item 18 SUR/ parameter in
the ICAO 2012 section of the MEL Database overrides the Item 18 SUR/
parameter value in the CADB and removes the output from Item 18 SUR/
in the ICAO filing strip. For more information, see the Help topic for the
MEL Database in JetPlan.com or Chapter 38, “Minimum Equipment List
Database.”
DEP/ – Name and location of departure airport if ZZZZ is in Item 13.

This information is derived from the flight plan. It is only output if the
departure airport is ZZZZ.
DEST/ – Name and location of destination airport if ZZZZ in Item 16.

destination airport is ZZZZ.
DOF/ – Date of flight departure

This information is transferred from the flight plan.
NOTE Previously optional, DOF/ (Date of Flight) is always output in all
ICAO 2012 FPLs to ensure compliance with more stringent DOF/ rules for
ICAO 2012.
REG/ – Nationality or common mark and registration mark of aircraft

This field is populated by the Registration Number (RN) parameter in the
“ATS Plan” section of the CADB.
IMPORTANT The IFPS requires the registration number (REG/######)
in Item 18 on the ICAO flight plan. If the registration number is not present,
the IFPS might reject the flight plan.

526
ATC Filing

EET/ – Significant points or FIR boundary designators and accumulated
estimated elapsed times
This information is transferred from the flight plan.
Item 18 Indicators (continued) SEL/ – Special Code, for aircraft so equipped

This field is populated from the (SC) SELCAL CODE parameter in the
“ATS Plan” section of the CADB.
TYP/ – Type(s) of aircraft if ZZZZ in Item 9.

NOTE Not currently supported.
CODE/ – Aircraft address

Specifies the aircraft address for the aircraft, expressed in the form of an
alphanumerical code of six hexadecimal characters (as prescribed by the
appropriate ATS authority). For example, F00001 is the lowest aircraft
address contained in the specific block administered by ICAO.
This field is populated from the Item 18/ CODE (I6) parameter in the
Input value: Alphanumeric code of six hexadecimal characters
NOTE The application of an override to the Item 18 CODE/ parameter in
the ICAO 2012 section of the MEL Database overrides the Item 18 CODE/
parameter value in the CADB and removes the output from Item 18 CODE/
Database.”
DLE/ – Enroute delay or holding

This information is derived from the ETD input by the user. See the
“Estimated Time of Departure Commands” chapter in the JetPlan User
Manual.
OPR/ – ICAO designator or name of the aircraft operating agency

This field is populated from the Company Name (CN) and OPR Required
(OR) parameters in the “ATS Plan” section of the CADB.
ORGN/ – Originator’s 8 letter AFTN address

This field is populated by a matching Flight Brief Type “A” record with
ORG/ in the FBDB.
Input value: Up to 30 alphanumeric characters

527
ATC Filing

Item 18 Indicators (continued) PER/ – Aircraft performance data
Allows you to enter aircraft performance data as prescribed by the
appropriate ATS authority. The data is indicated by a single letter as
specified in the ICAO document: Procedures for Air Navigation Services
— Aircraft Operations (PANS-OPS, Doc 8168), Volume I — Flight
Procedures.
This field is populated from the Item 18/ PER (I7) parameter in the
Input value: One (1) alphanumeric character only. Permissible values are:
A, B, C, D, E, or H. May be left blank.
NOTE The application of an override to the Item 18 PER/ parameter in
the ICAO 2012 section of the MEL Database overrides the Item 18 PER/
parameter value in the CADB and removes the output from Item 18 PER/
Database.”
ALTN/ – Destination alternate if ZZZZ in Item 16

destination alternate is ZZZZ.
NOTE Not presently handled in JetPlan.
RALT/ – Enroute alternates

ETOPS alternates for flight.
This information is derived from the computed flight plan.
NOTE Requires RALT Preference to be set for output. Contact Jeppesen
Technical Support if needed.
TALT/ – Takeoff alternate

This information is transferred from the computed flight plan.
Information can also be entered manually at filing time.
RIF/ – Reclear information

Route to reclear airport
This information is transferred from the computed flight plan.
Information can also be entered manually at filing time.
Automatically output if the customer format supports it, and a reclear
plan is run. Only output if customer format supports it.

528
ATC Filing

Item 18 Indicators (continued) RMK/ – Other remarks
This is a free-text field. As a general guideline, anything not covered in
any of the available Item 18 sub-fields can be put in RMK/.
This field is automatically populated from the Flight Brief Text
parameter in the Fight Brief Database. Information can also be entered
manually at filing time.
NOTE RMK/ output can also be generated from other data sources, such
as a customer’s ID/Attribute File.
NOTE If the flight plan contains the ERAD flight plan option, ERAD
special remarks are automatically added to Item 18 on the filing strip. For
information, see the “Electronic Route Availability Document Option” in the
20 1ST ALTERNATE This information is derived from the flight plan. The system prompts for
AIRPORT (ICAO Item 16) this information if no alternate is specified in the flight plan.
21 2ND ALTERNATE This information is derived from the flight plan. The system does not
AIRPORT (ICAO Item 16) prompt for this information, whether or not the flight plan has it.
However, you can add a second alternate using this command prompt.
23 PILOT NAME (ICAO Item This information is derived from the flight plan if the name option
19) (CPT/xxxxx) is entered in flight plan request. The system does not
prompt for this information, whether or not the flight plan has it.
However, you can add or change the pilot’s name using this command
prompt.
24 ENDURANCE (ICAO Item This information is derived from flight plan. However, you can change
19) the value using this command prompt.
25 PERSONS ON BOARD (Required) This information is derived from the flight plan or from the
(ICAO Item 19) CADB, if a value is available in the Persons on Board (OB) parameter.
Otherwise, enter the appropriate information.
26 COLOR OF AIRCRAFT (Required) This information is derived from the flight plan or from the
(ICAO Item 19) CADB, if a value is available in the Aircraft Color (AC) parameter.
Otherwise, enter the appropriate information.
27 EMERGENCY RADIO (Required) This information is populated from the CADB, if a value is
(ICAO Item 19) available in the Emergency Radio (ER) parameter. Otherwise, enter the
appropriate information.
28 SURVIVAL EQUIPMENT (Required) This information is populated from the CADB, if a value is
(ICAO Item 19) available in the Survival Equipment (SE) parameter. Otherwise, enter the
29 LIFE JACKETS (Required) This information is populated from the CADB, if a value is
(ICAO Item 19) available in the Life Jackets (JA) parameter. Otherwise, enter the

529
ATC Filing

30 DINGHIES (ICAO Item 19) (Required) This information is populated from the CADB, if a value is
available in the Dinghies (DN) parameter. Otherwise, enter the
31 FILED BY (ICAO Item 19) (Required) Enter the name of the person who is filing the flight plan. An
entry is required for international filings.
The Short Autofile feature can be applied by having this information set
in your ID/Attribute File (see “Short Autofile Feature” on page 552
below).
33 DEPARTURE CENTER This information is derived from the flight plan. However, you can
(ICAO ADDRESSES Field) change the information using this command prompt.
Database Support for the Filing Program

JetPlan provides several databases that support your automatic filing capabilities.
The Customer Aircraft Database (CADB)

You can store information related to ATC filing for each aircraft in the CADB, including
navigation/communication information, certifications, and other equipment information.
When you use an aircraft in a flight plan request, the system derives the aircraft’s information
from the CADB, eliminating the need to provide information for many of the FI prompts. See
Table 19-1, “JetPlan Automatic Filing Program Command Prompts,” on page 516 for the
prompts and data sources.
The CADB must be configured for ICAO 2012. The “ICAO 2012 Certification and
Equipment” section in the CADB contains ICAO-2012 specific data elements that
automatically populate Item 10 and Item 18 in the ICAO FPL. The parameters added for
ICAO 2012 parameters are listed in the following paragraphs.

530
ATC Filing
Item /b You can store codes for communication, navigation equipment and
EQUIPMENT capabilities, and/or surveillance equipment and capabilities in the
Parameter (NC2) NC2 parameter. JetPlan automatically inserts the 10a codes before the
“/” indicator and the 10b codes after the “/” indicator in Item 10a/b
EQUIPMENT on the filing strip.
NOTE The application of degradations to RNAV equipment and to RVSM, RNP,

and MNPS (NAT HLA) certifications in the MEL database overrides the settings for
these items in the CADB and removes their designators from the NAV/COM code in
Item 10 of the ICAO filing strip. See Chapter 38, “Minimum Equipment List Database.”
PBN Certified Indicates whether or not the aircraft has Performance Based
parameter (I1) Navigation (PBN) capabilities. When the PBN Certified (I1)
parameter is set to “Yes,” JetPlan inserts an “R” in Item 10a on the
filing strip.
ICAO 2012 Item 18 Item 18 indicators must be filed in a prescribed order per the
indicators and “Procedures for Air Navigation Services — Air Traffic Management,
codes (I2) Fifteenth Edition (PANS-ATM, DOC 4444).” When an Item 18
indicator parameter is populated in the CADB, JetPlan inserts the
stored value in Item 18 on the filing strip in the required order.
The following parameters are available:
• Item 18 PBN/ – Stores ICAO codes for the aircraft's PBN

capabilities. JetPlan inserts your selected codes as a single,
concatenated string in Item 18 PBN/.
• Item 18 COM/ – Stores communications applications or
capabilities not listed in Item 10a.
• Item 18 DAT/ – Stores data capabilities not specified in
Item10b.
• Item 18 SUR/ – Stores surveillance application/capability not
specified in Item10b.
• Item 18 CODE/ – Stores the aircraft address.
For complete information, see the Help topic for the CADB on
JetPlan.com or Chapter 27, “Customer Aircraft Database.”

531
ATC Filing
The Flight Brief Database (FBDB)

When creating an FBDB record, you first define a “flight brief type,” which indicates
information that you want to add or a condition that you want to apply automatically to certain
flight plan requests. You can then use selection criteria, such as fleet type or POD and POA, to
limit use of that information or condition to flight plan requests that match the criteria. For
example, you can include Remarks in Item 18 on the ATC filing strip just for flight plans with
a particular POA. Other examples include specifying the use of bonded or non-bonded fuel
price or including the output of AIR OPS emissions data on flight plans.
The FBDB includes parameters that support the ICAO 2012 FPL format. Those parameters
allow you to automatically output Item 18 Special Handling (STS/) and 18 Originator
(ORGN/) information to specified flight plan requests, auto populating the filing strip.
For more information on the FBDB, see the Help topic for the FBDB on JetPlan.com or
Chapter 36, “Flight Brief Database.”
The Minimum Equipment List (MEL) Database

The MEL Database contains parameters that allow you to degrade or override certain
capabilities and certifications stored for the aircraft in the CADB. Parameters have been added
to the MEL Database to degrade the following ICAO 2012-specific parameters in the “ICAO
2012” section of the CADB:
• 10a/b EQUIPMENT
• R - PBN Certified
• Item 18 COM/
• Item 18 PBN/
• Item 18 SUR/
• Item 18 CODE/
For more information, see the Help topic for the MEL Database on JetPlan.com, or see
Chapter 38, “Minimum Equipment List Database.”

532
ATC Filing
The Customer Preference Database

The Customer Preference Database allows you to save time by setting some filing activities to
happen automatically. Some filing related preferences are:
FILEORIG=(Y/N) When this preference is present and set to N, it prevents the flight
Filing Originator plan filing from being sent to the originator address, as defined in the
Address (Control) customer's ID/Attribute file. If the preference is set to Y or is not
present in the Customer Preference Database, the filing is sent to the
originator address.
FINOW File Now When present, this preference carries out an immediate transmission
action on the filing request. This preference also enables the TIME
option in line mode. If the TIME or the LEAD option is used, the
FILE NOW action is overridden.
FIONEALT=(Y/N) When this preference is present and set to Y, it limits the number of
File One Alternate destination alternates included on the ATC filing strip to one, even if
two or more are in the flight plan request. If the preference is set to N
or is not present in the Customer Preference Database, a second
destination alternate (if submitted) is included on the ATC filing strip.
The JetPlan Flight Plan Filing Database (FDB)

The JetPlan Flight Plan Filing Database enables you to customize the filed product, including
a way to define the type of message sent, any additional addresses, and the suppression of
specific information. This custom alteration capability applies to the format of the information
sent and to the filing destinations.
NOTE Contact your Jeppesen account manager to make use of the Flight Plan
Filing database.
The custom alterations available through the Flight Plan Filing Database are as follows:
• Include down-line FIR and customer addresses when transmitting ICAO

filing
• Omit down-line FIR and customer addresses when transmitting ICAO filing
• Send long ICAO filing (includes supplementary data)

533
ATC Filing
• Send short ICAO filing (excludes supplementary data)

• Send flight plan in U.S. Domestic format only, regardless of departure
(POD) and/or arrival (POA) station identifiers
• Send flight plan in ICAO format only, regardless of departure (POD) and/or
arrival (POA) station identifiers
• Include additional filing destination addresses
• Include one or more destination alternate filing addresses
• Suppress the output of SID and STAR identifiers in the ICAO filing
The application of the Flight Plan Filing database is typically keyed to information in your
flight plan. This means that custom alterations are applied automatically when the plan is filed.
The following factors can be set to initiate certain filing alterations:
• POD identifier
• POA identifier
• POD/POA combination of identifiers
• Specific FIR identifiers
These key factors can be stored in the database as complete ICAO IDs (for example, EGLL,
LIRA, and so on) so that only the presence of the complete identifiers in your flight
information (plan) activates the custom filing. They can also be stored as abbreviations, using
the first one or two characters of the ICAO IDs (for example, EG, LI, G). The abbreviation of
identifiers to the first one or two characters allows the custom alterations to be applied to any
filing that has the abbreviated portion in the key factor (POD, POA, or FIR). A flight plan with
the correct ICAO ID portion activates custom filing instructions.
For example, if you want to send a flight plan filing message to additional addresses (such as
RJAA and RJCC) for all flights that depart from Seoul, South Korea, and arrive at Jakarta,
Indonesia, you would have the ICAO identifiers RKSS and WIII entered into the Flight Plan
Filing database as key factors that initiate the additional transmissions.
For another example, if you wanted to suppress the output of SID identifiers in your ICAO
filing for all flight plans that depart a Japanese airport, you would have the characters RJ
entered into the filing database as a key factor.

534
ATC Filing
ICAO 2012 Flight Plan Filings
Overriding the Flight Plan Filing Database

You can always override the custom filing information in the Flight Plan Filing database,
regardless of key factors, by including the exception option, XFDB, in your flight plan
request. The filing of a plan run with this option is standard, not custom. The exception option
is entered on the Options command line, anywhere after the FP command.
Example:
01 OPTIONS FP,XFDB,CS/JD123...

This section contains information on the ICAO 2012 FPL format, which became the default
filing format used by the JetPlan Automatic Filing Program after Jeppesen’s cutover to the
ICAO 2012 FPL format on November 14, 2012.
IMPORTANT All flight plans filed with Jeppesen flight planning products are filed in
the ICAO 2012 format by default.

DOC 4444),” which describes the ICAO 2012 FPL requirements in detail.

535
ATC Filing
Summary of ICAO 2012 Changes

The following paragraphs describe the ICAO 2012 FPL changes and how the JetPlan customer
databases support those changes.
ICAO 2012 Changes to Item 10a/b and Item 18
New Item 10a/b ICAO 2012 introduced new EQUIPMENT Item 10a codes for
EQUIPMENT and communication and navigation equipment and capabilities and new
Codes Item 10b codes for surveillance equipment and capabilities.
Database Source: When your CADB Item 10a/b EQUIPMENT

(NC2) parameter is configured with these codes, JetPlan
automatically inserts the 10a codes before the “/” indicator and the
10b codes after the “/” indicator in Item 10a/b EQUIPMENT on the
filing strip.
NOTE If you manually override Item 10a/b codes using the command line, be sure
to enter the “S” code (if used) first, or some ATC Centers might reject the filing. In
addition, if entering Item 10a/b manually, you need to include the “/” indicator after the
Item 10a codes and before the Item 10b codes. For a list of the Item 10a/b codes, see
Table 19-1, “JetPlan Automatic Filing Program Command Prompts,” on page 516.
R – PBN Approved The PBN Approved (“R”) code in Item10a indicates that the aircraft
Item 10a Indicator has Performance Based Navigation (PBN) capabilities. Note that
there are dependencies between “R” in Item 10a and Item 18 PBN/.
For information, see “New links between Item 10a/b and Item 18”
below.
Database Source: When the PBN Certified (I1) parameter in the

CADB is set to “Yes,” JetPlan automatically inserts an “R” in Item
10a on the filing strip.
New or Revised The following new or revised Item 18 indicators parameters are
Item 18 Indicators available.
and Definitions
• Item 18 PBN/ – ICAO codes for the aircraft's PBN capabilities.
This indicator must be populated if “R” is in Item 10a and vice
versa.

536
ATC Filing
• Item 18 COM/ – Communications applications or capabilities

not listed in Item 10a.
• Item 18 DAT/ – Data capabilities not specified in Item10b.
• Item 18 SUR/ – Surveillance application/capability not
• Item 18 CODE/ – The aircraft address.
• Item 18 PER/ – Aircraft performance data.
Item 18 indicators must be filed in a prescribed order per the

“Procedures for Air Navigation Services — Air Traffic Management,
Fifteenth Edition (PANS-ATM, DOC 4444).”
Database Source: When an Item 18 indicator parameter is populated

in the CADB, JetPlan inserts the stored value in Item 18 on the filing
strip in the required order. (See the Help file for the CADB on
JetPlan.com or Chapter 27, “Customer Aircraft Database.”)
IMPORTANT If you manually override any data in the Item 18 field using the
command line, you override all the Item 18 data that was generated by the flight plan
computation. You need to re-enter any desired Item 18 data plus your changes in the
prescribed order. For a list of Item 18 indicators and codes, see Table 19-1, “JetPlan
Automatic Filing Program Command Prompts,” on page 516.
New links between Several links between Item 10a and Item 18 apply, as follows:
Item 10a/b and
Item 18 • R (PBN Approved) and Item 18 PBN/ – When “R” is in Item
10a on the filing strip (the PBN Certified [I1] parameter is set to
“Yes” in the CADB), PBN levels must be specified in Item 18
PBN/ and vice versa. Otherwise, the flight plan might be
rejected.
Database Source: The Item 18 PBN/ (I2) parameter in the

CADB allows you to store the required data for insertion into
Item 18 on the filing strip.

537
ATC Filing
• Specific Associations Between Item 10a Codes and Item 18

PBN/ Descriptors – The following table lists specific
associations that exist between Item 10a codes and descriptors
in Item 18 PBN/.
Table 19-2 Links Between Item 18 PBN/ and Item 10a
For Item 18 PBN If Item 18 PBN/

RNAV entry includes Then Item 10a
Specification: any/all of these: requires:
GNSS B1, B2, C1, C2, D1, G
D2, O1, O2
DME/DME B1, B3, C1, C3, D1, D

D3, O1, O3
VOR/DME B1, B4 OD or SD
INS B1, B5 I
DME/DME/IRU C1, C4, D1, D4, O1, DI

O4
LORAN B6 C
• G (GNSS) and Item 18 NAV/ – When “G” is in Item 10a on

the filing strip, the type of external GNSS augmentation, if any,
must be specified in Item 18 NAV/.
Database Source: The Other Equipment (OE) parameter in the

“ATS Plan” section of the CADB allows you to store the GNSS
augmentation information for insertion into Item 18 NAV/ on
the filing strip.
• Z (Other Equipment) and Item 18 COM/, NAV/, or DAT/ –
“Z” is inserted in 10a when OE is populated. When “Z” is in
Item 10a, equipment or capabilities that are not specified in
Item 10a must be specified in Item 18, preceded by COM/,
NAV/, or DAT/.
Database Source: The Item 18 COM/ (I3) and Item 18 DAT/

(I4) parameters in the CADB allow you to store data for
insertion into Item 18 on the filing strip. The Other Equipment
(OE) parameter in the “ATS Plan” section of the CADB allows
you to specify the data for insertion into Item 18 NAV/ on the
filing strip. (See the Help file for the CADB on JetPlan.com or
Chapter 27, “Customer Aircraft Database.”)

538
ATC Filing
ICAO 2012 Changes to the JetPlan Automatic Filing Program

While a few modifications to the JetPlan Automatic Filing Program were made to support
ICAO 2012 FPL filings, the FI command itself did not change. The following example shows
the FI filing commands and the resulting FPL with the ICAO 2012-specific data in Item 10a/b
and in Item 18. In this case, the data was derived from the CADB.
01 OPTIONS FI561,NOW
02 AIRCRAFT ID OR CALL SIGN TTTJP1
-
31 FILED BY TONY
ENTER QUESTION NUMBER OR GO GO
20 COMPUTING 29012
(FPL-TTTJP1-IN
-B772/H-SDGHIJ1M1RWXYZ/HU1
-KMSP2300
-N0483F410 SMITH4 DLL J34 CRL J584 SLT DCT MIP MIP4
-KLGA0202
-PBN/A1B1C1D1 NAV/RNVD1E2A1 DOF/121031 REG/973603
EET/KZAU0017 KZOB0049 CZYZ0100 KZNY0130 SEL/ABCD CODE/F00001
OPR/JEPPESEN TONY 1 PER/D RMK/AGCS EQUIPPED TCAS EQUIPPED)
COMPLETE, FLIGHT PLAN #00561 WILL BE FILED NOW AT FOLLOWING

ADDRESS(ES)
KZMPZQZX CZYZZQZX

REQUEST NO. 29012
Although the FI command remains the same for ICAO 2012 filings, modifications to the 22
OTHER INFORMATION and 18 REMARKS/GENERAL INFORMATION prompts were
made. Other changes were made to Delay, Change, and Cancel messages. These changes,
which are now the default functionality in the JetPlan Filing Program, are described below.
22 OTHER The 22 OTHER INFORMATION @22 command prompt is not used

INFORMATION at all for ICAO 2012 filings.
18 REMARKS Information added with @18 with the FI or CHG command at the 18
/GENERAL REMARKS/GENERAL INFORMATION prompt overwrites all of
INFORMATION the Item 18 information that was generated for the flight plan. If you
manually override any data in Item 18 using the command line, you

539
ATC Filing
must enter all the Item 18 data even if you are changing just some of
the data. You must also ensure that the Item 18 indicators are entered
in the prescribed order, per the “Procedures for Air Navigation
Services — Air Traffic Management, Fifteenth Edition (PANS-ATM,
DOC 4444)” or the filing might be rejected.
For a list of Item 18 indicators and codes, see Table 19-1, “JetPlan
Automatic Filing Program Command Prompts,” on page 516.
Delay (DLA) The default functionality for DLA messages is as follows:

Messages
• DLA messages include the Date of Flight (DOF).
• Delays are not entered beyond 22 hours from the current time.
• To comply with the ICAO recommendation to use a CHG
message for a delay over midnight, a DLA command over
midnight UTC sends a CHG message automatically. All
subsequent CHG/DLA/CNL messages have the new DOF.
For more information about DLA messages, see “Delaying Filing” on

page 543.
Change (CHG) As explained above, a DLA over midnight UTC uses a CHG
Messages message. In addition, all CHG messages now contain the DOF. For
more information, see “Changing Filed ICAO Plans” on page 546.
Cancel (CNL) CNL messages include the ETD and DOF. For more information, see
Messages “Canceling Filed ICAO Plans” on page 545.
ICAO 2012 Changes to Customer Databases

The CADB, FBDB, and MEL databases have been modified to support ICAO 2012 flight plan
filings. See “Database Support for the Filing Program” on page 530.

540
ATC Filing
Before Filing the ICAO 2012 Flight Plan

Before filing in the ICAO 2012 format, please be aware of the following:
• The ICAO 2012 FPL format is used by default unless your account has been
configured to file in the Domestic format.
• You must configure your CADB with ICAO 2012 parameters. The ICAO
2012 FPL is pre-populated with this data. For information on setting up the
CADB, see the “ICAO 2012 Certification and Equipment” section in the
Help topic for the CADB on JetPlan.com or Chapter 27, “Customer Aircraft
Database.”
• See “Reducing the Likelihood of Flight Plan Rejects” on page 541 for
important notes and cautions.
• For detailed information on the requirements of the ICAO 2012 FPL format,
see the “Procedures for Air Navigation Services — Air Traffic
Management, Fifteenth Edition (PANS-ATM, DOC 4444).”
Reducing the Likelihood of Flight Plan Rejects

To reduce the likelihood of flight plans rejections due to incorrect entry of ICAO 2012 data,
follow these guidelines:
• Ensure that when “R” is in Item 10a, PBN levels are specified in Item 18
PBN/ and vice versa.
• Manage the other dependencies between Item 10a EQUIPMENT and Item
18 PBN/ described in “ICAO 2012 Changes to Item 10a/b and Item 18” on
page 536.
• Enter a maximum of eight PBN codes in the Item 18 PBN/ parameter.
• Enter only numbers and letters for the ICAO 2012 parameters.
• If making changes at the @09 (EQUIPMENT) prompt, the “S” code (for
Standard Equipment) is retained as the first character. (The correct order is
implemented automatically when JetPlan derives the Item 10a/b codes from
the CADB). Also, E, J,M, P, Q before the slash in Item10a are no longer
valid entries, and D in 10b after the slash is no longer valid.
• If making changes at the @18 (REMARKS/GENERAL INFORMATION)
prompt, be sure to re-enter all the Item 18 data (not just the items you are
changing) and enter the indicators in the prescribed order per the
Fifteenth Edition (PANS-ATM, DOC 4444).” For the indicators, see

541
ATC Filing
Table 19-1, “JetPlan Automatic Filing Program Command Prompts,” on

page 516. (The correct order is implemented automatically when JetPlan
derives the indicators from the customer databases).
• Enter ICAO 2012-specific data only in the proper fields.
Filing Priority and Timeliness Options

JetPlan transmits your filed flight plan to the departure station ACC/ARTCC three hours
before the estimated time of departure (ETD) for U.S. Domestic flights and five hours before
the ETD for international flights. If the flight plan is filed less than three hours prior to the
ETD (or five hours for international), then the flight plan is filed immediately. In the case of
international filings, JetPlan also transmits the flight plan to the appropriate enroute and/or
destination addresses.
NOTE For filing purposes, JetPlan distinguishes between U.S. Domestic and ICAO
flight plans by the first letter of the ICAO identifier for the POD and POA stations. If
both begin with the letter, K, JetPlan recognizes a U.S. Domestic flight plan. If one or
both stations begin with any letter other than K, JetPlan recognizes an international
(ICAO) flight plan.
If the planned flight is changed or delayed so that the departure time (ETD) is different, you
have options available for filing immediately or delaying the auto-file, depending on the
situation.
File Immediately
A flight plan filed more than three to five hours prior to the ETD (as discussed above) can be
filed immediately by using the command FI<####>,NOW, where <####> is the flight plan
number. This command can also be used with plans that are already in the queue.
NOTE JetPlan allows flight plans to be filed right up to one minute prior to the
planned ETD.

542
ATC Filing
Example:
Explanation: File plan number 1234 immediately.
01 OPTIONS FI1234,NOW
NOTE If you have made changes to a previously filed flight plan that are beyond the
scope of the CHG option and are re-filing the plan using the NOW option, do not
forget to cancel the previously filed flight plan. Otherwise, ATC might exhibit some
confusion as to which plan to follow.
AFTN Priority Code Method

Another method available for filing a flight plan immediately is to raise the priority of the
message. The default AFTN priority code for transmitting flight plan filings is FF. You can
specify the priority code DD after the File command to raise the priority of the transmission.
There are a few ACCs that process the filing message more quickly when the DD code is used.
See the Forward Plans, Messages, etc chapter for more information about priority codes.
Example:
01 OPTIONS FI1234,DD
Delaying Filing
NOTE You cannot delay a flight more than 22 hours from the current time. A CHG
message is automatically used for a delay over midnight UTC. See “ICAO 2012 Flight
Plan Filings” on page 535.
To delay the filing of an ICAO flight plan by revising the ETD, enter the filing command
followed by DLA=<####> where <####> is the revised ETD.
Example:
Explanation: Delay the filing of plan number 1234 to 3 (or 5) hours prior to the new ETD of
1230.
01 OPTIONS FI1234,DLA=1230
The delay option can also contain an estimated date of departure (EDD).

543
ATC Filing
Example:
Explanation: Delay the filing of plan number 1234 to 3 (or 5) hours prior to the new ETD of
1230 on the 27th of July, 2007.
01 OPTIONS FI1234,DLA=1230/EDD,27JUL07
DLA messages always contain the ETD and DOF.
Example:
20 COMPUTING 29014
(DLA-TTTJP1-KMSP2345-KLGA-DOF/121031)
In addition, a CHG message is automatically used for a delay over midnight UTC. All
subsequent CHG/DLA/CNL messages have the new DOF.
Example:
20 COMPUTING 29016
(CHG-TTTJP1-KMSP2345-KLGA-DOF/121031-8/IN-9/B772/H
-10/SDGHIJ1M1RWXYZ/HU1
-13/KMSP0100
-15/N0483F410 SMITH4 DLL J34 CRL J584 SLT DCT MIP MIP4
-18/PBN/A1B1C1D1 NAV/RNVD1E2A1 DOF/121101 REG/973603
EET/KZAU0017 KZOB0049 CZYZ0100 KZNY0130 SEL/ABCD CODE/F00001
OPR/JEPPESEN TONY 1 PER/D RMK/AGCS EQUIPPED TCAS EQUIPPED)
Lead Time Filing

The command FI<####>,LEAD=<hhmm> (hours and minutes) specifies the time before ETD
that the filing request is sent. The time specified with this option must be at least one hour and
not more than 23 hours and 59 minutes prior to ETD. If no time is specified, the default of 3 or
5 hours is used.
Example:
Explanation: File plan number 1234 12 hours and 30 minutes prior to the ETD.
01 OPTIONS FI1234,LEAD=1230

544
ATC Filing
Filing at a Specified Time

The TIME option can be used to specify the time at which the flight plan is sent to ATC. If an
estimated date of departure (EDD) is not specified, the TIME value is assumed to be within the
preceding 24 hours of the ETD.
NOTE The FINOW customer preference setting is required for the TIME option to
work. Contact your Jeppesen account manager for more information.
The TIME option is specified by FI<####>,TIME=<hhmm>, where <hhmm> is the desired

filing time expressed in UTC (Zulu time).
The TIME option can also be used with an estimated date of departure as shown here:
FI<####>,TIME=hhmm/EDD,ddMONyy
Example:
Explanation: File plan 1234 at 1545Z on the 27th of July, 2007
01 OPTIONS FI1234,TIME=1545/EDD,27JUL07
NOTE You are responsible for ensuring the time is adequately ahead of the ETD.
Canceling Filed ICAO Plans

To cancel an ICAO flight plan, type the command, FI, followed by the plan number of the
international flight, a comma, and the cancel option, CX, on the Options command line. You
can cancel a flight plan up to 90 minutes past the ETD. The cancellation message is sent to all
stations that received the original transmission. Cancel (CNL) messages include the ETD and
DOF.
Example:
Explanation: Cancel the filing of plan number 561
01 OPTIONS FI561,CX
20 COMPUTING 29020
(CNL-TTTJP1-KMSP0100-KLGA-DOF/121101)

545
ATC Filing
Changing Filed ICAO Plans

To invoke a change on a previously filed flight plan, enter the File command, followed by the
change option, CHG. This option provides the security of retaining the original filing slot time,
which can be lost when the method of applying changes involves canceling and re-filing a
plan.
Example:
Explanation: Modify the filing of plan number 1234.
01 OPTIONS FI1234,CHG
The CHG option has the following restrictions:
• Applies only to ICAO 2012 filings. The CHG option does not work for U.S.
Domestic filings.
• You can only change the following items:
– 04 TYPE OF FLIGHT
– 06 TYPE OF AIRCRAFT
– 07 WAKE TURBULENCE CATEGORY
– 09 EQUIPMENT
– 18 REMARKS/GENERAL INFORMATION
IMPORTANT If you use the @18 REMARKS/GENERAL INFORMATION prompt to

make a change to any Item 18 information in an ICAO 2012 filing, you overwrite all of
the Item 18 data from the computed plan. You must re-enter the entire field 18 plus
your changes. You must also ensure that the Item 18 indicators are entered in the
prescribed order, per the “Procedures for Air Navigation Services — Air Traffic
Management, Fifteenth Edition (PANS-ATM, DOC 4444).” For a list of Item 18
indicators and codes, see Table 19-1, “JetPlan Automatic Filing Program Command
Prompts,” on page 516.
When you submit a change to a previously filed flight plan, the notification sent to ATC
includes the CHG lead, as long as the plan has been actually filed. If the plan is still in queue to
be filed, the notification sent to ATC appears like any other filing (no CHG lead in the
message).

546
ATC Filing
CHG messages always contain the ETD and the DOF.
Example:
01 OPTIONS FI1184,CHG
ENTER QUESTION NUMBER OR GO @18
-PBN/A1B3B4B5C3C4
-
20 COMPUTING 11661
(CHG-TEST1-KMSP2300-KLAX-DOF/121109-8/IS-9/B772/H
-10/SABCDE1E2E3FGHIJ1J2J3J4J5J6J7KM1M2M3TURWXYZ/D1EU1V1
-15/N0478F430 DCT ONL J114 SNY DCT DBL J60 HEC DCT
-18/PBN/A1B3B4B5C3C4)
A CHG message is automatically used for a delay over midnight UTC. All subsequent
CHG/DLA/CNL messages have the new DOF. For more information on DLA messages, see
“Delaying Filing” on page 543.
Filing Reclear Flight Plans

If you request a reclear flight plan set with the RC, RC3, or RCN command, you have the
choice of filing either the first or second flight plan. The first flight plan is to the intended
destination with full reserve fuel. The second flight plan is to the intended destination with
reserve fuel calculated from the reclear fix. Jeppesen recommends that you file the second
flight plan because JetPlan automatically prepares the RIF/ data in Item 18 of the ICAO ATS
plan for output in the second and third flight plans of the reclear set (for most formats). JetPlan
does not prepare this data for output in the first flight plan of the reclear set.
NOTE Do not attempt to file the third flight plan of the reclear set. This is the flight
plan to the reclear airport. JetPlan does not file this plan.
If you request a reclear flight plan compression set with the RCC command, JetPlan prints out
the flight plan number to file above the compression plan.

547
ATC Filing
Viewing Filing Status and History

You can check the status of computed flight plans and search for filing records.
Using the STAT Command

Entering FI<####>,STAT (where <####> represents the flight plan number) provides the
status of a flight plan, whether filed, queued, or canceled.
Example:
Output:
ATC MESSAGES FOR PLAN 2615
DATE/TIME (GMT) STATUS CENTER REFNO SEQNO
SEND BY
04/12/2007-10:31:57 FILING ACCEPTED LFPYZMFP 25240
Entering FI<####>,STAT,ALL shows the filing history (when the flight plan was queued,
submitted, accepted, canceled, and so on).
Example:
01 OPTIONS FI2615,STAT,ALL
Output:

SEND BY
04/12/2007-10:31:04 FILING QUEUED ~~~~ 25238
04/12/2007-10:31
04/12/2007-10:31:37 FILING SUBMITTED ~~~~ 25238
04/12/2007-10:31:57 FILING ACCEPTED LFPYZMFP 25240
Using the SHOW Command

Several input options can be used with the SHOW option. The syntax is as follows:
FI<####><request date>,SHOW,<options 1>,<options 2>

548
ATC Filing
The following table lists the input options that can be used with SHOW.
Table 19-3 FI,SHOW Input Options
Parameter Explanation
#### Plan number
Request Date The date for which you want to look up filing
records.
• To display a specific month, enter: /mm (ex. /03
for March).
• To display a specific day, enter: /mmdd (ex.
/0331 for March 31).
• To display a specific hour, enter: /mmdd/hh (ex.
/0331/17 for 1700Z).
Options 1 One or more of the following options can be entered:

• ALL – Shows all unexpired entries. By default,
these are active entries. Active entries are those
with an ETD/EDD + 90 minutes before the
current time. An expired entry increases this
range by 48 hours. If the ALL option is used, it
must be first.
• Q – Shows queued requests
• S – Shows submitted requests
• R – Shows responded to requests (for
“roger/reject” users only)
• N – Shows requests that were never sent due to
user cancellations.
• T – Shows requests on the queue. This must be
used separately (not used with other options).
NOTE Each option must be separated with a
comma.
Options 2 One or more of the following options can be entered:
• POD (enter the airport designator)

• POA (enter the airport designator)
• Call sign (enter the aircraft call sign)
• ETD entered in one of the following formats:
hhmm
/mm
/mmdd
/mmdd/hhmm
Specifying any of the options 1 or options 2 parameters is optional. However, if the options are
used, they must be entered in the correct order. A comma placeholder must be entered for each
parameter skipped and a comma must always separate each value entered.

549
ATC Filing
The following table lists examples of the various uses of the FI,SHOW command:.
Table 19-4 FI,SHOW Examples
Option Description
FI,SHOW Displays all of the active filed plans.
NOTE This can be a lengthy process.
FI,/mmdd,SHOW Displays all of the active filed plans computed on

specified date.
FI1234,SHOW Displays all of the active filed plans with the specified
plan number (1234).
FI1234,SHOW,ALL Displays all of the filed plans with the specified plan
number (1234) that are still in the FPFHDB, expired
or not.
NOTE This can be a lengthy process.
FI/0630,SHOW, ,SJC,LAX,,0100 Displays active requests computed on specified date

(0630) with specified time (0100) for specified airport
pair (SJC-LAX).
FI/0630,SHOW, ,SJC,LAX,0701/0100 Same as above except that the request further limits
what is displayed to those flights that are also on the
specified date (0701).
FI/mmdd,SHOW,Q,S,SJC,LAX,mmdd/0100 Same as above except that the request further limits

what is displayed to those requests that are still
queued or submitted (not responded to).
FI,SHOW,T Displays the currently, actually queued requests for

this user, including send time (T – must be used
separately).
FI,SHOW,,,,,/0630 Displays the active requests for flights with an EDD

of the specified date (0630).
FI,SHOW,ALL,,,TEST Displays requests for flights with a call sign of

“TEST.”
FI,SHOW,,,TEST Displays only active requests for flights with a call

sign of “TEST.”
Example:
01 OPTIONS FI9618,SHOW
PLAN/mmdd/hh POD POA Calsign ETD SEQNO STATE

9618/0902/22 DEN PDX TEST 09/03-00:00 011 SUBMITTED

550
ATC Filing
Working with Domestic Flight Plan Sequence Numbers

All domestic USA filing strips are assigned a sequence number used for identification by
ATC. Plans filed immediately are not actually sent to ATC until the next minute or so.
Therefore, the sequence number is not immediately available when the plan is filed and
displays as zeros instead, as shown in this example:
XLD0000000 FP TEST B752/Q 0461 DEN P0000 400

DEN.ROCKI4.EKR..MLD..BOI.J15.IMB.BONVL4.PDX/0215 :
TEST
COMPLETE, FLIGHT PLAN #09618 WILL BE FILED NOW AT FOLLOWING AD-

DRESS(ES)
KZDVZQZX
The sequence number can be found by using the FI<####>,STAT or FI<####>,SHOW

commands described above. Before the plan is sent to ATC, it shows as queued but indicates
the scheduled send time. The sequence number is displayed as “TBA.” (For ICAO plans, the
sequence number is blank.)

SEND BY
09/02/2005-22:20:07 FILING QUEUED ~~~~ 10024 TBA

09/02/2005-22:20
After the plan is sent, the sequence number is available using either the FI<####>,STAT or
FI<####>,SHOW command.
Example:
Output:
SEND BY
09/02/2005-22:21:00 FILING SUBMITTED ~~~~ 10027 011

551
ATC Filing
Example:
01 OPTIONS FI9618,SHOW
Output:
PLAN/mmdd/hh POD POA Calsign ETD SEQNO STATE
9618/0902/22 DEN PDX TEST 09/03-00:00 011 SUBMITTED
The new REFNO shows the filing strip with the correct reference number added:
XLD2221003 FP TEST B752/Q 0461 DEN P0000 400

DEN.ROCKI4.EKR..MLD..BOI.J15.IMB.BONVL4.PDX/0215 :
TEST
COMPLETE, FLIGHT PLAN #09618 WILL BE FILED NOW AT FOLLOWING ADDRESS(ES)

KZDVZQZX
Short Autofile Feature

Short Autofile is a feature that is set in your ID/Attribute File and that allows you to store
answers for the Remarks/General Information and Filed By command lines of the JetPlan
Automatic Filing Program. It eliminates the need to enter these inputs manually. The Remarks
command input applies to both domestic and international (ICAO) filings. The Filed By
command input applies to ICAO filings only. Please contact your Jeppesen account manager
to have the Short Autofile feature set.
NOTE To change or add remarks or specify who is filing the flight plan, enter
FI<####> (where<####> is the plan number), followed by the option, HOLD, on the
Options command line. You can then make any changes and/or additions (overrides)
to these and any other filing program command input needed.
Example:
01 OPTIONS FI1234,HOLD
02 AIRCRAFT ID OR CALL SIGN JEPP234
18 REMARKS/GENERAL INFORMATION 3 ENG FERRY
33 DEPARTURE CENTER A KSFOXLDI

552
ATC Filing
Domestic U.S. Filing

NOTE U.S. Domestic Flight Plans (NAS FP) were unaffected by the ICAO 2012 FPL
changes.
To file a domestic flight plan, enter FI and the flight plan number on the Options command
line. The filing program might require other information prior to transmission in order to
clarify the filing message. JetPlan prompts you for needed information. This section reviews
the possible needs.
AIRCRAFT ID OR The aircraft call sign command. This is not required if the aircraft call
CALL SIGN sign or full registration number is entered on the Options command
line when the flight plan is requested. In addition, this is optional if
the CADB contains the necessary information.
REMARKS/ Remarks related to ATC handling command. For example, remarks

GENERAL can include: loss of pressurization, inoperative avionics, and so on.
INFORMATION
Bypass this prompt without specifying an input by pressing the
ENTER key.
1ST ALTERNATE Alternate airport command. This item is optional except when no
AIRPORT alternate is specified in the flight plan request.
JetPlan looks for an alternate airport in the flight plan. You can
bypass this prompt without specifying an alternate airport input by
pressing the ENTER key.
PERSONS ON Persons on board command. This information can be stored in the OB

BOARD parameter in the CADB record. The inputs, ON FILE and TBN (To
Be Notified), are possible entries for this option.
DEPARTURE Filing center command. This option allows the change of the
CENTER departure center address or the addition of extra addresses.
To specify changes or additions, type 33 at the “ENTER QUESTION

NUMBER OR GO” prompt to get the Departure Center command
line prompt.

553
ATC Filing
To change the departure center address, or to override it and add one

or more new addresses, specify the new or additional addresses at the
Departure Center Command. If more than one address is specified,
separate each address with a space.
To include additional addresses in the filing message without

changing the departure address, type the letter A, followed by the
additional addresses at the prompt. Include a comma or a space
between A and the first address. If more than one address is specified,
separate each address with a space.
The following examples highlight the application of the filing program commands for a
domestic flight. These illustrations assume that you do not have the Short Autofile feature set
in your ID/Attribute File.
For this example, assume that an alternate airport has been specified in the flight plan.
Example:
01 OPTIONS FI5330
02 AIRCRAFT ID OR CALL SIGN JD1234
18 REMARKS/GENERAL INFORMATION BOTH ADF INOP
25 PERSONS ON BOARD ON FILE
33 DEPARTURE CENTER A,KSFOXLDI KSFOXHYR
The JetPlan response to a successful domestic filing input is to output the filing message sent
to the ARTCC and a summary statement listing the addresses to which the filing was sent.
This is illustrated below.
Output example:
XLD0249060 FP JD123 H/MD11/R 0470 SFO P0800 370
SFO.PORTE8.AVE.J1.FIM.FIM6.LAX/0055:
COMPLETE, FLIGHT PLAN #5330 TO BE FILED AT FOLLOWING ADDRESS(ES)

KZOAZQZX KSFOXLDI KSFOXHYR
“XLD0249060” includes the Jeppesen DataPlan filing identifier “XLD”, the time of day (0249
UTC), and the sequential number for this filing (this was the 60th filing message since 0000
UTC).
In the next example, assume that no alternate airport has been specified in the flight plan.

554
ATC Filing
Example:
01 OPTIONS FI5330
18 REMARKS/GENERAL INFORMATION <ENTER>
- <ENTER>
20 1ST ALTERNATE AIRPORT KONT
ENTER QUESTION NUMBER OR GO
In this example, two extra AFTN addresses are added.
Example:
01 OPTIONS FI5330
18 REMARKS/GENERAL INFORMATION <ENTER>
- <ENTER>
33 DEPARTURE CENTER A,KSFOXLDI EGKKJPNX
- <ENTER>ENTER QUESTION NUMBER OR GO GO
Canceling a Domestic Flight Plan

To cancel a domestic flight plan, type the command, FI, followed by the flight plan number, a
comma, and the cancel option, CX, on the Options command line. You can cancel a flight plan
up to 90 minutes past the ETD. The cancellation message is sent to all stations that received
the original filing message.
Example:
01 OPTIONS FI5330,CX
The JetPlan response includes the cancellation message (“Remove Strip” message) sent to the
ARTCC and a summary statement listing the addresses to which the cancellation was sent.
XLD0249061 RS JD123
COMPLETE, FLIGHT PLAN #5330 TO BE CANCELED AT FOLLOWING ADDRESS(ES)

KZOAZQZX KSFOXLDI EGKKJPNX

555
C HAPTER 20
Reclear Commands
Reclear Commands
Overview
Overview
The purpose of the reclear flight plan is to legally reduce the reserve fuel required on an
international flight. Achieving this goal affords a corresponding increase in the amount of
payload a flight can carry or the distance it can cover.
International reserve fuel is calculated as a percentage of the fuel required to complete the trip.
However, if the trip is broken up and re-cleared enroute, the operator can safely and legally
carry less reserve fuel. The following example shows how this is accomplished with a reclear
flight plan.
For this example, assume a distance of 6,000 nautical miles, average speed of 500 knots,
average fuel burn of 16,000 pounds/hour, and a reserve fuel requirement of 10% of the trip
fuel.
To fly the trip directly from the Point of Departure (POD) to the Point of Arrival (POA) would
require a total of 211,200 pounds of fuel, as follows:
• Trip time = 12 hours (6,000 nautical miles ÷ 500 knots = 12 hours)

• Trip fuel = 192,000 pounds (12 hours × 16,000 pounds/hour = 192,000
pounds)
• 10% reserve = 19,200 pounds
• Total fuel = 211,200 pounds (trip + reserve)
Now, suppose we select a different airport (the reclear airport) which is along the route of
flight and 5,000 nautical miles from the POD.
Reclear Airport
The fuel required to fly from the POD to the reclear airport is:

• Trip fuel = 160,000 pounds (10 hours × 16,000 pounds/hour = 160,000
pounds)

559
Reclear Commands
Overview
The fuel required to fly from the reclear airport to the POA is:

• Trip fuel = 32,000 pounds (2 hours × 16,000 pounds/hour = 32,000 pounds)
But if we carry the trip fuel for the POD-to-reclear leg and the total fuel for the reclear-to-POA
leg, we satisfy the total fuel requirements for both legs, while actually carrying less fuel than is
required for original POD-to-POA flight:
• POD-to-reclear trip fuel = 160,000 pounds

• Reclear-to-POA total fuel = 35,200 pounds
• Total fuel carried = 195,200 pounds (satisfies the POD-to-reclear
requirement of 176,000 pounds)
This results in a savings of 16,000 pounds of fuel when compared to the original POD-to-POA
flight plan (211,200-195,200).
In order for this approach to work, we must initially plan as if our destination is the reclear
airport. We then determine (at an enroute decision point) if we do, in fact, have enough fuel to
continue to the actual POA. If we do, then the flight is re-cleared to the originally intended
POA. If, for some reason, we do not have enough fuel to continue to the POA, the reclear
airport becomes a convenient diversion airport.
Of course, this example is an oversimplification to illustrate the principles behind a reclear

flight plan. JetPlan takes into account variables such as winds and the location of usable
reclear airports.
Plan Scenarios
JetPlan offers five different reclear scenarios:
• Reclear with known payload value and arrival fuel value.

• Reclear with known payload value and departure fuel value.
• Reclear with known takeoff weight value. JetPlan determines the optimal
payload.
• Reclear with known takeoff fuel value. JetPlan determines the optimal
payload.

560
Reclear Commands
Overview
• Reclear with known landing weight value. JetPlan determines the optimal
payload.
Autoweight Flight Plan Option
If several reclear flight plans are calculated, Jeppesen recommends that you invoke the
Autoweight (AW) flight plan option—or have it set for automatic application by including it
in your User ID/Attribute File. Depending on the given reclear scenario, the Autoweight
option provides the following resolutions:
• It adjusts the payload/fuel/weight case as necessary in order to achieve the

greatest payload increase or the greatest fuel decrease.
• It includes an alert message (“Landing Burnoff Warning”) in the flight plan
output, suggesting the need to either dump fuel or hold in pattern until the
aircraft’s weight is reduced to the maximum landing weight (rather than
simply output an “Exceeds Landing Weight” error message). The specific
amount to be reduced or dumped is included in the alert message.
NOTE For a review of each plan scenario, see “Reclear Scenario Review” on
page 574.
Commands, Options, and Definitions

To request a reclear flight plan, three steps are required. First, invoke the Reclear flight plan
option on the Options command line. Second, enter the reclear point, airport, and alternate (or
Island Reserve value) on the Reclear command line. Finally, request the compression plan.
The following paragraphs describe these steps in more detail.
To request a reclear flight plan, using the command-line

1. On the Options command line, enter one of the following reclear options:
• 01 OPTIONS FP,RC
JetPlan generates a flight plan based on the request, in long or short
form (depending on the use of the SP option), to the intended
destination with full international reserve fuel.
- or -

561
Reclear Commands
Overview
• 01 OPTIONS FP,RCC
JetPlan delivers a long (or short) plan to the intended destination
with full international reserve fuel.
NOTE For output formats that provide two column compression only.
NOTE JetPlan prints only the flight plan numbers from the two reclear plans. The
first number is used for ATC filing.
2. After the non-reclear (original) plan is computed, JetPlan displays the

Reclear command line (02 RECLEAR) prompt. At this prompt enter the
reclear point, airport, and alternate (or Island Reserve) inputs you wish to
apply in the reclear calculations.
Example:
02 RECLEAR NODAN,RJAA,RJTT
JetPlan generates the following:
• Based on the RC option, a short plan to the intended destination
with international reserve fuel from the reclear point
• Based on the RC option, a second short plan to the reclear airport
with full international reserve fuel
• Based on the RCC option, a compression plan
3. For reclear plans run using the RC option, specify the Reclear Compression
Print command (CM) on the Options command line. The reclear flight plan
is compressed to output a comprehensive comparison plan that includes
either a two or three column header section (format dependent). To request a
compression flight plan, enter one of the following inputs on the Options
command line:
• CM1234,1235 – Two column compression. The numbers
(1234,1235) represent the reclear flight plan transaction numbers.
Enter the actual numbers from your plan computations.

562
Reclear Commands
Overview
• CM1234,1235,1236 – Three column compression. The numbers

(1234,1235,1236) represent the flight plan transaction numbers
from the non-reclear and the two reclear flight plans. Enter the
actual numbers from your plan computations.
NOTE The CM command is not necessary with the RCC option because the RCC
option causes the system to compresses the reclear plans automatically.
Output Criteria
To make the second flight plan (first reclear plan—intended destination with partial
international reserves) and the third flight plan (second reclear plan—reclear airport with full
international reserves) consistent for compression, JetPlan ensures that the second and third
flight plans meet the following criteria:
• Both plans have the same takeoff weight.

• Both plans have the same payload.
• Both plans have the same departure fuel.
• Both plans meet or exceed all user input criteria.

563
Reclear Commands
Reclear Command Line Inputs

A Reclear command line input has two basic requirements: 1) a reclear point and 2) a reclear
airport. Without these two items, the reclear calculation cannot proceed. JetPlan allows you to
specifically define both the reclear point and the reclear airport or request that JetPlan make an
automatic selection based on certain principles and database settings.
The reclear alternate is an optional input on the Reclear command line, but it too can be
specifically defined by you or automatically selected by JetPlan. Other options that change or
affect the alternate are also available on the Reclear command line.
Reclear Point Selection

Four different types of inputs can be entered on the Reclear command line to specify a reclear
point (fix or waypoint). Three of the input types are user-defined positions, while the fourth
type requests JetPlan to determine the reclear point for you. Reclear point types and examples
are given below:
Waypoint A waypoint on the non-reclear (original) flight plan’s route of flight

can be used as a reclear point. You can enter the JetPlan ID for this
waypoint or the charted name (NOA or NODAN).
Example:
Explanation: NODAN is entered as the reclear point. RJAA is the

reclear airport, and RJTT is the reclear alternate.
02 RECLEAR NODAN,RJAA,RJTT
Distance A distance value from the intended destination (POA) can be used as
a reclear point. JetPlan scans the waypoint information in the non-
reclear flight plan for the nearest waypoint to the distance value
entered. The waypoint on the route of flight found to be the nearest to
the selected distance is then used as the reclear point (for example,
400M).

564
Reclear Commands
Example:
Explanation: The reclear point is a waypoint on the route of flight that

most closely approximates the specified distance (400M) from the
intended POA. KSFO is the reclear airport, and KOAK is the reclear
alternate.
02 RECLEAR 400M,KSFO,KOAK
Coordinate A latitude or longitude value can be used as a reclear point. The value
entered must include the hemisphere identifier (N, S, E, or W
appended to the value). JetPlan scans the waypoint information in the
non-reclear flight plan for the nearest waypoint to the entered
coordinate. The waypoint on the route of flight found to be the nearest
to the specified coordinate is then used as the reclear point (130W).
Example:
Explanation: The reclear point is a waypoint on the route of flight that

most closely approximates the 130 West longitude. KSFO is the
reclear airport and KOAK is the reclear alternate.
02 RECLEAR 130W,KSFO,KOAK
Auto Selection Entering $AUTO or $AUTO,D instructs JetPlan to automatically

select the reclear point.
The automatically selected reclear point is a fix (waypoint) on the

non-reclear plan’s route of flight. JetPlan determines the reclear point
based on the following theory:
The optimal reclear point is an equal fuel point. This is the point
where the fuel required for the flight from the POD to the reclear
airport exactly matches the fuel required for the flight from the POD
to the actual POA (with the appropriate reserve fuel included in each
scenario).

565
Reclear Commands
To attain the optimal reclear point, JetPlan applies the following

methodology:
Using a formula to solve for the equal fuel point, JetPlan accurately
determines the optimal point. The nearest fix (found on the non-
reclear plan’s route of flight) to the optimal point is then selected as
the reclear point.
NOTE Despite the fact that the reclear point is not precisely the optimal point, the
results are very accurate. However, this methodology can produce some odd results,
such as backtracking to the reclear airport, or—in the case of both airports (reclear
and POA) being in close proximity—long distances between the reclear point and
both airports.
Example:
Explanation: The reclear point is the waypoint on the route of flight

that most closely approximates the calculated equal fuel point (as
defined previously). KSFO is the reclear airport, and KOAK is the
reclear alternate.
02 RECLEAR $AUTO,KSFO,KOAK
Reclear Airport and Alternate Selection

The reclear airport and reclear alternate inputs are typically defined by entering the ICAO
identifier for each station. However, like the reclear point, you can use the $AUTO option to
instruct JetPlan to automatically select these items.
Auto Selection (Reclear Airport and Alternate)

JetPlan’s auto selection capability can be applied to the reclear airport and the reclear alternate
when the $AUTO option is entered in the appropriate field. However, to perform this
capability, JetPlan must be able to find candidate airports from those stored in specific
customer databases. For reclear airports, this means storing stations in your Customer Airport
Database (CAPD).
To save an airport record in your CAPD, enter the AP access command on the 01 Options
command line, followed by the save option (SAV) and the ICAO identifier of the airport you
want to store.

566
Reclear Commands
Example:
01 OPTIONS AP,SAV,RJAA
NOTE For the purpose of the Reclear option, your input can be kept to a minimum
(as shown above). However, you can include additional parameter settings with each
AP,SAV input. For more information about parameter settings, see the Customer
Airport Database chapter or the Help file for the CAPD on JetPlan.com.
The airport selected by JetPlan as the reclear airport is the one that meets specific internal
requirements for the flight.
For the reclear alternate the application of the $AUTO option requires the storage of
information in the Customer Alternate Database.
To save an alternate airport record in your alternate database, enter the access command, ALT,
followed by the add option (ADD), the ICAO identifier of the airport for which the alternate
applies, the ICAO identifier of the alternate airport, and a distance value or a route file name
from your Customer Route Database (CRDB).
Example:
01 OPTIONS ALT,ADD,KLAX,KSAN,90
NOTE To use a route file name (rather than a distance value), you must first store
the route in your CRDB. For more information about saving alternate and route
records in customer databases, see the Customer Alternate Database and the
Customer Route Database chapters or the Help files for these databases on
JetPlan.com.
The following examples illustrate the use of the $AUTO option for reclear airports and reclear
alternates.
Example:
Explanation: Select the best reclear airport from the set of airports available in the Customer
Airport Database. Note that the waypoint, CVC, is the selected reclear point and the airport,
RJTT, is the selected reclear alternate.
02 RECLEAR CVC,$AUTO,RJTT

567
Reclear Commands
Example:
Explanation: Select the best reclear alternate from the set of alternates available for RJAA in
the Customer Alternate Database. Note that the waypoint, CVC, is the selected reclear point
and the airport, RJAA, is the selected reclear airport.
02 RECLEAR CVC,RJAA,$AUTO
Example:
Explanation: First, select the best reclear airport from the CAPD. Second, using the
automatically selected reclear airport, find a corresponding alternate from the Alternate
Database. If the reclear airport has no records in the Customer Alternate Database, an error
occurs. Note that the waypoint, CVC, is the selected reclear point.
02 RECLEAR CVC,$AUTO,$AUTO
Example:
Explanation: This example applies the auto select feature to all three fields.
02 RECLEAR $AUTO,$AUTO,$AUTO
- or -
02 RECLEAR $AUTO (works the same as entering three $AUTO inputs)
Entering the Auto Selection option, $AUTO, as your input for all three fields instructs JetPlan
to determine your reclear airport, an alternate stored for that airport, and then find the optimal
reclear point based on the identified reclear airport.

568
Reclear Commands
Other Reclear Options

To this point, the reclear examples provided have included the basic inputs of the reclear point,
the reclear airport, and the reclear alternate airport only. However, additional options are
available to define certain alternate and reserve situations. These additional options are
standard JetPlan options already described in other sections of this manual. The following list
identifies the options that you can add to the Reclear command line:
Alternate airport This distance bias works for the reclear alternate in the same manner
distance bias as the conventional alternate bias. To apply a distance bias to the
reclear alternate, enter a slash and the distance value (in nautical
miles or kilometers) after the reclear alternate input.
Example:
02 RECLEAR 130W,KSFO,KOAK/50
Alternate airport This holding time works for the reclear alternate in the same manner
holding time as the conventional alternate holding time. For example, a standard,
non-reclear flight plan request might include the following input on
the Hold (Alternate/Distance) command line.
Example:
07 HOLD,ALTERNATE/DIST 30,EFHK
However, in a reclear flight plan, a hold time for the reclear alternate
airport is entered on the Reclear command line between the reclear
airport input and the reclear alternate input. See the following
example.

569
Reclear Commands
Example:
Explanation: The input, 45, changes the hold time from the default
value of 30 minutes to a hold time of 45 minutes.
02 RECLEAR 400M,ENFB,45,ENGM
NOTE The standard (default) holding time value for the reclear alternate is 30
minutes. Enter a different value, like the preceding example, if a time other than 30
minutes is needed.
NOTE The holding time input does not affect the calculation of international reserve
fuel.
Reserve fuel A reserve fuel can be added to the reclear flight via the Reclear
command line. The value entered (in minutes) must be prefixed with
the letter, I or D. Typically, I stands for island reserve and D stands
for domestic reserve, but in this case the two letters are
interchangeable. The reserve fuel amount is calculated using the fuel
flow from the last cruise segment before Top of Descent (TOD). The
input of an alternate airport is optional. The default hold fuel amount
for the reclear airport (30 minutes) is eliminated unless specifically
added to the request.
Example:
Explanation: I120 requests 120 minutes of island reserve fuel.
02 RECLEAR 006E,ENFB,I120
These options can be applied to the same flight plan as the options in
the next example.
Example:
Explanation: 120 minute Island reserves and 60 nautical miles bias to

reclear alternate airport.
02 RECLEAR 006E,ENFB,I120,ENGM/60

570
Reclear Commands
Example:
Explanation: 120 minute Island reserves and 30 minute hold.
02 RECLEAR 4640,LPLA,I120,30
Route Selection for Reclear

JetPlan typically determines the routing from the reclear point to the reclear airport. The Route
Optimizer (RO) applies the nav optimize method to make this determination—selecting the
best combination of airways and direct segments to complete the route.
User-Defined Routing for Reclear

Some instances can require you to apply your own route input. In those instances you have the
following options:
• You can request a direct route from the reclear point to the reclear airport by
entering the letter D (for direct) between the two inputs on the Reclear
command line. This means that the navigational route structure is ignored
and direct segments are created to get from the reclear point to the reclear
airport.
Example:
02 RECLEAR 5070,D,PANC,PAFA
NOTE This entry does not work when the reclear waypoint and the reclear airport
are both in Area 0. See next example.
Example:
Explanation: Reclear point and reclear airport are both in Area 0. Do not use
the D input.
02 RECLEAR 4030,LPLA,LPAZ
NOTE See the Route Commands chapter for more information about the Route
Optimizer, route areas, and Area 0 route inputs.

571
Reclear Commands
• You can request a canned (previously stored) track from the reclear point to
the reclear airport. A canned track file must be available between the two
(the specific reclear point and the specific reclear airport). If one is
available, then the input is as follows:
02 RECLEAR <reclear point,/three-character canned track name,reclear
airport,remainder of input>
See the example below.
Example:
02 RECLEAR NINNA,/NP1,PANC,PAFA
NOTE Canned tracks are relatively scarce on the JetPlan system. Therefore, this
option is rare.
Table 20-1 lists the canned tracks that currently exist and are available for this purpose. The
table lists the canned track file name (ID) and the start and end points of each track.
Table 20-1 Canned Tracks Available for Reclear Routing
ID Start/End ID Start/End
AN1 JED / LOWW NP7 ONEIL / PAFA
AN4 MAG / EDDF NP8 ONEIL / PAKN
AN5 CDA / EDDF NP9 ONEMU / RJCC
AN6 ALS / EDDF 1AN TEB / EKCH
AN7 SORLA / EKCH 2AN SVD / EHAM
AN8 CDA / EHAM 3AN IKADA / RJCC

AN9 SPB / EFHK 4AN SCORE / RJAA
AN0 SPB / ESSA 5AN VACKY / RJAA
EE1 VELTA / RJCC 6AN SMOLT / RJAA
KA1 NUBDA / RJCC 7AN FORDO / RJAA
NP1 NINNA / PANC 8AN JNS / ESSA
NP2 ONEIL / PANC 9AN AGAMO / EFHK
NP3 NINNA / PAFA 0AN AGAMO / ESSA
NP6 NINNA / PAKN

572
Reclear Commands
Routing when Using the Auto Select Option

Routing from the automatically selected reclear point to the reclear airport is determined by
the input used, as follows:
• If $AUTO is entered, JetPlan’s Route Optimizer uses the nav optimize

method for determining the route. This means that the best combination of
airways and direct segments within the navigational route structure is used
to get from the reclear point to the reclear airport.
• If $AUTO,D is entered, JetPlan’s Route Optimizer uses the optimize direct
method for determining the route. This means that the navigational route
structure is ignored and direct segments are created to get from the reclear
point to the reclear airport.
NOTE See the Route Commands chapter for more information on the Route
Optimizer.
Example:
02 RECLEAR $AUTO,RJAA,RJTT (nav optimize)
- or -
02 RECLEAR $AUTO,D,RJCC,RJCH (optimize direct)

573
Reclear Commands
Reclear Scenario Review

The following sections review each of the possible plan scenarios when running reclear flight
plans.
Known Payload
This arrival case scenario is used to minimize the required fuel when the payload is a known
value. JetPlan applies the following criteria to the calculations and output for the Known
Payload case.
• JetPlan calculates four flight plans internally, of which the first three are run
in the arrival fuel case:
– Flight plan 1 – POD to POA with full international reserve fuel.
– Flight plan 2 – POD to POA with international reserve fuel from the
reclear point.
– Flight plan 3 – POD to reclear airport, with full international reserve
fuel.
– Flight plan 4 – JetPlan compares the fuel amounts required for flight
plans 2 and 3 and flags for output the one that requires more fuel.
Taking the other plan (the one that requires less fuel), JetPlan
recalculates it in a departure fuel case, and flags it for output as
flight plan 4.
• JetPlan always outputs flight plan 1. It outputs either flight plan 2 or plan 3
(whichever requires more fuel). Finally, it outputs flight plan 4.
Known Takeoff Weight/Optimum Payload

This scenario is used to maximize the payload when the takeoff weight is a known value. The
following criteria apply to the calculations and output for the “Known Takeoff Weight” case.
• JetPlan calculates four flight plans internally, all of which are run in the
departure weight case:
• Flight plan 1 – POD to POA with full international reserve fuel.
• Flight plan 2 – POD to POA with international reserve fuel from the
reclear point.

574
Reclear Commands
• Flight plan 3 – POD to reclear airport, with full international reserve

fuel.
• Flight plan 4 – JetPlan compares the payloads calculated for flight
plans 2 and 3 and flags for output the one with less payload (the
more restrictive of the two). Taking the other plan (the one that
provides more payload), JetPlan recalculates it using the lighter
payload in a Tanker Fuel/Departure Weight Case. This is flight plan
4, which is also flagged for output.
• JetPlan always outputs flight plan 1. It outputs either flight plan 2 or plan 3,
whichever plan allows less payload. Finally, it outputs flight plan 4.
Known Takeoff Fuel/Optimum Payload

This scenario is used to maximize the allowable payload when the takeoff fuel is a known
value. It is frequently used when the “Reclear With Known Takeoff Weight” scenario results
in weight or fuel limits exceeded, thus obstructing the output of the reclear flight plans and
compression. This can occur on long flights, especially with a strong headwind component.
The following criteria apply to the calculations and output for the “Known Takeoff Fuel” case.
• JetPlan calculates four flight plans internally, all of which are run in the
departure fuel case:
reclear point.
• Flight plan 3 – POD to reclear airport, with full international reserve
fuel.
• Flight plan 4 – JetPlan compares the payloads calculated for flight
plans 2 and 3 and flags for output the one with less payload (the
more restrictive of the two). Taking the other plan (the one that
provides more payload), JetPlan recalculates it using the lighter
payload. This is plan 4, which is also flagged for output.
• JetPlan always outputs flight plan 1. It outputs either flight plan 2 or plan 3,
whichever plan allows less payload. Finally, it outputs plan 4.

575
Reclear Commands
Known Landing Weight/Optimum Payload

This scenario is used to maximize the allowable payload when the landing weight is a known
value. It is the least used of all the reclear scenarios because of the payload restrictions
calculated during the computations to match weights. The following criteria apply to the
calculations and output for the “Known Landing Weight” case.
• JetPlan calculates five flight plans internally:

reclear point.
• Flight plan 3 – POD to reclear airport with full international reserve.
• Flight plan 4 – JetPlan compares the takeoff weights calculated for
flight plans 2 and 3. It then takes the lower takeoff weight amount
from the two plans and plugs it into the plan that had the higher
takeoff weight and calculates a new plan. This is flight plan 4. In
effect, this matches the takeoff weights for flight plans 2 and 3.
• Flight plan 5 – In addition to comparing takeoff weights, JetPlan
compares the payloads of the two plans that now have the same
takeoff weight (flight plan 4 and either plan 2 or 3—whichever
originally had the lower takeoff weight). In doing this comparison,
JetPlan takes the flight plan with the higher payload and recalculates
it using the lower payload amount. This results in flight plan 5.
JetPlan needs to match not only the takeoff weights for flight plans
2 and 3, but also the payload and takeoff fuel. This keeps the plans
consistent for compression.
• JetPlan always outputs flight plan 1. It outputs flight plan 4, which is either
flight plan 2 or 3 with the lighter takeoff weight and lesser payload. Finally,
it outputs flight plan 5, which is either flight plan 2 or plan 3 rerun in a
tanker case to reduce the initially heavier payload to the lighter payload of
the other plan.

576
Reclear Commands
Landing Burnoff Calculations
Landing Burnoff Calculations

If you select a reclear point and reclear airport combination that causes one or both of the
reclear flight plans to exceed the aircraft's maximum landing weight, JetPlan offers the
following two options:
1. Print out an “Exceed Landing Weight” (XLWnnnnn) error and stop the
reclear flight planning process.
2. Print out a warning statement and process the reclear flight plans using the
aircraft's maximum landing weight.
NOTE Both solutions require the use of autoweight, either as an option or as a

parameter setting in your ID/Attribute File. See the information on Automatic Weight
Reiteration (Autoweight) in Chapter 14, “Payload, POD/POA, Weight, and Fuel
Commands.” Contact your Jeppesen account manager for more information.
When the first option is chosen, JetPlan uses the maximum landing weight stored in the CADB
file, or, in the case of a generic aircraft, in the generic aircraft data file.
When the second option is preferred, the following statement appears in reclear flight plans
that have exceeded the maximum landing weight:
*** WARNING LBO ASSUMED IN LANDING WEIGHT CALCULATION ***
LBO is the acronym for landing burnoff. This value is the amount of fuel that needs to be
burned off (or dumped) to bring the aircraft’s weight down to the maximum for landing. That
value is found in the CADB or generic aircraft data file.

577
Reclear Commands
Examples of Reclear Flight Plans

This section illustrates examples of reclear flight plans for the following scenarios:
• Known payload, arrival fuel case

• Unknown payload, departure weight case
• Unknown payload, departure fuel case
NOTE These examples demonstrate only one compression flight plan. They show
the inputs for each set of reclear flight plans, followed by pertinent remarks. Both
reclear flight plans (the flight plan to the intended destination with reduced reserves
and the flight plan to the reclear airport) output the letter R after the date on the top
line of the flight plan. The compression plan outputs the letter C after the date on the
top line of the flight plan.
Inputs for Known Payload (Arrival Fuel Case)

The following inputs were used to obtain the known payload, arrival fuel case scenario reclear
flight plans. (See plans numbered 8120, 8124, 8129 in “Reclear Example Output” on
page 581.)
Example:
01 OPTIONS FP,RC,SP
02 POD KJFK/CYQX
03 POA LYBE/EINN
06 ROUTE P/Z/J
07 HOLD,ALTERNATE/DIST 30,LQSA
08 ETD 0100
09 PROFILE C
10 A/C TYPE/REGN $DC8-73
11 CRUISE MODE M80
14 PAYLOAD 65000
The first flight plan (8120), KJFK to LYBE with full international reserve fuel, requires
109,203 pounds of fuel. The more restrictive reclear plan requires only 101,612 pounds of
fuel.

578
Reclear Commands
The flight plan (8124) from KJFK to LYBE with international reserve fuel from the reclear
point (KOK) does not show any extra fuel (XTR). This indicates that it is more restrictive than
the flight plan from KJFK to EDDF (8129) with full international reserve fuel, which shows
5,200 pounds extra fuel.
The compression flight plan (8136) has a header composed of the data from the two reclear
plans (8124 and 8129). It has two complete flight plan bodies: (1) KJFK to LYBE and (2)
KJFK to EDDF. Only the compression header is illustrated in the text.
Inputs for Unknown Payload (Departure Weight Case)

The following inputs were used to obtain the “unknown payload, departure weight case”
scenario reclear flight plans. (See plans numbered 8152, 8164, and 8171 in “Reclear Example
Output” on page 581.)
Example:
01 OPTIONS FP,RC,SP
02 POD KJFK/CYQX
03 POA LYBE/EINN
06 ROUTE P/Z/J
08 ETD 0100
09 PROFILE C
11 CRUISE MODE M80
14 PAYLOAD ZW
Notice the payload differences between the first, second, and third flight plans. The first plan
(8152) allows 69,765 pounds payload without taking advantage of the reclear option. The
payload increases to 75,984 pounds in the reclear plans (8164 and 8171).
the flight plan (8171) from KJFK to EDDF with full international reserve fuel, which shows

579
Reclear Commands
Inputs for Unknown Payload (Departure Fuel Case)

The following inputs were used to obtain the “unknown payload, departure fuel case” scenario
reclear flight plans. (See plans numbered 8173, 8180, and, 8182 in “Reclear Example Output”
on page 581.)
Example:
01 OPTIONS FP,RC,SP
02 POD KJFK/CYQX
03 POA LYBE/EINN
06 ROUTE P/Z/J
08 ETD 0100
09 PROFILE C
11 CRUISE MODE M80
14 PAYLOAD F
16 POD OR POA FUEL D100000,I
All three flight plans were calculated based on a takeoff fuel load of 100,000 pounds. Notice
the payload differences between the first, second, and third flight plans. The first plan (8173)
allows 35,203 pounds payload without taking advantage of the reclear option. The payload
increases to 57,710 pounds in the reclear plans (8180 and 8182).
the flight plan (8182) from KJFK to EDDF with full international reserve fuel, which shows

580
Reclear Commands
Reclear Example Output

This section contains examples of flight plan output.

581
Reclear Commands
The user input on 02 RECLEAR for this flight plan is:
02 RECLEAR KOK,EDDF,EDDM

582
Reclear Commands
The user input on 01 OPTIONS to compress these plans is:
01 OPTIONS CM8124,8129

583
Reclear Commands

584
Reclear Commands

585
Reclear Commands

586
Reclear Commands
Decision Point Procedure

Decision Point Procedure (DPP) is a EU-OPS compliant fuel policy (Reg. 1.255) which allows
you to legally reduce international fuel reserves. It is available only to those customers with
the EU-OPS attribute set in their ID/Attribute File (contact Jeppesen Customer Service for this
attribute setting). The policy requires that the operator carry reserves based on one of two
scenarios:
• Contingency fuel equaling no less than 5% of the estimated fuel

consumption from the decision point to the destination airport
- or -
• Contingency fuel equaling no less than 3% of the estimated fuel
consumption from the departure airport to the enroute alternate.
DPP Usage
DPP is used in conjunction with the Reclear and Flight Plan commands on the Options
command line. The following example demonstrates a Decision Point Procedure entry.
Example:
01 OPTIONS FP,RC,DPP
Using the figure below, JetPlan produces the following outputs:
1. A long or short plan (per user’s request) from POD to POA with a full
international fuel reserve policy of 5%.
2. A short plan from POD to POA (via Decision Point) with international
reserve fuel of 5% computed from Decision Point to POA (second plan).

587
Reclear Commands
3. A short plan from POD to reclear airport (via Decision Point) with full
international fuel reserve policy of 3% (third plan).
In both plans 2 and 3, the total amount of fuel carried is the greater of those
two fuel scenarios.
4. For those users with formats that are compressible, a compressed plan can
be attained entering the CM command on the Options command line.
A compression plan can also be attained automatically by using the RCC
command on the Options command line.
Example:
01 OPTIONS FP,RCC,DPP
EU-OPS Attribute
As stated previously, the DPP option is only available to those customers with the EU-OPS
attribute set in the ID/Attribute File. The following information depicts how JetPlan handles
computations when the proper attribute is set and when it is not.
• EU-OPS ID attribute set

– User invokes the RC option:
JetPlan conducts the reclear planning sequence using the fuel
reserve policy stored in the ID/Attribute File (for example, 5%) and
according to the current functionality.
– User invokes the RC,DPP options:
JetPlan conducts the DPP planning sequence in agreement with EU-
OPS 1.255 regarding the fuel policy.
– User specifies an enroute alternate (ERA), with the RC,DPP option:
The ERA is ignored and the DPP plan is computed. For more
information on ERA, see Chapter 14, “Payload, POD/POA, Weight,
and Fuel Commands.”
• EU-OPS ID attribute not set
– User invokes the RC option:
JetPlan conducts the reclear planning sequence as normal.
– User invokes the RC,DPP options:
JetPlan ignores the DPP option.

588
C HAPTER 21
ETOPS
ETOPS
Overview
Overview
The “ETOPS” chapter in the JetPlan User Manual has been superseded by the ETOPS User’s
Guide: 2 Engine Aircraft, which can be found on the User Manuals page on JetPlan.com.
The JetPlan User Manual contains information on customer database parameters related to
ETOPS in the following chapters:
• Chapter 27, “Customer Aircraft Database.”

• Chapter 28, “Aircraft Fleet Database.”
• Chapter 30, “Customer Airport Database.”
• Chapter 31, “Airport Fleet Database.”
• Chapter 34, “City Pair Fleet Database.”
• Chapter 38, “Minimum Equipment List Database.”

591
C HAPTER 22
Overwater Driftdown
and Terrain Analysis
Overwater Driftdown and Terrain Analysis
Overview
Overview
The Overwater (Basic) Driftdown and Terrain Analysis features are intended to help verify
compliance with the following regulations that ensure the safety of flight in emergencies:
• FAR 121.191 defines the operational limitations with one-engine

inoperative.
• FAR 121.193 defines the operational limitations with two-engines
inoperative.
• FAR 121.646 defines an additional critical fuel analysis to account for a
rapid decompression scenario when operating more than 90 minutes from an
adequate airport.
This chapter describes the following terrain clearance and driftdown features available on the
JetPlan system:
• Overwater Driftdown (with MORA check) – Most JetPlan users can access
this feature, as long as their generic aircraft database contains the necessary
data. You can invoke Overwater Driftdown by doing one of the following:
– By entering the Driftdown or Driftdown Extended Information
flight plan command in a front-end flight-planning product that
interfaces with JetPlan, such as JetPlanner.
- or -
– By typing FP,DRFT for Driftdown or FP,DRFTX for Driftdown
Extended Information on the 01 Options command line in JetPlan.
NOTE In the front-end products that interface with JetPlan, the names of the
Driftdown and Driftdown Extended Information options can vary slightly. Please see
the documentation for your product.
• Terrain Analysis – Terrain Analysis refers collectively to Terrain Clearance

and Mountain Driftdown, which is separate from Overwater Driftdown.
NOTE Terrain Analysis is not available through the JetPlan command-line interface.
It requires a Jeppesen front-end flight planning product or a customer software
application designed to interface with JetPlan. Consult your product documentation
for instructions on invoking the Terrain Analysis options.

595
Overview
FAR Regulations
The following paragraphs provide additional information on the federal regulations governing
terrain clearance in emergency situations.
FAR 121.191 – One Engine Inoperative

FAR 121.191 requires operators to comply with one of the following:
• A positive slope exists at an altitude of at least 1,000 feet above all terrain
and obstructions within five statue miles of each side of the intended track.
A positive slope exists at 1,500 feet above the airport where the airplane is
assumed to land after engine failure.
• The net flight path allows the airplane to continue flight from the cruising
altitude to an airport where a landing can be made under FAR 121.197
(alternate airport), clearing all terrain and obstructions within five statue
miles of the intended flight track by at least 2,000 feet vertically. A positive
slope exists at 1,500 feet above the airport where the airplane is assumed to
land after engine failure.
FAR 121.191 assumes the following conditions:
• The engine fails at the most critical point enroute.

• The airplane passes over the critical obstruction after engine failure at a
point that is no closer to the obstruction than the nearest approved radio
navigation fix, unless a different procedure is authorized.
• An approved method is used to allow for adverse winds.
• If the crew is trained for it, fuel dumping is allowed.
• The alternate airport meets prescribed weather minimums.
FAR 121.193 – Two Engines Inoperative

FAR 121.193 requires operators to comply with one of the following:
• At no place along the route of flight is the aircraft more than 90 minutes
flying time with all engines operating at cruise power from an airport that
satisfies the alternate airport requirements of FAR121.197 (alternate
airport).

596
Overview
• The net flight path allows the airplane to fly from the point where the two
engines are assumed to fail simultaneously to an airport that satisfies the
requirements of FAR 121.197, with the net flight path clearing vertically by
at least 2,000 feet all terrain and obstructions within five statute miles on
each side of the intended track.
FAR 121.193 assumes the following conditions:
• Two engines fail at the most critical point enroute.

• The net flight path has a positive slope at 1,500 feet above the airport where
the landing is assumed to be made after the engines fail.
• If the crew is trained for it, fuel dumping is approved.
• The airplane's weight at the point where the two engines are assumed to fail
provides enough fuel to continue to the diversion airport, to arrive at an
altitude of at least 1,500 feet directly over the airport, and thereafter to fly
for 15 minutes at cruise power or thrust or both.

597
Overwater (Basic) Driftdown

The Overwater Driftdown feature is designed to determine the critical fuel shortfall for a given
flight and address it by ensuring that enough fuel exists on board for the worst case scenario,
even at the expense of payload.
Overwater Driftdown uses user-specified enroute alternates and Equal Time Points (ETPs)
along the primary flight path, and reports MORA heights along the forward and backward path
from each ETP to each associated enroute alternate. One-engine out, two-engines-out, and
depressurization scenarios are analyzed.
The system supports Overwater Driftdown with two flight plan options: Driftdown and
Driftdown Extended. Both Driftdown and Driftdown Extended provide critical fuel data based
on ETP information you provide, but Driftdown Extended also provides extended information
on the flight plan through a detailed fuel analysis of the computed flight.
The following sections provide more information on Overwater Driftdown setup

requirements, flight plan calculation, and output.
NOTE In the JetPlan command-line interface, FP,DRFT invokes Driftdown, and

FP,DRFTX invokes Driftdown Extended. This chapter includes examples of FP,DRFT
and FP,DRFTX. If you are using a front-end product such as JetPlanner, see your
product documentation for instructions on selecting the Driftdown options.

598
Overwater Driftdown Setup Requirements

This section describes how your customer databases must be configured to support Overwater
Driftdown.
NOTE For complete information about fulfilling the prerequisites for the Overwater
Driftdown feature, contact your Jeppesen account manager.

The following table lists the Customer Airport Fleet database parameters that apply to
Overwater Driftdown. For detailed descriptions, see Chapter 31, “Airport Fleet Database.”
Table 22-1 Airport Fleet Database Parameters Used in Overwater Driftdown
Parameter Description
Enroute Alternate Defines the key airport as available for use as an
(EA) enroute alternate for the key fleet type.
When set to Yes, this parameter indicates that the
airport is available for use in the entry and exit point
calculations in the automatic driftdown process or for
ETOPS alternate selection.
Input value: Yes/No
Enroute Alternate in ETOPS/Overwater Driftdown Activates the key airport as a possible enroute
Operations alternate in the automatic alternate selection process
(ET) when either the ETOPS or the Overwater (Basic)
Driftdown feature is used in the flight plan.

599
ETP Database
In Overwater Driftdown processing, user-supplied aircraft performance factors dictate the
determination of the ETPs. These factors include situational cruise modes, flight levels, and
true airspeeds, all of which are addressed in the ETP database, a subsection of the CADB. The
following table briefly describes these parameters. For detailed descriptions, see Chapter 27,
“Customer Aircraft Database.”
NOTE The only ETP database parameters necessary for Overwater Driftdown are
EA, EM/EF, EA1, EM1/EF1, and—if more than two engines—EA2 and EM2/EF2.
NOTE The information in the ETP database is applicable to Overwater Driftdown

but not to Mountain Driftdown. Mountain Driftdown is described in the “Terrain
Analysis” section of this chapter.
Table 22-2 Overwater Driftdown – ETP Database Parameters
Non-emergency ETP True Airspeed This parameter is for customers who wish to perform
(NA) the basic ETP calculation without being at a
depressurized flight level. If a value is entered here,
JetPlan ignores the EA parameter.
Non-emergency ETP Flight Level The NF parameter does not accept a millibar input,
(NF) only a flight level. This parameter is for customers
who wish to perform the basic ETP calculation
without being at a depressurized flight level. If a value
is entered here, JetPlan ignores the EM parameter.
ETP O2 Time Indicates the time in minutes that oxygen is available

(OX) for use after depressurization occurs. Use this
parameter with the ETP O2 FL x100 FT parameter
ETP O2 FL x100 FT Indicates the flight level at which the aircraft can
(OF) cruise while depressurized and using oxygen. Set this
value only when ETP O2 Time (OX) is set to a
- or -
positive value. OF is the flight level in feet; OL is the
ETP O2 Millibars flight level in millibars.
(OL)
ETP Cruise Mode Low-level (depressurized) ETP Cruise Mode Table.

(EC) Entry must coincide with table performance data
within the generic aircraft data file. This parameter
provides cruise data, based on the aircraft’s weight
and the weather conditions, for the actual driftdown
segment under an all-engine, low-level scenario.

600
Table 22-2 Overwater Driftdown – ETP Database Parameters (continued)
ETP Cruise Mode (Anti-Ice On) Low-level (depressurized) ETP Cruise Mode Table -
(ECA) Anti-Ice on. Entry must coincide with table
performance data within the generic aircraft data file.
ETP Cruise Mode (Anti-Ice Off) Low-level (depressurized) ETP Cruise Mode Table -
(ECN) Anti-Ice off. Entry must coincide with table
ETP True Airspeed Low-level (depressurized) ETP True Airspeed

(EA) constant. This parameter provides the airspeed used in
the ETP selection process under the all-engine, low-
level scenario.
ETP Flight Level Low-level (depressurized) ETP Millibar constant.

(EF) (May be replaced with the flight level parameter EF,
for which an actual flight level value is entered.) This
- or -
parameter provides the altitude at which winds are
ETP Millibars averaged for the ETP selection process under the all-
(EM) engine, low-level scenario.
ETP Hold Time Scenario: All-engine, depressurized

(EH) Provides a reserve fuel that is used in the ETP worst
- or - case (critical) fuel calculation for the all-engine, low-
level scenario.
ETP Reserve Fuel
The EH parameter defines a hold time for the purpose
(EX)
of providing a reserve fuel. The input value is a one to
three-digit time entry in minutes. Example: EH=15
The EX parameter defines a specific amount of
reserve fuel. The input value is a one to six-digit fuel
entry in pounds or kilograms. Example: EX=2500
NOTE The EH and EX parameters are mutually
exclusive. You can use one or the other but not both.
ETP 1LE Cruise Mode One-engine inoperative (1LE) ETP Cruise Mode
(EC1) Table. Entry must coincide with table performance
data within the generic aircraft data file. This
parameter provides cruise data, based on the aircraft’s
weight and the weather conditions, for the actual
driftdown segment under a one-engine out scenario.
ETP 1LE Cruise Mode (Anti-Ice On) One-engine inoperative (1LE) ETP Cruise Mode -
(ECA1) Anti-Ice On. Entry must coincide with table
ETP 1LE Cruise Mode (Anti-Ice Off) One-engine inoperative (1LE) ETP Cruise Mode -
(ECN1) Anti-Ice Off. Entry must coincide with table
ETP 1LE Descent (Anti-Ice On) One-engine inoperative (1LE) ETP Descent - Anti-Ice
(EDA1) On.

601
ETP 1LE Descent (Anti-Ice Off) One-engine inoperative (1LE) ETP Descent - Anti-Ice
(EDN1) Off
ETP 1LE True Airspeed One-engine inoperative (1LE) ETP True Airspeed
(EA1) constant. This parameter provides the airspeed used in
the ETP selection process under the one-engine out
scenario.
ETP 1LE Flight Level One-engine inoperative (1LE) ETP Millibar constant.
(EF1) (May be replaced with the flight level parameter EF1,
in which an actual flight level value is entered.) This
- or -
ETP 1LE Millibars averaged for the ETP selection process under the one-
(EM1) engine out scenario.
ETP 1LE Hold Time Scenario: One engine-out, depressurized

(EH1) The EH1 and EX1 parameters are similar to the EH
- or - and EX parameters but are applicable to the one
engine-out, low-level scenario (Driftdown). Example:
ETP 1LE Reserve Fuel
EH1=120 or EX1=2250.
(EX1)
NOTE The EH1 and EX1 parameters are mutually
ETP 2LE Cruise Mode Two-engine inoperative (2LE) ETP Cruise Mode
(EC2) Table. Entry must coincide with table performance
data within the generic aircraft data file. This
parameter provides cruise data, based on the aircraft’s
weight and the weather conditions, for the actual
driftdown segment under a two-engine out scenario.
ETP 2LE Cruise Mode (Anti-Ice On) Two-engine inoperative (2LE) ETP Cruise Mode -
(ECA2) Anti-Ice On. Entry must coincide with table
ETP 2LE Cruise Mode (Anti-Ice Off) Two-engine inoperative (2LE) ETP Cruise Mode -
(ECN2) Anti-Ice Off. Entry must coincide with table
ETP 2LE Descent (Anti-Ice On) Two-engine inoperative (2LE) ETP Descent - Anti-Ice
(EDA2) On
ETP 2LE Descent (Anti-Ice Off) Two-engine inoperative (2LE) ETP Descent - Anti-Ice
(EDN2) Off
ETP 2LE True Airspeed Two-engine inoperative (2LE) ETP True Airspeed
(EA2) constant. This parameter provides the airspeed used in
the ETP selection process under the two-engine out
scenario.

602
ETP 2LE Millibars Two-engine inoperative (2LE) ETP Millibar constant.
(EM2) (May be replaced with the flight level parameter EF2,
in which an actual flight level value is entered.) This
- or -
ETP 2LE Flight Level averaged for the ETP selection process under the two-
(EF2) engine out scenario.
ETP 2LE Hold Time Scenario: Two engine-out, depressurized

(EH2) The EH2 and EX2 parameters are similar to the EH
- or - and EX parameters but are applicable to the two
engine-out scenario (Driftdown).
Example: EH2=20 or EX2=2800
(EX2)
NOTE The EH2 and EX2 parameters are mutually
Driftdown Performance Tables

JetPlan calculates Overwater Driftdown performance using a combination of a specially
constructed JetPlan descent model (1LE/2LE engine inoperative) and ordinary 1LE/2LE
cruise table data.JetPlan does not strictly use the manufacturer's driftdown performance tables.
This approach yields satisfactory, albeit slightly more conservative, performance figures
compared to the manufacturer's driftdown performance data.
This approach has the advantage of providing reasonable performance figures without a
dependency upon nearly flawless pilot technique and aircraft performance.
Overwater Driftdown Flight Plan Methodology

The Driftdown and Driftdown Extended Information flight plan options invoke Overwater
Driftdown. In response, JetPlan performs the following three steps:
• First, the system runs the basic flight plan, gathering the necessary weight
and fuel data. This process provides the profile and the reserve fuel figures
for the route selected. The objective is to meet flight level rules and
restrictions, company fuel policies, and all the basic and optional flight plan
request parameters at a minimum expenditure of fuel or time.
• The next step involves running the Overwater Driftdown program to
determine the ETP positions and perform the critical fuel analyses. This step
revolves around several important computations performed by the
Overwater Driftdown program. First is the determination of ETP positions

603
based on the user-specified divert airports. After the ETPs are determined,
the time, distance, and fuel expenditures from the POD to each ETP are
determined based on the departure weight and fuel and segment times and
burns determined in step 1.
At this point, JetPlan performs the critical fuel analysis. For each ETP, the
largest detected fuel need—considering backward and forward scenarios to
the appropriate divert airport—is recorded as the ETP critical fuel. The
system then makes an evaluation to determine if enough fuel is available to
meet or exceed the critical fuel. If enough fuel exists, the plan is finished. If
a worst case fuel shortfall (WCFS) exists, step 3 begins.
• Step 3 involves performing a methodology for alleviating the WCFS.
NOTE Step 3 is not applicable to the Overwater Driftdown program available to

most JetPlan customers.
The following sections provide more detailed information about the Overwater Driftdown
process.
Diversion Airports
A maximum of 12 diversion airports can be entered for overwater driftdown purposes by one
of two methods:
• Diversion airports can be entered sequentially on the POD Command line.

• Diversion airports can be entered in combined pairs between the POD and
POA Command lines.
Example:
02 POD VTBD/VECC/VIDP/OIII/LTBA
03 POA LOWW
Example:
02 POD VTBD/VTBD/VECC/VIDP/OIII/LTBA
03 POA LOWW/VECC/VIDP/OIII/LTBA/LOWW
For sample flight plan output resulting from the sample inputs, see “Overwater Driftdown
Data on the Flight Plan” on page 609. For more information on diversion airports, see
Chapter 3, “Point of Departure and Point of Arrival Commands.”

604
ETP Selection
NOTE For an in-depth review of the basic ETP process see Chapter 3, “Point of
Departure and Point of Arrival Commands.”
Part of the Overwater Driftdown procedure is to determine the worst-case diversion fuel burn.
This critical fuel calculation requires the determination of critical points. A critical point is
defined as a point from the intended route where the one-engine (or two-engines) inoperative
diversion time from the two closest alternates is equal— an equal time point (ETP).
When performing the Overwater Driftdown calculation, JetPlan must determine three different
ETP cases simultaneously:
• Depressurized operation (low-level all-engine cruise)

• One-engine inoperative operation (1LE)
• Two-engines inoperative operation (2LE)
JetPlan determines the ETPs based on your diversion airport inputs and performance factors
stored in the ETP database, which is a subsection of the CADB (see “ETP Database” on
page 600).
Critical Fuel Calculation Scenarios

The Overwater Driftdown program calculates the worst-case diversion fuel burn using three
scenarios at each ETP (critical point): lost pressurization, one-engine inoperative, and two-
engines inoperative. Each scenario calculation is discussed in the following paragraphs.

605
Depressurized Scenario
For the depressurized (low-level) cruise with all engines operating scenario, the following
assumptions and calculations are made:
• If the ETP O2 Time (OX) parameter is set to a positive value, cruise at the
altitude defined by the ETP O2 FL x100 FT parameter (OF or OL) for the
time that oxygen is available (as indicated by the OX parameter). When the
oxygen runs out, a descent to 10,000 feet can occur.
- or -
If the ETP O2 Time (OX) parameter is not set to a positive value (is 0), at
the critical point, initiate an emergency descent to the “depressurized” flight
level specified in the ETP database (EM/EF parameter). For critical fuel
calculation purposes, this descent is considered to be zero distance, zero
time, and zero fuel.
• The final descent from the ETP “depressurized” flight level to the field
elevation of the diversion airport is computed using the descent performance
model found in the generic aircraft data file.
• The low-level (depressurized) cruise distance is computed using the great
circle distance from the ETP to the diversion airport minus the final descent
distance.
Cruise performance is calculated using an iterative process of taking
snapshots of several factors at the midpoint of the cruise segment and
applying the information to a cruise table found in the generic aircraft data
file. Typically, the cruise table used is all-engine long range cruise (LRC),
but it can be specified differently in the ETP Database using the EC, ECA,
or ECN parameter.
NOTE The cruise mode specified using the EC/ECA/ECN parameter must have
performance table data available in the generic aircraft file.
Each midpoint snapshot of information includes the temperature and aircraft

gross weight. These factors determine the average cruise fuel flow for the
given airspeed (EA parameter). Midpoint winds are measured and applied to
the average cruise true airspeed across the segment. This process provides a
ground speed figure, which is then used to compute the low-level
(depressurized) cruise segment fuel burn and time.
• Fifteen minutes of hold fuel is computed using the estimated landing weight
at the diversion airport and the hold calculation model found in the generic
aircraft data file.

606
• Depressurized critical fuel is the sum of the cruise, final descent, and hold
fuel burns.
One-Engine and Two-Engines Inoperative Scenarios

• At the critical point (and using the computed aircraft gross weight,
determined in the basic flight plan calculation), JetPlan generates a series of
trial descents. These descents use the one and two-engine inoperative
descent models found in the generic aircraft data file.
For each trial descent, a gross weight and ambient temperature are measured
at the descent level-off altitude.
Using the measured weight and temperature information, JetPlan determines
whether or not the 1LE/2LE operation is sustainable at the descent’s level-
off altitude, according to the aircraft’s cruise table data.
If the descent’s level-off altitude is not sustainable in the 1LE/2LE cruise
tables, then another iteration is performed using a lower descent level-off
altitude. This iteration process continues until:
– A descent level-off altitude is found that is sustainable. In this case,
the descent performance information (distance, fuel, and time) is
saved for use in the critical fuel calculation.
- or -
– The lowest flight level available for the aircraft is reached and is
found to be unsustainable. In this case, a value is reported as
“driftdown dump fuel.” This value equals the difference between
the aircraft gross weight at the bottom of the last trial descent and
the maximum weight in the table data.
• The final descent is computed using the same descent model described in the
first step - or a model based on the value entered in the
EDA1/EDN1/EDA2/EDN2 parameters—except that the descent parameters
are constructed to calculate performance from the trial descent altitude to the
diversion airport elevation.

607
• The 1LE/2LE cruise distance is computed using the great circle distance
from the ETP to the diversion airport minus the sum of the two descent (trial
and final) distances.
Cruise performance is calculated using an iterative process of taking
snapshots of several factors at the midpoint of the cruise segment and
applying the information to a cruise table. The 1LE/2LE cruise table is used,
but it can be specified differently in the ETP Database (EC1, EC2, ECA1,
ECA2, ECN1, or ECN2 parameters).
NOTE The cruise mode specified using the EC1(2)/ECA1(2)/ECN1(2) parameter

must have performance table data available in the generic aircraft file.
Each midpoint snapshot of information includes the temperature and aircraft

gross weight. These factors determine the average cruise fuel flow for the
given true airspeed (EA1 or EA2 parameter). Midpoint winds are measured
and applied to the average cruise true airspeed across the segment. This
process provides a groundspeed figure, which is then used to compute the
1LE/2LE cruise segment fuel burn and time.
• Fifteen minutes of hold time is computed using the 1LE/2LE hold
calculation model (at the estimated landing weight) at the diversion airport.
• The 1LE/2LE critical fuel is the sum of the trial descent, cruise, final
descent, and hold fuel burns.
Highest Terrain Diversion Path Calculation

In the Overwater Driftdown process, JetPlan evaluates the terrain and the need for terrain
avoidance on the diversion route. The system performs this informational process, providing
the highest terrain elevation diversion path, by:
1. Considering the great circle segment from each enroute ETP to each
diversion airport
2. Determining the highest point five miles either side of the great circle route
segment
3. Adding 2000 feet of pad altitude for any obstacle over 5001 feet MSL
within the determined path.
4. Printing the largest elevation value found next to the computed driftdown
altitude on the flight plan.

608
Overwater Driftdown Data on the Flight Plan

You can invoke either the Driftdown or the Driftdown Extended Information flight plan
option. Both options provide the same Overwater Driftdown critical fuel calculation, and the
data from both is intended for operational use. However, Driftdown Extended Information
provides a critical fuel analysis for each ETP airport pair at the end of any flight plan format
output. This analysis is intended to justify the Overwater Driftdown calculations rather than to
provide operational data to flight crews.
NOTE In the JetPlan command-line interface, FP,DRFT invokes Driftdown, and

FP,DRFTX invokes Driftdown Extended Information. If you are using a front-end
product such as JetPlanner, see your product documentation for instructions on
selecting the Driftdown options.
NOTE The following examples demonstrate the two methods for entering diversion
airports in the JetPlan command-line interface. The sample output is based on either
of these input methods. Depressurized (low-level) and one-engine inoperative
scenario data is output. For more information, see Chapter 3, “Point of Departure and
Example:
02 POD VTBD/VECC/VIDP/OIII/LTBA
03 POA LOWW
Example:
02 POD VTBD/VTBD/VECC/VIDP/OIII/LTBA
03 POA LOWW/VECC/VIDP/OIII/LTBA/LOWW

609
Explanation of output:
Line 1: Driftdown summary data header
Line 2: Column headings
Lines 3–6: Diversion data based on LRC
Lines 7–10: Diversion data based on 1LE

610
The following table defines the driftdown summary output in detail.
Table 22-3 Overwater Driftdown Summary Data
Column Headings Description

CRZ Cruise mode indicator. JetPlan uses LRC for low-level (depressurized) all
engines operating, 1LE for one-engine inoperative cruise, and 2LE for two-
engines inoperative cruise (three and four-engine aircraft).
TO ICAO identifier of the divert airport backward to the point of departure from
the applicable ETP. The divert airport listed under the second “TO” is forward
of the applicable ETP towards the point of arrival (POA).
BURN Total fuel burn from the ETP backward to the divert airport.
FL Cruise altitude from the ETP backward to the divert airport. For LRC
diversion, this altitude is specified by the EM (EF) parameter. For 1LE and
2LE diversion, this altitude is determined by the performance calculations.
MSA Minimum Safe Altitude backward to the divert airport. This value is derived
from the grid MORA altitudes on the Jeppesen charts. These values clear all
reference points within the section outlined by latitude/longitude lines by 1000
feet in areas where the highest reference point is 5000 feet MSL or lower. They
clear all reference points by 2000 feet in areas where the highest reference
point is 5001 feet MSL or higher.
TO ICAO identifier of the divert airport forward towards the point of arrival from
the applicable ETP. The divert airport listed under the first “TO” is backward
from the applicable ETP to the point of departure (POD).
BURN Total fuel burn from the ETP to the forward divert airport.
FL Cruise altitude from the ETP forward to the divert airport. For LRC diversion,
altitude is specified by the EM (EF) parameter. For 1LE and 2LE diversion,
this altitude is whatever the performance calculations determine.
MSA Minimum Safe Altitude forward to the divert airport. This value is derived
from the grid MORA altitudes on the Jeppesen charts. These values clear all
reference points within the section outlined by latitude/longitude lines by 1000
feet in areas where the highest reference point is 5000 feet MSL or lower. They
clear all reference points by 2000 feet in areas where the highest reference
point is 5001 feet MSL or higher.
FOB Fuel On Board at the applicable ETP. This value is the available fuel from
which JetPlan calculates the total required fuel to each diversion airport.
LAT The latitude of the applicable ETP.
LON The longitude of the applicable ETP.

611
Table 22-3 Overwater Driftdown Summary Data (continued)
Column Headings Description

W Warning flags to alert dispatchers and pilots of potential problems. Only one
flag is output per line. Look carefully at the diversion data to determine which
diversion airport is being flagged. The flag might apply to both diversion
airports. For example, the divert cruise altitude might be below the grid
MORA to both divert airports. Also, a hierarchy of flags exists. For example, a
divert fuel required flag overrides the grid MORA flag.
The possible warning flags are:
• M – Indicates that the cruise altitude is below the grid MORA from the
applicable ETP to the divert airport via a great circle route.
• D – Indicates that it might be necessary to dump fuel. This value is most
frequently seen with the TWO-ENGINE INOP DIVERT SUMMARY.
This value is the difference between the maximum table weight
(considering temperature deviation) loaded for the divert cruise altitude
and the computed weight at the end of descent to this altitude.
• F – Indicates that additional fuel is required from the applicable ETP to
the diversion airport
• X – Indicates that an error has occurred in the driftdown summary
calculation.
• S – Indicates that JetPlan has added a mileage bias, simulating a spiral
descent for the diversion airport. JetPlan adds the bias when the distance
to the diversion airport is shorter than the calculated required driftdown
distance.
NOTE The asterisk (*) in the TO column indicates the fuel critical diversion airport
pair for each cruise mode. Sufficient fuel exists on board for the diversion calculation,
but less pad exists between the fuel required and the fuel on board than for any of the
other diversion airport pairs. If only one diversion airport pair exists for each cruise
mode, the asterisk prints out next to it.

612
Terrain Analysis
Terrain Analysis
NOTE Terrain Analysis is available through front-end flight planning applications
that interface with JetPlan, such as Jeppesen Dispatch Control and JetPlanner.
Terrain Analysis is not available through the JetPlan command-line interface.
The goal of the Terrain Analysis is to assist operators in verifying compliance with FARs
121.191 and 121.193. The term Terrain Analysis refers collectively to the JetPlan Terrain
Clearance and Mountain Driftdown options. Briefly described, terrain clearance refers to the
ability of an aircraft with one or more engines out to clear terrain by 1,000 feet in a corridor
along the route for the entire distance, without the need for driftdown alternates. Mountain
driftdown, on the other hand, refers to the ability of an aircraft with one or more engines out to
clear obstructions by 2,000 feet throughout the driftdown gradient to an alternate airport.
JetPlan can be configured to perform either terrain clearance or mountain driftdown or both in
the order you specify until a safe route of flight is determined. When a flight plan is submitted
with the Terrain Analysis feature activated, the primary flight plan is calculated first. Once
those calculations are complete, Terrain Analysis is initiated to test one or more (depending on
configuration) of four possible scenarios: terrain clearance/anti-ice on, terrain clearance/anti-
ice off, mountain driftdown/anti-ice on, and mountain driftdown/anti-ice off. The flight plan
can be run again and again utilizing each of the four scenarios one at a time until one complies
or all fail. If the chosen scenario fails, the primary flight plan is printed with an alert of the
failure to comply with terrain clearance/mountain driftdown requirements.
Terrain Analysis Key Terms
Applicable The Applicable TAF is the data used to evaluate alternate airport
Terminal Area suitability. For a single airport, multiple TAFs with different weather
Forecast (TAF) data can be available to the system from multiple sources. The system
prioritizes the use of TAFs from a customer’s source over TAFs from
Jeppesen's source.
Decision Point The last mileage marker from which the previous diversion option
was achievable, and the first mileage marker from which the next
diversion option is considered.
Diversion Option An alternate airport that can be reached via some path (great circle or
escape route) from a decision point.

613
Terrain Analysis
Driftdown The adequate or suitable airports that are candidates for selection
Alternate along the route of flight in the mountain driftdown computations.
Escape Route A user-defined stored approach route to a mountain driftdown

alternate designed to route the aircraft safely through high terrain and
to be used when a great circle route fails mountain driftdown
validation. The escape route string begins with the departure point (or
transition point) and ends with the driftdown alternate airport. Escape
route records are stored in the Customer Route String database.
Escape Route The first waypoint farthest from the mountain driftdown alternate
Transition Point airport in the series of waypoints defining an escape route. For
example, for the escape route defined as BNA CBC .LRS PJG ABA
TNCA, where TNCA is the mountain driftdown alternate, the escape
route transition point is BNA.
Mileage Marker The points along the primary route where checks are made for the
capability to drift down to an alternate.The system calculates the
distance of each segment along the primary route of flight and divides
this distance by the given corridor width. This is done in order to
break the segment up into equal mileage marker distances that are ten
(default value) statue miles or less.
Mountain In general terms, the computational problem of suitable enroute

Driftdown alternate selection by assuming engine failure at planned all-engine
altitude, and determining decision points and alternates so that the
aircraft can fly safely according to the plan by drifting down, clearing
terrain by 2,000 feet, and flying to an enroute alternate. Mountain
Driftdown is also the name of the JetPlan option that calculates a
mountain driftdown flight plan.
Terrain Analysis A collective term for the Terrain Clearance and Mountain Driftdown
options in JetPlan.
Terrain Clearance In general terms, the computations of clearance of terrain by 1,000

feet with one or two engines out along the primary route, without the
need for driftdown alternates. Terrain Clearance is also the name of
the JetPlan feature that calculates a terrain clearance flight plan.

614
Terrain Analysis
Terrain Summary An extracted summary of the Terrain Analysis results computed for a
flight plan. The Terrain Summary is accessible separately from the
flight plan through Jeppesen Dispatch Control or other front-end user
interface with similar capability.
Transition Point See the definition for “Escape Route Transition Point” on page 614.
Terrain Analysis Setup Requirements

The setup requirements for Terrain Analysis include the following:
• You must have access to a flight-planning front-end application that

interacts with JetPlan and supports Terrain Analysis functionality. The
JetPlan command-line interface does not support Terrain Analysis fight plan
requests. Front-end Terrain Analysis options are described in “Terrain
Analysis Flight Planning” on page 628.
• You must supply manufacturer driftdown and engine-out climb/cruise
performance data for each fleet type before you can use Terrain Analysis for
flight planning.
• You must use a flight plan format that supports inclusion of Terrain
Analysis results.
• Your customer preferences and customer databases must be configured to
support Terrain Analysis, as described in the following sections.
NOTE For complete information about fulfilling the prerequisites for the Terrain
Analysis feature, contact your Jeppesen account manager.

615
Terrain Analysis

The Customer Preferences database, which is not customer-controlled, contains some of the
basic specifications for the Terrain Analysis option. For example, the anti-ice rules used to
clear the portion of a flight from the planned destination airport to a destination alternate are
stored in this database.
NOTE For information on configuring Terrain Analysis customer preferences,

NOTE Some front-end flight planning software applications offer options that over-
ride some customer preferences. See “Terrain Analysis Flight Planning” on page 628.
The following table lists customer preferences that apply to Terrain Analysis.
Table 22-4 Terrain Analysis Customer Preferences
Customer Preference Description

NOTE The following anti-ice settings are specific to the Terrain Analysis feature. They are different from other
anti-ice settings that can be requested for take-off anti-ice, ETOPS anti-ice for the Critical Fuel Scenario
calculation, and the anti-ice setting for the Overwater (Basic) Driftdown functionality. The Terrain Analysis anti-
ice selection apply only to the terrain clearance and mountain driftdown portions of the flight plan.
Anti-Ice Rules for the Primary This parameter allows you to configure the system to attempt terrain
Route analysis scenarios for the primary route. You can specify how many of
these scenarios are attempted and in what order. The following four
scenarios are possible:
• Terrain clearance/anti-ice on
• Terrain clearance/anti-ice off
• Mountain driftdown/anti-ice on
• Mountain driftdown/anti-ice off
NOTE The default values set by this parameter can be overridden by
the Terrain Analysis Indicator parameter in the City Pair Fleet database
and by ad hoc entries on the flight plan. See “City Pair Fleet Database”
on page 623 and “Terrain Analysis Flight Planning” on page 628.

616
Terrain Analysis
Table 22-4 Terrain Analysis Customer Preferences (continued)

Anti-Ice Rules for the Alternate This parameter allows you to configure the system to attempt a terrain
Route analysis scenario for the route to the alternate. You can specify how
many of these scenarios are attempted and in what order. The
following four scenarios are possible:
NOTE The default values set by this parameter can be overridden by
the Terrain Analysis Indicator parameter in the City Pair Fleet database
and by ad hoc entries on the flight plan. See “City Pair Fleet Database”
on page 623 and “Terrain Analysis Flight Planning” on page 628.
NOTE A terrain analysis scenario for the route to the destination
alternate is always qualified using Terrain Clearance Anti-Ice ON rules.
Airport Minima Source When JetPlan checks the suitability of an airport as an alternate
(departure, en route, or arrival) it can perform a TAF check on that
airport by comparing the TAF forecast with the landing minima values
for the airport. This preference specifies which customer database acts
as the source or sources of the minima values. The options are:
• (Default) Get the minima values from the Customer Airport Fleet
database first, and then, for any that are zero, get them from the
Customer Airport database.
• Get the minima values from the Customer Airport Fleet database
only.
• Get the minima values from the Customer Airport database only.
See “Customer Airport Database” on page 619 and “Customer Airport
Fleet Database” on page 620.
Corridor Width This preference defines the lateral terrain clearance minimum in feet.
FAR 121.191 requires a 10 statute mile corridor clearance width.
Mountain Driftdown Clearance This preference defines the vertical clearance minimum for mountain
Altitude driftdown scenarios. The default value is 2000 feet per FAR 121.191.
Terrain Clearance Altitude This preference defines the vertical clearance minimum for terrain
clearance scenarios. The default value is 1000 feet per FAR 121.191.
Airfield Clearance This preference defines the airfield vertical clearance minimum. The
default value is 1500 feet per FAR 121.191.

617
Terrain Analysis
Table 22-4 Terrain Analysis Customer Preferences (continued)

ETOPS Terrain Clearance For terrain clearance and mountain driftdown flight plans that are also
ETOPS flight plans, this preference tells JetPlan to compute terrain
clearance or mountain driftdown either for the entire route or just for
all areas of the route outside of the ETOPS area of operation.
NOTE Both this parameter and the ETOPS Area of Operation
Determination Policy (ETOPSAOO) preference must be turned on, or
the terrain clearance or mountain driftdown calculation reverts back to
default of computing for the entire route.
Mountain Driftdown Alternate This preference (1) defines the alternate ellipse, which is the area in
Ellipse which the system searches for alternates, and (2) determines the sort
order for the search results. The ellipse is computed forward along the
route from each decision point. The nearest edge of the ellipse falls at
the edge of the decision point.
The alternate ellipse preference is defined as follows:
• The length of the major axis in nautical miles (nm). The default
value is 300 nm.
• The length of the minor axis given as a percentage of the major
axis. The default value is 75 percent. (100 percent is a full circle).
• The ellipse search type. The search type determines the sort order
for alternates found within the ellipse. Depending on the search
type, alternates are sorted appropriately and placed at the top of
the list. The possible sort orders are:
- (Default) Closest to the decision point
- Closest to the center of the ellipse
- Farthest from the decision point
For all alternates that fall outside of the ellipse, the system reverts to
the default of sorting by alternates that are closest to the decision
point.
Driftdown Escape Routes This preference specifies whether or not the user uses escape routes
when qualifying mountain driftdown alternates. The default is to use
escape routes if they exist.
Terrain Clearance Method Previously, flight levels were limited to that of the driftdown level-off
altitudes. When set to 1, this preference removes this limitation for the
primary route. This preference applies to terrain clearance scenarios,
not mountain driftdown.

618
Terrain Analysis
Customer Database Requirements

The following databases contain parameters that can be configured to support the Terrain
Analysis feature. For more detailed information, see the chapters in this manual that cover
these databases.

An entry in the Customer Airport database must exist for every airport you want the system to
consider using as a mountain driftdown alternate. The identifiers for these airports must match
the identifiers used in any other airport database. The following table lists the Customer
Airport database parameters that apply to mountain driftdown alternates. For detailed
descriptions, see Chapter 30, “Customer Airport Database.”
Table 22-5 Terrain Analysis – Customer Airport Database Parameters
Parameter Description Application

Alternate Ceiling Minimum These non-precision approach parameters are Mountain Drifdown
(Non-Precision Approach) weather criteria checks in the automatic alternate
(N3) selection process.
- and - When JetPlan checks the suitability of an airport as
an alternate (departure, en route, or arrival) it can
Alternate Visibility
compare the TAF forecast with the landing minima
Minimum (Non-Precision
Approach)
By default, JetPlan first checks the Customer
(N4)
Airport Fleet database for these minima values. If
the minima value in the Customer Airport Fleet
database is zero, JetPlan looks for the value in the
Customer Airport database.
This default behavior can be overridden by
changing the setting of the Airport Minima Source
customer preference. For more information, see
“Customer Preferences Database” on page 616.

619
Terrain Analysis

The Customer Airport Fleet database allows you to store and manage data related to a specific
airport and a specific aircraft fleet type, the Jeppesen generic aircraft ID that defines a specific
airframe/engine combination. An entry must exist in this database for every airport you want
the system to consider using as a mountain driftdown alternate. The identifiers for these
airports must match the identifiers used in any other airport database.
Table 22-6 Terrain Analysis – Airport Fleet Database Parameters

Enroute Alternate in This parameter defines the clearance status for Mountain Driftdown
Terrain Driftdown airports as terrain clearance/mountain driftdown and Terrain Clearance
Operations alternate airports.
(TD)
Maximum Allowable This parameter defines a radius distance limit to the Mountain Driftdown
Distance to Takeoff proximity search for candidate takeoff alternate and Terrain Clearance
Alternate airports in the automatic alternate selection process.
(MA) The distance is relative to the key airport when used
as a POD.
Approach Plate Available This parameter defines the availability of approach Mountain Driftdown
(AP) plate material for the key airport.For an airport to be
considered a candidate mountain driftdown alternate,
either this parameter must be set to Yes, or the All
Alternates Valid option in the front-end application
must be selected. For more information on the All
Alternates Valid option, see “Terrain Analysis
Flight Planning” on page 628.
Type of Operations This parameter is no longer used by Mountain NA

(TO) Driftdown or Terrain Clearance.
Alternate Ceiling These non-precision approach parameters are Mountain Drifdown

Minimum (Non-Precision weather criteria checks in the automatic alternate
Approach) selection process.
(N3) When JetPlan checks the suitability of an airport as
- and - an alternate (departure, enroute, or arrival) it can
compare the TAF forecast with the landing minima
Alternate Visibility
Minimum (Non-Precision
Approach) By default, JetPlan first checks the Customer Airport
Fleet database for these minima values. If the minima
(N4)
value in the Customer Airport Fleet database is zero,
JetPlan looks for the value in the Customer Airport
database.
This default behavior can be overridden by changing
the setting of the Airport Minima Source customer
preference. For more information, see “Customer
Preferences Database” on page 616.

620
Terrain Analysis
Customer Aircraft Database
NOTE The standard aircraft performance tables do not support the Terrain
Clearance and Mountain Driftdown features. You must arrange for additional tables to
be loaded in the Generic Aircraft database for the aircraft types you plan to use with
Terrain Analysis. Contact your Jeppesen account manager for more information.
The following table lists the Customer Aircraft database parameters that apply to mountain
driftdown. These parameters are in the “Driftdown” section of the Customer Aircraft database
parameters. For detailed descriptions, see Chapter 27, “Customer Aircraft Database.”
Table 22-7 Terrain Analysis – Customer Aircraft Database Parameters
Generic Aircraft ID The name of the associated aircraft record in the
Generic Aircraft database
Driftdown-Climbout
Engine Out Climbout Anti-Ice On The name of the engine-out climb table for the
(D11) climbout, anti-ice on
Engine Out Climbout Anti-Ice Off The name of the engine-out climb table for the
(D12) climbout, anti-ice off
Engine Out Cruise Anti-Ice On The name of the engine-out cruise table for the
Engine Out Cruise Anti-Ice Off The name of the engine-out cruise table for the
Driftdown Descent Anti-Ice On The name of the driftdown descent table for the
Driftdown Descent Anti-Ice Off The name of the driftdown descent table for the
Driftdown-Enroute (Route Exclusive)
Engine Out Climbout Anti-Ice On The name of the engine-out climb table for the route
(D21) exclusive of climbout, anti-ice on
Engine Out Climbout Anti-Ice Off The name of the engine-out climb table for the route
(D22) exclusive of climbout, anti-ice off
Engine Out Cruise Anti-Ice On The name of the engine-out cruise table for the route
Engine Out Cruise Anti-Ice Off The name of the engine-out cruise table for the route

621
Terrain Analysis
Table 22-7 Terrain Analysis – Customer Aircraft Database Parameters (continued)
Driftdown Descent Anti-Ice On The name of the driftdown descent table for the route
Driftdown Descent Anti-Ice Off The name of the driftdown descent table for the route
Defaults
Takeoff Fuel Burn The default takeoff fuel burn value in pounds
(D31)
Takeoff Time The default takeoff time value in minutes

(D32)
Takeoff Distance The default takeoff distance value in nautical miles

(D33)
Approach Fuel Burn The default approach fuel burn value in pounds
(D34)
Approach Time The default approach time value in minutes

(D35)
Landing Table The default landing data table name (can be blank)
(D36)
Temperature Threshold Unavailable at this time.

(D41)
Driftdown Bias The driftdown bias, a percent bias to apply to fuel

(D42) burn calculations for engine-out operations (an
integer representing a fixed-point number in tenths of
a percent; for example, 16.9% would be passed as
169)
NOTE The driftdown bias parameter (D42) is not yet
supported.

622
Terrain Analysis

This database stores information that can be applied to a city pair/fleet type combination. The
following parameters apply to Terrain Analysis.
Table 22-8 Terrain Analysis – City Pair Fleet Database Parameters
Terrain Analysis Indicator Indicates the default Terrain Analysis computation to
(TA) be applied to any flight for the designated city pair and
fleet type. Choices are:
• (Default) None
• Terrain clearance
• Mountain driftdown
• Both terrain clearance and mountain driftdown
NOTE When set, the value of the Terrain Analysis
Indicator overrides the Anti-Ice Terrain Analysis Rules
defined in the Customer Preference database. In turn,
these City Pair Fleet and Customer Preference
database values can be overridden by ad hoc inputs
entered through the front-end flight planning software.
For more information, see “Customer Preferences
Database” on page 616 and “Terrain Analysis Flight
Planning” on page 628.
NOTE A terrain analysis scenario for the route to the
destination alternate is always qualified using Terrain
Clearance Anti-Ice ON rules.
NOTE The following parameters in the City Pair Fleet database are inoperative:
Driftdown Mode: Primary (DRFP) and Driftdown Mode: Alternate (DRFA).

623
Terrain Analysis
Minimum Equipment List (MEL) Database

The MEL database allows you to create and manage records of performance degradations and
equipment shortcomings for aircraft of a given fleet type. The following table lists weight
penalty parameters that apply to Terrain Analysis flight plans.
NOTE All weight penalties included in an ad hoc flight plan request are summed
with all Enroute Weight Penalty values and all Enroute Weight Factor values
contained in each Type M or C MEL currently assigned to the aircraft. For more
information about how weight penalties are applied in terrain clearance and mountain
driftdown scenarios, see “Application of Weight Penalties to Terrain Analysis Flight
Plans” on page 625.
Table 22-9 Terrain Analysis – MEL Database Parameters

Enroute Weight Factor The Enroute Weight Factor option allows you to set a Mountain Driftdown and
(EF) penalty to be applied to the aircraft gross weight at the Terrain Clearance
decision point for mountain driftdown computations
and over the entire route for terrain clearance. The
value is a percentage by which the gross weight is
increased. You can choose to apply a multiplier
degradation to this penalty.
Penalty Subject to When selected, this parameter indicates that the Mountain Driftdown and
Multiplier Enroute Weight Factor is subject to a multiplier. Terrain Clearance
(MEF)
Enroute Weight The Enroute Weight Penalty (LBS) option allows you Mountain Driftdown and
Penalty (LBS) to set a penalty in pounds to be added to the aircraft Terrain Clearance
(EP) gross weight for Terrain Analysis. You can choose to
apply a multiplier degradation to this penalty.
Penalty Subject to When selected, indicates that the Enroute Weight Mountain Driftdown and
Multiplier Penalty (LBS) is subject to a multiplier. Terrain Clearance
(MEP)

624
Terrain Analysis
Application of Weight Penalties to Terrain Analysis Flight Plans

When JetPlan computes terrain clearance flight profiles, the total enroute weight penalty is
applied as follows:
• Any ad hoc enroute weight penalty contained in the flight plan request
- plus -
• Any enroute weight penalty contained in each type M or C MEL record
currently assigned to the aircraft
- plus -
• Any enroute weight factor contained in each type M or C MEL currently
assigned to the aircraft, converted to a weight penalty as follows: enroute
weight factor (%) x aircraft gross weight.
NOTE Because aircraft gross weight changes due to fuel burn off, the enroute
weight factor penalty is computed using a gross weight at each mileage marker.
When JetPlan computes the mountain driftdown gradient, the total enroute weight penalty is
applied as follows:
• Any ad hoc enroute weight penalty contained in the flight plan request
- plus -
• Any enroute weight penalty contained in each type M or C MEL record
currently assigned to the aircraft
- plus -
weight factor (%) x aircraft gross weight at the decision point.
The responsibility for determining the correct Gradient Penalty percentage to use for each
MEL is left to the JetPlan user. The following is a sample formula for deriving an enroute
weight penalty factor from the enroute gradient penalty in the published MEL:
EWF = 1 + (GP / (1 / LDR + NG)), where:
• EWF is the Enroute Weight Factor percentage that is to be stored in the

MEL record.
• GP is the Gradient Penalty as defined in the manufacturer’s MEL.
• LDR is the Lift to Drag Ratio.

625
Terrain Analysis
• NG is the Net/Gross Performance Factor. A standard value for NG is 0.011

(or 1.1%) for two-engine aircraft.
For example, using the formula above, for an MEL that specifies a 0.032% gradient penalty
for a 737-800 at 160,000 pounds at the decision point, the weight penalty derived would be
751 pounds, assuming that LDR is 17.5 and NG is 0.011. (This equates to a 0.469% Enroute
Weight Factor if the gradient penalty were instead calculated against the aircraft weight
without the L/D formula.)
Escape Routes Database Records
NOTE The Driftdown Escape Routes customer preference controls use of escape
routes. For more information, see “Customer Preferences Database” on page 616.
The Customer Route String database stores escape route records. Escape routes define arrival
routes to mountain driftdown alternates that have been designated for use in mountainous
terrain as alternatives to the direct route. When an attempt to use a great circle route to a
particular driftdown alternate fails, the system attempts to use an escape route, as long as a
record for the given alternate exists in the Route String (Escape Routes) database.
NOTE Escape routes records appear as a sub-database on the Customer Route

database page in JetPlan.com. This is where escape route records can be
maintained. However, escape route records are stored in the Route String database,
not the Customer Route database.
The use of escape routes in mountain driftdown flight planning offers the following
advantages:
• A preferred route might otherwise be rejected in flight planning due to

failure to find a suitable mountain driftdown alternate that can be reached
via the normally-assumed direct, great-circle route.
• Sub-optimal alternates (far afield) can be selected for a route because better
alternates cannot be reached via the great-circle routing from the decision
point.
• Escape routes in the flight plan can provide safe-routing guidance to the
pilot in mountain driftdown situations.

626
Terrain Analysis
The following table lists the parameters included in each escape route database record. For
more detailed information on escape route database parameters, see Chapter 6, “Route
Commands.”
Table 22-10 Escape Route Record Parameters
Route Name This parameter is the name you give to the escape route record
in the database.
Group Name This parameter indicates the group to which all escape routes
below (ES). This information cannot be modified for escape
routes.
Begin Point and End Point of the Route This parameter specifies the beginning and end points of the
route. An escape route can go from airport to airport, waypoint
to airport, airport to waypoint, or waypoint to waypoint.
Airport or Waypoint This parameter defines the ICAO or IATA code for the airport
used as the route departure or arrival point, as appropriate.
- or -
The name of the waypoint used as the beginning or end point of
the escape route.
Waypoint Area This parameter specifies the 2-character A424 area code for the
waypoint.
NOTE This parameter must be set when the corresponding
point is a waypoint. If the point is an airport, do not set this
parameter.
Waypoint Type This parameter defines the VOR, Enroute Waypoint, Terminal
NDB, Terminal Waypoint, or NDB
point is a waypoint. If the point is an airport, do not set this
parameter.
Routing String This parameter defines the Specific Route Selector (SRS) route
string. For information on SRS syntax, see Chapter 6, “Route
Commands.”

627
Terrain Analysis
Terrain Analysis Flight Planning

The front-end flight planning application, such as JetPlanner or Jeppesen Dispatch Control,
allows you to include Terrain Analysis on a selected flight plan request. How JetPlan responds
to the request is determined by the database parameter settings described in the preceding
sections and also by front-end, ad hoc inputs made on the flight plan request itself. Some of the
front-end options allow you to override default database configuration settings on a given
flight plan request.
The system can be configured to attempt the following four possible Terrain Analysis
scenarios.
How many of these scenarios are attempted and in what order is configurable through database
settings and also through the front-end application. Up to four different attempts can be made
on any one flight plan. Processing continues until the first success or until all selected
scenarios have been exhausted.
The default Terrain Analysis sequence is defined by the Anti-Ice Rules for the Primary and
Alternate Route preferences, stored in the Customer Preference database. You can also set the
Terrain Analysis Indicator in the City Pair Fleet database, which overrides the Customer
Preference settings. Front-end options allow you to override both the Customer Preference and
the City Pair Fleet database values on a given flight plan. Precedence for these values works as
follows:
• If only a Customer Preference value exists, it is used.

• If only a Customer Preference value and a City Pair Fleet database value
exist, the City Pair Fleet database value overrides the Customer Preference
database value.
• If any database values are set and front-end options are also set, the front-
end options take precedence over the database values.
NOTE Terrain analysis scenarios for the route to the destination alternate are
always qualified using Terrain Clearance Anti-Ice ON rules.
For more information, see “Customer Preferences Database” on page 616, “City Pair Fleet
Database” on page 623, and “Terrain Analysis Front-End Options” on page 629

628
Terrain Analysis
Terrain Analysis Front-End Options

Front-end applications that support JetPlan Terrain Analysis allow you to set configuration
options that customize the Terrain Analysis functionality for a given flight plan. For example,
Figure 22.1 shows the Driftdown tab in JetPlanner, a Jeppesen front-end flight planning
application that interfaces with JetPlan. The Driftdown tab lists options that JetPlanner users
can select to customize Terrain Analysis for a selected flight plan request.
Figure 22.1. Driftdown Tab in JetPlanner
Front-end configuration options, in combination with your database and customer preference
settings, affect terrain clearance and mountain driftdown calculations and flight plan output.
Once the flight plan request has been submitted, JetPlan applies the various computations,
generates the flight plan in the customer's format, and returns the results to the flight planning
front end.

629
Terrain Analysis
The following table lists some possible front-end flight planning configuration options that
apply to terrain clearance or mountain driftdown or both.
NOTE Available Terrain Analysis flight plan options are determined by the
capabilities and configuration of your front-end software application. For detailed
information, contact your Jeppesen account manager or consult your product
documentation.
Table 22-11 Terrain Analysis Front-End Options
Option Description Application

Anti-Ice Rules for the Front-end options allow you to define up to four Terrain Clearance
Primary Route different scenarios to indicate the types of Terrain and Mountain
Analysis processing desired for the primary route.You Driftdown
can specify how many of these scenarios are attempted
and in what order:
NOTE If any combination of scenarios is specified
through the front-end options, these options supersede
any values that are set in the Customer Preference
Database or the City-Pair Fleet Database. For more
information, see “Customer Preferences Database” on
page 616 and “City Pair Fleet Database” on page 623.
Mandatory Alternates This option allows you to name up to 25 mountain Mountain Driftdown
driftdown alternates for a given flight plan. only
When mandatory alternates are specified, the list of
alternates is restricted to the mandatory alternates, the
POD and POA, and the takeoff alternate, if one is
specified. The system does not consider any other
alternates in the Airport or Airport Fleet databases.
Excluded Alternates This option allows you to name up to 25 alternate Mountain Driftdown
airports to be disqualified from consideration as only
mountain driftdown alternates for a given flight plan.
Maximum Driftdown This option allows you to specify the maximum number Mountain Driftdown
Alternates of driftdown alternate airports for which the system only
searches. During mountain driftdown processing, the
search for viable and qualified alternates can be
lengthy. Setting this value reduces search times by
preventing the system from attempting to reach
driftdown alternates that are too far to away to be
practical.

630
Terrain Analysis
Table 22-11 Terrain Analysis Front-End Options (continued)

Maximum Alternate This option allows you to specify the maximum radius Mountain Driftdown
Distance (in nautical miles) within which the system searches for only
suitable alternate airports. Setting this value reduces
search times by eliminating from consideration
alternates that are too far away to be practical.
ISA Temperature This option allows you to specify a value in degrees Terrain Clearance
Deviation Padding centigrade to be added to all retrieved ISA temperature and Mountain
values. Driftdown
Default value: 0
NOTE Since the system uses the retrieved weather
values from the specified database, it is highly
recommended that this value never be set to anything
other than zero (0).
Wind Padding This option allows you to specify a value, in nautical Terrain Clearance
miles per hour, that is added to all retrieved wind data. and Mountain
Default value: 0 Driftdown
NOTE Since the system uses the retrieved weather

values from the specified weather database, it is highly
recommended that this value never be set to anything
other than zero (0).
Weather (WX) Time This option allows you to specify a time in minutes Mountain Driftdown
Window used to filter TAF reports to evaluate a candidate only
mountain driftdown alternate for suitability. This value
is applied to the arrival time in a plus-or- minus
fashion. For example, if the value is 60, TAF reports for
plus or minus one hour of the calculated arrival time is
considered.
Default value: 0
Fuel Reserve, Time This option allows you to specify a fuel reserve in Mountain Driftdown
minutes at the driftdown alternate. This option is only
specific to mountain driftdown divert alternates and has
no bearing on any other fuel reserve policy. If a certain
amount of fuel is necessary landing at the divert
alternate, then a driftdown reserve must be specified.
Default value: 0
NOTE The fuel reserve option can be set to time or
weight, but not both.

631
Terrain Analysis

Fuel Reserve, Weight This option allows you to specify a fuel reserve, in Mountain Driftdown
pounds, at the divert alternate. This option is specific to only
mountain driftdown divert alternates and has no bearing
on any other fuel reserve policy. If a certain amount of
fuel is necessary landing at the divert alternate, then a
driftdown reserve must be specified.
Default value: 0
NOTE The fuel reserve option can be set to time or
weight, but not both.
Short Search When the Short Search option is turned on, the system Mountain Driftdown
stops searching for mountain driftdown alternates once only
a destination-assured point is determined. The
destination-assured point is that point at which the
aircraft can reach the POA, using driftdown rules, along
the planned route of flight.
Default value: OFF
Display Ad Hoc Enroute This option allows you to specify an Enroute Weight Terrain Clearance
Weight Penalty Penalty on a given flight plan and Mountain
NOTE All weight penalties included in the ad-hoc flight
Driftdown
plan request are summed with all Enroute Weight
Penalty values and all Enroute Weight Factor values
contained in each type M or C MEL currently assigned to
the aircraft.
Terrain Clearance Fuel When set, this option tells the system not to check for Terrain Clearance
Check an out-of-fuel condition during normal terrain clearance only
calculations (from POD to POA, or from POA to all
destination alternates, if any have been designated).
This flag has no effect on calculations done under
mountain driftdown rules. See the “Mountain
Driftdown Fuel Check” parameter below.
WARNING It is the position of Jeppesen that setting
the Terrain Clearance Fuel Check flag to anything other
than OFF (O or not set) is extremely dangerous and
should never be done. If you have any questions about
this parameter, contact your Jeppesen account
manager.

632
Terrain Analysis

Mountain Driftdown Fuel When set, this option tells the Driftdown server not to Mountain Driftdown
Check check for any out-of-fuel conditions during driftdown only
calculations to the POD, the Take-Off alternate, or the
POA. This flag has no effect on calculations done under
terrain clearance rules. See the “Terrain Clearance Fuel
Check” parameter above.
WARNING It is the position of Jeppesen that setting
the Mountain Driftdown Fuel Check flag to anything
other than OFF (O or not set) is extremely dangerous
and should never be done. If you have any questions
about this parameter, contact your Jeppesen account
manager.
Abbreviated Driftdown This option allows you to abbreviate the driftdown Mountain Driftdown
Report report in the flight plan output. only
Climbout Qualification This option is an on/off value which, when turned on, Mountain Driftdown
processes mountain driftdown rules during the climb only
portion of the flight. If set to “off,” no driftdown
climbout qualification occurs prior to top of climb. This
field has no effect on terrain clearance.
Landings Limiting This option is an on/off value which, when turned on, Mountain Driftdown
instructs the mountain driftdown program to do a only
landing field check. It requires that landing data be
present in the aircraft performance database.
NOTE For customers with their own MGL packages,
this option should never be turned on.
All Alternates Valid This option is an on/off value which, when turned on, Mountain Driftdown
tells the Mountain Driftdown program to consider all only
possible alternates in the SRS Airports database as
divert candidates. When turned off, mountain driftdown
only considers the airports stored as candidates in the
Customer Airport Fleet database.

633
Terrain Analysis

Three Flight Levels On This option is an on/off value which, when turned on, Mountain Driftdown
(3FL) instructs the mountain driftdown program to attempt only
driftdown qualification at two flight levels below, one
flight level below, and finally at the planned altitude. If
driftdown passes two flight levels below, then no
further check is done. If a failure occurs, then the
program goes up to the next level and evaluate the
calculations there, until all levels are exhausted and a
total driftdown failure occurs.
NOTE If there are user-specified altitudes for the flight
plan, these levels are not reduced by two flight levels.
The 3FL option is ignored for destination alternates.
Delete Summary This option allows you to delete the mountain Mountain Driftdown
driftdown summary file at the end of processing. only
Terrain Clearance Computations

The primary assumption under which the JetPlan Terrain Clearance function operates is that
there is no suitable divert alternate that is closer to the POD than the POA. Because there are
no divert alternate airports under terrain clearance rules, terrain clearance processing is an all-
or-nothing proposition. The terrain clearance criteria state that the aircraft must clear all terrain
and obstructions by at least 1000 feet within 5 statute miles of the route center line. See
Figure 22.2.
At least 100 nm
At least 1000’
At least 1000’
Failure
POD P OA
Engine-out climb to terrain clearance altitude.
Engine-out cruise to destination.
Maintain airfield clearance and positive slope at the POA.
Figure 22.2. Terrain Clearance Profile

634
Terrain Analysis
The Terrain Clearance option performs under the following guidelines:
• All weight penalties included in the ad-hoc flight plan request are summed
with all Enroute Weight Penalty values and all Enroute Weight Factor
values contained in each type M or C MEL currently assigned to the aircraft.
For more information on application of weight penalties, see “Minimum
Equipment List (MEL) Database” on page 624 and “Terrain Analysis Front-
End Options” on page 629.
• Fuel checks from POD to POA, or from POA to destination alternates, if
any, are configurable on or off. For more information, see the Terrain
Clearance Fuel Check option in Table 22-11, “Terrain Analysis Front-End
Options,” on page 630.
WARNING It is the position of Jeppesen that setting the Terrain Clearance Fuel
Check flag to anything other than OFF (O or not set) is extremely dangerous and
should never be done. If you have any questions about this parameter, contact your
• JetPlan iterates to find the maximum takeoff weight that allows terrain
clearance. This can be reported in the output, depending on the flight plan
format. The front-end flight-planning software can be configured to return
an alert.
• JetPlan assumes engine failure at cruise altitude and determines the highest
terrain along the route of flight. The target enroute altitude is determined
this way.
• As in mountain driftdown, engine-out climb is made without regard to
terrain for the first 16 nm outbound from the POD. After reaching the 16nm
marker, the climb continues on to the target enroute altitude while checking
for terrain obstructions.
• If level-off occurs prior to the POA, an engine-out cruise is calculated for a
100 nm segment. At the 100 nm outbound mark, a step-climb check is
performed. If a step-climb is possible, then one is included in the flight plan.
If a step-climb is not possible, then the engine-out cruise is calculated again
for another 100 nm segment. This pattern repeats until over the POA, where
airfield clearance and positive slope are checked. See Figure 22.2 on
page 634.

635
Terrain Analysis
• When a departure alternate is mandated, it is handled in the same manner

described in the mountain driftdown case. See “Mountain Driftdown
Computations” on page 638.
NOTE When ETOPS is requested for the same flight plan for which terrain
clearance has been requested, JetPlan returns a terrain clearance failure only when
terrain clearance fails for segments not between an ETOPS entry point (EEP) and an
ETOPS exit point (EXP) pair.
Terrain Clearance Output on the Flight Plan

The following sample block of output shows a typical Terrain Clearance Primary Route
scenario with Terrain Clearance Altitude, Departure Terrain Clearance Weight and ISA
Temperature Deviation displayed.

636
Terrain Analysis
The following sample block of output uses another format to display similar results as above.
With this format, however, the ramp weight is displayed.
The following sample block of output shows a typical Terrain Clearance Takeoff Alternate
analysis.
The following sample block of output shows a typical Terrain Clearance Landing Alternate
analysis.

637
Terrain Analysis
Mountain Driftdown Computations

The primary assumption under which the JetPlan Mountain Driftdown option operates is that
the flight qualifies under driftdown rules as long as the aircraft can safely reach a qualified
divert airfield, from any point along the planned route of flight while clearing all obstacles by
at least 2,000 feet. See Figure 22.3.
Decision Point
Driftdown Level-Off Point

At least 2000’
At least 2000’
Engine-Out Cruise Altitude
Diversion Airfield
Great circle route or escape route from the decision point to the
diversion airfield.
Maintain driftdown clearance height during and after descent.
Maintain airfield clearance and positive slope at the diversion airfield.
Figure 22.3. Mountain Driftdown Profile

The Mountain Driftdown option performs under the following guidelines:
• Terrain checking is ignored in the outbound direction from the POD to the
16nm point. It is assumed that all departure possibilities are cleared within
that limit.
• Mileage marker positions along the route of flight—from which attempts are
made to reach a diversion option—are controlled by a configurable
customer preference. FAR 121.191 requires 10 statute miles—5 statute
miles either side of the center line (see “Customer Preferences Database” on
page 616).
• The decision point, the point at which a new diversion option is established,
is a mileage marker from which at least two diversion options to alternate
airfields can be safely reached.

638
Terrain Analysis
• The list of candidate alternates for each decision point consists of “adequate
airports” defined as follows:
– All user-submitted mandatory alternates received on the flight plan
request. In this case, the list of alternates consists of the specified
mandatory alternates, as well as the POD and POA and a takeoff
alternate if one has been specified. No other alternate airport listed
in a customer database is considered.When mandatory alternates are
specified, they are not evaluated for suitability against the Customer
Airport or Customer Airport Fleet databases.
NOTE Whether an alternate is mandatory or not, it is always checked for suitability

in the SRS Airports database.
– Airports that are listed as acceptable driftdown alternates for the

aircraft's fleet type in the Customer Airport and the Customer
Airport Fleet database and that are not on the list of alternates to be
excluded in the flight plan request. These airports are ranked for
proximity relative to the decision point and are evaluated for
distance along the route forward of the decision point and to the side
of the route within the parameters of the alternate ellipse as defined
in the Customer Preference database. See “Customer Preferences
Database” on page 616 and “Mountain Driftdown Methodology” on
page 641 for more information about the alternate ellipse.
When no mandatory alternates are specified, alternates are
evaluated for suitability in the Customer Airport and the Customer
Airport Fleet database. Ceiling and visibility are evaluated using the
applicable TAFs and the ETA factors in the additional time to fly
the escape route.The Weather Time Range is submitted on the flight
plan request. See Chapter 30, “Customer Airport Database.” and
“Customer Airport Fleet Database” on page 620 for more
information.
NOTE Driftdown alternates can be located within established and ad hoc restricted
areas. JetPlan does not check routing restrictions to driftdown alternates.
• For every mileage marker on the primary route, the great circle route to the
driftdown alternate is tried first.
• An attempt to use an escape route is processed only when a great circle
attempt to a particular driftdown alternate fails (if a record for that alternate
exists in the Route String database).The system prefers a more optimal
escape route in terms of the distance from the decision point to the transition

639
Terrain Analysis
point, which is defined as the first point of the escape route. For more
information on escape routes, see “Escape Routes Database Records” on
page 626 and “Mountain Driftdown Methodology” on page 641.
• All weight penalties included in the ad-hoc flight plan request are summed
with all Enroute Weight Penalty values and all Enroute Weight Factor
values contained in each type M or C MEL currently assigned to the aircraft.
JetPlan determines the driftdown gradient after adding the Total Enroute
Weight Penalty and anti-ice penalty (if selected) to the aircraft gross weight.
For more information on how the system computes the driftdown gradient,
see “Application of Weight Penalties to Terrain Analysis Flight Plans” on
page 625.
NOTE JetPlan applies the anti-ice penalty to the level-off altitude if anti-ice is
specified for mountain driftdown in the flight plan request. If the request does not
specify, the system applies anti-ice penalties to mountain driftdown when the Terrain
Analysis anti-ice default is set.
• If the Three Flight Levels On (3FL) front-end option is selected, JetPlan

validates mountain driftdown two flight levels lower than the planned flight
level, factoring in the effects of the Enroute Weight Penalty and Enroute
Weight factors to the profiles as described above. For more information on
the 3FL Option, see Table 22-11, “Terrain Analysis Front-End Options,” on
page 630.
• Fuel checks to the POD, Takeoff Alternate, and POA are configurable on or
off. For more information on the Mountain Driftdown Fuel Check option,
see Table 22-11, “Terrain Analysis Front-End Options,” on page 630.
WARNING It is the position of Jeppesen that setting the Mountain Driftdown Fuel
Check flag to anything other than OFF (O or not set) is extremely dangerous and
should never be done. If you have any questions about this parameter, contact your
• When ETOPS is requested for the same flight plan for which mountain
driftdown has been requested, JetPlan responds according to the setting of
the ETOPS Terrain Clearance and ETOPS Area of Operation customer
preferences (see “Customer Preferences Database” on page 616.) If these
preferences are set, JetPlan only applies mountain driftdown computations
to the portions of the route that are not between an ETOPS entry point (EEP)
and an ETOPS exit point (EXP) pair. At each EEP and EXP, the system
ensures that a driftdown alternate can be reported.

640
Terrain Analysis
• The Short Search front-end flight-planning option can configure the process
to look for a destination-assured point. This is defined as the point at which,
using normal driftdown procedures, the aircraft can lose an engine and make
it to the planned POA by following the flight-planned route. If the Short
Search option is active, the system does not look for alternates past that
point in the route. For more information on the Short Search option, see
Table 22-11, “Terrain Analysis Front-End Options,” on page 630.
• Destination alternates are run as straight terrain clearance problems.
Mountain Driftdown Methodology

In simple terms, mountain driftdown refers to the search for a viable emergency landing
alternate airfield. The unique feature of this option is the active search forward along the route
of flight for viable and qualified alternates, while maintaining specified minimum terrain
clearance.
The mountain driftdown scenario assumes engine failure at cruise altitude, and the route is
evaluated based on the need for divert airports. A check is made for diversion option at
specific mileage markers. As discussed above, the distance between mileage markers is a
configurable customer preference setting (the FAR-mandated flight path corridor clearance
width is 10 statute miles—5 statute miles either side of center line). These mileage markers
generally begin at Top of Climb (TOC), although there can be exceptions—for example, when
the departure airport is at a relatively high altitude and the climbout is such that the TOC is a
considerable distance beyond the 16 nm mark (as in Figure 22.4 on page 643). Checks for
diversion options at the mileage markers continue until the destination is determined to be
within range, eliminating the need for any more diverts.
At each decision point, the system locates the closest alternate airport within the default
parameters set for the alternate ellipse in the Customer Preference database (see “Customer
Preferences Database” on page 616.) The starting point of the alternate ellipse is the decision
point; its forward dimensions are determined by a configurable customer preference setting.
The major axis is a distance in nautical miles, and the minor axis is a percentage factor of the
major axis.
For every decision point attempt to identify a suitable driftdown alternate, the great circle
route to the alternate is tried first. The system attempts to verify that the great circle route to
the alternate is feasible—for example, clearing terrain and meeting weather minimums. When
a great circle attempt to a particular driftdown alternate fails, an attempt using an escape route
is processed—if a record for that alternate exists in the escape route subsection of the Route
String database (see the “Escape Routes Database Records” on page 626.) The escape routes
are tried in proximity order, starting with the closest escape route in terms of distance from the
decision point to the transition point (the first point of the escape route).

641
Terrain Analysis
If the first escape route is not feasible for that decision point, the system attempts to verify that
the next closest escape route is feasible. When an escape route is not feasible, the system
moves on to the next escape route to the same alternate until a valid escape route is found or
until all escape routes to this alternate are exhausted. If no escape route is found, the system
moves on to the next closest alternate airport and repeats above steps until a feasible great
circle or escape route is found.
If an escape route is feasible, the system transitions onto the route only via the transition point,
which is the first waypoint defining the escape route. At each subsequent mileage marker, the
system attempts to verify that the same escape route, beginning with the same transition point,
is still feasible. JetPlan attempts to maintain the same escape route for as many mileage
markers as possible. The process continues until that particular escape route is no longer
feasible because of terrain, fuel constraints, changed conditions at the destination alternate
airport, or other factors. Once a divert airport fails to meet driftdown requirements, JetPlan
reverts from this “failure point” to the previous mileage marker and begins a search for a new
divert airport within the alternate ellipse.
If the Short Search (destination-assured point) option is active, the system does not look for
alternates past the point that it becomes known that the aircraft can lose an engine and make it
to the planned POA by following the flight-planned route. (For more information on the Short
Search option, see Table 22-11, “Terrain Analysis Front-End Options,” on page 630.) If the
Short Search option is not active, the system continues to look for alternates until the POA or a
feasible driftdown alternate has been achieved. The alternate ellipse becomes smaller as the
aircraft approaches the POA.
With regard to the portion of the flight from POD to TOC, the FAR regulations do not address
climbout under driftdown rules. However, JetPlan is designed to always return to the POD via
the great circle route during the climbout, even if the POD is known to be below required
weather minimums. If the POD is known to be below minimums, another alternate (departure
alternate, if specified; closest available, if not) is selected and a modified terrain clearance

642
Terrain Analysis
analysis is attempted from over the POD to the alternate. If a failure point is encountered on
the climb, a decision point is established at the previous mileage marker and the remainder of
the flight continues to be evaluated/cleared under driftdown rules. See Figure 22.4.
This Point Fails TOC
Decision Point
16 nm
POD
Qualification back to the POD starts at the 16 nm point and goes to the TOC.
Driftdown problem is run from the edge of each terrain profile back to the P OD.
Any failure prior to TOC establishes a decision point at the previous profil e.
Figure 22.4. Climbout
When a departure alternate is mandated, JetPlan assumes the POD is not available for landing.
Departure alternates are cleared, based on a modified terrain clearance problem. If it is
necessary for the aircraft to first climb in order to reach a safe terrain clearance altitude, climb
is assumed to take place over the POD. Level flight (engine-out cruise) from over the POD to
the departure alternate is assumed. See Figure 22.5.

643
Terrain Analysis
Minimum 1000’
16 nm
POD Departure Alternate
For planning purposes, assume 32 nm (16 out and 16 back) are always used for climb.
If still too low to clear terrain, climb in place to terrain clearance altitude.
Check for a irfield clearance and positive slope at alternate.
Figure 22.5. Departure Alternate
Mountain Driftdown Output on the Flight Plan

Mountain driftdown output on the flight plan is customer-specific. Generally speaking, the
output includes a brief description, driftdown decision points, and routes to driftdown
alternates. Some formats display escape routes if they can be successfully flown to a given
driftdown alternate.
The following sample block of output shows a typical mountain driftdown scenario with
Direct (great circle) routes to RST, PVU, and SFO. In this example the short search option
(also known as destination-assured) is turned off. Each decision point is displayed in Radial
DME format.

644
Terrain Analysis
In the sample output above. the first three lines provide the following information:
• The first line indicates that up to the first decision point (MTU232/008), if
the airplane loses an engine, the pilot should use RST as the first divert
alternate. The maximum calculated landing weight at RST is 135.4 thousand
pounds. The minimum acceptable altitude shows that this analysis is valid as
long as the plan maintains a flight level of at least 300.
• The second line indicates that up to the second decision point
(TROSE067/024), if the airplane loses an engine, the pilot should use PVU
as the second divert alternate. The maximum calculated landing weight at
PVU is 135.5 thousand pounds. The minimum acceptable altitude shows
that this analysis is valid as long as the plan maintains a flight level of at
least 300.
• The third line indicates that from the second decision point
(TROSE067/024) to SFO (the POA), if the aircraft loses an engine, the
divert alternate is SFO, via a Direct (great circle) route for the remainder of
the route of flight.
The following sample block of output shows a typical mountain driftdown scenario with
Direct (great circle) routes to MSP and JNU. In this example the short search option (also
known as destination-assured) is turned on. The second decision point indicates destination
assured—the point at which the aircraft can reach the POA, using driftdown rules, along the
planned route of flight.
The following sample block of output shows a typical mountain driftdown scenario where
mountain driftdown is successful, but no alternates were required because destination assured
is found at Top of Climb.

645
Terrain Analysis
The following sample block of output uses another format to display the same results as above.
The following sample block of output shows driftdown decision points and direct (great circle)
routes to KCOS, KPIH, and KCOS. In this example, the Short Search (destination-assured)
option was either turned off or destination assured was never found.
The next sample block of output shows driftdown decision points, a direct route, and an escape
route. The main change from the previous sample is on the second and third decision points.
The “AFTER” route on the second decision point is “CYS FQF – KCOS/COS.” The PRIOR
route on the third decision point is “CYS FQF – KCOS/COS.” Note that the location some of

646
Terrain Analysis
the decision points themselves change. The second sample shows the ability to find and
successfully traverse a customer escape route to KCOS after the great circle route to KCOS
has failed.

647
Terrain Analysis
Mountain Driftdown Error Codes

A mountain driftdown route can fail for a variety of reasons, such as poor weather, failure to
clear terrain, or an inadequate airport. The system displays an error code that defines the
failure. The following is a list of possible error codes and associated meanings.
Table 22-12 Mountain Driftdown Error Codes
Tag Code Description

DD_FAILED GF Either the system failed to allocate
memory, or a Jeppesen utility
errored-out.
DD_FAILED_WX WX An error occurred during weather

retrieval.
DD_FAILED_FUEL FF There is insufficient fuel
DD_FAILED_WEIGHT WT Performance issue; the aircraft is

too heavy to be at start-climb
altitude.
DD_FAILED_RWY RY The aircraft cannot land in the

available runway (or is over
maximum certified landing
weight).
DD_FAILED_SLOPE SL The aircraft not maintaining

positive slope at airfield.
DD_FAILED_RESERVES FR Unused at this time.
DD_FAILED_ISA IS Unused at this time.
DD_FAILED_TERRAIN TR There was a problem retrieving

data from the Terrain database.
DD_FAILED_PERFORMANCE PF Attempt to access performance
data that is out of range.
DD_FAILED_TOO_LOW LW Aircraft fell below terrain

clearance altitude.
DD_FAILED_NO_ALT NA A suitable takeoff alternate was

not found.
DD_FAILED_INPUT IE Some data from performance was

illegal.
DD_FAILED_UNKNOWN UK Cause of failure unknown.
DD_FAILED_TAF TF TAF weather did not meet

minimums or was not available.
DD_FAILED_NO_POD_POA NP The POD or POA is not in the

Airport database.

648
Terrain Analysis
Terrain Database Extract Reports

JetPlan provides the ability to extract terrain and route data from the Jeppesen NavData
sources and Terrain database. The data can be imported into third-party software that can then
generate reports that support troubleshooting and analysis of route paths and profiles relative
to terrain heights as computed by the system. The visual presentation of these reports depends
upon the software tools available to you. For more information on generating Terrain database
extract reports, contact your Jeppesen account manager.
JetPlan supports the following Terrain database reports:
• Segment Terrain Profile Report

• Enroute Terrain Profile Report
• Off-route Terrain Profile Report
• Raw Terrain Data Extract Report
The following paragraphs describe these reports.
Segment Terrain Profile Report

This report covers the maximum terrain heights within a user-specified corridor along a great
circle route between two user-specified waypoints, reported at user- specified intervals along
the route. See the following input and output requirements.
Report Input:
• Start Point in the form of a waypoint, latitude/longitude, or airport ID

• End Point in the form of a waypoint, latitude/longitude, or airport ID
• Corridor width, defaulted to 5 nm; can be over-ridden by user
NOTE A customer preference can be used to override the default corridor width
(default = 5.000 nm).
• Mileage marker interval distance, defaulted to 2.5 nm, over-ridable upon

request

649
Terrain Analysis
Report Output:
• Segment overview
– Corridor width
– Mileage marker interval distance
– Start point
– End point
– Great circle distance of the segment.
– True course heading from the start point to the end point (magnetic
not required)
– Maximum terrain height along the great circle route within the
corridor, based on the TerrainScape Data at the resolution used by
JetPlan in Terrain Analysis computations
• Mileage marker detail
– Mileage markers at user specified intervals (defaults to 2.5 nm).
– Maximum terrain height within specified corridor and between the
specified intervals
Enroute Terrain Profile Report

This report covers the maximum terrain heights within a user-specified corridor for all
segments of a given Customer Route String database record. See the following input and
output requirements.
Report Input:
• Start point in the form of a customer route string waypoint or a customer

route string airport ID
• End point in the form of a customer route string waypoint or a customer
• Name in the form of a customer route string name

650
Terrain Analysis
• Group in the form of a customer route string group

Report Output:
– Corridor width
– Maximum terrain height for any one segment
– Customer route string start point
– Customer route string end point
– Customer route string name
– Customer route string group
– Point name
– Great circle distance of the segment
– True course heading from the start point to the end point (magnetic
not required
– Maximum terrain height along the great circle route within the
corridor, based on the TerrainScape data at the resolution used by
JetPlan in Terrain Analysis computations

651
Terrain Analysis
Off-Route Terrain Profile Report

This report covers the maximum terrain heights for all off-route diversion attempts within a
user-specified corridor at specified intervals within a given Customer Route String database
record. The enroute intervals are computed as the corridor width x 2. For example, if the
corridor width is 5 nm, the enroute intervals move in increments of 10. See the following input
and output requirements.
Report Input:
• Start point in the form of a customer route string waypoint or a customer

• End point in the form of a customer route string waypoint or a customer
• Name in the form of a customer route string name
• Group in the form of a customer route string group
• Mileage marker interval distance, defaulted to 2.5 nm; can be over-ridden

upon request
Report Output:
– Corridor width
– Mileage marker interval distance
– Maximum terrain height for any one segment
– Customer route string start point
– Customer route string end point
– Customer route string name
– Customer route string group
– Off-route airport
– True course heading from the enroute point to the off-route airport
– Great circle distance from the enroute point to the off-route airport

652
Terrain Analysis
– Maximum terrain from the enroute point to the off-route airport,

within the corridor width, based on the TerrainScape data at the
resolution used by JetPlan in Terrain Analysis computations
– Mileage markers at user-specified intervals (default is 2.5 nm)
– Maximum terrain height within specified corridor, between the
specified intervals
Raw Terrain Data Report

This report covers the post latitude and longitude of each sub-tile to the West and North of a
given point. The JetPlan terrain data is expected to be at 5-minute resolution, which is 1/12th
of a degree. One tile covers 1 degree square northwest from a given point.
Report Input:
• Raw point in the form of a waypoint, latitude/longitude, or airport ID.

• Tile resolution in the form an integer. For example, if a tile resolution of 12
is entered, then a 12 by 12 output is delivered.
Report Output:
– Raw point
– Tile resolution
• Tile Detail
• Latitude/longitude for each post within the tile
– Maximum terrain height for each post within the tile

653
C HAPTER 23
Point of Safe Diversion

and Point of Safe Return
Point of Safe Diversion and Point of Safe Return
About Point of Safe Diversion (PSD) Flight Plans
About Point of Safe Diversion (PSD)

Flight Plans
You can use the PSD flight plan option to calculate PSDs along a flight plan route. A PSD is
the point where the fuel required to fly to a divert airport is the same as the fuel onboard while
maintaining necessary reserve fuel. The PSD flight plan option enables users to specify
airports for consideration as divert airports. In addition, in a PSD flight plan, the system
always considers the Point of Departure (POD) as the first divert airport. When JetPlan
identifies a PSD for the POD, that PSD is also the Point of Safe Return (PSR), the point at
which it is possible to return to the POD with required reserve fuel intact.
PSD options enable you to direct JetPlan to consider all ETP and ETOPS airports as PSD
divert airports or to consider the PSD divert airports separately from ETP and ETOPS airports.
You can use only one of these methods to specify a PSD divert airport in a given flight plan
request. The following section describes these two options in detail.
PSD Flight Plan Inputs and Output

To direct JetPlan to consider all ETP and ETOPS airports for PSD purposes, enter one or
more PSD divert airports on the POD command line. Entering the airports in sequential order
prompts JetPlan to consider the POD and POA as the first and last diversion airports. The
following example illustrates the PSD flight plan option with the divert airports in sequential
order on the POD command line:
01 OPTIONS FP,PSD (You can also enter other optional commands)

02 POD KMEM/KLAX/KSAN/KOAK
03 POA PHNL
You can also specify a separate PSD divert airport on the POA command line. In this case,
JetPlan considers only the PSD divert airport you specified and does not consider any ETP and
ETOPS airports as PSD divert airports.
The syntax for specifying a PSD divert airport on the POA command line is PSD=<PSD
divert airport>, where PSD divert airport is the ICAO or IATA code of the airport you
are specifying. In the following example, the PSD divert airport is specified on the POA
command line. This input directs JetPlan to consider only KOAK as the PSD divert airport.
01 OPTIONS FP,PSD (You can also enter other optional commands)

02 POD KMEM/KLAX/KSAN
03 POA PHNL,PSD=KOAK

657
About Point of Safe Diversion (PSD) Flight Plans
You can also specify multiple PSD divert airports on the 03 POA command line, as in the
following example:
03 POA PHNL,PSD=KLAX/KOAK
NOTE When a PSD divert airport is specified with PSD= on the POA command line,
JetPlan does not consider any ETP or ETOPS airports in the request as PSD divert
airports.
PSD Output
Information on the PSR and PSD latitude, longitude, enroute time, and divert airport is
provided on the formatted flight plan for normal operations and for a configured worst
performance case, as shown in the following example:
PSD/PSR SUMMARY - ENROUTE

DIVERT POINT TIME TO
PSR: KMEM/PHNL Normal Operation N31246W131054 0506

PSR: KMEM/PHNL [Worst Case] N31126W131474 0512
PSD: KLAX Normal Operation N27060W143342 0700

PSD: KLAX [Worst Case] N26504W144120 0706
PSD: KOAK Normal Operation N26294W145024 0714

PSD: KOAK [Worst Case] N26222W145186 0716
[Worst Case] = 1LE case requested
The following sections describe how JetPlan performs the PSD calculations.

658
Calculating the PSDs

JetPlan calculates a PSD on each segment of a flight plan, starting at the Top of Climb (TOC)
and continuing to the Top of Descent (TOD). A PSD exists on a route segment if (1) there is
enough fuel on board to fly from the segment start fix to the current divert while maintaining
reserve fuel and (2) the same condition is false for the segment end fix. The PSD becomes the
start fix of the first route segment for the next divert airport to be considered. If JetPlan does
not identify a PSD on a route segment, it moves on to the next segment.
Figure 23.1 illustrates how JetPlan calculates PSDs. In this example, the first PSD is also the
PSR because it is the point at which the aircraft can return to the POD with required reserve
fuel intact.
Figure 23.1. Determining the PSR and PSDs

659
Calculating Reserve and Divert Leg Fuel Burn

When considering a potential divert airport, JetPlan calculates the fuel required from a given
fixed point on the route segment to the divert airport, factoring in the required reserve fuel.
The divert leg begins at the PSD route point, but leg burn is calculated at the divert altitude.
The fuel on board at the PSD divert airport is one of the following: (1) at least 10% of the trip
fuel required to get to the divert airport or (2) the specified minimum (in weight or time) as
defined by the Minimum Safe Divert Alternate Fuel (MDF) or the Minimum Safe Divert
Alternate Time (MDT) parameter in the Customer Aircraft Database (CADB). The formula
used to determine the divert leg burn and the reserve fuel burn for a PSD flight plan is as
follows:
• Divert leg burn = Cruise fuel burn plus descent fuel burn
• Reserve fuel burn = The highest of the following values:
– 10% x (cruise fuel burn plus descent fuel burn)
– PSD minimum fuel weight ─ Defined by the Minimum Safe Divert
Alternate Fuel (MDF) parameter in the CADB.
– PSD minimum fuel time ─ Defined by the Minimum Safe Divert
Alternate Time (MDT) parameter in the CADB.
For details on the CADB parameters, see Chapter 27, “Customer
NOTE These are minimum fuel calculations. The actual reserve value is based on a
distance/fuel calculation that can result in slightly higher fuel reserves.

660
Figure 23.2 illustrates the divert leg. See Table 23-1 for information on the CADB parameters
used to determine the worst performance case in PSD flight plans.
Figure 23.2. The Divert Leg of a PSD plan
Calculating PSD for Normal Operations and for the Worst

Performance Case
JetPlan performs the PSD calculations in two phases, performing a first pass through the
calculations assuming normal operations, followed by a second pass that assumes a specific
worst performance case.
You can define the worst performance case by setting the ETP cruise mode, airspeed, and
altitude parameters in the CADB record for the aircraft used in the PSD flight plan. Table 23-1
lists the parameters in the CADB that the system uses to determine the worst performance
case.

661
JetPlan applies an order of precedence to the process of determining the worst performance
case. See “Order of Precedence for Worst Performance Case Calculations” on page 662. If the
necessary CADB parameters are not configured, the application does not calculate a worst
performance case. For details on the CADB parameters, see Chapter 27, “Customer Aircraft
Database.”
Table 23-1 CADB Parameters Used to Determine Worst Performance Case
Performance Case CADB Parameter Parameter Code

Non-emergency Non-emergency ETP True NA
Airspeed
Non-emergency Non-emergency ETP Flight Level NF
One engine-out ETP 1LE Cruise Mode EC1
One engine-out ETP 1LE True Airspeed EA1
One engine-out ETP 1LE Pressurized Flight Level EF1

in hundreds of feet
- or - - or -
ETP 1LE Pressurized Flight Level
in millibars EM1
Emergency ETP True Airspeed EA
Emergency ETP Cruise Mode EC
Emergency ETP Depressurized Flight Level EF

in hundreds of feet
- or - - or -
ETP Depressurized Flight Level in
EM
millibars
Order of Precedence for Worst Performance Case Calculations

JetPlan applies the following order of precedence to determine the worst performance case
(see Table 23-1 for definitions of the parameters):
• If the NA and NF parameters are set in the CADB record, the system
calculates the non-emergency case using the following values:
– Divert cruise True Airspeed (TAS) = NA
– Divert cruise flight level = NF

662
• If the NA and NF parameters are not set in the CADB record, the system
checks the values of EC1, EA1, and EF1 (or EM1). If all of these parameters
are set, the system calculates the one-less engine case using the following
values:
– Divert cruise TAS = EA1
– Divert cruise flight level = EF1 (or equivalent for EM1)
• If the NA, NF, EC1, EA1, and EF1 (or EM1) parameters are not set in the
CADB record, JetPlan checks the values of EA, EC, and EF (or EM). If all
of these parameters are set, JetPlan calculates the emergency case using the
following values:
– Divert cruise TAS = EA
– Divert cruise flight level = EF (or equivalent for EM)
• If JetPlan cannot find the necessary values defined in the CADB, it does not
calculate the worst performance case.

663
C HAPTER 24
Optimal Scenario
Analysis
Optimal Scenario Analysis
Overview
Overview
Optimal Scenario Analysis (OSA) is a JetPlan feature that provides increased route choice and
flight-cost evaluation. The purpose of OSA is to achieve the best possible route, based on a
user-defined factor of fuel, time, or money. JetPlan analyzes and compares multiple route and
profile possibilities, called scenarios. These multiple scenarios are the result of either an
external evaluation, in which several routes are considered (for example, a RT/ALL input), or
an internal evaluation, for which multiple profile entries provide route variations that can be
evaluated.
To use OSA, enter 4D after the FP flight plan command on the Options command line. For
more information on flight plan commands, see Chapter 2, “Option Commands.”
Typically, JetPlan produces an optimal route and profile for nearly every flight plan
calculated. However, conditions can exist which result in less efficient, sub-optimal results.
Generally, these conditions occur on very long flights where the weight of the aircraft varies
greatly between the beginning and end of cruise, or if other factors cause the aircraft to stay at
a lower altitude than normal for a significant portion of the flight. In these cases, OSA
improves flight planning results and lower costs along the way.
With OSA active, JetPlan calculates information by accessing wind and temperature
information at two or more flight levels. Optimal routes are determined using the data from
each profile, and the results are ranked. The analysis and ranking process of an OSA flight
plan is based on the user-determined outcome parameters: fuel burn or flight operating cost.
Reducing inefficient route planning significantly lowers fuel and operating costs. However,
fuel and operating costs are not always the most expensive factors.
OSA can be used in coordination with JetPlan's Enroute Charges feature to produce savings
that are even more meaningful. Combining the OSA cost parameter with the Enroute Charges
function ranks routes based on total cost figures: operating costs plus navigational fees.
JetPlan can calculate an operator's optimal route between city pairs for any day, time, or
condition.
Used properly, OSA can determine the most cost-effective route, based on fuel, time, or
enroute charges.
NOTE The decision to use OSA is based on several factors and the type of
operation. Used in its simple form, OSA is employed when an operator expects to
encounter any of the aforementioned conditions that lead to sub-optimal results. If
these conditions are not expected or are unlikely to impact a flight due to user-
imposed restrictions (altitude restraints, Minimum Equipment List items, and so on),
OSA probably does provide a benefit compared to JetPlan's traditional optimization
methods.

667
Overview
Background
With JetPlan’s traditional optimization method, a flight plan is calculated using one external
and one internal scenario. The external scenario is the data or user entries in a flight plan
request—for example, Point of Departure (POD), Point of Arrival (POA), route, profile, and
so on. The internal scenario is the basis on which a flight plan is computed. With any flight
plan calculation, consideration of both external and internal factors occurs before a result is
produced.
On rare occasions and given the right set of circumstances, the traditional method produces a
sub-optimal route The OSA technique, however, allows the flight planner to provide the extra
data necessary to reduce the possibility of sub-optimal routes. By entering multiple scenarios,
you can ensure a ranking of the results based on the specified outcome parameter. The extra
scenarios can be internal, external, or both, depending on your requirements.
The OSA feature automatically applies two internal scenarios by default, but this can be
adjusted to fit your needs. Multiple external scenarios can be run and the results archived for
comparison or printed at your discretion. The specifics depend on the requirements of the
planner. To determine which method to use, a more detailed understanding of internal and
external scenarios is necessary.
Internal Scenarios
Internal scenarios are the predefined or programmed situations set up to provide a basis for
developing information. For example, using JetPlan's traditional optimization method, the
internal scenario is a single representative airspeed and altitude used to calculate the route.
Once that route is determined, an optimized profile can then be applied and a flight plan is
formed. This process of applying representative data is normally outside the control of the
user, but is set up by JetPlan for the development of route information. Implicitly, there is
always one internal scenario for every computer flight plan.
With OSA, multiple internal scenarios can be predefined by varying or increasing the number
of representative altitudes used in the calculations. Having multiple altitudes provides multiple
optimal routes, one for each altitude used. The variance in each route (if any) is the result of
changes in the weather data from one flight level to the next. With multiple internal scenarios
there is an increased probability of achieving the optimal route for the given flight factors.
OSA has a default setup defining two internal scenarios. The first accesses weather data from
the 200 millibar level; the second uses data from the 300 millibar level. A route is determined
for each of these scenarios. A plan is then calculated for each route, an optimized profile is
applied, and the data from the two completed flight plans is then analyzed and ranked based on

668
Overview
your preferred outcome parameter: fuel, time or cost. The most effective flight plan can then
be printed. As implied above, user-defined internal scenarios can be set up to calculate flight
plans at additional or alternative altitudes.
External Scenarios
External scenarios refer to those factors directly controlled by the JetPlan user, specifically the
input request set. For example, the inputs that typically provide the data necessary to compute
a flight plan constitute one external scenario. If a change is made to any one input item, or
input string, a new external scenario is created. In other words, every flight plan request that
differs from the next request is a new external scenario. By definition, every computer flight
plan has at least one external scenario.
External scenarios can also be defined implicitly using the Customer Route Database (CRDB)
entry of RT/ALL. In this case, each applicable company-stored route invokes a unique
external scenario, a unique flight plan. For example, if ten company-stored routes exist for the
POD/POA combination of KSFO and RJAA, a RT/ALL input implicitly defines ten external
scenarios.
When you enter multiple external scenarios, OSA generates a complete route optimization
computation on each input set and every predefined internal scenario (see “Internal and
External Scenario Interaction” on page 669). The outcome provides one optimal plan per input
set. These plans are ranked based on the outcome parameter (least fuel burned), and the top
five are printed according to rank. OSA prints the top ranked, or primary, flight plan in its full
output format, while summarizing the four lower ranked, secondary plans.
Internal and External Scenario Interaction

In OSA, every external scenario encounters the predefined internal scenarios for route
generation. Using the default internal scenario situation, an external scenario faces two
internal calculations—one at 200mb and the other at 300mb. However, a RT/ALL entry that
provides ten company routes (10 external scenarios) encounters only 10 OSA calculations.
This is because the routes are already defined. Invoking the RT/ALL command limits the route
evaluation process to the RT/ALL inputs only. In this case, JetPlan evaluates to find the best of
the available routes.

669
OSA Commands and Options

In preparing to use OSA, you need to maintain consistency between the flight plan
performance index and the OSA preferred outcome parameter. The performance index can be
defined in your Customer Aircraft Database (CADB) or entered on the Performance Index
Command Line. If the outcome parameter and performance index do not match, the resulting
output might be misleading. For example, entering an outcome parameter of flight cost (C)
and a performance index of fuel (F) creates a situation in which JetPlan calculates the flight
plan data based on one factor (fuel) and ranks the plans based on another factor (cost). If a user
typically runs flight plans with a performance index set to optimize based on fuel, then fuel
needs to be the outcome parameter specified in the OSA plan. Of course, you can enter any
OSA outcome parameter available, but be aware of how the plans are calculated versus the
way they are ranked.
The following commands and options are available through any product that interfaces with
JetPlan, such as JetPlan.com or JetPlanner. If you access JetPlan through a customer-specific
product, consult the user guide for that product.
The OSA command and options and commands are as follows:
4D Option command – Invokes the OSA feature. 4D follows the flight

plan command (FP) on the Options command line. This input must be
used in conjunction with a preferred outcome parameter.
F Preferred outcome parameter – Ranks OSA flight plans based on the

least fuel burned enroute. The flight plan's Performance Index should
not contradict the preferred outcome parameter.
T Preferred outcome parameter – Ranks OSA flight plans based on the

least amount of time enroute. The flight plan's Performance Index
should not contradict the preferred outcome parameter.
C Preferred outcome parameter – Ranks OSA flight plans based on the

least amount of flight cost (fuel cost and direct operating cost). The
flight plan's Performance Index should not contradict the preferred
outcome parameter.

670
P Immediate Print parameter – Specifies that you are entering only one
explicitly defined external scenario (not including the RT/ALL
input). Plan results are immediately printed upon completion of the
computation.
Note: Omitting the P option invokes the JetPlan expectation of

multiple external scenario requests, that is, no output is rendered until
Print is requested. (see “Explicit External Scenarios” on page 674).
MB/xxx,xxx,xxx... Specifies additional or alternative millibar levels (altitudes). You can

enter up to nine values. This option is only available for OSA flight
plans.
-e Calculates enroute charges and includes results in the total cost

computation. The least-cost outcome parameter (C) should be
invoked when this option is of interest.
-o Outputs enroute charges summary at the bottom of the flight plan.

This is only available to those accounts contracted to use JetPlan's
Enroute Charges feature.
-k Similar to the -e option, the -k is used in conjunction with the cost

outcome parameter (C) to determine the price difference between fuel
at POD and POA. This option takes the total fuel the flight plan
represents to be in the aircraft upon landing—reserve, alternate, and
contingency fuel as well as any extra or tankering fuel—and
multiplies that amount by the price difference between fuel at the
POD and POA. Fuel price figures must be stored in the Customer
Airport Database for each airport.
PRINT Used after multiple external scenario requests. This option prints the
top five optimal flight plans (those selected as optimal in the internal
scenario calculations). The plan ranking the best, based on your
preferred outcome parameter, is printed in its entirety, while the four
lower ranked plans are printed in synopsis as secondary.
2D Revert back to standard (non-OSA) mode. After running a 4D

request, you can rerun the same request, without OSA, by entering 2D
rather than 4D.

671
Basic OSA Examples And Explanations

The basic OSA flight plan refers to the calculation of the predefined internal scenario(s)—
however many that might be—for the single external scenario requested (non-RT/ALL input).
A single optimum output is expected. The following examples demonstrate the proper use of
the basic OSA feature and provide explanations of the user input. The examples given use the
line mode entry method and assume all remaining JetPlan prompts (questions 02–19) are
answered in a typical fashion.
Example:
01 OPTIONS FP,4DFP
This input invokes JetPlan to compute a flight plan (FP) using the OSA feature (4D). The
program performs dynamic route optimization using the OSA default wind and temperature
forecast data from 2 altitudes, 200mb and 300mb. The two resulting optimal routes are
analyzed according to your preferred outcome parameter (F), and the most effective plan (fuel-
efficient) is printed immediately (P).
Example:
01 OPTIONS FP,4DTP
This input is the same as the example above except that the analysis and subsequent output is
time (T) based rather than fuel based.
Example:
01 OPTIONS FP,4DCP
This input is the same as the previous two except that the analysis and subsequent output is
cost-based. The cost parameter (C) implies the specification of a cost index and/or cost factors
within the request set or stored in the CADB.
Example:
01 OPTIONS FP,4DFP,MB/300,250,200,150
This input requests an OSA flight plan using four internal scenario calculations. Dynamic
route optimization is performed using wind and temperature forecasts from the 300, 250, 200,
and 150 millibar levels. The resulting output is based on your preferred outcome parameter
(fuel) and printed immediately.
Example:
01 OPTIONS FP,4DFP,MB/250

672
This example generates only one internal scenario calculation (250mb) which is no different
than the traditional method, but the level specified can be closer to the intended flight level,
and thereby more beneficial.
Example:
01 OPTIONS FP,MB/250,150
This input invokes the use of the OSA millibar feature despite missing the 4D command input.
Since the millibar specification command (MB/xxx,xxx) is only available when used in
conjunction with the 4D command, the implication is that the intent of the request is for an
OSA calculation. In this example, two internal scenarios are calculated using forecast data
from the 250 and the 150 millibar level. JetPlan assumes the print immediately option (P) and
uses the performance index specified (in the CADB or on the Performance Index command
line) as the preferred outcome parameter.
Example:
01 OPTIONS FPR1234,2D
This input takes plan #1234, previously run with OSA invoked, and runs it without OSA (in
standard or traditional mode).
Multiple External Scenarios

As defined above, the basic OSA example derives one flight plan from the analysis of two or
more internal scenarios per request set. This example increases the likelihood of an optimal
route for a given request set, but it does not address the possibilities available by varying the
external scenario request sets and then comparing and ranking those results.
By using multiple external scenarios, the data available for analysis increases the optimization
and cost savings benefits far beyond simple route optimization. Varying any of the inputs in
the request set provides the possibility of a new outcome. Comparing and ranking multiple
outcomes is the intended idea behind OSA. Hence, using multiple external scenarios provides
both route optimization—the result of internal scenario comparisons—and plan-efficiency
determination, which is the result of comparison analysis between all of the optimal outputs.
Unfortunately, multiple external scenarios do increase computation times and plan number
generation, but the benefits can far exceed the inconveniences, especially when least total cost
is the outcome desired.

673
Explicit External Scenarios

By omitting the immediate print option (P) from the OSA command (4D), additional input
request sets can be entered. This feature allows you to enter several request sets before actually
getting any output back. When all external scenarios have been submitted and output is
desired, the command 4DPRINT is entered and the results of the top five plans are printed by
rank, according to your preferred outcome parameter.
For example, suppose six external scenarios are submitted using the 4DF command. Each
external scenario encounters the predefined internal scenario computations (12 computations
by default) and then produces the optimal plan for each input request set (6 optimal plans in
all). As each optimum is determined, the plan is stored in an archive file for the eventual
ranking and retrieval. Once all of the computations are complete, the 4DPRINT command
initiates a comparison of the archived plans. The plans are ranked and printed according to
your preferred outcome parameter. The plan ranked as primary is printed in full. The
secondary plans (up to four in total) are printed in summary at the end of the primary plan.
More than four secondary summaries are available by requesting customer service to amend
the password attribute file. An enroute charges output option also provides more than four
secondary summaries.
Example:
01 OPTIONS FP,SP,4DC (OSA plan with cost as the outcome parameter)
02 POD KSFO
03 POA RJTY
06 ROUTE J//
07-19...
20 COMPUTING 5959 (internal scenario at 300mb)
20 COMPUTING 5960 (internal scenario at 200mb)
Result: No flight plan output is produced, the optimal plan is archived.
Example:
01 OPTIONS FPR (Reload previous inputs)
02 POD @6
06 ROUTE //J (The route input is changed)
07 HOLD,ALTERNATE/DIST GO (Compute request with amended inputs)
20 COMPUTING 5961 (Internal scenario at 300mb)
Result: No flight plan output is produced, the optimal plan is archived.

674
Example:
01 OPTIONS 4DPRINT (Requests output of optimal plans, primary and secondary)
PLAN 5960 KSFO TO RJTY 747N LRC/M IFR 07/22/08

NONSTOP COMPUTED 1733Z FOR ETD 0000Z PROGS 2212ADF SS747 LBS
FUEL TIME DIST ARRIVE TAKEOFF LAND AV PLD OPNLWT

POA RJTY 171107 09/32 4550 0932Z 607532 436425 010000 415000
ALT RJTT 004215 00/10 0024 0941Z
HLD 007210 00/30
RES 000000 00/00
XTR 000000 00/00
TXI 000000
TOT 182532 10/11
KSFO MOLEN3 ENI..KLARK..4230..4540..4750..4860..4870..4890..4870..
4560..4250..ONEMU R580 OATIS OTR3 GOC..MI..RJTY
WIND M003 MXSH 3/4870

FL 390/4980 430/ONEMU 390
DOLLARS COST 035065
SECONDARY FLIGHT PLAN

PLAN 005962 BURN 171164 TIME 09.32 COST 035076 AVG WIND M002
DIST 04549 TOW 607589 PLD 010000 ROUTE CRZ LRC
KSFO..FARRA..TREVR..4130..4440..4650..4860..4870..4980..4870..4560..
4250..ONEMU R580 OATIS OTR3 GOC ATS IZUMI W18 JD B14 MI..RJTY
FL 390/4980 430/ONEMU 390

REQUEST NO. 5960
In this example, note that the two flight plan requests encounter two internal computations
each, one at the 300mb level (plans 5959 and 5961) and the other at the 200mb level (plans
5960 and 5962). Once 4DPRINT is entered, a cost comparison is performed between the two
plans archived as optimal (plans 5960 and 5962). The primary plan (least expensive, 5960) is
printed in full, while the secondary plan (5962) is printed in synopsis format.
Explicit External Scenario Limits

You can enter up to 100 external scenarios before OSA automatically terminates the input
session and begins processing the results as if 4DPRINT had been requested. A route input of
RT/ALL can be used as one of the explicitly defined external scenarios, but the number of

675
external scenarios generated (the number of company-stored routes) counts against the upper
limit of 100 external scenarios. For example, a RT/ALL entry that initiates twenty (20)
scenarios leaves eighty external scenarios available for input before reaching the limit.
Changing Outcome Parameters

If you attempt to change the outcome parameter (fuel, time, or cost) before entering
4DPRINT, the OSA feature ignores this change and continues the process as originally begun.
In other words, the outcome parameter used on the first explicitly defined external scenario
(request set inputs) is applied to all subsequent scenarios until 4DPRINT is entered and an
output is delivered. However, other types of JetPlan requests, such as informational checks
and database searches, can be made without affecting the ability of OSA to archive and rank
external scenarios. The following example illustrates both.
Example:
01 OPTIONS FP,SP,4DF (OSA request with fuel as the outcome parameter)
02 POD KSFO
03 POA EGLL
06 ROUTE J,ARBO,ZAPPO
07-19...
Result: No flight plan output is produced, and the optimal plan is archived.
Example:
01 OPTIONS FPR,4DC (User attempts to change the outcome parameter. This is ignored.)
02 POD @6
06 ROUTE ABC,XYZ
07 HOLD,ALTERNATE/DIST GO (Compute request with amended inputs)
Result: No flight plan output is produced, and the optimal plan is archived.
Example:
01 OPTIONS RT,SUM/ALL (A totally different type of request is made.)
Result: Customer Route Database (CRDB) summary prints.
Example:
01 OPTIONS 4DPRINT (Requests output of optimal plans, primary, and secondary.)

676
Result: The formatted output for the primary OSA flight plan, followed by a secondary
synopsis prints.
Optimizing Direct vs. Specific Route Selector (SRS) Great Circle

When an external scenario has a route input of D (or D//D) on an OSA flight plan, a special
process occurs, increasing the number of internal scenarios by one. For example, if the internal
scenario situation is default, meaning two calculations (one at 300mb and the other at 200mb),
then the number of internal scenarios run becomes three. If you alter the number of internal
scenarios to some other amount by including the altitude specification command (for example,
MB/350,250,150), then the number of calculations is the amount specified plus one.
The extra internal scenario is an SRS great circle flight plan. The reason a great circle plan is
included as an internal calculation is that it is a logical and beneficial comparison to the
optimized direct (route input of D or D//D) scenario. In a few cases with very light winds, the
SRS great circle route can produce a better flight plan result than the optimized direct route.
This is because the optimized direct route is constrained to whole degrees of latitude/longitude
for ICAO ATC reporting purposes, while the SRS great circle route is primarily an analysis
tool not to be used for real flight plans. In any event, it is rare for SRS great circle to produce a
better result, since winds normally play a big role in determining the optimal route.
In this optimized direct situation, OSA processes each internal scenario (300mb, 200mb and
SRS great circle), ranks the results, and prints the optimal, or primary, flight plan. No
secondary flight plan summaries are produced since these calculations are all internal
scenarios. However, if an optimized direct plan is one of many external scenarios, then
secondary summaries are produced.
Example:
01 OPTIONS FP,SP,4DF
02 POD KSFO
03 POA KDEN
06 ROUTE D
07-19...
20 COMPUTING 1234 (internal scenario at 300mb, optimized direct
routing)
20 COMPUTING 1235 (internal scenario at 200mb, optimized direct
routing)
20 COMPUTING 1236 (internal scenario using SRS great circle input -
GR8C1010)
...no flight plan output is produced, the optimal plan is archived...

677
Example:
01 OPTIONS LDR1234
02 POD @6
06 ROUTE J
07 HOLD,ALTERNATE/DIST GO (compute request with amended inputs)
20 COMPUTING 1237 (internal scenario at 300mb, jet airway routing)
20 COMPUTING 1238 (internal scenario at 200mb, jet airway routing)
...no flight plan output is produced, the optimal plan is archived...
Example:
01 OPTIONS 4DPRINT
...the formatted output for the primary plan, followed by a secondary
synopsis prints here...
Enroute Charges and OSA

Among the OSA command definitions listed earlier is an option for including enroute charges
in the computation (-e). This means that flight plans that have flight cost as the outcome
parameter (for example, 4DCP) are impacted by the outcome of the fuel cost plus the time cost
(direct operating cost) plus the enroute charges. Hence, a low fuel or minimum time plan
might not necessarily be the minimum total cost plan if the route calculated incurs relatively
high enroute charges. OSA is therefore a very important feature with respect to assuring true
cost optimization in an environment where high enroute charges have a major impact on flight
costs (for example, international flights).
Enroute Charge Example

For an example of how combining enroute charges and OSA can provide dramatic results,
assume a user has two routes stored for the airport pairs: WSSS and RJAA (RTE1 and RTE2).
You select an OSA flight plan with cost as the outcome parameter and enroute charges to be
included. You also have selected a cost index of 150.
Example:
01 OPTIONS FP,4DCP,-e
02 POD WSSS
03 POA RJAA
06 ROUTE RT/ALL

678
Based on a route input of RT/ALL, assume that OSA computes the following results:
Index
Enroute based Enroute
Fuel Burn Time Cost Charges Total Cost
Scenario (lbs) (Hr/Min) (fuel/time) ($) ($)
RTE1 125613 6/08 $29,752 $2,926 $32,678
RTE2 128679 6/17 $30,449 $2,094 $32,543
These results indicate that OSA would select the second scenario (based on RTE2) for its
primary flight plan output. This would not have been the case if enroute charges had not been
included. It is evident that the route that is least flight cost is not always the least total cost
flight plan.
Enroute Charge Print Option

In coordination with the enroute charges option (-e), an enroute charges summary output
option (-o) is available. This option can only be used with the (-e) option. It provides the
summary output specific to the JetPlan Enroute Charges option at the bottom of the normal
flight plan output. For more information, see Chapter 25, “Enroute Charges and FIR
Traversal.”
Route Cost Summary Reports

A feature that is available upon request (additional format necessary) is the Route Cost
Summary report. This feature is used to summarize the cost effectiveness of each route stored
in a CRDB for a given airport pair (POD/POA). In this case, the use of the command 4DC(P)
assumes the inclusion of enroute charges.
The value added by this feature includes the ranking of all routes stored in the CRDB for the
given airport pair, and the inclusion of time restricted routes. In contrast, using the standard
OSA/Enroute Charges feature, a RT/ALL entry with ten stored route files produces a
maximum output of five plans (one primary and four secondary). See “Multiple External
Scenarios” on page 673). You are left with no information on the other five routes: how they
rank, what their costs are, and so on. In addition, the standard method does not provide any
information regarding routes that have time restrictions. If a route is not available due to time
restrictions, it is not part of the standard output at all.

679
Example:
01 OPTIONS FP,4DCP,BAW
02 POD EGLL
03 POA OERK
06 ROUTE RT/ALL
07 HOLD,ALTERNATE/DIST 30,OEDR
08 ETD 1200
09 PROFILE I
10 A/C TYPE/REGN $SS747G
11 CRZ MODE LRC
14 PAYLOAD 20000
20 COMPUTING 5974
20 COMPUTING 5975
20 COMPUTING 5976
20 COMPUTING 5977
20 COMPUTING 5978
20 COMPUTING 5979
20 COMPUTING 5980
20 COMPUTING 5981
20 COMPUTING 5982
In the example output, all plans are ranked and displayed (not just top five) based on the
amounts in the total cost column. In addition, a warning column provides flag information
regarding specific criteria to be considered (for example, time restrictions on route files
LHRRUH4 and LHRRUH2).
This option does not provide the typical flight plan output. It is strictly a planning and cost
evaluation tool for determining the total cost of each route available.

680
C HAPTER 25
Enroute Charges and

FIR Traversal
Enroute Charges and FIR Traversal
Overview
Overview
NOTE The Enroute Charges feature is disabled unless activation is requested.
Contact Jeppesen Customer Service to request activation of this feature.
Enroute Charges refers to the navigational fees levied by various countries for the privilege of
overflying their territorial airspace. These fees vary from country to country and are
complicated by many factors such as monetary exchange rates, aircraft size (weight), facilities
used, and distances traveled. An aircraft operator can be faced with tremendous and
sometimes unexpected costs if not prepared to spend the time necessary to determine least-
cost routing or to crosscheck invoices. JetPlan's Enroute Charges, Flight Information Region
(FIR) and Upper Information Region (UIR) Traversal, and Archive and Report features
provide a means for determining, documenting, and reporting the enroute costs associated
with international flight operations.
With JetPlan, you can perform the following tasks:
• Calculate overflight charges associated with a flight

• Display enroute charges on a flight plan
• Calculate overflight charges associated with a flight on an ad hoc basis
(without a flight plan)
• Generate and archive reports of enroute charges and FIR traversal
information. (For information on Enroute Charges archiving, see
Chapter 26, “Archiving.”
• View and generate reports of current exchange rates
• Manage a customer exchange rate database (requires a setting in your
ID/Attribute file)
These topics are discussed in the following sections.

683
Accessing Enroute Charges Through JetPlanIII
Accessing Enroute Charges Through

JetPlanIII
NOTE With the exception of Enroute Charges and FIR Traversal, the JetPlanIII
options are available to all customers. The Enroute Charges and FIR Traversal
options are disabled unless activation is requested. You must contact Jeppesen
Customer Service to request activation of these options.
You can access Enroute Charges and FIR Traversal through JetPlanIII, a program that
provides support information for your flight planning requirements. JetPlanIII enables you to
work with several databases that provide information on airports, airways, SIDs, STARs, and
waypoints, in addition to enroute charges and FIR traversal fees.
NOTE Most JetPlanIII options are also available in JetPlan.com on the General
Info tab.
To access the JetPlanIII program

• On the Options command line, enter JPIII.
01 OPTIONS JPIII
The system displays the JPIII (JEPPESEN Data Bases) menu.
JEPPESEN Data Bases

ENTER “1” for Airport Info
“2” for High/Low Altitude Airways
“3” for SID/STAR Info
“4” for SID/STAR Detail
“5” for Waypoint Info
“6” for Exchange Rates
“7” for Fir traversal (ad hoc)
“8” for Enroute charges (ad hoc)
“Q” to QUIT
The following sections discuss using the Enroute Charges (ad hoc), Exchange Rates (ad hoc),
and FIR Traversal (ad hoc) options.

684
Generating an Ad Hoc Enroute Charges Report
Generating an Ad Hoc Enroute Charges

Report
The Enroute Charges feature is a planning program that details a flight’s route in terms of
navigational cost. It reports the specifics of the flight—the terminals, flight level, aircraft
weight, and route—and summarizes the expected costs based on the standing currency
exchange rates and the distances traveled through the airspace of the countries or regions
traversed. This report provides a tool for analyzing and auditing the navigational fees charged
by various countries.
NOTE The Enroute Charges option is disabled unless you contact Jeppesen
Customer Service to request activation.
To generate an ad hoc Enroute Charges report

1. On the Options command line, type JPIII to start the JetPlanIII program.
01 OPTIONS JPIII
The system displays the JPIII menu. (See “Accessing Enroute Charges
Through JetPlanIII” on page 684.)
2. At the JPIII prompt, enter 8.
>8
The JPIII program displays the Enroute Charges Calculation Menu,
prompting you to provide information—similar to running a flight plan on
the JetPlan system. The following table lists the prompts and describes the
inputs.
Table 25-1 Enroute Charges Prompts and Inputs
Prompt Input
Options: Enter any flight plan option that applies to route or weather. Do not
enter options defined as output format. If no options are needed,
press ENTER.
POD: Enter the ICAO or IATA identifier for the Point of Departure
airport.
POA: Enter the ICAO or IATA identifier for the Point of Arrival airport.

685
Table 25-1 Enroute Charges Prompts and Inputs (continued)
Prompt Input
Route: Enter standard JetPlan “route” values, following the syntax and
input rules defined in this manual. You can use Customer Route
database files in lieu of standard inputs. If no route is entered,
JetPlan determines an optimum route. For more information, see
Flight Level: Enter a flight level using the syntax and input rules defined in this
manual (for example, 350 = 35,000 feet). For more information,
see Chapter 9, “Profile Commands.”
Aircraft Weight: Enter the weight of the aircraft (typically, the Maximum Takeoff
Weight), in pounds or kilograms, depending on the unit of measure
applied to the aircraft when running a flight plan.
Example:
Enroute Charges Calculation Menu
Options:RN
POD:OMDB
POA:EDDM
Route:J,TAMRO
Flight Level:350
Aircraft Weight:500000
NOTE The inputs entered at the Route prompt and the subsequent route output might not be
applicable at this time. Navigational structure changes over time. Use this example as a
guideline only.

686
3. The system generates an Enroute Charges report based on your inputs.

Sample Enroute Charges Report
FIR/UIR Enroute Charge Report
From OMDB to EDDMa

Flv 350 Weight 500000 lbs 29APR2013b
Routec
OMDB NADI1G NADIL M557 BALUS UL768 HFR A788 LOXOM UN318 TAMRO UT503
OVANO UL768 FIRAS A21 KTN R785 NIKAS UL619 MUT UB545 KFK UL610
VADEN Y520 UTEKA ATS BABIT UT23 GRZ UL604 MILGO Q112 NAPSA NAPS1A
EDDM
Eurocontrol RSO Summaryd

Country Distance Unit Rate Charge
LC 171 37.72 137.39
LT 902 31.14 598.28
LB 441 36.48 342.67
LY 355 46.38 350.70
LH 210 40.50 181.16
LJ 34 66.74 48.33
LO 260 70.21 388.82
ED 81 76.65 132.24
Total 2454 km 2179.59 EUR 2855.11 USD
Non-EuroControl Summarye
FIR/UIR AW Dist GC Dist Currency Charge Charge
(nm) (nm) USD
OMAE 144 129 USD 90.00 90.00
OBBB 310 310 BHD 56.70 150.36
OEJD 565 519 SAR 2096.00 558.87
OJAC 75 75 JOD 121.92 172.07
OSTT 190 182 EUR 283.75 371.69
Total 1284 1215 1342.99
Exchange Rate Summaryf
Currency Source Exchg Time Date

BHD JEPP 0.377 16:15:06 29APR13
SAR JEPP 3.750 16:15:06 29APR13
JOD JEPP 0.709 16:15:06 29APR13
EUR JEPP 0.763 16:15:06 29APR13
Charge Summary - USDg

ECTRL RSO 2855.11
Non-ECTRL 1342.99
Total 4198.10
a. POD and POA ICAO identifiers.

b. Flight level, aircraft weight, and report date.
c. Summary of the route as calculated using the Enroute Charges program. (This output might not
be applicable at this time. Use this example only as a guideline.)

687
d. Standard EUROCONTROL charge for POD and POA airports. Charge is in Euros and convert-
ed to U.S. Dollars.
e. List of FIRs/UIRs traversed, airway distance, Great Circle distance,
currency used by country, total charge in local currency, and total charge
converted to U.S. Dollars for regions outside of EUROCONTROL.
f. Currency exchange rate used in the calculation, source of exchange rate, and
time and date the exchange rate was last updated
g. Summary of charges in U.S. Dollars
Viewing Exchange Rates

To support the Enroute Charges feature, Jeppesen provides and maintains a currency exchange
rates database. You can access the menu for this database through JetPlanIII. The following
paragraphs cover the options available on the JEPPESEN Exchange Rates menu.
NOTE Currency exchange rates are updated once a day from XE.com, a
commercial data feed source based in Toronto, Canada.
To view all exchange rates in the Jeppesen Exchange Rates Database

1. On the Options command line, enter JPIII to start the JetPlanIII program.
For details, see “Accessing Enroute Charges Through JetPlanIII” on
page 684.
01 OPTIONS JPIII
The system displays the JPIII menu.
2. At the JPIII prompt, enter 6.
>6
The system displays the JEPPESEN Exchange Rates menu.
JEPPESEN Exchange Rates
Enter“C” for Customer Exchange Rates

Enter“L” to List all Exchange Rates
“V” to View an Exchange Rate
“Q” to QUIT

688
3. Enter L.
The system displays a list of all the current exchange rates in the Jeppesen
Currency Exchange Rates database.
Sample Report (Abbreviated)

COMPUTING 10840
Exchange Rates (per US Dollar)

CODE RATE LAST UPDATE TIME DATE COUNTRY
-------------------------------------------- -------------------------
AED 3.673100 16:15:00 06MAY13 United Arab Emirates
ANG 1.790005 16:15:01 06MAY13 Netherlands Antilles
AON 96.049300 16:15:01 06MAY13 Angola
ARS 5.203978 16:15:01 06MAY13 Argentina
AUD 0.977140 16:15:01 06MAY13 Australia
BDT 78.056813 16:15:01 06MAY13 Bangladesh
BGL 1.494649 16:15:01 06MAY13 Bulgaria
BHD 0.377099 16:15:01 06MAY13 Bahrain
BOL 6.910039 16:15:01 06MAY13 Bolivia
BRN 2.014623 16:15:01 06MAY13 Brazil
BWP 8.116883 16:15:01 06MAY13 Botswana
CAD 1.009100 16:15:01 06MAY13 Canada
CHF 0.939282 16:15:01 06MAY13 Switzerland
CLP 469.928195 16:15:01 06MAY13 Chile
CNY 6.169204 16:15:01 06MAY13 China
COP 1835.095762 16:15:01 06MAY13 Colombia
CSK 19.678543 16:15:01 06MAY13 Czech Republic
CUC 1.000000 16:15:01 06MAY13 Cuba
CUP 26.500000 16:15:01 06MAY13 Cuba
DJF 179.678271 16:15:01 06MAY13 Djibouti
DKK 5.707289 16:15:01 06MAY13 Denmark
DOP 40.984809 16:15:01 06MAY13 Dominican Republic
DZD 78.719707 16:15:01 06MAY13 Algeria
ECS 1.000000 16:15:01 06MAY13 Ecuador
ECU 0.765782 16:15:01 06MAY13 European Mon. Coop Fund
EEK 11.981921 16:15:01 06MAY13 Estonia
ETB 18.588839 16:15:01 06MAY13 Ethiopia
EUR 0.765782 16:15:01 06MAY13 European Mon. Coop Fund
FJD 1.765186 16:15:01 06MAY13 Fiji
GBP 0.643919 16:15:01 06MAY13 United Kingdom
GTQ 7.783498 16:15:01 06MAY13 Guatemala
HKD 7.758958 16:15:01 06MAY13 Hong Kong
HTG 42.502513 16:15:01 06MAY13 Haiti
HUF 227.569201 16:15:01 06MAY13 Hungary
IDR 9737.000000 16:15:01 06MAY13 Indonesia
ILS 3.570572 16:15:01 06MAY13 Israel
INR 54.140490 16:15:01 06MAY13 India
IQD 1158.990326 16:15:01 06MAY13 Iraq
IRR 12284.529880 16:15:01 06MAY13 Iran
...

689
To view a particular exchange rate in the Jeppesen Exchange Rates Database

• At the JEPPESEN Exchange Rates menu prompt, enter V, and then enter the
appropriate currency code when prompted.
V
Enter Currency Code, EX:“USD”:GBP
The system displays the currency’s current exchange rate per one U.S.
Dollar.
Exchange Rates (per US Dollar)

CODE RATE LAST UPDATE TIME DATE COUNTRY
--------------------------------------------------- --------------
GBP 0.643919 16:15:01 06MAY13 United Kingdom
Viewing and Modifying Customer Exchange Rate Information
NOTE The rates stored in the Customer Exchange Rates database are tied to your
customer ID and are only available for use with that ID. Rates stored in this database
override the corresponding rates stored in the exchange rates database maintained
by Jeppesen. If no value for a particular currency exists in your customer database,
the system uses the Jeppesen database value.
In addition to the exchange rate data maintained by Jeppesen, JetPlanIII allows you to store
and manage your own currency rate data, based on a source you choose. For example, you
could store the published exchange rates provided by EUROCONTROL to better mirror that
source of information.
You can access the Customer Exchange Rates database through the JEPPESEN Exchange
Rates database menu. The menu options allow you to add, change, and delete your exchange
rate information. You can also display a list of the rates stored under your ID in the database.
To access the Customer Exchange Rates database options

1. Open the JEPPESEN Exchange Rates database menu in the JetPlanIII
program. See “Viewing Exchange Rates” on page 688.

690
2. At the JEPPESEN Exchange Rates menu prompt, enter C to display the

JEPPESEN Customer Exchange Rates menu.
JEPPESEN Exchange Rates
Enter“C” for Customer Exchange Rates

Enter“L” to List all Exchange Rates
“V” to View an Exchange Rate
“Q” to QUIT
C
JEPPESEN Customer Exchange Rates
Enter“A” to Add Exchange Rates

“C” to Change Exchange Rates
“D” to Delete Exchange Rates
“L” to List All Exchange Rates
“Q” to QUIT
3. Enter any of the following options:

• A – to add an exchange rate
• C – to change an exchange rate
• D – to delete an exchange rate
• L – to list all of the exchange rates in the Customer Exchange Rates
database
• Q – to exit

691
Generating a FIR/UIR Traversal Report

NOTE The FIR Traversal menu option is disabled unless activation is requested.
You must contact Jeppesen Customer Service to request activation of this feature.
If you do not need JetPlan’s Enroute Charges feature (for example, because you already have a
program that calculates and tracks your navigational fees), you can still benefit from JetPlan’s
FIR Traversal program. This feature generates a report that contains information about the
airspace traversed between two airports. The report shows the identifiers of the FIRs crossed
and the cumulative mileage to each boundary identifier enroute. The report basically reflects
the type of information provided with the Enroute Charges program. However, the money
figures are omitted.
To generate a FIR Traversal Report

1. On the Options command line, type JPIII to start the JetPlanIII program.
01 OPTIONS JPIII
The system displays the JPIII menu. For details, see “Accessing Enroute
Charges Through JetPlanIII” on page 684.
2. At the prompt, enter 7.
>7
The program prompts you to provide information similar to that required for
an Enroute Charges report. See Table 25-1, “Enroute Charges Prompts and
Inputs,” on page 685.
NOTE The inputs entered at the Route prompt and the subsequent route output
might not be applicable at this time. Navigational structure changes over time. Use
this example as a guideline only.

692
Example:
FIR/UIR Traversal Menu
Options:RN
POD:EGLL
POA:LIRA
Route:J
Flight Level:410
The system generates a report based on your inputs.
Sample Report
FIR/UIR Traversal Report . . .
from EGLL to LIRAa
Routeb
EGLL MID4F MID UN615 XAMAB UL612 OGULO UQ223 LURAG UM135 TOP UL50 ELB UL146 ELKAP
ELKA2F LIRA
No. POD/POAc FIR/UIRd Mileage Markere Lat/Lonf

1 EGLL EGTT 0 N5128.7 W00027.7
2 LFFF 94 N5012.3 E00015.9
3 LSAS 427 N4613.7 E00559.9
4 LFFF 434 N4609.0 E00607.3
5 LIMM 476 N4541.0 E00651.0
6 LFFF 476 N4541.0 E00651.0
7 LIMM 484 N4535.2 E00700.0
8 LIRR 671 N4314.0 E00950.2
9 LIRA 829 N4148.0 E01235.8
FIR/UIRg Airway Great Circle

Distanceh Distancei
EGTT 94 81
LFFF 333 331
LSAS 7 7
LFFF 42 41
LIMM 0 0
LFFF 8 9
LIMM 187 187
LIRR 158 150
a. POD and POA ICAO identifiers.

b. Summary of the route as calculated using the FIR Traversal program. (This output might not be appli-
cable at this time. Use this example only as a guideline.)
c. Departure and destination airports.
d. Identifiers of FIRs/UIRs traversed.
e. Cumulative airway distance from departure airport to FIR/UIR boundary.

693
f. Coordinate position of FIR/UIR boundary crossing.

g. Identifiers of FIRs/UIRs traversed.
h. Planned route segment distance between FIR/UIR boundaries.
i. Great circle distance between FIR/UIR boundaries.

694
C HAPTER 26
Archiving
Archiving
Overview
Overview
This chapter covers JetPlan’s archiving functionality, which allows you to store and create
reports for the following data:
• Enroute charges
• Cosmic radiation
NOTE It is also possible to get access to reports of archived flight plan data
elements. Contact your Jeppesen account manager for more information.

697
Archiving
Enroute Charges Archive and Report

The Archive and Report feature is an extension of, and a supplement to JetPlan’s Enroute
Charges feature (see “Enroute Charges and FIR Traversal” on page 681). It provides long term
storage of a flight’s navigational fee information for up to one year. It can be set to
automatically archive every flight plan filed through JetPlan (through an ID attribute setting),
or you can apply it on a per plan basis.
Each plan stored in the archive is a record of the specific costs of flying through the airspace of
other countries or regions (FIR/UIR’s). The type of data stored includes the FIR/UIR
boundary information, the route segment distance within each region, the fee for passage
through each region, the code for the currency used in the region (country), the exchange rate
of the currency to U.S. dollars, the valid date of the exchange rate, and other helpful details of
the flight. These records can be used to create extensive informational reports by transferring
the data stored in the archive to a common spreadsheet program.
A sample archive record is shown below. The table that follows defines each column of
information within an archived record.

698
Archiving
Table 26-1 Enroute Charges Archive Record Detail
Column Definition Example Data Data Format

Date of Departure 29.08.2002 DD.MM.YYYY
ETD 0100 HHMM
Call Sign/Flt No. (Optional) SS1234 Text: 8-character maximum
Aircraft Tail No. (from CADB) N101SS Text: 12-character maximum
Slot No. (Optional) 0001 Four-digit number
POD OMDB ICAO identifier
POA EDDM ICAO identifier
FIR (or country) ED Two-letter country code or ICAO

identifier
AW Distance 65 Airway distance rounded to

nearest whole number, in
kilometers
GC Distance 62 Great Circle distance rounded to

the nearest whole number, in
kilometers
Unit Rate 77 Unit rate of route charges

published by EUROCONTROL
for country
Enroute Charge (Nav. Fee) 141 Segment cost rounded to nearest

dollar (U.S.)
Currency Code EUR Currency Code: 3 character ISO

code
Exchange Rate 1.16 Value relative to U.S. Dollar
Exchange Rate Valid Date 08.08.2002 DD.MM.YYYY
Route RT01 Customer Route database name
NOTE If the optional entries, Call Sign and Slot Number, are not included in the user
inputs, they appear as empty fields within the record. The same is true of the Tail
Number if it is not included in the aircraft file of the Customer Aircraft database
(CADB).

699
Archiving
Archive Commands (EC)

To apply the Archive and Report feature, use the EC command on the Options command line.
The following functions can be applied with the EC command.
To save a record
You can save the navigation fee information of a particular flight by either adding the EC
option to your flight plan request or by entering the EC command and a transaction number of
a flight plan that has already been computed.
To ensure that the information is added to the archive upon computation of the flight, enter the
option, EC, anywhere after the FP command on the Options command line.
Example:
01 OPTIONS FP,EC
To add information to the archive from a plan that has already been computed, enter the
command, EC, followed by the plan number on the Options command line.
Example:
01 OPTIONS EC,1234
NOTE You can save flight records automatically when each plan is filed by
requesting that this capability be set in your ID/Attribute File (see “Enroute Charges -
Archive and Report” below for more information).
You can apply an optional identification number, called a “slot” number, to the record you are
saving by adding the option, SLT=####, to your input. This number can be helpful in
itemizing your information. It is a four-digit value and preferably sequential in order as
records are added.
Example:
01 OPTIONS EC,1234,SLT=0001
To cancel a record
The term “cancel,” as it applies to the Archive and Report feature, simply means that the
record is flagged in the archive. This flagging prevents the record from being displayed in
subsequent reports. To cancel a record, append the option, CX, to your EC command input.

700
Archiving
Example:
01 OPTIONS EC,1234,CX
To change the ETD

You can change the departure time of a plan that has been previously stored by entering the
option DLA, followed by a new departure time input, using the HHMM format. This input is
similar to the Delay option used with the flight plan filing command, FI.
Example:
01 OPTIONS EC,1234,DLA1630
To print a record (or records)

You can display the entire contents of your archive or a defined portion by using the option
PRI after the EC command.
To print the entire contents of the archive, enter PRI after the EC command.
NOTE Canceled records are omitted from any print display.
Example:
01 OPTIONS EC,PRI
To print a portion of the archive, enter a begin point and an end point after the PRI option. The
begin point is a date input prefixed by the option BEG=. The end point is a later date input
prefixed by the option END=. Both date inputs are entered using the following format:
DDMMYYYY
Example:
01 OPTIONS EC,PRI,BEG=01052002,END=31122002

701
Archiving
Automatic Archive
Flight plans can be stored in the archive database automatically. To apply this capability, you
must request that both the Enroute Charges attribute and the Archive and Report attribute be
activated in your ID/Attribute File. Contact Jeppesen Customer Service to request this
activation.
Once these attributes are set, any time a flight plan is filed with ATC through the JetPlan
system, the navigational fee records are stored in the archive.
For example, assume a flight plan from KJFK to EDDF is computed on the JetPlan system.
Example:
01 OPTIONS FP,CS/ALPHA01
02 POD KJFK
03 POA EDDF
06 J//J
-
-
20 COMPUTING 1234
This plan is then filed with ATC through JetPlan.
Example:
01 OPTIONS FI1234,SLT=0002
With the Archive and Report attribute activated, the mere filing of your plan archives the
navigational fee information automatically.
NOTE The Slot Number option can be included with the Filing command to further
identify the data in your archive.

702
Archiving
Cosmic Radiation Archive and Report
Archive and Report Limitations

The following limitations exist with the Archive and Report feature.
• When determining the navigational fee, the program does not separate
charges within the same two-letter country code. For example, if crossing
LTAA and LTBB in Turkey, the program combines the fees into one charge
under the LT label.
• There is no capability to archive information other than flight plans (for
example, JetPlanIII Enroute Charges reports cannot be archived).

The Cosmic Radiation Archive and Report feature is functionally similar to Enroute Charges
Archive and Report capabilities. However, instead of storing navigational fee information, this
feature is designed to document flight crew exposure to the potentially harmful effects of
ionizing radiation. Keeping track of such exposure is beneficial because the risk of harmful
effects increases cumulatively (with every flight).
Like Enroute Charges Archive and Report, this archive provides long-term storage of
information. It can be set to automatically archive every flight plan filed through JetPlan (by
setting specific ID attributes), or you can apply it on a per plan basis.
Each plan stored in the archive is a record of the exposure information the flight has
encountered. The data includes the flight’s departure and destination, call sign, date, route, and
time at altitude. These records can be used to create extensive informational reports by
transferring the data stored in the archive to a common spreadsheet program.
A sample archive record is shown below. The table that follows defines the information within
an archived record.

703
Archiving
Table 26-2 Cosmic Radiation Archive Record Detail
Item Item Definition Item Format

2060 Plan Number Four digit JetPlan transaction
number
EDDM POA ICAO identifier
OMDB POD ICAO identifier
SS1234 Call Sign/Flt No. (Optional) Text: 8 character maximum
29/08/02 Date of Flight DD/MM/YY
OMDB RANB1E RANBI M302 Route Summary Standard ATC summary of

BALUS... EDDM airports, waypoints and airways
flown
00.17,TOC,02.20,390,02.52,280... Time/Altitude Summary Time shown in HH.MM format,

TOD followed by the flight level at
which time applies
05.47,TOTAL Time Total Format same as above.
NOTE If the optional entry, Call Sign, is not included in the user inputs, it appears as
an empty field within the record.
Archive Commands (CR)

To apply the Archive and Report feature, use the command CR on the Options command line.
The following functions can be applied with the CR command.
To save a record
You can save the radiation exposure information of a particular flight by either adding the CR
option to your flight plan request or by entering the CR command and a transaction number of
a flight plan that has already been computed.
To ensure that the information is added to the archive upon computation of the flight, enter the
option CR anywhere after the FP command on the Options command line.

704
Archiving
Example:
01 OPTIONS FP,CR
To add information to the archive from a plan that has already been computed, enter the
command CR, followed by the plan number on the Options command line.
Example:
01 OPTIONS CR,1234
NOTE You can save flight records automatically when each plan is filed by
requesting that this capability be set in your ID/Attribute File (see “Cosmic Radiation -
Archive and Report” in this chapter for more information).
To cancel a record
The term “cancel,” as it applies to this Archive and Report feature, simply means that the
record is flagged in the archive. This flagging prevents the record from being displayed in
subsequent reports (print displays).
To cancel a record, append the option CX to your CR command input.
Example:
01 OPTIONS CR,1234,CX
To change the ETD

You can change the departure time of a plan that has been previously stored by entering the
option DLA, followed by a new departure time input, using the HHMM format. This input is
similar to the Delay option used with the flight plan filing command FI.
Example:
01 OPTIONS CR,1234,DLA1630
To print a record (or records)

You can display the entire contents of your archive or various portions of it by using the option
PRI after the CR command.

705
Archiving
To print the entire contents of the archive, enter PRI after the CR command.
NOTE Canceled records are omitted from any print display.
Example:
01 OPTIONS CR,PRI
To print a portion of the archive by time frame, enter a begin date and an end date after the PRI
option. The begin date is prefixed by the option BEG=. The end date is prefixed by the option
END=. Both of the date inputs are entered using the format DDMMYYYY.
Example:
01 OPTIONS CR,PRI,BEG=01052002,END=31122002
To print a portion of the archive by a single date, enter the date after the PRI option. The date
input is prefixed by the option DAY=, and is entered using the format DDMMYYYY.
Example:
01 OPTIONS CR,PRI,DAY=01052002
To print records by aircraft call sign, enter the call sign after the PRI option. The call sign
input is prefixed by the option CS=.
Example:
01 OPTIONS CR,PRI,CS=SS1234
To print records by member of the crew, enter the crew member after the PRI option. A prefix
exists for each type of crew member. The flight’s captain is prefixed by the option CPT=.
Example:
01 OPTIONS CR,PRI,CPT=JSMITH
The flight’s first officer is prefixed by the option FOF=.
Example:
01 OPTIONS CR,PRI,FOF=RJONES
The flight’s flight engineer is prefixed by the option FEN=.

706
Archiving
Example:
01 OPTIONS CR,PRI,FEN=BJOHNSON
NOTE Crew member information can be tracked only if included in the flight plan
computation. See the “Option Commands” chapter for more information on including
crew member names in flight plan requests.
You can also print records in different output formats using the SR1, SR2, and SR3 format
codes. These formats give you a slightly different display of the information compared to the
standard output.
To print records in a different output format, prefix the format code input with the option
FMT=.
Example:
01 OPTIONS CR,PRI,FMT=SR1
You can combine the various print options shown to further filter the output to very specific
records. For example, if you wanted a print display of all records for a particular day and with
a particular call sign, you would enter something like this:
Example:
01 OPTIONS CR,PRI,DAY=29082002,CS=SS1234

707
Archiving
Automatic Archive
Flight plans can be stored in the archive database automatically. To apply this capability, you
must request that both the Long-term Performance Archive attribute and the Automatic Long-
term Performance Archive attribute be activated in your ID/Attribute File. Contact Jeppesen
Customer Service to request this activation.
Once these attributes are set, any time a flight plan is filed with ATC through the JetPlan
system, the crew exposure records are stored in the archive.
For example, assume a flight plan from KJFK to EDDF is computed on the JetPlan system.
Example:
01 OPTIONS FP,CS/ALPHA01
02 POD KJFK
03 POA EDDF
06 J//J
-
-
20 COMPUTING 1234
This plan is then filed with ATC through JetPlan.
Example:
01 OPTIONS FI1234
With the proper attributes activated, the mere filing of your plan archives the crew exposure
information automatically.

708
C HAPTER 27
Customer Aircraft
Database
About the Customer Aircraft Database

IMPORTANT This document contains information on International Civil Aviation
Organization (ICAO) 2012 database parameters. The Jeppesen cutover to the ICAO
2012 Filed Flight Plan (FPL) format occurred on November 14, 2012. All flight plans
filed with Jeppesen flight planning products are now filed in the ICAO 2012 format by
default. Flight plans not filed in the ICAO 2012 format might be rejected by (Air Traffic
Control) ATC.

DOC 4444)” which describes the ICAO 2012 FPL requirements in detail.
For information on the ICAO 2012 parameters in the CADB, see “CADB Parameters: “ICAO
2012 Certification and Equipment” Section” on page 783. For a summary of ICAO 2012
changes and filing requirements, see the “ATC Filing” chapter in the JetPlan User Manual.
The CADB provides a medium for the creation, storage and maintenance of aircraft
information in convenient records. CADB records can be used in the JetPlan system on a
regular basis, replacing generic aircraft inputs, minimizing other input requirements, and
increasing your flight planning capabilities in general. You identify each CADB record with a
name of your choosing. (Aircraft tail numbers are commonly used for CADB record names.)
The information stored in a record includes static and dynamic performance factors, specific
output factors, and other factors that support various feature applications.
The CADB interacts with several related but separate databases that support specific JetPlan
features. For instance, the Route Constraint Database is a separate database that interacts with
information in the CADB. The Route Constraint Database enables you to impose constraints
on route selection based on the equipment and certifications defined for the aircraft in the
CADB. For more information, see the “Route Constraint Database” chapter in the JetPlan
User Manual.

711
In addition, the CADB contains several sections or “sub-databases” that support specific
JetPlan features. The following sections provide information about the CADB subsections and
parameters:
• “CADB Parameters by Section” on page 720

• “CADB Record Sections” on page 714
NOTE The number of options available in the CADB depends both on the access
privileges assigned to the password you use to access the system and on your
customer preference settings.
CADB Records
CADB records originate from generic aircraft data records residing in the JetPlan Aircraft
Library in the JetPlan system. Every generic record in the library is derived from the structural
and performance data developed by the aircraft manufacturer. The data within a generic record
is specific to the model configuration and engine type for the aircraft. Certain models might
have more than one generic record, depending on modifications, refittings, and customer
input. For more information on the JetPlan Aircraft Library, see the “Aircraft Type
Commands” chapter in the JetPlan User Manual.
When you create a CADB record, you save the characteristic data for a specific instance of a
generic aircraft found in the JetPlan Aircraft Library. You define required and optional
parameters relevant to your operation and provide a name for the database record.
You do not need to set values for all the parameters in an aircraft database record before you
can use it. Some parameters, however, are preset with values carried over from the aircraft’s
generic data (for example, certain weight limitations). In general, values must be defined for
the preset parameters, as they are vital to the performance characteristics of the aircraft and the
JetPlan computation process. Within certain limits, you can elect to change the values of
preset parameters, but you cannot delete these values completely.
With the exception of Operational Weight, parameters that show no preset values upon record
creation can be set as needed or left untouched. Operational Weight must be given a value
before you can use the record in a flight plan. The use of other unset parameters is strictly
optional and dependent on the information you want to see in the flight plan or on the type of
operation you employ.

712
For detailed definitions of the CADB parameters, see “CADB Parameters by Section” on
page 720. JetPlan.com is the preferred interface for creating CADB records. For instructions,
see the JetPlan.com Help documentation. For information on using JetPlan to create CADB
records, see “Database Management” on page 800.
NOTE Generic aircraft records must be loaded into your account by Jeppesen
before you can access them. For more information, contact your Jeppesen account
manager.
Flight Plan Application

The JetPlan system requires the input of an aircraft as part of the information needed to create
a flight plan. You can enter a generic aircraft record name or a CADB record name to meet this
requirement. By entering a CADB record name, you not only provide an aircraft input, but you
also provide other inputs necessary to complete the flight plan request without manually
entering each item. The referenced CADB record supplies the JetPlan system with the
information you have stored in the record. The following list identifies the basic flight plan
requirements that can be met by parameter settings in your CADB record:
• Performance Index
• Aircraft Operational Weight
• Reserve or Max Fuel
• Climb and Descent Biases
To use a CADB record in a flight plan request, enter a dollar symbol ($) followed by the
record name on the Aircraft Type command line.
Example:
To include the Air Traffic Services (ATS) filing strip in your flight plan output, enter a slash
immediately after the record name input.

713
Example:
10 A/C TYPE/REGN $N1234/
NOTE You can request that all of your flight plans include the ATS filing strip by
asking your account manager to set the proper flag in your Password Attribute File.
You then no longer need to include the slash after the record name. Contact your
Jeppesen account manager for more information.
CADB Record Sections

A CADB record contains a large number of parameters. These parameters are grouped into
separate sections that divide the record into logical units of information. You can view all the
parameters within a given database record or just those within a specific section. When you
view the Aircraft Record summary page in JetPlan.com, you are looking at the current values
of the parameters within each section of the selected CADB record.
NOTE The following image does not show the entire Aircraft Record page.
The parameters on the Aircraft Record page correspond to editable options that appear in
JetPlan.com on the Change <Section> in Aircraft Record pages. These JetPlan.com options
allow you to modify the aircraft records.

714
The following table briefly defines the sections in each aircraft record. For definitions of each
parameter in each section, see “CADB Parameters by Section” on page 720.
Table 27-1 CADB Record Sections
Section Description
Weights The “Weights” section provides parameters that help you define the aircraft’s
weight limitations. Many of these parameters have values carried over from the
generic version of the aircraft, found in the JetPlan Aircraft Library. All of the
parameters can be set with new values, but settings must fall within the
tolerance range defined by the aircraft’s basic structural properties.
For definitions of all parameters in this section, see “CADB Parameters
“Weights” Section” on page 720.
Fuels The “Fuels” section contains parameters for various fuel specifications allowed
in JetPlan.
For definitions of all parameters in this section, see “CADB Parameters:
“Fuels” Section” on page 722.
Misc The “Miscellaneous” section contains parameters that apply to various

unrelated features on the JetPlan system, including cost index methods. Four of
the parameters (Print ETOPS, Print Brackets, Print ALT Capability, and Print
Driftdown) simply allow you to display sub-database sections that typically do
not display within the aircraft record.
“Miscellaneous” Section” on page 727.
Modes The “Modes” section contains speed setting parameters. They allow you to set
default values for the various profiles of a flight.
“Modes” Section” on page 736.
Cutoff Wt Tables The “Cutoff Weight Tables” section contains a list of up to nine aircraft weight
limit/flight condition settings. This section is not displayed in JetPlan.com
unless you set the Print ALT Capability Table parameter in the “Miscellaneous”
section to Yes.
“Cutoff Weight Tables” Section” on page 738.
Bracket Modes The “Bracket Modes” section contains up to six climb/descent models available
for application based on a flight’s cruise mode. The “Bracket Modes” section is
not displayed in JetPlan.com unless you set the Print Brackets parameter in the
“Miscellaneous” section to Yes.
“Bracket Modes” Section” on page 739.
IMPORTANT JetPlan.com does not currently support modifying this section.
Contact your Jeppesen account manager for information.

715
Table 27-1 CADB Record Sections (continued)
Section Description
Mode Coupling The “Mode Coupling” section enables you to link, or “couple,” specific
airspeeds for climb, descent, alternate, takeoff alternate, and holding to a
particular cruise mode. You can apply couplings to as many as 20 cruise modes
per aircraft. The “Mode Coupling” section is not displayed in JetPlan.com
unless you set the Print Brackets parameter in the “Miscellaneous” section to
Yes. The generic file for the aircraft also must contain the necessary data.
For definitions of all parameters in this section, see “CADB Parameters: “Mode
Coupling” Section” on page 740.
Tanker The “Tanker” section contains parameters related to the Single-Leg Tankering
feature. “CADB Parameters: “Tanker” Section” on page 743.
Equipment The “Equipment” section contains parameters to designate the types and
quantities of various hardware onboard. Some equipment parameters are used
by the RAIM Prediction Report request feature.
“Equipment” Section” on page 744.
NOTE This section is a factor in the application of the Route Constraint
database.
Certified The “Certified” section contains parameters that flag the aircraft positively or
negatively with regard to its use in various airspace regions and with certain
airway structures.
“Certified” Section” on page 749.
NOTE This section is a factor in the application of the Route Constraint
database.
ATS Plan The “ATS Plan” section contains parameters that provide information to Air
Traffic Control (ATC). Some of these parameters are entered automatically in
the flight plan filing form.
For definitions of all parameters in this section, see “CADB Parameters: “ATS
Plan” Section” on page 752.
ETP The “ETP” section is a sub-database that contains parameters for the
application of equal-time-point diversions. This information is applicable to
basic ETP (equal-time-point), ETOPS (Extended-Range Twin Engine
Operational Performance Standard), and Overwater Driftdown calculations.
For definitions of all parameters in this section, see “CADB Parameters: “ETP”
Section” on page 756.

716
Table 27-1 CADB Record Sections (continued)
Section Description
ETOPS The “ETOPS” section supports the JetPlan feature option, ETOPS. Parameters
set in this section apply to the ETOPS calculation. The “ETOPS” section is not
displayed in JetPlan.com unless you set the EP parameter in the
“ETOPS” Section” on page 763.
NOTE For more information about ETOPS flight plans, see the ETOPS User’s
Guide: 2 Engine Aircraft on the User Manuals page on JetPlan.com.
Driftdown The “Driftdown” section supports the JetPlan feature, Terrain Analysis.
Parameters set in this section apply to the Terrain Clearance/Mountain
Driftdown calculation. The “Driftdown” section is not displayed in JetPlan.com
unless you set the DD parameter in the “Miscellaneous” section to Yes.
“Driftdown” Section” on page 777.
NOTE The use of the “Driftdown” section is limited to certain customers.
Biases The “Biases” section contains parameters that allow you to set various flight
biases. POD and POA biases can be deferred (Yes/No); if set to Yes, you must
specify an entry on the Descent Bias and Arrival Bias command lines, plus
optional input, for each flight plan request.
“Biases” Section” on page 780.
ICAO 2012 Certification The “ICAO 2012 Certification and Equipment” section contains parameters
and Equipment that support the changes to be implemented for ICAO 2012 Flight Plan Filings.
These changes and the new CADB parameters are covered in “CADB
Parameters: “ICAO 2012 Certification and Equipment” Section” on page 783.

717
Searching Generic Aircraft Records for FPM and OUTFLT Information
Searching Generic Aircraft Records for

FPM and OUTFLT Information
You can search generic aircraft records to find FPM cruise and climb/descent and OUTFLT
cruise cost index information.
To find FPM and OUTFLT data information in JetPlan.com

1. In JetPlan.com, click the Aircraft database tab to open the Summary of
Aircraft page.
2. On the Aircraft Database menu, click Search All Aircraft Types.
3. Enter search criteria in any combination of the following boxes:
• Generic Aircraft ID
• ICAO (aircraft) Name
• AC Model
• Engine (name)
TIP Entering just one character returns a list of all records that begin with that
character. Entering more characters narrows the search results. The following
example shows results of a search for a Generic Aircraft ID that begins with “777.”
4. Click Search.
A page opens, listing FPM and OUTFLT information available in the
generic aircraft record.

718
Searching Generic Aircraft Records for FPM and OUTFLT Information
This page lists search results in the following columns:
OUTFLT Info The latest available version of the corresponding OUTFLT

column performance database and its revision date.
Version information in this column indicates that:
• The corresponding OUTFLT file is available, and it can be

matched to the Generic Aircraft ID using AC Model and Engine
names.
• The cruise FMS Matching (OUTFLT) Cost Index Method
option in the “Miscellaneous” section of the CADB can be
selected for the cruise performance calculation.
N (No) in this column indicates either that this file is not available or
that it cannot be matched to the Generic Aircraft ID.
NOTE OUTFLT is currently implemented only as a Cruise CI (cost index) method.
FPM Cruise Data If an FPM file exists for the aircraft/engine combination, the filename
Availability is listed here. If no FPM file exists, a blank space appears in the FPM
Cruise Data Availability column. To use any of the FPM cruise and
climb/descent cost index methods in the “Miscellaneous” section of
the CADB, an FPM file must exist.
FPM Y (Yes) indicates that climb/descent data is available in the FPM file
CLIMB/DESCENT in addition to cruise data. N (No) indicates that only cruise data exists
Data Availability in the FPM file. When there is a Y in this column, the G (FPM using
CAS-MACH) climb/descent FPM option in the “Miscellaneous”
section of the CADB can be selected.
FPM CI FMC Data Y (Yes) indicates that FPM FMC (Flight Management Computer)
Availability data is available in the FPM file. N (No) indicates that this data does
not exist in the FPM file. When there is a Y in this column and also a
Y in the FPM CLIMB/DESCENT Data Availability column, the F
(FPM using CI) climb/descent option in the “Miscellaneous” section
of the CADB can be selected.

719
CADB Parameters by Section

The following tables define all of the parameters available in the CADB. Each table below
corresponds to a section in a database record. Each parameter in a table appears as an option
on the corresponding CADB page in JetPlan.com. As you use JetPlan.com to review, create,
and modify aircraft records, consult these tables for detailed information on the parameters,
including the role they play in flight planning and their valid input values.
NOTE Depending on your customer preference settings, some options in the

following tables might not be available in JetPlan.com. For more information, contact
NOTE JetPlan.com is the recommended interface for customer database

maintenance. See the JetPlan.com Help file for directions. For the convenience of
JetPlan command-line users, the tables below list JetPlan database codes under the
parameter names. When setting parameter values in the CADB using JetPlan
command-line mode, you can enter the parameter code and value as one unit (for
example, OP150000) or include an equal sign (=) between the two (for example,
OP=150000). Exceptions to this style variation are three-character and four-character
codes. When entering these parameters (for example, CI1, EDN2, and so on.) you
must include the equal sign between the code and the value.
CADB Parameters “Weights” Section

The “Weights” section provides parameters that help you define the aircraft’s weight
limitations.
Table 27-2 CADB Record: “Weights” Section
NOTE Unless stated otherwise, all parameter values in this table are entered as pounds or kilograms.
Max Takeoff Weight Enables you to adjust the takeoff weight. You can change the setting, but only
(TO) within certain limits for the aircraft.
TO or TO= NOTE This parameter is preset with a value from the generic version of the
aircraft.
ex. TO=865000
Max Landing Weight Enables you to adjust the landing weight. You can change the setting, but only
(LA) within certain limits for the aircraft.
LA or LA= NOTE This parameter is preset with a value from the generic version of the
aircraft.
ex. LA=628950

720
Table 27-2 CADB Record: “Weights” Section (continued)
Max Zero Fuel Weight Enables you to adjust the zero fuel weight. You can change the setting, but only
(ZF) within certain limits for the aircraft.
ZF or ZF= NOTE This parameter is preset with a value from the generic version of the
aircraft.
ex. ZF=560000
NOTE If the Zero Fuel Table (ZT) parameter is set to Yes, the ZF parameter
must be set to 0.
Operational Weight Enables you to set the basic operational weight (BOW) or operational empty
(OP) weight (OEW). You can change the setting, but only within certain limits for the
aircraft.
OP or OP=
NOTE This parameter must be set before using the aircraft record in a flight
ex. OP=415000
plan request.
Max Payload Enables you to set the maximum payload. Typically, MP=ZF-OP, but you can
(MP) change the setting to limit payload to a value less than typical.
MP or MP= NOTE This parameter is preset with a value from the generic version of the
aircraft.
ex. MP=150000
Max Ramp Weight Enables you to set the ramp weight to a value greater than the maximum takeoff
(RW) weight. The weight beyond maximum takeoff would typically represent
departure taxi fuel.
RW or RW=
ex. RW=872500
Nav Charges Weight Enables you to set the weight at which navigational fees are levied. Typically,
(NW) the maximum takeoff weight is the value used, but this parameter enables you
to adjust the value.
NW or NW=
ex. NW=870000
Min. Flight Weight This parameter is used to ensure that a minimum in-flight weight is maintained.
(MW) When set to a non-zero, positive value, JetPlan compares the MW value with
the calculated enroute weight (the sum of the aircraft’s operational weight,
MW or MW=
payload, and unusable fuel at various mid-segment points). If the calculated
ex. MW=500000 value is less than the MW value, JetPlan adds enough unusable fuel to meet the
MW value and recalculate the plan. Thus, weight is increased and fuel capacity
is decreased.
NOTE This parameter is format or ID/Password-dependent.

721
CADB Parameters: “Fuels” Section

The “Fuels” section contains parameters for various fuel specifications allowed in JetPlan.
Table 27-3 CADB Record: “Fuels” Section
NOTE Unless stated otherwise, all parameter values in this table are to be entered as pounds or kilograms.
Zero Fuel Table Enables you to access the aircraft’s MZFW table (if it exists in the aircraft’s
(ZT) generic data record), which sets the zero fuel weight for the aircraft to an
amount related to the planned takeoff weight. If takeoff weight is reduced so
Variable Max ZFW
that it meets specific thresholds, zero fuel weight is increased.
ZT or ZT=
The input value is Yes or No. No is the default setting.
ex. ZT=Y
NOTE The MZFW table does not exist in every aircraft and must be requested
for load in your aircraft.
NOTE If the ZT parameter is set to Yes, the Max Zero Fuel Weight (ZF)
parameter must be set to 0.
Hold Calculation ZF When set to Yes, this parameter instructs JetPlan to determine hold fuel based
(HC) on the zero fuel weight table instead of the calculated landing weight. The
MZFW table must exist in the aircraft’s generic data record before this
HC or HC=
parameter is applicable to your operation.
ex. HC=Y
The input value is Yes or No. No is the default setting.
Max Fuel Capacity Enables you to set the fuel capacity of the aircraft to some value less than
(FC) default (using standard density, 6.7 lbs/gal).
FC or FC= NOTE This parameter is preset with a value from the generic version of the
aircraft.
ex. FC=390000
Holding Fuel Flow Enables you to set the fuel flow rate for the holding fuel calculation. This
(HF) parameter works in coordination with the hold time you specify in the flight
plan request.
HF or HF=
The value you enter represents all engines combined per hour. Example: 15000
ex. HF=15000
Min. Fuel Enables you to set a minimum amount of fuel the aircraft must have at Top of
(MF) Descent (TOD). If the calculated fuel total for holding, alternate divert, and
reserve/contingency is less than the MF value, JetPlan adds extra fuel.
MF or MF=
ex. MF=24000
Min. Hold Fuel Enables you to set a minimum amount of fuel for the purpose of holding. This
(MH) parameter only applies when you specify a hold time of one minute or more in
the flight plan request (a hold time input of zero does not invoke the MH
MH or MH=
parameter). If the calculated hold fuel is less than the MH value, JetPlan adds
ex. MH=5000 fuel to meet this minimum. Example: 5000

722
Table 27-3 CADB Record: “Fuels” Section (continued)
Min. Departure Fuel Enables you to set a minimum amount of fuel for departure. Ensures that the
(MD) fuel listed in the total fuel block of the flight plan has at least the amount
specified. Example: 50000
MD or MD=
ex. MD=50000
Min. Alternate Fuel Enables you to set a minimum amount of fuel for alternate divert. This
(MA) parameter only applies when you specify an alternate airport in the flight plan
request. If the calculated alternate fuel is less than the MA value, JetPlan adds
MA or MA=
more fuel to meet this minimum. Example: 5500
ex. MA=5500
Step Climb Fuel Adds a fuel penalty of the amount specified for every step climb initiated in the
(SF) flight plan calculation. Example: 400
SF or SF=
ex. SF=400
Reserve Fuel Enables you to set a minimum amount of fuel for reserve. This parameter only
(RF) applies when the flight plan is calculated in the departure fuel or weight case
(when you specify departure fuel or weight). Example: 5000
RF or RF=
ex. RF=5000
Approach Fuel Adds the amount specified to the Extra Fuel block. The AF value is in addition
(AF) to the calculated approach fuel included in the Descent or Alternate Fuel block.
Example: 2000
AF or AF=
ex. AF=2000
Min. Contingency/RES Fuel Ensures a minimum amount of fuel in the Contingency or Reserve Fuel block.
(MC) If calculated amount is less than the MC value, JetPlan adds fuel to meet this
minimum. Example: 4500
MC or MC=
ex. MC=4500
Fuel Over Destination Similar to the MF parameter (see above). Adds a warning message to flight plan
Warning output that the minimum specified has not been met in the calculation.
(FW) Example: 22000
FW or FW= NOTE This capability is dependent on specific output format designs. Contact
ex. FW=22000
Min. Contingency/RES Similar to the MC parameter (see above). Ensures a minimum amount of fuel in
Time the Contingency or Reserve Fuel block. If the calculated amount is less than the
(MT) MT value, JetPlan adds fuel to meet this minimum. The input value must be
specified as minutes. Example: 25
MT or MT=
ex. MT=25

723
Taxi Fuel Flow This parameter works in coordination with the Taxi-out and Taxi-in Time
(TX) parameters (TO and TI) in the Customer Airport Database. If the departure or
arrival airport is in the Airport Database and has a taxi time value specified, that
TX or TX=
time is applied to the TX value to determine taxi fuel. The TX value represents
ex. TX=2500 all engines combined per hour. Example: 2500
This parameter also works in coordination with the taxi-in and out data sets in
the City Pair Fleet Database and the Airport Fleet Database.
Max Contingency/RES Fuel Enables you to set a maximum amount of fuel that can go in the Contingency or
(MX) Reserve Fuel block. If calculated amount is more than the MX value, JetPlan
distributes excess to Extra Fuel block. Example: 8000
MX or MX=
ex. MX=8000
Min. Emergency Fuel This parameter is dependent on specific output format designs. JetPlan adds a
(FE) warning message to the flight plan output if calculated emergency fuel does not
meet the FE value. Example: 15000
FE or FE=
NOTE Contact your Jeppesen account manager for more information.
ex. FE=15000
Reserve + This parameter can be used to specify a minimum amount of Reserve and
Hold/Contingency Holding/Contingency fuel. If the sum of Reserve and Hold/Contingency fuel is
(RH) less than the desired minimum, JetPlan increases the Reserve fuel accordingly.
RH or RH= NOTE The RH parameter has no effect unless Special Reserve Policy 46 or 48
(RESDOM 46 or 48) is set. Contact your Jeppesen account manager for more
information.
Taxi-out Fuel Enables you to set a specific departure taxi fuel amount. Example: 2200
(DT)
DT or DT=
ex. DT=2200
Situation Code The situation code applies to aircraft that require the auxiliary power unit
(ST) (APU) to be running while in ETOPS airspace.
ST or ST= Input values:
ex. ST=E • E – APU fuel burn is calculated for the time while in ETOPS airspace.
• W – APU fuel burn is calculated for the whole flight.
• X – APU fuel burn is calculated from takeoff to the ETOPS exit point.
NOTE The X situation code is used only with ETOPS II flight plan options.
Contact Jeppesen Customer Support for more information.
• None – Set to None if you do not need to calculate ETOPS APU burn
while in ETOPS airspace.
NOTE The APU Burn Rate (BR) parameter value is applied only when the
Situation Code parameter is set to E, W, or X.

724
Taxi-in Fuel Enables you to set a specific arrival taxi fuel amount. Example: 1500
(AT) The following overrides apply to the use of the DT and AT parameters:
Taxi-in Fuel • Ad hoc taxi fuel inputs on the POD or POA command lines of a flight plan
AT or AT= request override all taxi fuel settings in various databases, including the
CADB DT and AT parameters.
ex. AT=1500
• Taxi fuel inputs on the POD or POA command lines of a Customer
Schedule Database record override all taxi fuel settings in other databases,
including the CADB DT and AT parameters.
• The DT and AT parameters do not override format-generated taxi fuel
values.
• The DT and AT parameters do not override software-generated taxi fuel
values (customer-specific).
International Reserve Policy This parameter enables a default International Reserve Fuel Policy value to be
(IR) set.
IR or IR= This field can contain the following values:
ex. IR=301 • -32768 – Unset value
• 0 – Unset value
• 101-199, 201-299, 301-399, 401-499, 601-699, 701-799, & 801-899 –
Valid International Reserve Policy entries as defined in the “Payload,
POD/POA, Weight and Fuel Commands” chapter in the JetPlan User
Manual.
Example: 301
APU Burn Rate The APU burn rate parameter applies to aircraft that require the APU to be
(BR) running while in ETOPS airspace. This parameter refers to the unloaded APU
burn rate. Unloaded in this context means that the APU is running idle. When
BR or BR=
the APU is running idle, the fuel burn is lower than when there is a load on the
ex. BR=110 APU. The APU fuel burn is not included in the Critical Fuel Scenario (CFS)
calculation.
Input value: Pounds or kilos per hour
Example value: 185
NOTE The BR parameter value is applied only if the Situation Code (ST)
parameter is set to E, W, or X.
NOTE Separate display of the APU fuel burn on the flight plan is format-
dependent. The APU fuel burn is part of the trip fuel if not otherwise defined in
the format.
Fuel Type Identifies the fuel type used by the aircraft. This parameter is used to calculate
(FU) CO2 emissions in support of EU ETS flight planning.
Ex.: FU= NOTE If the Fuel Type parameter is not set in the CADB when the Flight Brief
Database EU ETS flag or the EUETS line option is used, an error occurs.
AVGAS
Valid input values: JET A, JET A1, JET B, AVGAS
Default: Blank

725
Minimum Safe Divert Enables you to define a minimum amount of reserve fuel in pounds or kilos for
Alternate Fuel arrival at a Point of Safe Diversion/Return (PSD) divert airport.
(MDF) This parameter does not cause more fuel to be added to the aircraft. It only
ex. MDF=6000 determines how much fuel is still on board when arriving at your diversion
airports.
Input value: Weight in pounds or kilos, depending on the weight unit used for
the aircraft. Default is 0.
Example value: 6000
NOTE For more information, see the “Point of Safe Diversion and Point of Safe
Return” chapter in the JetPlan User Manual.
NOTE This parameter is not yet available in JetPlan.com. However, you can
configure this parameter using command-line inputs—for example: 01 OPTIONS
AC,CHG,<CADB Record Name>,MDF=6000. See the JetPlan User Manual for
complete instructions on using the command-line to maintain this database.
Minimum Safe Divert Enables you to define a minimum amount of reserve fuel in minutes for arrival
Alternate Time at a Point of Safe Diversion/Return (PSD) divert airport.
(MDT) This parameter does not cause more fuel to be added to the aircraft. It only
ex. MDT=10 determines how much fuel is still on board when arriving at your diversion
airports.
Input value: Time in minutes. Default is 0.
Example value: 10
NOTE For more information, see the “Point of Safe Diversion and Point of Safe
Return” chapter in the JetPlan User Manual.
NOTE This parameter is not yet available in JetPlan.com.However, you can
configure this parameter using command-line inputs—for example: 01 OPTIONS
AC,CHG,<CADB Record Name>,MDT=10. See the JetPlan User Manual for
complete instructions on using the command-line to maintain this database.

726
CADB Parameters: “Miscellaneous” Section

The “Miscellaneous” section contains parameters that apply to various unrelated features on
the JetPlan system, including cruise Cost Index Method parameters and Climb/Descent
Method parameters. To use the OUTFLT cruise cost index method and the FPM cruise and
climb/descent methods, you must ensure that the aircraft has OUTFLT and FPM files
available. You can use the Search All Aircraft Types menu option in JetPlan.com to search
for this information. See “Searching Generic Aircraft Records for FPM and OUTFLT
Information” on page 718.
Table 27-4 CADB Record: “Miscellaneous” Section
Performance Index Enables you to define the overriding optimization factor (fuel, time, or total
(PI) cost) in the calculation of the flight plan. The input value choices are: fuel, time,
or money. The default setting is fuel optimization.
PI or PI=
NOTE If a fuel price has been set in the Customer Airport Database record, that
ex. PI=F
price takes precedence over what is set in the CADB.
ex. PI=T
For more information about these optimization factors, see the “Profile
ex. PI=M,115,1850 Commands” chapter in the JetPlan User Manual.
Print ETOPS Setting this parameter to Yes displays the “ETOPS” section of the database in
(EP) the aircraft record. This section is otherwise hidden in the CADB record.
EP or EP=
ex. EP=Y
Max Flight Level Enables you to prevent the aircraft from exceeding a specific flight level
(FL) (altitude) in the flight plan computation. The input value is a 3-digit entry that
identifies a flight level in hundreds of feet.
FL or FL=
ex. FL=390
Print Brackets Setting this parameter to Yes displays the “Bracket Modes” and “Mode
(BK) Coupling” sections of the database in the aircraft record. These sections are
otherwise hidden in the CADB record.
BK or BK=
NOTE JetPlan.com does not currently support modifying the “Bracket Modes”
ex. BK=Y
section.
Min. Alternate Distance Enables you to set a minimum distance to the alternate airport. If the actual
(AD) distance from the arrival airport to the alternate airport is less than the AD
value, JetPlan adds distance to meet the AD value. The entered value acts as a
AD or AD=
distance bias, allowing JetPlan to properly calculate the performance data for
ex. AD=50 the divert leg.
The input value can be a 1 to 3-digit entry, in nautical miles.

727
Table 27-4 CADB Record: “Miscellaneous” Section (continued)
Print Altitude Capability When you set the Print Altitude Capability Table parameter to Yes or to
Table FPM/OUTFLT Available (A), the application displays the “Cutoff Weight
(CW) Tables” (altitude capability) section of the database in the CADB record.
Otherwise, the “Cutoff Weight Tables” section is hidden.
CW or CW=Y/N/A
The cutoff weight tables enable you to apply flight-level limitations to the
aircraft based on specific flight conditions, such as altitude, temperature, and
Mach number.
The Print Altitude Capability Table parameter also activates cutoff weight
tables for use with a specified cost index method. The Cost Index Method (LC)
parameter in the “Misc” section of the CADB lets you specify the cost index
method. The options in the “Cutoff Weight Tables” section then let you activate
specific tables for use with your selected cost index method.
Input values:
• Yes – The cutoff weight tables are activated for use with any of the
following cost index methods, which you can set using the Cost Index
Method parameter:
– (N) Default CI Method
– (F) FMS Matching
– (L) Traditional Method
– (Y) Simulated CI
• FPM/OUTFLT Available (A) – The cutoff weight tables are activated for
use with any of the following cost index methods, which you can set using
the Cost Index Method parameter:
– (P) FMS Matching (FPM)
– (O) FMS Matching (OUTFLT)
– (G) Golden Section Search (FPM)
NOTE For more information, see the Cost Index Method parameter in
Table 27-4, “CADB Record: “Miscellaneous” Section,” on page 727 and the
Cutoff Wt Tables parameter in “CADB Record: “Cutoff Weight Tables” Section”
on page 738.
SITA Address JetPlan does not currently use this value.

(SI)
SI or SI=
Print Driftdown Setting this parameter to Yes displays the “Driftdown” (Terrain Analysis)
(DD) section of the database in the aircraft record. This section is otherwise hidden in
the CADB record.
DD or DD=
NOTE Access to the “Driftdown” section is limited to certain customers.
ex. DD=Y

728
Profile Optimization Provides control over the altitude optimization, or step climb process. Enables
Interval you to override the programmed review of step climbs at each checkpoint by
(OI) setting a distance (in nautical miles) at which JetPlan considers a step climb.
OI or OI= Thus, if a flight segment distance (checkpoint to checkpoint) is greater than the
OI value, JetPlan considers a step climb somewhere between the checkpoints,
ex. OI=100
as well as at the checkpoints. Example: 100.
Hold Altitude Enables you to set the altitude at which hold fuel is calculated. This parameter
(HA) overrides the hold altitude setting loaded in the aircraft’s generic data. The input
value is an altitude entry, in feet. Example: 15000.
Hold Altitude
NOTE The Hold Altitude parameter is dependent on hold table data. You must
HA or HA=
request that the aircraft’s generic data include hold table information. Contact
ex. HA=15000 your Jeppesen account manager for more information.
Fuel Distribution Table Enables fuel distribution to be displayed in the flight plan output. This
(FD) parameter is dependent on special table loads in the aircraft’s generic data.
FD or FD= To display a fuel distribution report within a flight plan, the user can add the
option FDIST to the JetPlan option line.
ex. FD=B747-T1
NOTE The format keyword FDIST must be properly set by your account
manager.
Fuel distribution reports can also be retrieved by flight plan number or by
aircraft database name. Contact your Jeppesen account manager for more
information.

729
Cost Index Method The Cost Index Method parameter enables you to select the method that JetPlan
(LC or LC=) uses to determine the economy airspeed for a given cost index value. To use this
parameter correctly, enter a cost index value in the flight plan request or ensure
that the system automatically determines one for you. For more information,
see the “Cost Index Commands” chapter in the JetPlan User Manual.
NOTE To use the cost index methods associated with the First Principles
Aircraft Model (FPM), an FPM aircraft file must be available. To use the OUTFLT
method, OUTFLT aircraft files must be available. You can check the generic
aircraft record for the presence of this information. See “Searching Generic
Aircraft Records for FPM and OUTFLT Information” on page 718.
NOTE You can apply cutoff weight tables to selected cost index methods. For
more information, see “CADB Parameters: “Cutoff Weight Tables” Section” on
page 738.
Choosing a cost index method

The presence of an aircraft FPM file and FMS speed data determines whether a
method is available for use. The cost index methods associated with FMS
Matching are preferred. If possible, select either the (N) Default CI Method or
one of the three FMS Matching options instead of any other option. The
following list of input options ranks the cost index method options in order of
preference.
Input options:
• (N) Default CI Method – When the (N) Default CI method is selected, the
following occurs:
– The application attempts to use the (P) FMS Matching (FPM) CI
method based on the availability of an FPM file (Airbus, Boeing, and
McDonnell Douglass aircraft) and FMS optimal speed data.
– If an FPM file is not available, the application uses the (F) FMS
Matching method.
– If FMS optimal speed data are not available, the application uses
the (G) Golden Section Search (FPM) method with optimal FPM
speeds.
– The altitude is automatically applied for any of the above methods
based on the settings in the CUTOFF tables in the CADB. See “CADB
Parameters: “Cutoff Weight Tables” Section” on page 738.
• (P) FMS Matching (FPM) – If it is available, select (P) FMS Matching
(FPM). When this option is selected, the application computes the optimal
speed (Mach number) based on formulas used in a real FMS. However,
rather than using the traditional interpolation tables method, the fuel flow
is calculated based on the FPM method, which reduces the compute time
for the cost index flight plans.

730
Cost Index Method When (P) FMS Matching (FPM) is selected, the application checks limits
(continued) set by the maximal cruise thrust and 1.3 G buffet limits in the FPM file and
by the Rate of Climb with Max Climb Thrust or Rate of Climb with Max
Cruise Thrust parameter in the Aircraft Fleet Database. For more
information, see the “Aircraft Fleet Database” chapter in the JetPlan User
Manual or the Help file on JetPlan.com
• (F) FMS Matching – If (P) FMS Matching (FPM) is not available, select
(F) FMS Matching. When this option is selected, the application uses the
same algorithm as in the FMS, which ensures that speeds and fuel flows on
the flight plan match the speed that the FMS selects and the corresponding
fuel flow.
NOTE The Lowest Cost Index Mach (LM) and Highest Cost Index Mach (HM)
parameters in the “Modes” section are supported for use with the (F) FMS
Matching method.
• (O) FMS Matching (OUTFLT) – When this option is selected, the
application computes the optimal speed (Mach number) and the fuel flow
based on formulas used in a real FMS, which provides highly accurate fuel
flow and speeds and minimizes the computation time in cost index flight
plans.
When FMS Matching (OUTFLT) is selected, the application checks the
limits set by the maximal cruise thrust and 1.3 G buffet limits in the FPM
file and by the Rate of Climb with Max Climb Thrust or Rate of Climb
with Max Cruise Thrust parameter in the Aircraft Fleet Database. In
addition, the application uses the values of the MMO Margin and the
VMO Margin, also in the Aircraft Fleet Database. If MMO Margin or
VMO Margin is set to zero (0) or is not defined, the application uses a
default value of five (5) calibrated airspeed (CAS) in knots. For more
information, see the “Aircraft Fleet Database” chapter in the JetPlan User
Manual or the Help file on JetPlan.com.
• (G) Golden Section Search (FPM) – When this option is selected, the
application computes the optimal speed with the fuel-flow calculation
based on FPM. The application checks limits set by the Rate of Climb with
Max Cruise Thrust or Rate of Climb with Max Climb Thrust parameter in
the Aircraft Fleet Database. For more information, see the “Aircraft Fleet
Database” chapter in the JetPlan User Manual or the Help file on
JetPlan.com.
• (L) Traditional method —When this option is selected, the application
builds a numerical model of cost as a function of Mach number for each
flight segment.
NOTE The Lowest Cost Index Mach (LM) and Highest Cost Index Mach (HM)
parameters in the “Modes” section are supported for use with the (L) Traditional
method.
• (Y) Simulated CI (Constant Mach) —When this option is selected, the
application selects a single constant-Mach cruise speed for the entire
flight. This speed minimizes the combination of fuel and time equivalent
to the Cost Index number requested (or determined by the application).
The profile is also optimized to minimize the combination of fuel and time.

731
Noise Category Enables you to display the aircraft’s noise category in the flight plan output. The
(NZ) input value is an alphanumeric entry of up to 5 characters.
Noise Category NOTE This capability depends on specific output format designs. Contact your
NZ or NZ=
ex. NZ=3
Index Enables you to display the aircraft’s center of gravity (CG) index in the flight
(IX) plan output. The input value is a numeric entry of up to 3 characters.
Index NOTE This capability is dependent on specific output format designs. Contact
IX or IX=
ex. IX=145
Weight Unit Enables you to override the lbs/kgs setting tied to your ID/Attribute file. If your
(WU) attribute file is set to display all weights in kilograms, setting the WU parameter
to pounds changes all weights associated with the aircraft and any flight plan
WU or WU=
output to pounds. The input value is Pounds, Kilograms, or Default.
ex. WU=L
NOTE You can set the WU parameter value when you create an aircraft record.
ex. WU=K Once saved in the aircraft record, the WU parameter value can be changed only
ex. WU=D by Jeppesen. Contact your Jeppesen account manager for more information.
Climb and Descent Method Parameters

The Climb and Descent Method parameters enable you to select a method to compute climb and descent with
cost index or with a user-specified climb and descent profile (speed schedule). Currently, two methods exist for
computing climb and descent in JetPlan:
• Using First Principles Aircraft Model (FPM) – Based on FPM, this method involves building FPM climb
and descent data into the FPM file for each model and engine configuration for use with any climb and
descent profile with cost index support. FPM is currently available for Airbus and Boeing aircraft. You can
check the generic aircraft record for the presence of FPM climb/descent data. See “Searching Generic
Aircraft Records for FPM and OUTFLT Information” on page 718.
• Using the default climb or descent speed schedules from the generic aircraft file – If the Climb Method or
Descent Method parameter is left blank (no value is selected), JetPlan uses the default climb or descent
schedule from the generic aircraft file. For information on viewing the generic aircraft file, see the
“Aircraft Type Commands” chapter in the JetPlan User Manual.

732
Climb Method The Climb Method parameter enables you to define the climb performance
(CM) method.
NOTE Display of this information on the flight plan is format-dependent. For
information, contact your Jeppesen account manager.
NOTE To use the FPM methods, an FPM aircraft file must be available. You
can check the generic aircraft record for the presence of this information. See
“Searching Generic Aircraft Records for FPM and OUTFLT Information” on
page 718.
NOTE If no option is selected for Climb Method, the application uses the default
climb speed schedule from the generic aircraft file. For information on viewing the
generic aircraft file, see the “Aircraft Type Commands” chapter in the JetPlan
User Manual.
Input options
• (F) Cost Index: FMS Matching (FPM) – The application uses the FPM
cost index method to calculate the optimal climb CAS for an aircraft with a
FMC. The application computes climb using the FPM method with the
optimal climb CAS.
NOTE To use the (F) Cost Index: FMS Matching (FPM) method, both FPM
climb/descent data and climb/descent cost index FMC data must be available for
the aircraft. You can check the generic aircraft record for the presence of this
data. See “Searching Generic Aircraft Records for FPM and OUTFLT
• (G) Mach CAS Schedule (FPM) – The application uses the FPM climb
method with speed schedule parameters. The application uses the climb
profile parameters (if set) of the RALT, RIASC, MACHC and CASC
parameters in the Customer Airport Fleet database (CAPFDB).
If RALT and RIASC equal 0 (are not set) in the CAPFDB, the application
defaults to 100 (10000FT) for RALT and 250 knots for RIASC for Boeing
and Airbus aircraft.
If the MACHC and the CASC parameters are not set in the CAPFDB, the
application uses the climb CAS and the climb MACH speed in the aircraft
performance database record. For example, the default AAA descent mode
in the format MACH/CAS is 0.78/300. This information can be found in
the generic aircraft record. See Chapter 10, “Aircraft Type Commands” in
the JetPlan User Manual. The application computes climb using the FPM
method with climb profile.
• (N) Traditional Raw Sample JetPlan (FPM) – This option is no longer in
use.

733
Descent Method The Descent Method parameter enables you to define the descent performance
(DM) method.
NOTE Display of this information on the flight plan is format-dependent. For
NOTE To use the FPM methods, an FPM aircraft file must be available. You
can check the generic aircraft record for the presence of this information. See
“Searching Generic Aircraft Records for FPM and OUTFLT Information” on
page 718.
NOTE If no option is selected for Descent Method, the application uses the
default climb speed schedule from the generic aircraft file. For information on
viewing the generic aircraft file, see the “Aircraft Type Commands” chapter in the
JetPlan User Manual.
Input options:
• (F) Cost Index: FMS Matching (FPM) – The application uses the FPM
cost index method to calculate the optimal descent CAS for an aircraft
with an FMC. The application computes descent using the FPM method
with the optimal descent CAS.
NOTE To use the (F) Cost Index: FMS Matching (FPM) option, both FPM
climb/descent data and climb/descent cost index FMC data must be available for
the aircraft. You can check the generic aircraft record for the presence of this
data. See “Searching Generic Aircraft Records for FPM and OUTFLT
• (G) Mach CAS Schedule (FPM) – The application uses the FPM descent
method with speed schedule parameters. The application uses the descent
profile parameters (if set) of the RALT, RIASD, MACHD and CASD
parameters in the Customer Airport Fleet database (CAPFDB).
If RALT and RIASD equal 0 (are not set) in the CAPFDB, the application
defaults to 100 (10000FT) for RALT and 250 knots for RIASD for Boeing
and Airbus aircraft.
If the MACHD and the CASD parameters are not set in the CAPFDB, the
application uses the descent CAS speed and the descent MACH speed in
the aircraft performance database record. For example, the default AAA
descent mode in the format MACH/CAS is 0.78/300. This information can
be found in the generic aircraft record. See Chapter 10, “Aircraft Type
Commands” in the JetPlan User Manual. The application computes
descent using the FPM method with descent profile.
• (N) Traditional Raw Sample JetPlan (FPM) – This option is no longer in
use.

734
Climb/Descent Cost Index Enables you to define the climb/descent cost index.
(CL) NOTE Display of this information on the flight plan is format-dependent. For
This parameter can be set to perform climb/descent cost index calculations
using the (F) Cost Index: FMS Matching (FPM) method. If the (F) Cost Index:
FMS Matching (FPM) method is set, and the Climb/Descent Cost Index
parameter is not set, the application reuses the cruise cost index value.
ILS Category NOTE Use of this parameter is limited to specific customers.

(PP) NOTE The ILS Category parameter is different from the CAT III Approved
parameter in the “Certified” section of the CADB.
This parameter enables you to specify the Instrument Landing System (ILS)
approach category capability for the aircraft.
Input options:
• 1 – Approach category I
• 2 – Approach category II
• 3 – Approach category III
Apply French Contingency NOTE This parameter’s impact is limited to modifying contingency fuel
Factor calculations being done under the auspices of European fuel policy regulations.
For information on using this parameter, contact your Jeppesen account
FK or FK=Y/N manager.
FK=Y
When set to Yes, this parameter instructs JetPlan to calculate the flight plan in
accordance with French fuel policy rules—specifically, applying a French K-
Factor method to allow for a small reduction in the contingency fuel calculation
relative to the standard 3% or 5% methods normally used by European
operations. The small reduction allowed is for the fuel amount needed to carry
the contingency fuel to the destination. “K factor” is defined as the quotient of
the takeoff weight divided by the landing weight. The allowable reduction is to
divide the normal 3% or 5% contingency fuel by the K factor, which reduces
the contingency fuel number by an appropriate amount.
When set to No (the default), JetPlan applies the standard 3% or 5%
contingency fuel calculations for AIR OPS flight plans.
Input options: Yes/No

735
CADB Parameters: “Modes” Section

The “Modes” section contains speed setting parameters. They allow you to set default values
for the various profiles of a flight.
Table 27-5 CADB Record: “Modes” Section
Default Climb Enables you to set a secondary climb schedule as the default climb mode. If no
(CB) value is entered, JetPlan uses the default climb schedule from the originating
(generic) version of the aircraft. The input value is a valid JetPlan speed
CB or CB=
schedule for climb. Example: 340
ex. CB=340
NOTE Ad hoc climb schedule inputs in the flight plan request overrides this
parameter. For more information, see the “Cruise Mode Commands” chapter in
the JetPlan User Manual.
Default Cruise NOTE An ad hoc cruise mode input in the flight plan request overrides this
(CR)
Default Cruise
The Default Cruise parameter enables you to set a cruise mode that JetPlan uses
CR or CR= automatically for flight planning. If the Default Cruise parameter is not set, you
ex. CR=M82 must specify a cruise mode in the flight plan request.
NOTE The input value is a valid JetPlan speed schedule for cruise. Example:
M82.
Default Descent Enables you to set a secondary descent schedule as the default descent mode. If
(DE) no value is entered, JetPlan uses the default descent schedule from the
originating (generic) version of the aircraft. The input value is a valid JetPlan
DE or DE=
speed schedule for descent. Example: 280
ex. DE=280
NOTE Ad hoc descent schedule inputs in the flight plan request overrides this
Default Cost Index This parameter is the default cost index used in the Required Arrival Time –
(CI3) Cost Index (RATCI) calculation. The input value is a valid cost index number.
Example: 100
CI3 or CI3=
NOTE For more information, see the “ETD Commands” chapter in the JetPlan
ex. CI3=100
User Manual.
Default Reclear Enables you to set a secondary cruise schedule as the default cruise mode on the
(RC) reclear segment of a Reclear flight plan. The input value is a valid JetPlan speed
schedule for cruise. Example: M88
RC or RC=
ex. RC=M88
Fixed Operating Cost NOTE This parameter enables you to specify a fixed operating cost
(dollars/hour) for use with the JetPlan cost index functionality. The fixed
(OC)
operating cost is typically used to capture fixed maintenance costs per flight.
OC or OC= Example: 200.
ex. OC=5200

736
Table 27-5 CADB Record: “Modes” Section (continued)
Min RAT Cost Index This parameter sets the lower cost index airspeed limit in the Required Arrival
(CI1) Time – Cost Index (RATCI) calculation. The input value is a valid cost index
number. Example: 010.
CI1 or CI1=
ex. CI1=010
User Manual.
Max RAT Cost Index This parameter sets the upper cost index airspeed limit in the Required Arrival
(CI2) Time – Cost Index (RATCI) calculation. The input value is a valid cost index
number. Example: 1000
CI2 or CI2=
ex. CI2=1000
User Manual.
Lowest Cost Index Mach This parameter sets the lower Mach speed limit used in cost index calculations,
(LM) including RATCI. The input value is a valid Mach airspeed for the aircraft.
Example: M76
LM or LM=
ex. LM=M76
Highest Cost Index Mach This parameter sets the upper Mach speed limit used in cost index calculations,
(HM) including RATCI. The input value is a valid Mach airspeed for the aircraft.
Example: M88
HM or HM=
ex. HM=M88
Auxiliary Cruise Aircraft This parameter provides auxiliary fuel/time data for an alternative base aircraft
(AX) type within the primary flight plan (re-optimizes the profile for the auxiliary
AX or AX= cruise calculation).
NOTE Contact your Jeppesen account manager for details.

737
CADB Parameters: “Cutoff Weight Tables” Section

Cutoff weight tables (altitude capability tables) provide a way to limit altitude based on the
perceived weight of the aircraft. The perceived weight corresponds to a physical barrier, such
as maximum cruise thrust or buffet limits. It is the boundary of the flight envelope for a
specific condition.
Almost every aircraft in the JetPlan Aircraft Library has cutoff criteria loaded in the generic
data records. One cutoff weight criterion is always set as the default (standard) cutoff weight.
Having several active criteria helps ensure against flight outside of the designed capabilities
for the aircraft in any given situation.
You can apply cutoff weight tables to a selected cost index methods. You can use the Cost
Index Method parameter in the “Misc” section of the CADB to specify the cost index method.
The application of the cutoff weight tables to specific cost index methods depends on the
setting of the Print Altitude Table parameter in the “Misc” section of the CADB as follows:
• To activate the cutoff tables for use with non-FPM and non-OUTFLT cost
index methods, set the Print ALT Capability Table parameter to Yes.
• To activate the cutoff tables for use with the FPM and OUTFLT cost index
methods, set the Print ALT Capability Table parameter to FPM/OUTFLT
Available (A).
Table 27-6 CADB Record: “Cutoff Weight Tables” Section
NOTE When you set the Print ALT Capability Table (CW) parameter to Yes or to FPM/OUTFLT Available (A), the
application displays the “Cutoff Weight Table” (altitude capability) section of the CADB record in JetPlan.com.
Otherwise, the “Cutoff Weight Table” section is hidden. The Print ALT Capability Table (CW) parameter is in the
“Misc” section of the CADB.
Cutoff Wt Tables (1-9) This parameter enables you to apply flight-level limitations to the aircraft based
(CW) on specific flight conditions, such as altitude, temperature, and Mach number.
Depending on the aircraft, you can apply up to nine table settings.
CW1 or CW1=
The application of the cutoff weight tables to specific cost index methods
ex. CW1=Y
depends on the setting of the Print ALT Capability Table parameter in the
To activate a table, enter “Misc” section of the CADB. See the Cost Index Method and the Print Altitude
CW#=Y, where # represents Capability Table parameters in “CADB Parameters: “Miscellaneous” Section”
the number of the table, 1 on page 727.
through 9, you wish to
Input values:
affect. To deactivate a table,
enter CW#=N. • Y – Activates the cutoff weight table
• N – Deactivates the cutoff weight table
NOTE For FPM and OUTFLT cost index methods, you can activate any
combination of other cutoff criteria.

738
CADB Parameters: “Bracket Modes” Section
NOTE At present, modifying the Bracket Modes section of the CADB is supported
only in JetPlan, not JetPlan.com.
A “bracket mode” refers to the “bracketed” range of airspeeds applied to the cruise portion of
a flight plan calculation (between TOC [Top of Climb] and TOD [Top of Descent]). When a
specific cruise range is entered in the flight plan request, one which matches the data found in
an activated bracket mode table, JetPlan applies the climb and descent airspeed schedules
defined in that table to the flight plan calculation for those portions of the flight.
Foregoing the use of bracket modes restricts JetPlan to using one of the following: 1) default
climb and descent schedules defined in the aircraft’s generic data; 2) the climb and descent
schedules defined as default in the CADB (the CB and DE parameters); or 3) the climb and
descent schedules defined in the flight plan request on the Cruise Mode command line (ad hoc
inputs).
Bracket Modes are applied automatically when data exists and is activated in the “Bracket
Modes” section of the CADB record.
Table 27-7 CADB Record: “Bracket Modes” Section
NOTE You can display this section in the Aircraft Record in JetPlan.com by selecting Print Brackets in the “Misc”
section (see above). Modifying this section is currently supported only in JetPlan, not JetPlan.com.
Bracket Mode Tables In JetPlan, this parameter enables you to apply specific climb and descent
(BK 1-6) schedules based on a range (the bracket) of cruise speeds applied in the flight
plan calculation. There can be up to six table settings per aircraft.
BK1 or BK1=
NOTE This only works with cost index cruise modes.
ex.
BK1=CI0,CI500,340,290

739
CADB Parameters: “Mode Coupling” Section

The Mode Coupling parameter is similar to the Bracket Modes parameter in that particular
airspeeds for certain phases of flight are linked to cruise mode information. However, this
parameter enables you to couple more phases of flight and to do it based on an individual
cruise mode, not a cruise mode range.
With the Mode Coupling parameter you can couple the climb, descent, alternate, takeoff
alternate and hold phases of flight to a particular cruise mode. This feature can be applied
to each cruise mode available, up to 20 in total.
In JetPlan, mode coupling can be entered using one of two syntax formats: restricted and
unrestricted.
The restricted format is very rigid in the way you can enter information. You have to enter an
input for each of the five flight phases and you must follow an exact order of entry. Any
deviation results in an error or bad information. The syntactical order of the restricted mode
coupling input is:
CP=CRZ/CLB/DSC/ALT/TOALT/HLD
NOTE The cruise mode you are coupling always precedes the entries for the other
5 phases of flight (for example, CP=LRC/climb/descent/alt/toalt/hold).
The restricted method does allow you to enter just the airspeeds for each flight phase without
any identifying prefix. You must separate each phase of flight entry with a slash (/).
Example:
Explanation: For the cruise mode, LRC, invoke the following airspeeds in the flight plan
calculation: 300 (climb), GDD (descent), LRC (alternate), LRC (takeoff alternate), and the
LRC (hold).
01 OPTIONS AC,CHG,filename,CP=LRC/300/GDD/LRC/LRC/LRC

740
The unrestricted format is more flexible in methodology, though it does require you to prefix
each input phase and you still need to separate each phase with a slash (/). Flight phase entries
can be entered in any order, though the cruise mode entry must still be first. Not all phases
must have an input value. If you omit a phase input, JetPlan relies on the default setting in the
aircraft’s generic data record.
CP=CRZ=[crzmode]/CLB=[clmbsched]/DSC=[dscntsched]/ALT=[crzmode]/TOALT
=[crzmode]/HLD=[crzmode]
NOTE The cruise mode you are coupling always precedes the entries for the other
5 phases of flight (for example, CP=CRZ=LRC/CLB=AAA/DSC=290/ALT=LRC). You
can specify the cruise mode input without the CRZ= prefix (for example,
CP=LRC/CLB=AAA/DSC=290/HLD=LRC).
Example:
Explanation: For the cruise mode, M86, invoke the following airspeeds in the flight plan
calculation: 320 for climb and LRC for alternate. All other flight phases continue to use the
default airspeed settings from the aircraft’s generic data record.
01 OPTIONS AC,CHG,filename,CP=CRZ=M86/CLB=320/ALT=LRC
Using the unrestricted entry method, you can make changes to an individual phase without
affecting the rest of the record.
Example:
Explanation: For the cruise mode, M86, change the climb airspeed setting from 320 to 340. All
other flight phases continue to use their previous settings.
01 OPTIONS AC,CHG,filename,CP=M86/CLB=340
To delete a setting so that the aircraft’s generic (default) setting is used, enter the option, DEL,
after the phase prefix.
Example:
Explanation: For the cruise mode, M86, delete the climb airspeed setting. This results in a
climb airspeed of whatever is default in the aircraft’s generic data record.
01 OPTIONS AC,CHG,filename,CP=M86/CLB=DEL

741
To delete a mode coupling altogether, enter CP=DEL= followed by the cruise mode you wish
to uncouple. In this case, all phases of flight revert to their default settings when the particular
cruise mode is used in a flight plan.
Example:
Explanation: For the cruise mode, M86, delete or remove all couplings.
01 OPTIONS AC,CHG,filename,CP=DEL=M86
Table 27-8 CADB Record: “Mode Coupling” Section
NOTE To see the “Bracket Modes” and the “Mode Coupling” sections in JetPlan.com, you must set the Print
Bracket Modes parameter in the Miscellaneous section to Yes. Jeppesen has to load specific data in the generic
version of an aircraft to make Mode Coupling a viable option. If your aircraft has this data, you can see the “Mode
Coupling” section immediately after the “Bracket Modes” section in the Aircraft Record. To have the necessary
data for Mode Coupling loaded in the generic version of your aircraft, contact your Jeppesen account manager.
Mode Coupling Enables you to link, or “couple,” specific airspeeds for climb, descent,
CP or CP= alternate, takeoff alternate, and holding to a particular cruise mode. You
can apply couplings to as many as 20 cruise modes per aircraft.
ex.
CP=CRZ=LRC/CLB=300/ALT= To enter Mode Coupling information in JetPlan.com, first select a cruise
M82 mode from the Cruise drop-down list. Then select airspeeds for any of the
other phases you want to couple to the cruise mode. If you omit a phase
input, JetPlan relies on the default setting in the aircraft’s generic data
record.

742
CADB Parameters: “Tanker” Section

The “Tanker” section contains parameters related to the Single-Leg Tankering feature.
Table 27-9 CADB Record: “Tanker” Section
NOTE All of the parameters in the “Tanker” Section apply to JetPlan’s Single-Leg Tankering feature. See the
“Payload, POD/POA, Weight, and Fuel Commands” in the JetPlan User Manual.
Tanker Fuel Index Applies to the Fuel Index method of the Single-Leg Tankering feature (TANK1
(TI) or TANK1X options). The TI parameter is a required element of this feature. It
is a ratio that defines the relative price of fuel between two airports. The ratio
TI or TI=
expresses a point at which tankering is warranted—the cost of fuel is so much
ex. TI=10.5 greater at the arrival airport compared to the departure airport that tankering
fuel is cost effective to your operation.
The input value given to the TI parameter must be determined by the customer.
Example: 10.5
Tanker Currency Enables you to define the type of monetary output data you to work with in a
(TC) single-leg tankering plan calculation. The input value must be an ISO currency
code. Example: JPY
TC or TC=
ex. TC=JPY
Tanker Threshold Applies to the Fuel Cost method of the Single-Leg Tankering feature (TANK2
(TT) or TANK2X options). The TT parameter is an optional element of this feature.
It defines a minimum monetary savings value at which tankering is warranted.
TT or TT=
The TT value needs to correspond with the TC value in this database. For
ex. TT=10000
example, if TT=30000 and TC=JPY, you have expressed a tanker threshold of
¥30,000.00.
Tanker Landing Weight Enables you to set a limit to the landing weight when tankering is involved.
(TL) Since the aircraft already has a Max Landing Weight value (LA parameter), the
Tanker Landing Weight parameter is only used if you want to express a
TL or TL=
different value in the tankering situation.
ex. TL=620000
The input value can be expressed in pounds or kilograms, depending on your
preferred unit of measure. Example: 620000
Tanker Fuel Maximum Enables you to set a limit to the amount of fuel tankered in the single-leg
(TM) tankering plan calculation. The input value can be expressed in pounds or
kilograms, depending on your preferred unit of measure. Example: TM=15000
TM or TM=
ex. TM=15000
Tanker Fuel Capacity This field is used by certain external graphical user interfaces to JetPlan. There
(TK) is currently no other associated functionality with this parameter. Value range:
0-FC.
TK or TK=

743
CADB Parameters: “Equipment” Section

The “Equipment” section of the CADB contains parameters that designate the types and
quantities of hardware onboard the aircraft. Some of the parameters are used for Receiver
Autonomous Integrity Monitoring (RAIM) prediction reports.
Overview of RAIM Prediction Report Parameters

The “Equipment” section of the CADB record stores parameters that support requests for
RAIM prediction reports. Using a front-end GUI application that interfaces with JetPlan, such
as JetPlanner or Jeppesen Dispatch Control, you can plan your route of flight and submit a
RAIM prediction request. The system then uses sophisticated algorithms to generate a
prediction for the entire route, including the departure and arrival airports. Baro-aided outages
are reflected as True or False within the RAIM report, to allow easy analysis of Baro-aided
algorithm usage. You can also request RAIM prediction for reports for individual airports.
NOTE RAIM prediction reports are an additional fee service, and can be set up for
RAIM only, or for RAIM and RNP permissions. Contact your Jeppesen account
manager for fees, terms, and conditions.
You can request RAIM prediction reports for:
• Airports associated with a flight plan

• A set of airports not related to a flight plan
• The route in a flight plan
The following parameters in the CADB can be configured to support RAIM prediction
reports:
• GPS
• RAIM GPS Algorithm
• RAIM Mask Angle
• Departure Required Navigation Performance

744
• Enroute Required Navigation Performance

• Arrival Required Navigation Performance
For detailed information on how the CADB RAIM parameters are used in RAIM prediction
report requests as well as how to submit the requests, see the user documentation for the
applicable front-end flight planning product or contact your Jeppesen account manager.
Table 27-10 CADB Record: “Equipment” Section
NOTE Parameters marked with an asterisk (*) are applicable to the Customer Route Constraint Database.
HF Radios* Enter the number of high frequency radios available in the aircraft. Default
(HR) setting is zero (0).
HR or HR=
ex. HR=2
GPS Set this parameter to Yes if the aircraft has Global Positioning Satellite
(GP) capability. The default setting is No.
GP or GP=
ex. GP=Y
VHF Radios* Enter the number of very high frequency radios available in the aircraft. Default
(VR) setting is zero (0).
VR or VR=
ex. VR=2
OMEGA Set this parameter to Yes if the aircraft has an OMEGA radio navigation system
(OM) onboard. The default setting is No.
OM or OM=
ex. OM=Y
Dual ADF* Set this parameter to Yes if the aircraft has a dual Automatic Direction Finder
(DA) onboard. The default setting is No.
DA or DA=
ex. DA=Y

745
Table 27-10 CADB Record: “Equipment” Section (continued)
RNAV Set this parameter to specify whether the aircraft has area navigation (RNAV)
(RE) equipment on board. This parameter must be set to Terminal and Enroute (Y in
the command-line interface) or to Enroute Only to enable RNAV routing.
RE or RE=
Values:
ex. RE=T or RE=Y
• Terminal and Enroute – The aircraft is capable of flying all RNAV
segments. This setting implies an RNP level of less than 1.0 (or even 0.3)
and higher.
• Enroute Only – The aircraft is capable of flying only Enroute RNAV
segments. This setting implies an RNP capability of 2.0 or higher.
• None – The aircraft is not RNAV-equipped.
• (Y)es – Same as Terminal and Enroute (JetPlan command-line only).
The functionality associated with these settings requires the NAVALERT
preference to be set. When the NAVALERT preference is set, and RNAV is set
to a value other than Terminal and Enroute, the system optimizes to avoid
RNAV segments beyond the navigational capabilities of the aircraft.
The RNAV function considers RNAV airways and procedures as well as
standard airways and procedures in the flight plan computation. When the
NAVALERT preference is set, JetPlan returns an alert if the user specifies a
route that includes RNAV segments that exceed the RNAV capability of the
aircraft.
Dual INS* Set this parameter to Yes if the aircraft has a dual Inertial Navigation System
(DI) onboard. The default setting is No.
DI or DI=
ex. DI=Y
TCAS Equipped Set this parameter if the aircraft has a Traffic Collision Avoidance System
(TE) onboard. The default setting is No.
TE or TE= Setting this parameter to A (Always) inserts “RMK/TCAS EQUIPPED” in
ICAO flight plans (Item 18).
ex. TE=Y
Setting this parameter to Y inserts “RMK/TCAS EQUIPPED” in ICAO flight
ex. TE=A
plans (Item 18) that enter Canadian airspace only.
Flight Management System Set this parameter to Yes if the aircraft has a Flight Management Computer
(FM) onboard. The default setting is No.
FM or FM=
ex. FM=Y

746
8.33 KHz Communication Set this parameter to Yes if the aircraft is compliant with 8.33 KHz channel
(83) spacing requirement (in Europe). A Y character is inserted in Item 10a of the
filing strip.
83 or 83=
Set this parameter to Exempt if the aircraft is exempt at this time. JetPlan inserts
ex. 83=Y
EXM833 in Item 18 COM/ of the filing strip and restricts altitude.
ex. 83=N
Set this parameter to Permit if the aircraft is exempt, but you do not want the
ex. 83=E altitude restricted. JetPlan inserts EXM833 in Item 18 COM/ of the filing strip
ex. 83=P and does not restrict altitude.
The default setting is No.
ACARS Set this parameter to Yes if an Aircraft Communications Addressing and

(AS) Reporting System (ACARS) is onboard the aircraft. The default setting is No.
AS or AS=
ex. AS=Y
FMS Type Enables you to select the format type for ACARS uplink of data/information.
(FY) The input choices are:
FY or FY= • Blank – not set
ex. FY=UF • AFIS – Honeywell (AH)
• ARINC Direct (AD)
• Litton (SF)
• SATCOM (SC)
• Sperry – Honeywell (HF)
• Universal (UF)
NOTE For more information, see the “Forward Plans and Messages” chapter in
AGCS Set this parameter to Yes if an Air to Ground Communication System (AGCS)
(AG) is onboard the aircraft. The default setting is No.
AG or AG=
ex. AG=Y
NRS Capable Set this parameter to Yes if the aircraft’s navigational database has the
(NR) Navigational Reference System (NRS) points for the FAA’s High Altitude
Redesign (HAR) program. The default setting is No.

747
RAIM GPS Algorithm Enables you to indicate the algorithm used by RAIM GPS Equipment, if
(RM) present. This parameter is a necessary input for requests for a RAIM prediction
report.
RM or RM=
This parameter defaults to FD if no other value is supplied and if the GPS
ex. RM=FDE
parameter (GP) is set to Yes.
Input choices are:
• FD – Fault Detection
• FDE – Fault Detection Exclusion
• FD BARO – Fault Detection with Barometric Aiding
• FDE BARO – Fault Detection Exclusion with Barometric Aiding
NOTE This parameter must be populated if RAIM reports are required.
Submitting a request for a RAIM report without this parameter results in an error.
RAIM Mask Angle Enables you to enter the mask angle for the RAIM Global Positioning Satellite
(GM) receiver, if present. The mask angle is included in requests for a RAIM
prediction report. Range of input values: Increments of 0.5 from -0.5 to 20.0.
GM or GM=
Default setting is 0.0.
ex. GM=-0.5
NOTE This parameter must be populated if RAIM reports are required.
Departure Required Enables you to define the Departure Procedure RNP level. The RNP level is
Navigation Performance included in requests for a RAIM prediction report. Input choices are 0.3 and
(DR) 1.0. Default setting is 0.0.
DR or DR= NOTE This parameter must be populated if RAIM reports are required.
ex. DR=0.3
Enroute Required Enables you to define the Enroute Procedure RNP level. The RNP level is
Navigation Performance included in requests for a RAIM prediction report. Input choices are 1.0 and
(RR) 2.0. Default setting is 0.0.
RR or RR= NOTE This parameter must be populated if RAIM reports are required.
ex. RR=0.3
Arrival Required Navigation Enables you to define the Arrival Procedure RNP level. The RNP level is
Performance included in requests for a RAIM prediction report. Input choices are 0.3 and
(AR) 1.0. Default setting is 0.0.
AR or AR= NOTE This parameter must be populated if RAIM reports are required.
ex. AR=0.3
GPS Receiver Enables you to enter the name of the GPS receiver in the aircraft. This field is
(GR) informational only and supports no functionality in JetPlan.
GR or GR= Input value: 8 characters maximum
ex. GR=xxxx

748
CADB Parameters: “Certified” Section

The “Certified” section contains parameters that flag the aircraft positively or negatively with
regard to its use in various airspace regions and with certain airway structures.
Table 27-11 CADB Record: “Certified” Section
NOTE Parameters marked with an asterisk (*) are applicable to the Customer Route Constraint Database.
Overwater Equipped* When set to Yes, identifies the aircraft as certified for overwater flights.
(OW) The OW parameter is used in conjunction with the Customer Route Constraint
OW or OW= Database (CRCDB) to define routes that require aircraft to have certain
characteristics—for example, to be overwater approved. If the selected
ex. OW=Y
customer aircraft does not possess all of the characteristics to fly a route as
defined in the CRCDB, route constraint is automatically applied. See the
“Route Constraint Database” chapter in the JetPlan User Manual.
NOTE The OW parameter is different from the Overwater Capability parameter
(OA), which is used by JetPlan only when the Overwater Avoid (FP, OWATAA) or
Overwater Alert (FP, OWATAN) flight plan option has been invoked. See
“Overwater Capability” below.
NOTE Both the Overwater Equipped (OW) and the Overwater Capability (OA)
parameters can be overridden by the Overwater Restriction (OW) parameter in
the MEL Database. For more information, see the Help topic for the MEL
Database in JetPlan.com or the “Minimum Equipment Database” chapter in the
NAT HLA Equipped* NOTE “MNPS Equipped” has been renamed “NAT HLA Equipped.” The
definition of this parameter does not change as result of the name change.
(ME)
ME or ME= When set to Yes, identifies the aircraft as certified for NAT HLA airspace, and
JetPlan includes an “X” in Item 10 of the ICAO ATS plan.
ex. ME=Y
and MNPS (NAT HLA) certifications in the MEL Database overrides the settings
for these items in the CADB and removes their designators from the NAV/COM
code in Item 10 of the ICAO filing strip. For more information, see the Help topic
for the MEL Database in JetPlan.com or the “Minimum Equipment List” chapter in

749
Table 27-11 CADB Record: “Certified” Section (continued)
RVSM Certified* When set to Yes, identifies the aircraft as certified for Reduced Vertical
(RV) Separation airspace. JetPlan enables use of this aircraft in flight plans with
altitudes above FL280, and includes a “W” in Item 10a of the ICAO ATS plan.
RV or RV=
When set to No, identifies the aircraft as not certified for Reduced Vertical
ex. RV=Y
Separation airspace. JetPlan limits use of this aircraft to flight plans with
ex. RV=E altitudes at or below FL280, and omits “W” from Item 10a of the ICAO ATS
plan.
When set to Exempt, JetPlan enables use of a non-RVSM certified aircraft in
flight plans with altitudes above FL280, and adds STS/NONRVSM to Item 18
of the ICAO ATS plan.
for these items in the CADB and removes their designators from the NAV/COM
code in Item 10 of the ICAO filing strip. For more information, see the Help topic
for the MEL Database in JetPlan.com or the “Minimum Equipment List Database”
chapter in the JetPlan User Manual.
RNP Certified When set to Yes, this parameter identifies the aircraft as certified for Area
(RP) Navigation (RNAV).
RP or RP= NOTE See also the PBN Certified (I1) parameter. When the PBN Certified (I1)
parameter is set to “Yes,” JetPlan inserts an “R” in Item 10a on the filing strip. See
ex. RP=Y “CADB Parameters: “ICAO 2012 Certification and Equipment” Section” on
page 783”.
for these items in the CADB. For more information, see the Help topic for the MEL
Database in JetPlan.com or the “Minimum Equipment List Database” chapter in
CAT III Approved NOTE The CAT III Approved parameter is different from the ILS Category
parameter in the “Miscellaneous” section of the CADB.
(C3)
C3 or C3= When set to Yes, this parameter identifies the aircraft as approved for Category
III approaches.
ex. C3=Y

750
Table 27-11 CADB Record: “Certified” Section (continued)
Overwater Capability (OA) Indicates the aircraft’s overwater certification. An aircraft can be certified for
(OA) limited overwater or for full overwater operations. Certification implies certain
capabilities and equipment types such as personal flotation devices, life rafts
OA or OA=
equipped with survival kits, and location transmitters.
ex. OA=L
Input options:
• Full – Certification indicating capability to safely fly extended overwater
operations in compliance with regulations. 162 nm is the standard full
overwater boundary as measured from the nearest coastline or acceptable
landmass.
• Limited – Certification indicating capability to safely fly limited overwater
operations in compliance with regulations. 100 nm is the standard full
overwater boundary as measured from the nearest coastline or acceptable
landmass.
• None – The aircraft is not overwater-capable.
This parameter is used by JetPlan only when the Overwater Avoid (FP,
OWATAA) or Overwater Alert (FP, OWATAN) flight plan option has been
invoked. For more information, see the “Option Commands” chapter in the
NOTE The City Pair Database Overwater (OWI) parameter must be set to Yes
for JetPlan to implement the OWATAA and OWATAN options. If the Overwater
(OWI) parameter is set to No, JetPlan runs the flight plan but ignores the
OWATAA and OWATAN options. See the Help topic for the City Pair Database
on JetPlan.com for more information.
NOTE Both the Overwater Equipped (OW) and the Overwater Capability (OA)
parameters can be overridden by the Overwater Restriction (OW) parameter in
the MEL Database. For more information, see the Help topic for the MEL
Database in JetPlan.com or the “Minimum Equipment List Database” chapter in

751
CADB Parameters: “ATS Plan” Section

The “ATS Plan” section contains parameters that provide information to ATC. Some of these
parameters are entered automatically in the flight plan filing form.
Table 27-12 CADB Record: “ATS Plan” Section
USA Equipment Suffix NOTE This parameter applies to U.S. domestic filings. It is not used for ICAO
2012 filings.
(EQ)
EQ or EQ= Enables you to identify the aircraft’s special Nav/Com capabilities. The input
value must be a single character entry using one of the following choices: A, B,
ex. EQ=I
C, D, E, F, G, I, M, N, P, R, T, U, X, Y, or W.
Code designations can be found in the Aeronautical Information Manual,
Section 5-1-8 (Flight Plan – IFR Flights).
Operator Required When set to Yes, JetPlan includes the company name (from the Company Name
(OR) parameter) after OPR/ in Item 18 of the ICAO plan. The default input value is
No.
OR or OR=
ex. OR=Y
Emergency Radio Enables you to identify the types of emergency radios available on the aircraft.
(ER) You can select any or all of the following:
ER or ER= • UHF
ex. ER=UVE • VHF
• ELT – Emergency locater transmitter
Company Name Enables you to specify the company name. This parameter needs to be set if the
(CN) OR parameter is set to Yes. The input value cannot exceed 16 characters.
CN or CN=
ex. CN=JEPPESEN
Phone Number Enables you to specify a phone number. The input value cannot exceed 12
(PH) characters.
PH or PH=
ex. PH=303-799-9090
Miscellaneous Information Enables you to add any miscellaneous note. The input value cannot exceed 16
(MI) characters.
MI or MI=
ex. MI=ANYTHING

752
Table 27-12 CADB Record: “ATS Plan” Section (continued)
Type of Flight Enables you to identify the type of flight the aircraft typically performs. You
(TF) can select one or more of the following characters:
TF or TF= • N (non-scheduled)
ex. TF=S • S (scheduled)
• G (general aviation)
• M (military)
• X (Other)
Survival Equipment Enables you to define the type of survival equipment carried on board the
(SE) aircraft. You can select any or all of the following:
SE or SE= • P (polar)
ex. SE=PM • M (maritime)
• D (desert)
• J (jungle)
Selective (SELCAL) Call Enables you to set the Selective Call code to the unique tones that identify the
Code aircraft. The input value is a 4-character entry using the letters A to M
(SC) (excluding the letter, I), P, Q, R, and S. The specific combination of letters is
user determined. Example: AGJH
SC or SC=
ex. SC=AGJH
Life Jackets Enables you to define the type of life jackets carried on board the aircraft.
(JA) You can select any or all of the following:
JA or JA= • Lighted
ex. JA=LF • Fluorescent
• UHF beacon
• VHF beacon
Registration Number Enables you to define the aircraft’s registration or tail number. The input value
(RN) does not exceed 12 alphanumeric characters.
RN or RN= IMPORTANT The IFPS requires the registration number (REG/######) in Item
18 on the ICAO flight plan. If the registration number is not present, IFPS might
ex. RN=N123456 reject the flight plan.
Number of Dinghies Enables you to define the total number of dinghies carried on board the aircraft.
(DN) The input value cannot exceed 2 digits.You can also enter the number, 0, to
signify no or none. This ensures a zero in the ICAO plan rather than a blank.
DN or DN=
ex. DN=15
Aircraft Type Enables you to specify the ATA code of the aircraft. The input value cannot
(TY) exceed 12 characters. Example: 747N
TY or TY=
ex. TY=747N

753
Dinghy Capacity Enables you to define the total capacity, in persons, of all dinghies carried on
(DC) board the aircraft. The input value cannot exceed 3 digits. You can also enter the
number, 0, to signify no or none. This ensures a zero in the ICAO plan rather
DC or DC=
than a blank.
ex. DC=375
Aircraft Color Enables you to specify the aircraft’s color markings. The input value cannot
(AC) exceed 16 characters. Example: AC=WHITE RED
AC or AC= NOTE The display of the Aircraft Color parameter in the aircraft record is limited
to 15 characters.
ex. AC=WHITE RED
Dinghy Cover Color Enables you to specify the color of the dinghy covers. The input value cannot
(CC) exceed 16 characters.
CC or CC=
ex. CC=YELLOW RED
Persons on Board Enables you to specify the total number of people boarded on the aircraft. The
(OB) input value cannot exceed a 3-digit number. You can also enter the code, TBN,
to acknowledge that a number is yet To Be Named.
OB or OB=
ex. OB=185
ex. OB=TBN
Aircraft ICAO Code Enables you to specify the ICAO code of the aircraft. The KO parameter is
(KO) optional. JetPlan automatically includes the default ICAO code and wake
turbulence category in the ICAO plan. The input value cannot exceed 8
KO or KO=
characters. Example: B744/H
ex. KO=B744/H
RVR Weather Minima Enables you to define the minimum runway visual range (in meters) for the
(WX) aircraft before low visibility procedures become applicable.
WX or WX= This parameter is used primarily in Europe and matches the lowest RVR value
for which the aircraft/crew are rated.
ex. WX=500
The input value cannot exceed a 4-digit number.
Domestic Call Sign Enables you to specify the aircraft’s call sign. The DO parameter value appears
(DO) in both the flight plan output and the filing. The input value cannot exceed 12
characters.
DO or DO=
NOTE If a flight plan is filed with a call sign of 8 or more characters, the flight
ex. DO=SSDOCS101
plan is rejected by ATC.
NOTE The ad hoc call sign option, CS/xxxxxxx, overrides the DO parameter.
See the “Option Commands” chapter in the JetPlan User Manual.
FAA Aircraft Type This parameter is used when the FAA aircraft identifier differs from the ICAO
(FA) identifier. For example, a Stage-3 Boeing 727 can have the ICAO identifier
B722, but the FAA identifier is B72Q. Example: B72Q
FA or FA=
ex. FA=B72Q

754
Other Equipment IMPORTANT Do not enter ICAO 2012 Item 18 PBN/ or Item 18 RMK/
information in the Other Equipment (OE) parameter. See “CADB Parameters:
(OE)
“ICAO 2012 Certification and Equipment” Section” on page 783.
OE or OE=
When populated, this parameter adds the specified text to Item 18 preceded by
the indicator NAV/ and inserts “Z” into Item 10a on the filing strip.
Example:
(FPL-COOPAIR-IG
-GLF4/M-SXDGHIWZY/S
-KSFO0000
-N0455F450 DCT OAK DCT EHF J65 BLH DCT GBN J50 ELP J86 FST
CSI1
-KSAT0240
-EET/KZLA0026 KZAB0103 KZHU0213
SEL/FDLF DAT/S
NAV/RNAV1 RNAV5 RNP5
RMK/AGCS EQUIPPED)
Input values: Plain text entries up to 80 characters.

755
CADB Parameters: “ETP” Section

The “ETP” section is a sub-database that contains parameters for the application of equal-
time-point diversions. This information is applicable to basic ETP, ETOPS, and Overwater
Driftdown calculations.
NOTE The aircraft selected as well as customer preference settings determine

which ETP parameters are available for use.
Table 27-13 CADB Record: “ETP” Section
NOTE When setting ETP parameter values in command-line mode, you must use an equal sign (=) between the
parameter and the value when the parameter code ends with a number (for example, EC1=330, ECA2=290, and
so on). Otherwise, you can use either method.
Non-emergency ETP True Scenario: All-engine, pressurized

Airspeed (Optional). Used in conjunction with the NF parameter, the NA parameter
(NA) enables you to define a true airspeed constant for an all-engine, pressurized
NA or NA= (high-level) ETP calculation.
ex. NA=420 The input value is a 3-digit true air speed entry, in knots.
NOTE This parameter overrides the EA parameter. Set a parameter value only
if you do not want ETP calculations performed in a depressurized, low-level
scenario.
NOTE For overwater driftdown flight plans (DRFT or DRFTX options), an
aircraft with the NA and NF parameters set produces ETP data in the ETP
summary (usually at the top of the flight plan) based on these non-emergency
settings. However, the ETP data in the Driftdown summary (usually at the end of
the flight plan) is based on other settings, specifically, the parameters for all-
engine, one engine-out, and two engine-out calculations (the EA, EA1 or EA2
parameters).
Non-emergency ETP Flight Scenario: All-engine, pressurized

Level (Optional). Used in conjunction with the NA parameter, the NF parameter
(NF) provides a flight level constant for a pressurized, high-level ETP calculation.
NF or NF= The input value is a 3-digit altitude entry, in hundreds of feet. Example: 350
ex. NF=350 NOTE A millibar entry is unavailable with this scenario.

756
Table 27-13 CADB Record: “ETP” Section (continued)
ETP All Engine Scenario: All-engine, depressurized
Depressurized Cruise Mode The EC parameter enables you to set the cruising speed of the aircraft for the
(EC) divert portion of an all-engine, low-level ETOPS or Driftdown flight plan based
EC or EC= on cruise table data. If the EC parameter is not set, the system defaults to using
the LRC cruise mode. If EC is set, it must be equal to LRC or a Mach number
ex. EC=LRC
between the primary Mach number cruise modes that exist for the aircraft.
Set this parameter only if LRC is not preferred. The input value is a 3-character
cruise mode or true airspeed entry.
NOTE If EC is set with a Mach number outside the range of those listed for the
aircraft type, an error occurs.
NOTE The aircraft’s generic record must include cruise table data for ETOPS
and Driftdown. Additional table data can be loaded in the generic record upon
request.
See the “Cruise Mode Commands” chapter in the JetPlan User Manual for
more information on cruise modes.
ETP Cruise Mode (Anti-Ice Scenario: All-engine, depressurized

On) See EC parameter. The ECA parameter setting considers the application of anti-
(ECA) ice procedures.
ECA or ECA= NOTE The aircraft’s generic record must include cruise table data for ETOPS
ex. ECA=330 and Driftdown. Additional table data can be loaded in the generic record upon
request.
NOTE Use of this parameter is limited to specific customers.
ETP Cruise Mode (Anti-Ice Scenario: All-engine, depressurized

Off) See EC parameter.
(ECN) NOTE The aircraft’s generic record must include cruise table data for ETOPS
ECN or ECN= and Driftdown. Additional table data can be loaded in the generic record upon
ex. ECN=340 request.
ETP True Airspeed Scenario: All-engine, depressurized

(EA) The EA parameter enables you to set a true airspeed constant for the ETP
EA or EA= calculation for the divert portion of an all-engine, low-level ETP flight plan.
Since ETP calculations are performed for ETOPS and Driftdown flight plans,
ex. EA=400
the EA parameter is also the standard by which those calculations occur.
The input value is a 3-digit true airspeed entry, in knots.
NOTE The NA parameter overrides this parameter when set. This is for basic
ETP position, but not for overwater driftdown and ETOPS.
Entry/Exit True Airspeed This is a true airspeed constant parameter used to determine ETOPS entry and
(NX) exit points. Example: 450.
NX or NX=
ex. NX=450

757
ETP Depressurized Flight Scenario: All-engine, depressurized
Level (All Eng, 1LE) The EM or EF parameter enables you to set a flight level for the divert portion
x 100 Feet (EF) of an all-engine, low-level ETP, ETOPS or Driftdown flight plan. These
or parameters act as both the cruise flight level and the wind data extraction level
for the ETP calculation.
Millibars
You have the choice of how the parameter value is entered.
(EM)
If you want to enter an altitude as you would a flight level, select the EF
parameter. The input value is a 3-digit entry, in hundreds of feet (for example,
EM or EM= 140 = 14,000 ft). The use of the EF parameter allows for any flight level the
EF or EF= aircraft can fly. Example: EF=140
ex. EM=700 If you want to enter an altitude in millibars, select the EM parameter. The input
ex. EF=140 value must be one of the following millibar levels: 200, 250, 300, 400, 500,
550, 600, 650, 700, 750, 800, 850.Example: EM=700
The EF and EM parameters are mutually exclusive.
ETP Available Oxygen Time Scenario: All-engine, depressurized

(OX) The ETP Available Oxygen Time parameter is used for Driftdown flight plans
OX or OX= (DRFT or DRFTX options). This parameter enables you to indicate the time in
minutes that oxygen is available for use after depressurization occurs. While
oxygen is available, the aircraft can cruise at a higher altitude (and therefore
burn less fuel) until the oxygen runs out, at which point, a descent to 10,000 feet
can occur.
Use this parameter in conjunction with the ETP Decompressed Cruise Altitude
parameter (OF or OL), which enables you to indicate the flight level at which to
fly while depressurized and using oxygen (see below). For example, the
following settings indicate that the aircraft has 60 minutes of available oxygen
and can cruise depressurized at 25,000 feet: OX=60, OF=250.
Setting the OX parameter to 0 (the default) disables this feature and renders the
OF/OL parameter inert.
Input value: Time in minutes; default is zero.
NOTE Output of this information on a flight plan is format-dependent.

758
ETP Decompressed Cruise Scenario: All-engine, depressurized
Altitude The ETP Decompressed Cruise Altitude parameter is used for Driftdown flight
x100 Feet (OF) plans (DRFT or DRFTX options). It enables you to indicate the flight level at
or which the aircraft can cruise while depressurized and using oxygen.
Millibars Set this value only when ETP Available Oxygen Time (OX) is set to a positive
value (see above). The OX parameter indicates the number of minutes that
(OL)
oxygen is available for use after depressurization occurs. When the OX
parameter is set to 0 (the default), the OF/OL parameter value is inert.
The input value for OF is a 3-digit entry, in hundreds of feet (for example, 140 =
14,000 ft).
OL is the flight level in millibars. The input value must be one of the following
millibar levels: 200, 250, 300, 400, 500, 550, 600, 650, 700, 750, 800, 850.
The OF and OL parameters are mutually exclusive.
NOTE Output of this information on a flight plan is format-dependent.
ETP Hold Time Scenario: All-engine, depressurized

(EH) Provides a reserve fuel that is used in the ETP worst case (critical) fuel
or calculation for the all-engine, low-level scenario.
ETP Reserve Fuel The EH parameter enables you to set a hold time for the purpose of providing a
reserve fuel. The input value is a 1 to
(EX)
3-digit time entry, in minutes. Example: EH=15
EH or EH=
The EX parameter enables you to set a specific amount of reserve fuel. The
EX or EX= input value is a 1 to 6-digit fuel entry, in pounds or kilograms. Example:
ex. EH=15 EX=2500
ex. EX=2500 NOTE The EH and EX parameters are mutually exclusive. You can use one or
the other but not both.
ETP 1LE Scenario: One engine-out, pressurized/depressurized

Pressurized/Depressurized The EC1 parameter is similar to the EC parameter except that it applies to the
Cruise Mode one-engine-out calculation. For ETOPS, this is a depressurized scenario. For
(EC1) Driftdown, it is the highest one-engine-out altitude attainable.
EC1= If EC1 is not set, the system defaults to using the 1LE cruise mode. If EC1 is
ex. EC1=330 set, it must be equal to one of the auxiliary cruise modes that exist for the
aircraft.
ex. EC1=M76
Set this parameter only if 1LE is not preferred. The input value is a 3-character
entry specifying an auxiliary cruise mode. Examples: 330 or M76.
NOTE If EC1 is set to a value other than one of the auxiliary cruise modes listed
for the aircraft type, an error occurs.
and Driftdown. Long Range Cruise (LRC) data for one engine-out (1LE) and two
engine-out (2LE) scenarios is loaded in the generic record as appropriate for the
aircraft type. Additional table data can be loaded in the generic record upon
request.

759
ETP 1LE Cruise Mode Scenario: One engine-out, depressurized
(Anti-Ice On) See ECA parameter. Typically, the default airspeed is 1LE (one less engine
(ECA1) LRC). Change this parameter only if 1LE is not preferred. Example: 290
ex. ECA1=290 NOTE Use of this parameter is limited to specific customers.
ETP 1LE Cruise Mode Scenario: One engine-out, depressurized

(Anti-Ice Off) See ECN parameter. Typically, the default airspeed is 1LE (one less engine
(ECN1) LRC). Change this parameter only if 1LE is not preferred. Example: 310
ECN1= NOTE Use of this parameter is limited to specific customers.
ex. ECN1=310
ETP 1LE Descent (Anti-Ice Scenario: One engine-out, depressurized

On) Enables you to set a descent airspeed for one engine-out, low-level, anti-ice on
(EDA1) scenario. Typically, the default airspeed is 1LE (one less engine LRC). Change
EDA1= this parameter only if 1LE is not preferred.
ex. EDA1=290 The input value is a 3-digit cruise mode or true airspeed entry, in knots.
NOTE The aircraft’s generic record must include descent table data for ETOPS
and Driftdown. Long Range Cruise data for one engine-out (1LE) and two engine-
out (2LE) scenarios is loaded in the generic record as appropriate for the aircraft
type. Additional table data can be loaded in the generic record upon request.
ETP 1LE Descent (Anti-Ice Scenario: One engine-out, depressurized

Off) Enables you to set a descent airspeed for one engine-out, low-level, anti-ice off
(EDN1) scenario. Typically, the default airspeed is 1LE (one less engine LRC). Change
EDN1= this parameter only if 1LE is not preferred.
ex. EDN1=290 The input value is a 3-digit cruise mode or true airspeed entry, in knots.
NOTE The aircraft’s generic record must include descent table data for ETOPS
ETP 1LE True Airspeed Scenario: One engine-out

(EA1) Similar to EA parameter except that it is a one-engine-out true airspeed
EA1= constant.
ex. EA1=390 The input value is a 3-digit true air speed entry, in knots.

760
ETP 1LE Pressurized Flight Scenario: One engine-out
Level Similar to EF and EM parameters except that it is applicable to the one engine-
x 100 Feet (EF1) out, ETP calculations (Driftdown). Example: EF1=120 or EM1=300
or
Millibars
(EM1)
EF1=
EM1=
ex. EF1=120
ex. EM1=300
ETP 1LE Hold Time Scenario: One engine-out, depressurized

(EH1) Similar to EH and EX parameters except that it is applicable to the one engine-
or out, low-level scenario (Driftdown). Example: EH1=120 or EX1=2250
(EX1)
EH1=
EX1=
ex. EH1=12
ex. EX1=2250
ETP 2LE Cruise Mode Scenario: Two engine-out

(EC2) The EC2 is similar to the EC parameter except that it applies to two-engine-out
EC2= calculations. It is used only for driftdown and only for the highest two-engine-
out altitude attainable. Typically, the default airspeed is 2LE (two less engine
ex. EC2=330
LRC). Change this parameter only if 2LE is not preferred. Example: EC2=330
ex. EC2=M76 or EC2=M76.
ETP 2LE Cruise Mode Scenario: Two engine-out, depressurized

(Anti-Ice On) See ECA parameter.Typically, the default airspeed is 2LE (two less engine
(ECA2) LRC). Change this parameter only if 2LE is not preferred. Example: 290
ECA2= NOTE Use of this parameter is limited to specific customers.
ex. ECA2=290
ETP 2LE Cruise Mode Scenario: Two engine-out, depressurized

(Anti-Ice Off) See ECN parameter. Typically, the default airspeed is 2LE (two less engine
(ECN2) LRC). Change this parameter only if 2LE is not preferred. Example: 310
ECN2= NOTE Use of this parameter is limited to specific customers.
ex. ECN2=310

761
ETP 2LE Descent (Anti-Ice Scenario: Two engine-out, depressurized
On) See EDA1 parameter. Typically, the default airspeed is 2LE (two less engine
(EDA2) LRC). Change this parameter only if 2LE is not preferred. Example: 290
EDA2= NOTE This parameter is limited to specific customers
ex. EDA2=290
ETP 2LE Descent (Anti-Ice Scenario: Two engine-out, depressurized

Off) See EDN1 parameter. Typically, the default airspeed is 2LE (two less engine
(EDN2) LRC). Change this parameter only if 2LE is not preferred. Example: 290
EDN2= NOTE Use of this parameter is limited to specific customers.
ex. EDN2=290
ETP 2LE True Airspeed Scenario: Two engine-out

(EA2) Similar to EA parameter except that it is a two-engine-out true airspeed
EA2= constant. Example: 390
ex. EA2=390
ETP 2LE Millibars Scenario: Two engine-out
(EM2) Similar to EM and EF parameters except that it is applicable to the two engine-
or out, low-level scenario (Driftdown).
ETP 2LE Flight Level Example: EM2=500 or EF2=100
(EF2)
EM2=
EF2=
ex. EM2=500
ex. EF2=100
ETP 2LE Hold Time Scenario: Two engine-out, depressurized

(EH2) Similar to EH and EX parameters except that it is applicable to the two engine-
or out scenario (Driftdown).
ETP 2LE Reserve Fuel Example: EH2=20 or EX2=2800
(EX2)
EH2=
EX2=
ex. EH2=20
ex. EX2=2800

762
Medical ETP Hold Time Scenario: All-engine, pressurized
(EH3) Similar to the EH and EX parameter in that it provides a reserve fuel, which is
or used in the ETP worst case fuel calculation. However, this parameter is tied to
Medical ETP Reserve Fuel the NA/NF parameters, which are used in an all-engine, high-level ETP plan.
(EX3) Example: EX3=3000
EH3=
EX3=
ex. EX3=3000
CADB Parameters: “ETOPS” Section

The ETOPS section within the CADB enables you to control and modify the relevant
performance criteria used in the ETOPS flight plan calculation.
NOTE The database must be activated before any of your parameter values
become applicable in a flight plan. To activate the ETOPS Database, set the EP
parameter in the “Miscellaneous” section of the CADB to (Y)es.
If the ETOPS Database is not activated, the analysis calculations become limited to generic
performance factors or whatever methodology is tied to your User ID or format. If your
aircraft has no generic ETOPS information, then you receive no ETOPS analysis, whether the
option is turned on or not. Once the ETOPS Database is populated (and activated), your inputs
override any stored data found in your aircraft’s generic data file.
The parameters in the ETOPS section include flags and factors. Simply put, the flag turns a
feature on or off, and the factor says what to do when it is turned on. The value given to a flag
or factor is coded information. A factor is the formula used in an ETOPS calculation. A flag
activates a particular factor and specifies the situation in which it is applied. Although some
factors are fixed values that do not need the activation of a flag, most have a corresponding
flag. For example, if the anti-ice flag is activated, the corresponding anti-ice factor is
calculated—for example, .05 x (cruise fuel + descent fuel + hold fuel).

763
The following tables list the CADB ETOPS parameters and the flags and factors that affect
them.
NOTE See the ETOPS User’s Guide for more information on these parameters.
Click the User Manuals link on the JetPlan.com home page to access the ETOPS
User’s Guide and other manuals.
For information on ETOPS II, contact your Jeppesen account manager.
Table 27-14 CADB Record: “ETOPS” Section
Use ETOPS When set to Yes, JetPlan calculates ETOPS performance data based on the
(ED) parameter settings in the “ETOPS” section of the CADB. Otherwise,
calculations are based on the generic aircraft information or hard-coded ETOPS
ED or ED=
methodology tied to a specific format. The default input value is No.
ex. ED=Y
Cruise Mode Begin Flag NOTE In ETOPS II plans only, this parameter has been replaced by the
Scenario Options parameters in the Flight Brief Database. See the “Flight Brief
(CS)
Database” chapter in the JetPlan User Manual or the “Flight Brief Database” Help
CS or CS= topic on JetPlan.com.
ex. CS=1 Must be used in combination with the CE flag. Together, CS and CE allow you
to specify which of the ETOPS critical fuel scenarios the system computes: All-
Engine Depressurized or Engine-out Depressurized or both. The CE and CS
parameters must be set to either 1 or 2, or an error occurs.
Set the CS and CE parameters in the following manner to include the specific
cruise modes in the ETOPS calculation:
• CS=1 and CE=2 – Applies All-Engine Depressurized and Engine-out
Depressurized
• CS=1 and CE=1 – Applies All-Engine Depressurized only
• CS=2 and CE=2 – Applies Engine-out Depressurized only
Cruise Mode End Flag NOTE In ETOPS II plans only, this parameter has been replaced by the
Scenario Options parameters in the Flight Brief Database. See the “Flight Brief
(CE)
Database” chapter in the JetPlan User Manual or the “Flight Brief Database” Help
CE or CE= topic on JetPlan.com.
ex. CE=2 Must be used in combination with the Cruise Mode Begin (CS) flag. Together,
CS and CE allow you to specify which of the ETOPS critical fuel scenarios the
system computes: All-Engine Depressurized or Engine-out Depressurized or
both. The CE and CS parameters must be set to either 1 or 2, or an error occurs.
See the Cruise Mode Begin Flag (CS) above for examples of how to set the CS
and CE parameters.

764
Table 27-14 CADB Record: “ETOPS” Section (continued)
ETOP Approval Time Enables you to specify the approved ETOPS duration time for the aircraft. This
(ET) parameter can also be used as an AIR OPS compliance parameter. The value is
a time expressed in minutes, up to four digits. Example: 180
ET or ET=
ex. ET=180
Icing TEMP Threshold Enables you to specify a temperature that defines the threshold where anti-ice
(IT) performance calculations begin in an ETOPS flight plan. Example: -3
IT or IT= When temperatures encountered in the flight plan are at or above the IT value,
anti-ice calculations are applied (if defined). When temperatures dip below the
ex. IT=-3
IT value, ice drag calculations are applied (if defined).
To calculate both AI and ID, set AI=5CEI (percentage) or 1CEI (whole
number).
NOTE The value of this parameter is used in the calculation of a temperature-
based icing penalty in certain ETOPS II flight plans when the Temperature-Based
Icing Penalty parameter in the Flight Brief Database is set to On. For more
information, see the Flight Brief Database Help topic on JetPlan.com.
Ice Drag Flag Defines the application of the ice drag factor. The flag input value depends on
(ID) how you want to apply the ice drag factor.
ID or ID= Input value: Up to five alphanumeric characters. Enter the predefined flag code
followed by the situation code(s). Example: 1CEI
ex. ID=1CEI
Anti-Ice Flag Defines the application of the anti-ice factor (the formula defined by the AL or
(AI) AE parameter). The flag input value depends on how you want to apply the
anti-ice factor.
AI or AI=
• 1 = whole number
ex. AI=1CEN
• 5 = percentage
Input value: Up to five alphanumeric characters. Enter the predefined flag code
followed by the situation code(s). Example: 1CEN
Ice Drag LRC Factor Scenario: All-engine, depressurized

(IL) Defines the calculation used to determine the fuel calculation for ice drag in an
IL or IL= all-engine, low-level ETOPS plan.
ex. IL=P1600CDHM The factor input value depends on how you want to calculate ice drag fuel.
Enter an actual fuel burn value or percentage rate followed by the application
code(s). Example: P1600CDHM

765
Anti-Ice LRC Factor Scenario: All-engine, depressurized
(AL) Defines the calculation used to determine the fuel calculation for anti-ice
AL or AL= operations in an all-engine, low-level ETOPS plan.
ex. AL=P1000CDHM The factor input value depends on how you want to calculate anti-ice fuel. Enter
an actual fuel burn value or percentage rate followed by the application code(s).
Example: P1000CDHM
Ice Drag 1LE Factor Scenario: One engine-out, depressurized

(IE) Defines the calculation used to determine the fuel calculation for ice drag in a
IE or IE= one engine-out, low-level ETOPS plan.
ex. IE=P1700CDHM The factor input value depends on how you want to calculate ice drag fuel.
Anti-Ice 1LE Factor Scenario: One engine-out, depressurized

(AE) Defines the calculation used to determine the fuel calculation for anti-ice
AE or AE= operations in a one engine-out, low-level ETOPS plan.
ex. AE=P1200CDHM The factor input value depends on how you want to calculate anti-ice fuel. Enter
Example: P1200CDHM
Ice Drag 1LE Pressurized NOTE This parameter is used only with ETOPS II flight plan options. Contact
(Factor) your Jeppesen account manager for more information.
(IEP) Scenario: One engine-out, pressurized
Defines the calculation used to determine the fuel calculation for ice drag in a
one engine-out, low-level ETOPS plan.
The factor input value depends on how you want to calculate ice drag fuel.
Anti-Ice 1LE Pressurized NOTE This parameter is used only with ETOPS II flight plan options. Contact
(AEP)
Scenario: One engine-out, pressurized
Defines the calculation used to determine the fuel calculation for anti-ice
operations in a one engine-out, low-level ETOPS plan.
The factor input value depends on how you want to calculate anti-ice fuel. Enter
Example: P1200CDHM
Conservatism Flag Defines the application of the conservatism factor (the formula defined by the
(CF) CV parameter). The flag input value depends on how you want to apply the
conservatism factor. Enter the predefined flag code followed by the situational
CF or CF=
code(s). Example: 2CE
ex. CF=2CE

766
Conservatism Time Enables you to define the critical time for the ETOPS area. The value is used in
(TV) the conservatism fuel calculation and can be applied to the APU burn
calculation as well. Format specific. The input value is a time entry, in minutes.
TV or TV=
Example: 120
ex. TV=120
Conservatism Factor Defines the formula used to determine the fuel calculation for conservatism in
(CV) an ETOPS plan. The factor input value depends on how you want to calculate
conservatism fuel. Enter an actual fuel burn value or percentage rate followed
CV or CV=
by the application code(s). Example: P1000CDHM
ex. CV=P1000CDHM
Time Conservatism Factor Defines the formula used in the conservatism time calculation. Format specific.
(TR) The factor input value depends on how you want to calculate conservatism
time. Example: P1000CDAI
TR or TR=
ex. TR=P1000CDAI
Cruise Distance Flag Defines the application of the cruise distance factor (the formula defined by the
(CZ) CD parameter). The flag input value depends on how you want to apply the
cruise distance factor. Enter the predefined flag code followed by the initial
CZ or CZ=
descent distance. Example: 1D20
ex. CZ=1D20
Missed Approach Flag Defines the application of the missed approach (MAP) fuel burn. The flag input
(ML) value is either 1 or 0, with 1 activating the missed approach burn factor (MB).
Example: 1
ML or ML=
In JetPlan.com, the input value is On or Off.
ex. ML=1
Cruise Distance Factor Enables the inclusion of additional mileage in the cruise distance calculations.
(CD) The factor input value depends on how you want to calculate cruise distance.
Enter a distance (nm) to be added, followed by other inclusion code(s).
CD or CD=
Example: 20CD
ex. CD=20CD
Missed Approach Burn Enables you to specify a missed approach fuel burn amount. The input value is
(MB) an amount of fuel, in pounds or kilograms. Example: 2500
MB or MB=
ex. MB=2500
Auxiliary Power Unit Flag Defines the application of the auxiliary power unit (APU) fuel burn. The flag
(AP) input value depends on how you want to apply the APU burn factor (AU). Enter
the predefined flag code followed by the situation code(s). Example: 1CE
AP or AP=
ex. AP=1CE

767
Hold Flag Defines the application of the hold fuel burn. In JetPlan.com, when this option
(HL) is selected, the Hold Burn text box appears.
HL=1 (Time in minutes) JetPlan.com input options:
HL=2 (Fuel in pounds or • Time – Set hold burn to a time value in minutes.
kilograms) • Fuel – Set hold burn to a fuel amount value in pounds or kilograms
HL=0 (Ignore) • Ignore – Ignore any hold burn value
NOTE In JetPlan.com, you can choose Time, Fuel, or Ignore on the Edit
Aircraft Record page. Hold Flag=Time is recorded in the aircraft database
record as the HL=1, Hold Flag=Fuel is recorded as HL=2, and Hold Flag=Ignore
is recorded as HL=0. For this reason, the Aircraft Record summary page in
JetPlan.com displays 1, 2 or 0 for HL.
Hold Burn Factor Defines the time or fuel amount applied to the hold fuel calculation. In
(HB) JetPlan.com, the Hold Burn text box appears when the Hold Flag option is
selected. Depending on the selected hold flag value, the factor input value is
HB or HB=
either a time entry in minutes, or a fuel amount in pounds or kilograms.
ex. HB=15
Example: 15
APU Loaded Depressurized This parameter is used to calculate the Engine-Out Depressurized critical fuel
(AU) scenario. This parameter is populated with the loaded APU burn rate at FL100.
The burn rate is a percent or pounds/kilograms per hour value.
AU or AU=
Input values: The burn rate in percent or in lbs/kgs hour. Enter a percentage
ex. AU=320CDH
multiplier or an integer followed by the divert special flag code(s). Up to 16
alphanumeric characters are allowed. Example: 380CDH
APU Unloaded NOTE This parameter is used only with ETOPS II flight plan options. Contact
Depressurized (AZ) your Jeppesen account manager for more information.
This parameter is used to calculate the All Engine Depressurized critical fuel
scenario for aircraft that do not require the APU to be running while in ETOPS
airspace. This parameter is populated with the unloaded APU burn rate at
FL100. The burn rate is a percent or pounds/kilograms per hour value.
Input values: The burn rate in percent or in lbs/kgs hour. Enter a percentage
multiplier or an integer followed by the divert special flag code(s). Example:
380CDH
ISA Deviation Flag Defines the application of the ISA deviation fuel burn. The flag input value
(IS) depends on how you want to apply the ISA deviation burn factor (IB). Enter the
predefined flag code followed by the situation code(s). Example: 1CE
IS or IS=
ex. IS=1CE

768
APU Loaded Pressurized NOTE This parameter is used only with ETOPS II flight plan options. Contact
(Driftdown) your Jeppesen account manager for more information.
(AY) This parameter is used to calculate the Engine Out Pressurized and Engine-Out
Depressurized critical fuel scenario for aircraft that require the APU to be
running while in ETOPS airspace. This parameter is populated with the loaded
burn rate of the APU at a nominal driftdown flight level. The burn rate is a
percent or pounds/kilograms per hour value.
Input value: The burn rate in percent or in lbs/kgs hour. Enter percentage
multiplier or an integer or followed by the divert special flag code(s). Up to 16
alphanumeric characters are allowed.
ISA Deviation Burn Factor Defines the formula used to determine the fuel calculation for ISA deviation.
(IB) The factor input value depends on how you want to calculate ISA deviation
fuel. Enter an integer or percentage multiplier followed by the divert phase of
IB or IB=
flight code(s). Example: P300CDHM
ex. IB=P300CDHM
Early Arrival TAS Enables you to define the airspeed used in the Earliest Arrival Time calculation.
(ES1) The calculation applies to the determination of the forward divert (ETP)
airport’s weather suitability. Example: 465
ES1 or ES1=
ex. ES1=465
Late Arrival TAS Enables you to define the airspeed used in the Latest Arrival Time calculation.
(ES2) The calculation applies to the determination of the backward divert (ETP)
airport’s weather suitability. Example: 363
ES2 or ES2=
ex. ES2=363
Early Arrival Flight Level Enables you to define a fast speed altitude that corresponds to the Early Arrival
(ESA1) TAS and allows for more accurate weather sampling.
Default value: 100
Late Arrival Flight Level Enables you to define a slow speed altitude that corresponds to the Late Arrival
(ESA2) TAS and enables for more accurate weather sampling.
Default value: 100
Cargo Fire Suppression NOTE This parameter is used only with ETOPS II flight plan options. Contact
Time Limit your Jeppesen account manager for more information.
(FS) Enables you to specify the amount of cargo fire suppression time that is used by
JetPlan to compute the Time-Limited System compliance times for ETOPS
flights greater than 180 minutes.
Other Most Time-Limiting NOTE This parameter is used only with ETOPS II flight plan options. Contact
System Limit your Jeppesen account manager for more information.
(OS) Enables you to specify the amount of fire suppression time other than cargo fire
suppression that is used by JetPlan to compute the Time-Limited System
compliance times for ETOPS flights greater than 180 minutes.

769
Divert Time Flag Defines the flight segments from which diversion time is determined. The flag
(DV) input value depends on how you want to calculate divert time. Enter the
predefined flag code followed by the situational code(s). Example: 1CDH
DV or DV=
ex. DV=1CDH
Performance Bias Flag Enables you to apply a performance bias when Hold and Missed Approach
(PF) fuels are calculated. The input value is 1 (on) or 2 (off). Example: 1
PF or PF= In JetPlan.com, the input value is On or Off.
ex. PF=1 NOTE Use of this parameter is limited to specific customers.
ETOPS Flag and Factor Codes

The following tables list the flag and factor codes you use with the ETOPS parameters. Flag
codes can be entered in various combinations, depending on the type of performance factors
you want to affect. The first set of flag codes are the “activation” codes, which basically
instruct JetPlan to turn “on” or “off” the particular ETOPS control parameter. The second set
of flag codes are the “situation” codes, which instruct JetPlan to apply the factor formula when
a particular situation exists (for example—apply the formula during the LRC segment of the
ETOPS calculation, or apply when icing is present). Lastly, there are some special codes that
apply only to particular controls. All of the flag codes are shown in the following tables.

770
ETOPS Activation Flag Codes

The following activation flag codes instruct JetPlan to turn “on” or “off” a particular ETOPS
control parameter.
Table 27-15 ETOPS Activation Flag Code
Code Definition
0 (off) This code implies no application; this feature is turned “off.” For example, if the Ice Drag
Flag is set to 0, no fuel burn computations are performed for this particular control
parameter, whether you have a formula stored in the Ice Drag Factor parameter or not.
1 (on) This code is used if you want to activate the corresponding factor (formula). For example, if
the Cruise Flag is set to 1, then the corresponding Cruise Factor is calculated and added to
the ETOPS analysis. When a flag is turned “on”, the calculation made depends on the
formula you set in the corresponding factor field.
NOTE The following are special applications of the flag code 1:
- A Hold Flag set to 1 indicates that the Hold Value is a time entry.
- An ISA Flag set to 1 instructs JetPlan to add the ISA deviation burn (factor) for every 10
degrees of temperature increase above Standard ISA temperature.
2 (on) The flag code 2 applies only to certain controls. A Hold Flag set to 2 indicates that the Hold
Value is a weight entry. An ISA Flag set to 2 instructs JetPlan to add the ISA deviation burn
(factor) for every 5 degrees of temperature increase above Standard ISA temperature.

771
ETOPS Situation Flag Codes

The situation codes instruct JetPlan to apply the factor (formula) when a particular situation
exists—for example, the factor is applied when icing is present.
Table 27-16 ETOPS Situation Flag Codes
Code Definition
C This code instructs JetPlan to apply the factor (formula) to the LRC segment of the ETOPS
analysis.
D NOTE This code is used only with ETOPS II flight plan options. For more information,
This code instructs JetPlan to apply the factor (formula) to the engine-out pressurized
(driftdown) segment of the ETOPS analysis.
For example, adding the D code to the Auxiliary Power Unit Flag (AP) parameter indicates
that the APU burn is computed for the engine-out pressurized (driftdown) segment.
Example: AP=1CED
E This code instructs JetPlan to apply the factor (formula) to the 1LE segment of the ETOPS
analysis.
I This code instructs JetPlan to apply the factor (formula) to the ETOPS analysis when icing
is present.
N This code instructs JetPlan to apply the factor (formula) to the ETOPS analysis when icing
is not present.
NOTE If neither I nor N is specified, JetPlan applies both the ice drag and anti-ice
penalties simultaneously.

772
ETOPS Special Flag Codes
The following table lists the ETOPS special flag codes.
Table 27-17 ETOPS Special Flag Codes
Flag Special Code Explanation

Cruise Flag The Cruise Flag has an “initial descent distance” code, D which enables you to set the
distance, in nautical miles, to the initial descent point (for example, D20 indicates an initial
descent distance of 20 nautical miles).
Divert Flag The following codes apply to the Divert Flag only:
• The code, C, indicates that “cruise time” is included in the diversion time calculation.
• The code, D, indicates that descent time is included in the diversion time calculation.
You can also cut the descent time in half by entering D(/2).
• The code, H, indicates that hold time is included in the diversion time calculation. You
can also set the hold time to a specific number of minutes (for example, H(15) sets the
hold time to 15 minutes). The hold time can also be multiplied (for example, H(*2) sets
the hold time to twice its calculated value).
Example:
ID=1C – Demonstrates the combining of code parameters with an ETOPS Database flag. The
number “1” activates the factor formula, and the letter “C” applies the formula to the LRC
segment of the divert.

773
ETOPS Factor Code Definitions

Factors are the formulas applied to the divert “phase of flight” fuel burn numbers. They are
activated by the corresponding flag. The codes used for each factor vary, so factors that use the
same code nomenclature are grouped together for explanation.
The following factors use the same code nomenclature: Ice Drag LRC Factor, Ice Drag 1LE
Factor, Anti-Ice LRC Factor, Anti-Ice 1LE Factor, Conservatism Factor, Time Conservatism
Factor, and ISA (Deviation) Value. The codes for these factors are shown in the following
table.
Table 27-18 ETOPS Factor Codes
Code Definition
x Integer multiplier input. This value, when combined with the codes for the fuel burn phases
of flight (for example, cruise, descent, hold, and so on shown below in this table) is
multiplied by the calculated fuel burns to provide a fuel pad total for the flag entered.
For example, if you enter an Ice Drag LRC Factor of 2CDH, the calculated fuels for the
cruise, descent and hold (CDH) phases of the divert are doubled (CDH x 2) to provide the
fuel burn total for the Ice Drag Factor. The multiplier you enter needs to be a rather small
number, because the product fuel burn you produce can be a number so large as to exceed
the capabilities of the aircraft (the error “needs more burnable fuel” results).
Pxxx Percentage multiplier input. This value works in the same manner as the integer multiplier
explained above. However, in this case you are taking a percentage of the calculated fuel
burns.
For example, if you enter an Ice Drag LRC Factor of P1000CDH, the calculated fuels for the
cruise, descent, and hold phases of the divert are multiplied by 10% (CDH x .10) to provide
the fuel burn total for the Ice Drag Factor.
NOTE The percentage you wish to enter is multiplied by 100 to arrive at your input (for
example, 5% is entered as P500).
C Using this code includes the cruise fuel burn from the divert as part of the calculation. As
one of the elements that can be applied to the factor formula, this code is used in conjunction
with the integer or percentage multiplier.
D, D(/2) Using this code includes the descent fuel burn from the divert as part of the calculation. As
with the integer or percentage multiplier. The D(/2) entry halves the descent fuel in the
calculation.
H, H(xxx), Using this code includes the hold fuel burn from the divert as part of the calculation. As one
H(*2) of the elements that can be applied to the factor formula, this code is used in conjunction
with the integer or percentage multiplier. The H(xxx) entry sets the value of the hold fuel to
the number entered—for example, H(100) sets the hold fuel to 100 lbs/kgs. The H(*2) entry
doubles the hold fuel.
M Using this code includes the missed approach (MAP) fuel burn from the divert as part of the
calculation. As one of the elements that can be applied to the factor formula, this code is
used in conjunction with the integer or percentage multiplier.

774
Table 27-18 ETOPS Factor Codes (continued)
Code Definition
A Using this code includes the auxiliary power unit (APU) fuel burn from the divert as part of
the calculation. As one of the elements that can be applied to the factor formula, this code is
V Using this code includes the conservatism fuel burn from the divert as part of the
calculation. As one of the elements that can be applied to the factor formula, this code is
T Using this code includes the anti-ice fuel burn from the divert as part of the calculation. As
I Using this code includes the ice drag fuel burn from the divert as part of the calculation. As
Examples:
• IL=P200CD – Ice Drag LRC Factor. This factor calculates a fuel total based
on the product of 2% (P200) of the cruise (C) and descent (D) fuel figures
from the divert fuel totals.
• IE=2DMA – Ice Drag 1LE Factor. This factor calculates a fuel total based
on the product of 2 times the descent (D), MAP (M) and APU (A) fuel
figures from the divert fuel totals.
• AL=P100CDH(/2)MAT – Anti-Ice LRC Factor. This factor calculates a fuel
total based on the product of 1% (P100) of the cruise (C), descent (D), half
of the hold (H(/2)), MAP (M), APU (A), and anti-ice (T) fuel figures from
the divert fuel totals.
The following tables list the codes for the other factors individually. Some codes are the same
as above, and others differ from factor to factor. Examples are provided after each table.
Table 27-19 APU Burn Factor Codes
Code Definition
xx Integer multiplier input. See previous table.
Pxxx Percentage multiplier input. See previous table.
C Using this code includes the cruise time for the divert as part of the calculation.
D Using this code includes the descent time for the divert as part of the calculation.
H(xx) Using this code includes the hold time for the divert as part of the calculation (for example,
H(15) sets the hold time to 15 minutes).

775
Example:
5CD – APU burn is 5 times the cruise and descent time values.
Table 27-20 MAP Burn Factor Codes
Code Definition
xxx Enter the MAP burn value, in pounds or kilos (for example, the entry 150 sets the MAP burn
value to 150 lbs/kgs).
Example:
150 – MAP burn is 150 lbs/kgs.
Table 27-21 ETOPS Hold Burn Factor Codes
Code Definition
xxx Enter the hold burn value. This is a fuel weight entry (lbs/kgs) when the Hold Flag is set to
2, and a time entry (minutes) when the Hold Flag is set to 1.
Examples:
• 500 – Hold burn is set to 500 lbs/kgs when Hold Flag is set to 2.
• 15 – Hold burn is set to 15 minutes when Hold Flag is set to 1.
Table 27-22 ETOPS Cruise Distance Factor Codes
Code Definition
xx This input adds xx nautical miles to the cruise distance.
C This input includes the great circle (GC) distance to the cruise distance.
D This input subtracts the descent distance from the cruise distance.
H(xx) Using this code includes the hold time from the divert as part of the calculation (for
example, H(15) sets the hold time to 15 minutes).
Example:
20CD – Add 20nm to the cruise distance, plus the great circle distance (C), minus the descent
distance (D).

776
CADB Parameters: “Driftdown” Section

The “Driftdown” section supports the JetPlan feature, Terrain Analysis. Parameters set in this
section apply to the Terrain Clearance/Mountain Driftdown calculation. The “Driftdown”
section is not displayed in JetPlan.com unless you set the DD parameter in the
NOTE Parameters within the “Driftdown” section apply to Mountain Driftdown, not
Basic (Overwater) Driftdown (DRFT and DRFTX). Application is limited to those
customers that use the Mountain Driftdown feature.
Table 27-23 CADB Record: “Driftdown” Section
NOTE If you are using the JetPlan command-line interface, all Driftdown parameter entries must include an
equal sign (=) between the parameter code and the input value.
Driftdown-Climbout
Engine Out Climbout Anti- Scenario: Engine-out, anti-ice on

Ice On Enables you to set a divert climb airspeed for the climbout portion of the flight
(D11) under an engine-out, anti-ice on, driftdown scenario. The input value is the
D11= name of the table data available for the aircraft. Example: 1LE
ex. D11=1LE
Engine Out Climbout Anti- Scenario: Engine-out, anti-ice off

Ice Off Enables you to set a divert climb airspeed for the climbout portion of the flight
(D12) under an engine-out, anti-ice off, driftdown scenario.
D12= The input value is the name of the table data available for the aircraft. Example:
ex. D12=1LE 1LE
Engine Out Cruise Anti-Ice Scenario: Engine-out, anti-ice on

On Enables you to set a divert cruise airspeed for the climbout portion of the flight
(D13) under an engine-out, anti-ice on, driftdown scenario.
ex. D13=1LE 1LE
Engine Out Cruise Anti-Ice Scenario: Engine-out, anti-ice off

Off Enables you to set a divert cruise airspeed for the climbout portion of the flight
ex. D14=1LE 1LE

777
Table 27-23 CADB Record: “Driftdown” Section (continued)
Driftdown Descent Anti-Ice Scenario: Engine-out, anti-ice on
On Enables you to set a divert descent airspeed for the climbout portion of the
(D15) flight under an engine-out, anti-ice on, driftdown scenario.
ex. D15=3DO 3DO
Driftdown Descent Anti-Ice Scenario: Engine-out, anti-ice off

Off Enables you to set a divert descent airspeed for the climbout portion of the
(D16) flight under an engine-out, anti-ice off, driftdown scenario.
ex. D16=3DF 3DF
Driftdown-Enroute (Route Exclusive)
Engine Out Climbout Anti- Scenario: Engine-out, anti-ice on

Ice On Enables you to set a divert climb airspeed for the enroute portion of the flight
ex. D21=1LE 1LE
Engine Out Climbout Anti- Scenario: Engine-out, anti-ice off

Ice Off Enables you to set a divert climb airspeed for the enroute portion of the flight
ex. D22=1LE 1LE
Engine Out Cruise Anti-Ice Scenario: Engine-out, anti-ice on

On Enables you to set a divert cruise airspeed for the enroute portion of the flight
ex. D23=1LE 1LE
Engine Out Cruise Anti-Ice Scenario: Engine-out, anti-ice off

Off Enables you to set a divert cruise airspeed for the enroute portion of the flight
(D24) under an engine-out, anti-ice off, driftdown scenario. The input value is the
D24= name of the table data available for the aircraft. Example: 1LE
ex. D24=1LE
Driftdown Descent Anti-Ice Scenario: Engine-out, anti-ice on

On Enables you to set a divert descent airspeed for the enroute portion of the flight
(D25) under an engine-out, anti-ice on, driftdown scenario. The input value is the
D25= name of the table data available for the aircraft. Example: 3DO
ex. D25=3DO

778
Driftdown Descent Anti-Ice Scenario: Engine-out, anti-ice off
Off Enables you to set a divert descent airspeed for the enroute portion of the flight
(D26) under an engine-out, anti-ice off, driftdown scenario. The input value is the
D26= name of the table data available for the aircraft. Example: 3DF
ex. D26=3DF
Defaults
Takeoff Fuel Burn Enables you to define the fuel burned while maneuvering from rotation to
(D31) touchdown at the divert airport. The input value is a fuel amount, in pounds or
kilograms. Example: 500
D31=
ex. D31=500
Takeoff Time Enables you to define the time spent while maneuvering from rotation to
(D32) touchdown at the divert airport. The input value is a length of time, in minutes.
Example: 10
D32=
ex. D32=10
Takeoff Distance Enables you to define a specific takeoff distance. The input value is a distance,
(D33) in nautical miles. Example: 12
D33=
ex. D33=12
Approach Fuel Burn Enables you to define the fuel burned while maneuvering from overhead the
(D34) divert airport to touchdown. The input value is a fuel amount, in pounds or
kilograms. Example: 1000
D34=
ex. D34=1000
Approach Time Enables you to define the time spent while maneuvering from decision point to
(D35) touchdown at the divert airport. The input value is a length of time, in minutes.
Example: 5
D35=
ex. D35=5
Landing Table Enables you to define the table used to supply airspeed schedules. The input
(D36) value is a record name. The name cannot exceed 8 characters. Example:
filename
D36=
ex. D36=filename
Temperature Threshold Unavailable at this time.

(D41)
D41=
ex. D41=5

779
Driftdown Bias Enables you to set a driftdown bias for engine-out operations. The input value is
(D42) a percentage bias entry (for example, 16.9 = 16.9%). Example: 10.2
D42=
ex. D42=10.2
CADB Parameters: “Biases” Section

The “Biases” section contains parameters that allow you to set various flight biases.
Table 27-24 CADB Record: “Biases” Section
POD Biases Enables you to bias the departure (POD) for fuel, time, and distance. Each
(DB) factor can be set individually or in combination.
DB or DB= Input values:
ex. DB500,9,50 • Fuel in pounds
ex. DB=500,0,0 • Time in minutes
or • Distance in nautical miles
DBF Default value for each of the above: 0
DBT
DBD
ex. DBT9,DBF500,
DBD50
ex. DBT=9,DBF=500
Defer Departure Bias When set to Yes, enables you to defer departure bias inputs until the time the
(DBQ) flight plan is created.
DBQ or DBQ= Input values: Yes/No
ex. DBQ=Y

780
Table 27-24 CADB Record: “Biases” Section (continued)
POA Biases Enables you to bias the arrival (POA) for fuel, time, and distance. Each factor
(AB) can be set individually or in combination.
AB or AB= Input values:
ex. AB=300,0,25 • Fuel in pounds
or • Time in minutes
ABF or ABF= • Distance in nautical miles
ABT or ABT= Default value for each of the above: 0
ABD or ABD=
ex. ABF300,ABT8,ABD25
ex. ABT=10,ABF=500
Defer Arrival Bias When set to Yes, enables you to defer arrival bias inputs until the time the flight
(ABQ) plan is created.
ABQ or ABQ= Input values: Yes/No
ex. ABQ=Y
Altimeter Bias Enables you to define a bias adjustment for an altimeter that has a slight
(B11) deviation in its display.
B11= Input value: The known difference, in feet, between the aircraft’s instrument
reading and the actual reading. Example: 200
ex. B11=200
Airspeed Bias Enables you to define a bias adjustment for an airspeed indicator that has a
(B12) slight deviation in its display.
B12= Input value: The known difference, in knots, between the aircraft’s airspeed
indicator reading and the actual reading. Example: 20.
ex. B12=20
Fuel Quantity Bias Enables you to define a bias adjustment for a fuel gauge that has a slight
(B13) deviation in its display.
B13= Input value: The known difference, in pounds, between the aircraft’s fuel gauge
reading and the actual reading. Example: 2400
ex. B13=2400
Payload Pad (less than 800 Enables you to define a bias adjustment for last minute additions in passengers
NM flight) and cargo for flights that are less than 800 nautical miles.
(P0) Input value: Weight in pounds. Example: 7500
P0= NOTE Use of this parameter is limited to specific customers.
ex. P0=7500

781
Table 27-24 CADB Record: “Biases” Section (continued)
Payload Pad (more than 800 Enables you to define a bias adjustment for last minute additions in passengers
NM flight) and cargo for flights that are more than 800 nautical miles.
(P8) Input value: Weight in pounds. Example: 1000
P8= NOTE Use of this parameter is limited to specific customers.
ex. P8=1000
CADB Parameters: “Special Bias Modifications”

Section
You might see the following section at the end of a CADB record summary (after the Biases
parameters): Contact JetPlan Customer Service for Modification of the Following Data.
The biases listed in this section can only be modified by Jeppesen. They include:
• Cruise Mode Biases – For fuel flow and true airspeed
NOTE Fuel flow biases may not exceed a 35% increase or decrease of the stored
table value.
• Climb Biases – For fuel, distance, and time

• Descent Biases – For fuel, distance, and time
• Alternate Biases – For divert fuel, distance, and time
NOTE Use of these biases is considered a permanent modification to your aircraft

record. Contact your Jeppesen account manager or the JetPlan Global Support and
Control Center (GSCC) to learn more about permanently biasing your CADB records.

782
CADB Parameters: “ICAO 2012 Certification and

Equipment” Section
format occurred on November 14, 2012. All flight plans filed with Jeppesen flight
planning products are now filed in the ICAO 2012 format by default.

How the CADB Supports the ICAO 2012 Filed Flight Plan
Format
The “ICAO 2012 Certification and Equipment” section in the CADB contains data elements
that support the changes implemented for ICAO 2012 flight plan filings. These changes and
the new CADB parameters are summarized in the following paragraphs. For detailed
definitions and input values, see “CADB Record: “ICAO 2012” Section” on page 789.
New Item 10a/b You can select new codes for communication and navigation
EQUIPMENT equipment and capabilities. JetPlan automatically inserts the selected
Parameter (NC2) 10a codes before the “/” indicator in Item 10a/b EQUIPMENT on the
and Codes flight plan filing strip.
You can also select new codes for surveillance equipment and
capabilities. JetPlan automatically inserts the 10b codes after the “/”
indicator in Item 10a/b EQUIPMENT on the flight plan filing strip.
R - PBN Certified The new PBN Certified parameter enables you to indicate whether or
Parameter not the aircraft has Performance Based Navigation (PBN)
capabilities. When the PBN Certified (I1) parameter is set to “Yes,”
JetPlan inserts an “R” in Item 10a on the filing strip.
New or Revised The following new or revised Item 18 indicator parameters are
Item 18 Indicators available. When an Item 18 indicator parameter is populated in the
and Definitions aircraft record, JetPlan inserts the stored value in Item 18 on the filing
strip:

783
• Item 18 PBN/ – Enables you to select ICAO codes for the

aircraft's PBN capabilities. JetPlan inserts your selected codes
as a single, concatenated string in Item 18 PBN/.
• Item 18 COM/ – Enables you to specify communications
applications or capabilities not listed in Item 10a.
• Item 18 DAT/ – Enables you to specify data capabilities not
• Item 18 SUR/ – Enables you to specify surveillance
application/capability not specified in Item10b.
• Item 18 CODE/ – Enables you to enter the aircraft address.
Item 18 indicators must be filed in a prescribed order per the

Fifteenth Edition (PANS-ATM, DOC 4444).” When an Item 18
indicator parameter is populated in the CADB, JetPlan automatically
inserts the stored value in Item 18 on the filing strip in the required
order.
New links between Several links between Item 10a and Item 18 apply, as follows:
Item 10a/b and
Item 18 • R (PBN Certified) and Item 18 PBN/ – When “R” is in Item
10a on the filing strip (the PBN Certified parameter is set to
“Yes” in the aircraft record), PBN levels must be specified in
Item 18 PBN/ and vice versa. Otherwise, the flight plan might
be rejected.
The Item 18 PBN/ parameter enables you to store the required

data for insertion into Item 18 on the filing strip.

784
• Specific Associations Between Item 18 PBN/ and Item 10a –

The following table lists specific associations that exist between
Item 10a codes and descriptors in Item 18 PBN/.
Table 27-25 Links Between Item 18 PBN/ and Item 10a
For Item 18 PBN If Item 18 PBN/

RNAV entry includes Then Item 10a
Specification: any/all of these: requires:
GNSS B1, B2, C1, C2, D1, G
D2, O1, O2
DME/DME B1, B3, C1, C3, D1, D

D3, O1, O3
VOR/DME B1, B4 OD or SD
INS B1, B5 I
DME/DME/IRU C1, C4, D1, D4, O1, DI

O4
LORAN B6 C
• G (GNSS) and Item 18 NAV/ – When “G” is in Item 10a on

the filing strip, the type of external GNSS augmentation, if any,
must be specified in Item 18 NAV/.
The Other Equipment (OE) parameter in the “ATS Plan”

section of the CADB enables you to store the GNSS
augmentation information for insertion into Item 18 NAV/ on
the filing strip.
• Z (Other Equipment) and Item 18 COM/, NAV/, or DAT/ –
When “Z” is in Item 10a, equipment or capabilities that are not
specified in Item 10a must be specified in Item 18, preceded by
COM/, NAV/, or DAT/.
The Item 18 COM/ and Item 18 DAT/ parameters allow you to

store data for insertion into Item 18 on the filing strip. The
Other Equipment (OE) parameter in the “ATS Plan” section of
the CADB enables you to specify the data for insertion into
Item 18 NAV/ on the filing strip.

785
Related Customer Database Changes for ICAO 2012

The following section describes customer database changes related to ICAO 2012.
Flight Brief Parameters in the Flight Brief Database allow you to automatically
Database apply the Item 18 Special Handling (STS/) and 18 Originator
(ORGN/) parameters to specified flights, auto populating the filing
strip. For more information, see the Help topic for the Flight Brief
Database on JetPlan.com or the “Flight Brief Database” chapter in the
MEL Database Parameters have been added to the MEL Database to degrade the
following ICAO 2012–specific parameters in the “ICAO 2012
Certification and Equipment” section of the CADB:
• 10a/b EQUIPMENT
• Item 18 COM/
• Item 18 PBN/
• Item 18 SUR/
• Item 18 CODE/
For more information, see the Help topic for the MEL Database on
JetPlan.com or the “Minimum Equipment List” chapter in the JetPlan
User Manual.
Before Using the ICAO 2012 CADB Parameters

Before using the ICAO 2012 parameters or filing ICAO 2012 flight plans, be aware of the
following guidelines:
• You must configure your CADB with ICAO 2012 parameters to file ICAO
2012 flight plans using Jeppesen’s flight planning products. The ICAO 2012
FPL is pre-populated with this data.
• If your CADB is not configured correctly for ICAO 2012, your flight plans
might fail or be rejected. For information on setting up the CADB, see the
following sections.

786
• See “Reducing the Likelihood of Flight Plan Rejects” on page 787 and
individual parameter definitions in “CADB Parameters: “ICAO 2012
Certification and Equipment” Section” on page 783 for important notes and
cautions.
Reducing the Likelihood of Flight Plan Rejects

To reduce the likelihood of ATC rejections of flight plans due to incorrect entry of ICAO 2012
data, follow these guidelines:
• Ensure that when the PBN Certified (I1) parameter is set to “Yes,” PBN
levels are specified for the Item 18 PBN/ (I2) parameter.
• Manage the other dependencies between Item 10a EQUIPMENT and Item
18 PBN/ described in “How the CADB Supports the ICAO 2012 Filed
Flight Plan Format” on page 783.
• Enter no more than eight PBN codes in the PBN/ parameter.
• Enter only numbers and letters for the ICAO 2012 parameters. See “CADB
Parameters: ICAO 2012 Certification and Equipment Section” on page 788
for information on entering data in the ICAO 2012 database fields.
• Enter ICAO 2012-specific data only in the designated ICAO 2012 database
fields. For example, enter Item 18 PBN/ information only in the Item 18
PBN/ (I2) parameter in the “ICAO 2012 Certification and Equipment”
section.
• Do not enter ICAO 2012 Item 18 RMK/ information in the Other Equipment
(OE) parameter in the “ATS Plan” section. Use the Flight Brief Database to
set up an “A” Flight Brief type that uses the Flight Brief Text parameter to
output Item 18 RMK information.
• Do not enter any of the Item 18 indicators themselves in any database field.
The indicators are the following terms: NAV/, PBN/, COM/, DAT/, SUR/,
CODE/, PER/, STS/, ORGN/. For example, in the Item 18 CODE/ (I6) field,
do not enter “CODE” or “CODE/” followed by the input value. Enter only
the input value for the field. Example: F00001

787
CADB Parameters: ICAO 2012 Certification and Equipment

Section
NOTE This section assumes you use JetPlan.com to maintain the CADB.
IMPORTANT The table in this section provides high-level information. For detailed
information on ICAO 2012 changes, requirements, and data, see the “Procedures for
DOC 4444).”
See also “How the CADB Supports the ICAO 2012 Filed Flight Plan Format” on
page 783 and “Reducing the Likelihood of Flight Plan Rejects” on page 787.
The following table lists the parameters in the “ICAO 2012 Certification and Equipment”
section of the CADB. As you perform database tasks, consult this table for information.

788
Table 27-26 CADB Record: “ICAO 2012” Section
10a/b EQUIPMENT Parameter
(NC2)
In JetPlan.com, the 10a Equipment codes and the 10b Surveillance Equipment codes are entered in separate
areas on the CADB ICAO 2012 page. However, the 10a and 10b codes are stored together in the Aircraft
database record as the value of the 10a/b EQUIPMENT (NC2) parameter. Based on your selections on the
Change ICAO 2012 in Aircraft Record page in JetPlan.com, JetPlan automatically inserts the 10a codes
before the / indicator and the 10b codes after the / indicator in Item 10a/b EQUIPMENT on the flight plan filing
strip.
Example:
ABCDHJ2KM2RT/CHU2
NOTE If the plan is sent to an AFTN (Aeronautical Fixed Telecommunication Network) center, the 10a/b
EQUIPMENT parameter is limited to the first 69 characters (including the “/” indicator), even though you can enter
82 characters for the parameter value in the CADB record.
NOTE The application of a degradation to the Item 10a/b EQUIPMENT parameter in the ICAO 2012 section of
the MEL Database overrides the 10a/b EQUIPMENT parameter value in the CADB and removes the CADB output
from Item 10/a in the ICAO filing strip. For more information, see the Help topic for the MEL Database in
JetPlan.com or the “Minimum Equipment Database” chapter in the JetPlan User Manual.
10a Equipment Enables you to add ICAO 2012 codes for Item 10a/ to the aircraft record. 10a
NOTE The values for 10a
codes are for radio communication (COM) equipment, navigation (NAV)
Equipment and for 10b equipment, and approach aids. You can make multiple selections on the
Surveillance Equipment Change ICAO 2012 in Aircraft Record page. JetPlan inserts your selected
together constitute the value 10a codes as a single, concatenated string before the “/” indicator in Item 10a/b
of the NC2 parameter in the EQUIPMENT on the flight plan filing strip.
Aircraft record. Example:
ABCDHJ2KM2RT/CHU2
Input options:
• N - No Std Equip
Indicates that no COM/NAV/approach aid equipment for the route to be
flown is carried or that the equipment is unserviceable. If you select N -
No Std Equip, none of the 10a Equipment codes are available for selection
on the CADB ICAO 2012 page. Code “N” is automatically inserted into
Item 10a on the filing strip.

789
Table 27-26 CADB Record: “ICAO 2012” Section (continued)
10a Equipment (continued) • S - Standard Equip
Indicates that standard COM/NAV/approach aid equipment for the route
to be flown is carried and serviceable. If code “S” is used, standard
equipment is considered to be VHF RTF,VOR and ILS. Code “S” is
automatically inserted into Item 10a/b EQUIPMENT on the flight plan
filing strip. You can also select additional equipment codes (see 10a
Equipment codes below) for insertion into Item 10a.
When you select S - Standard Equip, the following equipment codes are
not available for selection on the CADB ICAO 2012 page in JetPlan.com.
- L - ILS
- O - VOR
- V - VHF
• Edit Standard Equipment

When you select Edit Standard Equipment, the following equipment codes
are automatically selected on the CADB ICAO 2012 page but are also
available for editing:
- L - ILS
- O - VOR
- V - VHF
You can also select additional equipment codes (see 10a Equipment codes
on below) for insertion into Item 10a in the filing strip.
NOTE Code “S” or code “O” is required in Item 10a when Item 18 PBN/
contains certain descriptors. See “New links between Item 10a/b and Item 18” on
page 784.
10a Equipment Codes

If you choose S - Standard Equip or Edit Standard Equipment for 10a
Equipment, you can also select additional equipment codes that you want to use
on the flight plan filing strip.
The equipment codes for Item 10a are listed below:
• A - GBAS
Stands for the GBAS landing system
• B - LPV
Stands for LPV (APV with SBAS)
• C - LORAN C
NOTE “C” is required in Item 10a when Item 18 PBN/ contains certain
descriptors. See “New links between Item 10a/b and Item 18” on page 784.
• D - DME
NOTE “D” is required in Item 10a when Item 18 PBN/ contains certain
descriptors. See “Links Between Item 18 PBN/ and Item 10a” on page 785.

790
10a Equipment (continued) • E1 - FMC WPR ACARS
• E2 - D FIS ACARS
• E3 - PDC ACARS
• F - ADF
• G - GNSS
NOTE “G” is required in Item 10a when Item 18 PBN/ contains certain
descriptors.
When “G” is in Item 10a, additional types of external augmentation, if any, are
specified in item 18 following NAV/ and separated by a space. You can use the
Other Equipment (OE) parameter in the “ATS Plan” section of the CADB to save
the GNSS augmentation information. JetPlan automatically inserts the
augmentation information in Item 18 NAV/ on the filing strip. See the Other
Equipment (OE) parameter in the “CADB Parameters: “ATS Plan” Section” on
page 752. See also “New links between Item 10a/b and Item 18” on page 784.
• H - HF RTF
• I - Inertial Navigation
NOTE “I” is required in Item 10a when Item 18 PBN/ contains certain
• J1 - CPDLC ATN VDL Mode 2
• J2 - CPDLC FANS 1/A HFDL
• J3 - CPDLC FANS 1/A VDL Mode A
• J4 - CPDLC FANS 1/A VDL Mode 2
• J5 - CPDLC FANS 1/A SATCOM (INM)
• J6 - CPDLC FANS 1/A SATCOM (MTS)
• J7 - CPDLC FANS 1/A SATCOM (IRID)
• K - MLS
• L - ILS
NOTE L - ILS is selected by default if you have chosen S - Standard Equip for
the 10a Equipment option.
• M1 - ATC RTF SATCOM (INMARSAT)
• M2 - ATC RTF (MTSAT)
• M3 - ATC RTF (Iridium)

791
10a Equipment (continued) • O - VOR
NOTE O - VOR is selected by default if you have chosen S - Standard Equip for
the 10a Equipment parameter.
NOTE “O” is required in Item 10a when Item 18 PBN/ contains certain
• Required Communication Performance (RCP):
- P1
- P2 - Required for North Atlantic Performance-Based Communications

and Surveillance
- P3
- P4
- P5
- P6
- P7
- P8
- P9
• R - See “R - PBN Certified” below.

NOTE This code is required in Item 10a when Item 18 PBN/ contains certain
• S - See “S - Standard Equip” above.
• T - TACAN
• U - UHF RTF
• V - VHF RTF
NOTE V - VHF RTF is selected by default if you have chosen S - Standard
Equip for the 10a Equipment parameter.
• W - This code is not included in the “ICAO 2012 Certification and

Equipment” section of the CADB. Code “W” is inserted in Item 10a of the
filing strip when the RVSM Certified (RV) parameter is set to “Yes” in the
“Certified” section of the CADB. See the RVSM (RV) parameter in
“CADB Parameters: “Certified” Section” on page 749.
• X - This code is not included in the “ICAO 2012 Certification and
Equipment” section of the CADB. Code “X” is inserted in Item 10a of the
filing strip when the NAT HLA Equipped (ME) parameter is set to “Yes”
in the “Certified” section of the CADB. See the NAT HLA Equipped
(ME) parameter in “CADB Parameters: “Certified” Section” on page 749.

792
10a Equipment (continued) • Y - This code is not included in the “ICAO 2012 Certification and
Equipment” section of the CADB. Code “Y” is inserted in Item 10a of the
filing strip when the 8.33 KHz Communication (83) parameter is set to
“Yes” in the “Equipment” section of the CADB. See the 8.33 KHz
Communication (83) parameter in “CADB Parameters: “Equipment”
Section” on page 744.
• Z - Other Equipment Carried

If you select code “Z,” you also must specify the other equipment carried
or other capabilities in Item 18, preceded by COM/, NAV/, or DAT/, as
appropriate. See “New links between Item 10a/b and Item 18” on
page 784.
For NAV/ equipment and capabilities, you can specify the information in
the Other Equipment (OE) parameter in the “ATS Plan” section of the
CADB. JetPlan automatically inserts the information in Item 18 NAV/ on
the filing strip.
“Z” is automatically inserted into Item 10a on the filing strip if the Other
Equipment (OE) parameter in the “ATS” section of the CADB is
populated. See the Other Equipment (OE) parameter in the “CADB
Parameters: “ATS Plan” Section” on page 752.
Item 18 COM/ Enables you to specify additional communications applications or capabilities

(I3) for the aircraft that are not covered by the codes for Item 10a.
Input value: Up to 100 alphanumeric characters if needed. However,
EUROCONTROL accepts only 50 characters.
When “Z” is in Item 10a, you also must specify the other equipment carried or
other capabilities in Item 18, preceded by COM/, NAV/, or DAT/, as
appropriate. See “New links between Item 10a/b and Item 18” on page 784.
NOTE “Z “is automatically inserted in 10a if the Other Equipment (OE)
parameter in the “ATS Plan” section of the CADB is populated.
NOTE If the 8.33 KHz Communication (83) parameter is set to “Permit (P)” or
“Exempt (E)” in the “Equipment” section of the CADB, EXM833 is inserted in Item
18 COM/.
NOTE ANSP/ Air Services Australia indicates satcom phone numbers can be
entered here. No special characters are allowed. Example: 8889993123
NOTE Do not use any special characters, including a slash (/) or a hyphen (-)
in any Item18 text. Doing so might result in rejected flight plan filings.
NOTE The application of an override to the Item 18 COM/ parameter in the
“ICAO 2012” area of the MEL Database overrides the Item 18 COM/ parameter
value in the CADB and removes the CADB value from Item 18 COM/ in the ICAO
filing strip. For more information, see the Help topic for the MEL Database in
JetPlan.com or the “Minimum Equipment List Database” chapter in the JetPlan
User Manual.

793
Item 18 DAT/ Enables you to specify additional data applications or capabilities for the
(I4) aircraft that are not covered by the codes for Item 10a.
If you select code “Z,” you also must specify the other equipment carried or
other capabilities in Item 18, preceded by COM/, NAV/, or DAT/, as
appropriate. See “New links between Item 10a/b and Item 18” on page 784.
Item 18 NAV/ Navigation equipment

Significant data related to navigation equipment, other than specified in PBN/
as required by the appropriate ATS authority.
This field is automatically populated from the Other Equipment (OE) parameter
in the “ATS Plan” section of the CADB. See “CADB Parameters: “ATS Plan”
Section” on page 752. See also “Z - Other Equipment Carried” above.
If a “Z” is in Item 10a, the other equipment or other capabilities must be
specified in Item 18, preceded by COM/, NAV/, or DAT/, as appropriate. When
“G” is in Item 10a, additional types of external augmentation, if any, can be
specified in Item 18 following NAV/ and separated by a space. See “New links
between Item 10a/b and Item 18” on page 784.
R - PBN Certified NOTE See also the definition for the RNP Certified parameter in Table 27-11 on
page 749.
(I1)
Enables you to indicate whether or not the aircraft has Performance Based
Navigation (PBN) capabilities. When you select Yes, JetPlan automatically
inserts an “R” before the “/” indicator in item 10a/b EQUIPMENT on the flight
plan filing strip.
In addition, when the PBN Certified parameter is set to “Yes,” the PBN levels
must be specified after the PBN/ indicator in Item 18. Otherwise, the flight plan
might be rejected. See “Item 18 PBN/” below and “New links between Item
10a/b and Item 18” on page 784. See the Performance-Based Navigation
Manual (ICAO Doc 9613) for guidance on application of PBN levels.
NOTE The application of a degradation to PBN certification in the ICAO 2012
section of the MEL Database overrides the R - PBN Certified value in the CADB
and removes the “R” designator from Item 10a in the ICAO filing strip. For more
information, see the Help topic for the MEL Database in JetPlan.com or
“Minimum Equipment Database” chapter in the JetPlan User Manual.

794
Item 18 PBN/ IMPORTANT When the PBN Certified (I1) parameter is set to “Yes” in the
aircraft record, the PBN levels must also be specified in the PBN/ indicator in
(I2)
Item 18. Otherwise, the flight plan might be rejected. See “New links between
Item 10a/b and Item 18” on page 784.
IMPORTANT The current ICAO limit is eight PBN codes (16 characters) in the
PBN/ indicator. If the allowed maximum (currently eight codes) is exceeded, your
flight plans might be rejected.
This parameter enables you to identify the aircraft's Performance Based
Navigation (PBN) capabilities. If the aircraft has Area Navigation (RNAV) or
Required Navigation Performance (RNP) capabilities, they must be described
in Item 18 PBN/, using only the codes listed below. You can make multiple
selections, and JetPlan inserts your selected codes as a single, concatenated
string in Item 18 PBN/ on the flight plan filing strip.
Example: A1B2C2D2LIS1T204
NOTE The number of allowed codes (currently eight) might change in the
future. Therefore, there is no limit in the CADB to the number of codes you can
select. It is your responsibility to ensure that the number of selected codes
complies with the current ICAO 4444 Amendment.
NOTE The application of a degradation to the Item 18 PBN/ parameter in the
ICAO 2012 section of the MEL Database overrides the PBN/ parameter value in
the CADB and removes the CADB output from Item 18 PBN/ in the ICAO filing
JetPlan.com or the “Minimum Equipment Database” chapter in the JetPlan User
Manual.
Input value: Item 18 PBN/ input options are restricted to a total of eight codes
(16 characters) from the following lists of RNAV and RNP Certification codes.
PBN/ RNAV Specification Codes:
• A1 - RNAV 10 (RNP 10)
• B1 - RNAV 5 All Permitted Sensors

NOTE ICAO guidance indicates usage of B1 is acceptable even when you have
all sensors except LORANC.
• B2 - RNAV 5 GNSS
• B3 - RNAV 5 DME/DME
• B4 - RNAV 5 VOR/DME
• B5 - RNAV 5 INS or IRS
• B6 - RNAV 5 LORANC
• C1 - RNAV 2 All Permitted Sensors
• C2 - RNAV 2 GNSS
• C3 - RNAV 2 DME/DME

795
Item 18 PBN/ (continued) • C4 - RNAV 2 DME/DME/IRU
• D1 - RNAV 1 All Permitted Sensors
• D2 - RNAV 1 GNSS
• D3 - RNAV 1 DME/DME
• D4 - RNAV 1 DME/DME/IRU
PBN/ RNP Specification Codes:
• L1 - RNP 4
• O1 - RNP 1 All Permitted Sensors
• O2 - Basic RNP 1 GNSS
• O3 - Basic RNP 1 DME/DME
• O4 - Basic RNP 1 DME/DME/IRU
• S1 - RNP APCH
• S2 - RNP APCH with BARO-VNAV
• T1 - RNP AR APCH with RF

Requires special authorization.
• T2 - RNP AR APCH without RF

Requires special authorization.
10b Surveillance Enables you to add ICAO 2012 codes for Item 10b/ to the aircraft record. 10b
Equipment codes are for surveillance equipment and capabilities. You can make multiple
NOTE The values for 10a
selections. JetPlan inserts your selected 10b codes as a single, concatenated
Equipment and 10b string after the “/” indicator in Item 10a/b EQUIPMENT on the flight plan
Surveillance Equipment filing strip.
together constitute the value Example:
of the NC2 parameter in the
Aircraft record.
ABCDHJ2KM2RT/CHU2
Input options: Item 10b input options are restricted to codes selected from the
following lists of transponder and ADS codes.
NOTE The maximum number of characters allowed by the ICAO for 10b is 20.
Equipment 10b Transponder Codes

NOTE Only one transponder code can be selected.
• None – Select if no surveillance equipment for the route to be flown is

carried, or the equipment is unserviceable. If you select None, no 10b
Surveillance Equipment codes are available for selection on the CADB
ICAO 2012 page.
• A - Mode A (4 digits - 4 096 codes)

796
10b Surveillance • C - Mode A and C
Equipment (continued) Stands for Mode A (4 digits - 4 096 codes) and Mode C
• E - Mode S, including Aircraft Identification, Pressure-Altitude and

Extended Squitter (ADS-B) Capability
• H - Mode S, including Aircraft Identification, Pressure-Altitude and

Enhanced Surveillance Capability
• I - Mode S, including Aircraft Identification, but no Pressure-Altitude

Capability
• L - Mode S, including Aircraft Identification, Pressure-Altitude, Extended

Squitter (ADS-B) and Enhanced Surveillance Capability
• P - Mode S, including Pressure-Altitude, but no Aircraft Identification

Capability
• S - Mode S, including both Pressure-Altitude and Aircraft Identification

Capability
• X - Mode S with neither Aircraft Identification nor Pressure-Altitude

Capability
Equipment 10b ADS Codes

NOTE Only one type of each ADS-B code is used: B1 or B2, U1 or U2, V1 or
V2.
• B1 - ADS-B with dedicated 1090 MHz ADS-B “out” Capability
• B2 - ADB-B with dedicated 1090 MHz ADS-B “out” and “in” Capability
• U1 - ADS-B “out” Capability using UAT
• U2 - ADS-B “out” and “in” Capability using UAT
• V1 - ADS-B “out” Capability using VDL Mode 4
• V2 - ADS-B “out” and “in” Capability using VDL Mode 4
• D1 - ADS-C with FANS 1/A Capabilities
• G1 - ADS-C with ATN Capabilities

797
Item 18 SUR/ Enables you to enter surveillance applications or capabilities for the aircraft that
(I5) are not covered by the codes for Item 10b.
NOTE Per the FAA Aeronautical Information Manual, “SUR/ indicates
surveillance capabilities not specified in 10b, when requested by an Air
Navigation Service Provider. If ADS-B capability filed in Item 10 is compliant
with RTCA DO-260B, include the item 260B in SUR/. If ADS-B capability
filed in Item 10 is compliant with RTCA DO-282B, include the item 282B in
SUR/.”
EXAMPLE:
1. SUR/260B
2. SUR/260B 282B
For the latest FAA information on the above requirement, see the Aeronautical
Information Manual on the FAA Web site.Do not use any special characters,
including a slash (/) or a hyphen (-) in any Item18 text. Doing so might result in
rejected flight plan filings.
NOTE The application of an override to the Item 18 SUR/ parameter in the
ICAO 2012 section of the MEL Database overrides the Item 18 SUR/ parameter
value in the CADB and removes the output from Item 18 SUR/ in the ICAO filing
User Manual.
Item 18 CODE/ Enables you to enter the aircraft address for the aircraft, expressed in the form
(I6) of an alphanumerical code of six hexadecimal characters (as prescribed by the
appropriate ATS authority). For example, F00001 is the lowest aircraft address
contained in the specific block administered by ICAO.
Input value: Alphanumeric code of six hexadecimal characters
NOTE The application of an override to the Item 18 CODE/ parameter in the
ICAO 2012 section of the MEL Database overrides the Item 18 CODE/ parameter
value in the CADB and removes the output from Item 18 CODE/ in the ICAO filing
User Manual.

798
Item 18 PER/ Enables you to enter aircraft performance data as prescribed by the appropriate
(I7) ATS authority. The data is indicated by a single letter as specified in the ICAO
document: Procedures for Air Navigation Services — Aircraft Operations
(PANS-OPS, Doc 8168), Volume I — Flight Procedures.
Input value: One (1) alphanumeric character only. Permissible values are: A, B,
C, D, E, or H. May be left blank.
NOTE The application of an override to the Item 18 PER/ parameter in the
ICAO 2012 section of the MEL Database overrides the Item 18 PER/ parameter
value in the CADB and removes the output from Item 18 PER/ in the ICAO filing
User Manual.
Item 18 STS/ Item 18 Special Handling (STS/) parameters are not included in the “ICAO
2012 Certification and Equipment” section of the CADB. Instead, Item 18 STS/
values can be stored in a Flight Brief Database record and applied to flight
plans according to filtering criteria you have established in the same record. For
more information, see the Help topic for the Flight Brief Database on
JetPlan.com, or see the “Flight Brief Database” chapter in the JetPlan User
Manual.
NOTE JetPlan automatically adds STS/NONRVSM to Item 18 of the ICAO
2012 FPL format when the RVSM parameter in the CADB is set to Exempt.
Item 18 ORGN/ The Item 18 Originator (ORGN/) parameter is not included in the “ICAO 2012
Certification and Equipment” section of the CADB. Instead, Item 18 ORGN/
values can be stored in a Flight Brief Database record and applied to flight
plans according to filtering criteria you have established in the same record. For
more information, see the Help topic for the Flight Brief Database on
JetPlan.com, or see the “Flight Brief Database” chapter in the JetPlan User
Manual.

799
Database Management
Database Management
NOTE This section covers using the JetPlan command line interface to manage this
database. However, JetPlan.com is the recommended interface for managing the
customer databases. See the JetPlan.com Help file for detailed information.
Using JetPlan to Manage the Database

To make the CADB a data resource for flight planning, you must first create and manage
records of information in the database. To do this, you need to access the database. The CADB
access command is AC, and it is entered on the Options command line. Any attempt to affect
or reference the information in the database must begin with this command.
NOTE Use of the CADB is intended for the customer’s control and management.
You (the customer or company) can define who, within your organization, manages
the information stored in the CADB. Jeppesen, upon request, can assign extra
passwords specifically intended for database management. Contact your Jeppesen
account manager for more information.
The access command always precedes a function command. Function commands are those
inputs that instruct JetPlan to store, change, delete, or display information in the database. The
CADB function commands are divided into categories: file maintenance and file display.
These categories are listed below with the respective functions.
File Maintenance
• SAV – Creates a new record
• CHG – Modifies an existing record
• DEL – Deletes an existing record
• CPY – Copies the data of one record to another record
• REN – Renames an existing record

800
Database Management
File Display
• PRI – Displays the record
• SUM – Displays a list of records in the database
NOTE The CADB access command has several more function commands, but
these functions apply to the display of generic aircraft data. For more information see
the “Aircraft Type Commands” chapter in the JetPlan User Manual.
The records you affect in the database are referenced by record name. Record names are two-
to-eight (2-8) character inputs of your choosing.
NOTE You can choose to use the aircraft's registration number (or tail number) as
the aircraft record name. Note, however, that although registration numbers can
exceed eight characters, the aircraft record name cannot.
In most cases, the record name input immediately follows the access code and function
command. One time this is not true is when you first create a new record. In this case, the ID
of the generic aircraft you wish to save as a record in the database must precede the record
name (it is entered between the function command and the record name). Hence, the input
structure of a CADB command that creates a new record has the following syntax:
AC,function command,genericID,filename,parameter 1,parameter

2,parameter 3
In most other cases, the input structure of a CADB command has the syntax:
AC,function command,filename,parameter 1,parameter 2,parameter 3
NOTE Each input item in the command must be separated by a comma.

801
Database Management
CADB Commands
The CADB command functions are divided into two categories: file maintenance and file
display. This section describes each command function.
File Maintenance Commands

File maintenance commands create, modify, and delete records in the database. An
explanation and example of each maintenance command is shown in the following table.
Table 27-27 CADB File Maintenance Commands
Command Description
AC,SAV The SAV function command enables you to create a new record of information for a
particular aircraft in the database. On the Options command line, enter the generic ID of
the aircraft you want to save and the record name (or tail number) under which it is to be
stored. The record name can be from two to eight (2-8) characters in length.
Example:
Explanation: Save the generic record, 747N, to a CADB record named N12345. No
parameters are set with this input.
01 OPTIONS AC,SAV,747N,N12345
You can set any parameter value with the SAV command. You must set the OP
(operational weight) parameter to make use of the aircraft record in a flight plan.
NOTE When setting parameter values in the CADB, you can enter the parameter code
and value as one unit (for example, OP150000) or include an equal sign (=) between the
two (for example, OP=150000). Exceptions to this style variation are three-character and
four-character codes. When entering these parameters (for example, CI1, EDN2, and so
on), you must include the equal sign between the code and the value.
Example:
Explanation: Save the generic record, 747N, to a CADB record named N12345. Set the
operational weight (OP) to 415,000 lbs, the minimum flight weight (MW) to 630,000 lbs,
and turn on the display of the following CADB sections: ETOPS (EP) and Bracket
Modes (BK).
01 OPTIONS AC,SAV,747N,N12345,OP=415000,MW=630000,EP=Y,BK=Y
Once a modification is submitted via the SAV command, JetPlan returns a display of the
entire CADB record, showing the default settings and any new parameter settings you
might have made.

802
Database Management
Table 27-27 CADB File Maintenance Commands (continued)
Command Description
AC,CHG The CHG function command enables you to modify or update the parameter value
settings in an existing CADB record. The input is similar to the SAV command, except
that the generic ID is no longer needed. You can add new parameter settings to the record,
change existing values, or reset values to zero or their default (original) status. In most
cases, resetting a parameter value to its default state simply requires the input of the
parameter code without a value assignment.
NOTE It is a good practice to include the equal sign when resetting parameters to their
default status because some parameters require it.
Example:
Explanation: Update the CADB record, N12345, by changing the operational weight
(OP) to 414,500 lbs, and resetting the minimum flight weight (MW) to its default state
(zero).
01 OPTIONS AC,CHG,N12345,OP=414500,MW=
IMPORTANT The practice of resetting parameters to their default status does not apply
to certain aircraft weight parameters that have values brought into the record from the
generic record. Resetting one of these parameters (for example, takeoff weight - TO) by
omitting a value input results in a parameter value of zero. This must be avoided at all cost.
These parameters require some positive value that coincides with the physical
characteristics of the aircraft and they are vital to the flight plan calculation process.
Once a modification is submitted via the CHG command, JetPlan returns a display of the
entire CADB record, showing the new or changed values.
AC,CHG,ALL= You can make global changes to parameter settings by using the ALL= option. This
option enables you to apply modifications across all aircraft in your database by fleet
type. After the CHG command simply enter the option, ALL=xxxx, where xxxx is the
generic ID of the aircraft in your fleet that require the change.
For example, to change a couple of parameters for all 747M aircraft in your database,
simply include the option, ALL=747M, in the CHG command and specify the new
parameter settings.
Example:
Explanation: Set taxi fuel flow (TX) to 7200 lbs, and minimum contingency/reserve time
to 15 minutes for all 747M aircraft in the CADB.
01 OPTIONS AC,CHG,ALL=747M,TX=7200,MT=15
AC,DEL The DEL function command enables you to delete one or more existing aircraft records
from the CADB.
To delete a single record from the CADB, enter the name of the record you wish to delete
after the AC,DEL command.
Example:
01 OPTIONS AC,DEL,N12345
To delete multiple records from the CADB, enter the names of the record you wish to
delete after the AC,DEL command. Specify each record name and separate each with a
comma.
Example:
01 OPTIONS AC,DEL,N12345,N23456,N34567, and so on

803
Database Management
Table 27-27 CADB File Maintenance Commands (continued)
Command Description
AC,DEL,$ALL To delete all records in the CADB, enter the wildcard, $ALL, after the AC,DEL
command.
Example:
01 OPTIONS AC,DEL,$ALL
AC,CPY The CPY function command enables you to copy the contents (parameter settings) of one
CADB record into a new CADB record. If you try to copy data to an existing record,
JetPlan notifies you that the record already exists.
To copy the parameter settings of one record into a new record, enter the original record’s
name followed by a newly created name for the previously non-existent record after the
AC,CPY command.
Example:
Explanation: Copy the contents of CADB record, N12345, into the previously non-
existent CADB record, N54321.
01 OPTIONS AC,CPY,N12345,N54321
NOTE Once the new CADB record is created, modify those parameters that differentiate
it from the original record before using it in a flight plan (for example, the registration
number, SELCAL number, and possibly the operating weight).
AC,REN The REN function command enables you to give an existing CADB record a new record
name.
To rename a record, enter the original record’s name followed by a new name for the
record after the AC,REN command.
Example:
01 OPTIONS AC,REN,N12345,N99999

804
C HAPTER 28
Aircraft Fleet Database

About the Aircraft Fleet Database

A fleet type is the Jeppesen generic aircraft ID that defines a specific airframe and engine
combination. You can use the Aircraft Fleet Database (ACFDB) to maintain data for specific
aircraft fleet types. JetPlan automatically applies the information in an ACFDB record when
the aircraft fleet type in the record is used in a flight plan request.
For example, assume that your ACFDB contains a record for a Boeing 777-200ER aircraft
with GE90-110B1L engines (JetPlan generic aircraft ID 772R). JetPlan automatically applies
the information in the ACFDB record to your flight plan requests that include an aircraft of
type 772R. (For more information about generic aircraft IDs, see the “Aircraft Type
Commands” chapter in the JetPlan User Manual.)
SCM Data Sets and the ACFDB
NOTE If you are using ETOPS 2, the ETPRRMFL customer preference is not
required. ETOPS 2 flight plans automatically use SCM data sets, regardless of
customer preference or other configuration settings. For more information on
customer preferences and ETOPS 2, contact your Jeppesen account manager.
The ACFDB is primarily dedicated to storing the 12 ETOPS Speed and Cruise Mode (SCM)
data sets. The ETP Range Ring Method Flag (ETPRRMFL) customer preference activates use
of the SCM data sets. The SCM data sets replace a set of Customer Aircraft Database (CADB)
parameters that define the ETOPS area of operation, equal time point (ETP) location,
approved coverage ranges for ETOPS alternates, and suitability times. The SCM data sets
offer ETOPS operators a degree of flexibility and control that is not available when using only
the CADB parameters.
The following table shows the overlap between the CADB parameters and the SCM data set.
Table 28-1 SCM Data Set Overlap with the CADB
CADB Parameter SCM Data Set Parameter

ETOPS Approval Time (ET) • Default ETOPS Diversion Mode Title
(DMT)/Default ETOPS Deviation Time (SD)
• Sets 1–12 ETOPS Diversion Mode Title (DMT1-
DMT12)/ETOPS Deviation Time (SD1-SD12)
ETP Cruise Mode (EC) ETOPS All Engine Cruise Mode (CA1-CA12)
ETP Cruise Mode (EC1) ETOPS 1LE Depressurized Cruise Mode (CO1-
CO12)

807
Table 28-1 SCM Data Set Overlap with the CADB (continued)
CADB Parameter SCM Data Set Parameter

ETP True Airspeed (EA) ETOPS All Engine ETP TAS (SA1-SA12)
ETP True Airspeed (EA1) ETOPS 1LE Depressurized ETP TAS (SO1-SO2)
The advantages of SCM data sets include:
• The approval range around alternates is a user-provided distance as opposed

to a speed and time combination. This approach provides credit in the
ETOPS coverage circles for the extra distance resulting from the driftdown
profile flown after engine loss.
• SCM data sets allow ETOPS planning using different diversion speeds in
different regions of the world. For example, in one region, a slower speed
than approved for the aircraft type reduces the fuel required to meet the
ETOPS critical fuel requirement. In another region, the maximum approved
speed eases routing restrictions.
• If a Minimum Equipment List (MEL) item results in a restriction on the
approval time for the aircraft, an alternative SCM can be used to plan with a
lower approval time.
• SCM data sets support testing to determine the aircraft’s ETOPS results
using different approval times.
Each ETOPS SCM data set is uniquely identified in the database by the combined values of
the ETOPS Diversion Mode Title parameter and the ETOPS Deviation Time parameter (the
approved ETOPS diversion time in minutes). In addition to the ETOPS Range Ring Radius,
each SCM data set includes corresponding true airspeeds and cruise modes used for ETP and
Critical Fuel Scenario (CFS) calculations.
JetPlan applies the appropriate SCM data to a flight plan using the following logic:
• User interfaces capable of doing so can identify an SCM data set to use as an
override to any stored default data set.
• If no user input is submitted as an override, JetPlan uses the default SCM
data set as defined in the City Pair Fleet Database (CPFDB).
• If JetPlan cannot derive a default SCM data set from the CPFDB, it uses the
default ETOPS SCM data set in the ACFDB.
• If the ACFDB does not contain a default SCM data set, JetPlan fails the
flight plan and returns an error.

808
For more information on ETOPS, see the ETOPS User’s Guide: 2 Engine Aircraft on the User
Manuals page on JetPlan.com.
NOTE The ACFDB contains some parameters that JetPlan does not access
directly. The system simply stores these parameters for use by certain front-end
dispatch software applications, such as Jeppesen® Dispatch Control. For more
information, consult the appropriate front-end product documentation or contact your

809
Database Parameters
Database Parameters
The following table lists the parameters that authorized users can set in the ACFDB. These
parameters appear as options on the ACFDB pages in JetPlan.com. As you perform database
tasks, consult this table for information.
NOTE The ACFDB contains some parameters that JetPlan does not access
directly. The system simply stores these parameters for use by certain front-end
dispatch software applications, such as Jeppesen® Dispatch Control. These
parameters are identified in the following table. For more information, consult the
appropriate front-end product documentation or contact your Jeppesen account
manager.

maintenance. See the JetPlan.com Help file.
Table 28-2 Aircraft Fleet Database Parameters
Fleet Type (Required) Fleet Type refers to a specific airframe and
engine combination. The Fleet Type value is the
generic aircraft ID from the JetPlan Aircraft Library.
For instance, 777E is the JetPlan generic ID for the
aircraft type with ICAO identifier B772.
Critical Fuel Scenario (CFS) Fuel Pad NOTE Certain front-end applications use this
parameter. JetPlan does not use it directly. Consult the
CFS
dispatch software product documentation or contact
your Jeppesen Account Manager for more information.
This parameter specifies the default CFS fuel pad that
is applied to the CFS calculation for an aircraft
belonging to the fleet.
Input value: 0–99999 lbs/kgs. Default is 0.
Default ETOPS Diversion Mode Title This parameter is the customer-specified title of the
DMT SCM data set to be used as the default. This parameter
and ETOPS Deviation Time together constitute the
SCM data set key. This title and time combination
must exactly match the title and time of the SCM data
set defined as the default for the fleet type.
Input value: 1–10 alphanumeric characters

810
Database Parameters
Table 28-2 Aircraft Fleet Database Parameters (continued)
Default ETOPS Deviation Time This parameter indicates the number of minutes that
SD defines the approved ETOPS diversion time. This
parameter and ETOPS Diversion Mode Title together
constitute the SCM data set key. This title and time
combination must exactly match the title and time of
the SCM data set defined as the default for the fleet
type.
NOTE This parameter (with the Default ETOPS
Diversion Mode Title) corresponds to the ETOPS
Approval Time (ET) parameter in the CADB. For a
description of the ETOPS Approval Time parameter,
see the “Customer Aircraft Database” chapter in the
JetPlan User Manual or the Help file on JetPlan.com.
Input value: 60, 75, 120, 138, 180, 207, or 240
minutes
Tankering Interval NOTE Certain front-end applications use this

TI
This parameter specifies the maximum allowable time
aircraft can be on ground while holding extra fuel
intended for tankering.
Input value: 0–1440 minutes
Payload Tolerance NOTE Certain front-end applications use this

PT
The front-end system uses this parameter when
payload weights are received. The system checks if
the received payload exceeds a payload tolerance.
Input value: 0–999999 lbs/kgs
Print Aero Performance Set this parameter to Yes to display the Aero
AP performance parameters. (See the definitions of these
parameters in this table.)
Input values: Yes or No
Aero Performance Parameters

The following parameters become available for editing in JetPlan.com when you set the Print Aero Performance
Parameter to Yes.
Mach Speed Limit This parameter is not now in use.

MCL
CAS Speed Limit This parameter is not now in use.

CSL

811
Database Parameters
(TAS) Speed Limit This parameter is not now in use.
TSL
MMO Margin NOTE This parameter is used with the OUTFLT cost
index cruise method. Cost index cruise methods are
MMOM
set in the Customer Aircraft Database (CADB). See the
“Customer Aircraft Database” chapter in the JetPlan
User Manual or the Help file on JetPlan.com.
This parameter defines the maximum operating Mach
number (MMO) margin, intended to prevent
accidentally exceeding the MMO limit in flight.
The OUTFLT cost index cruise method uses the
MMO Margin parameter when it is set to a non-zero
number. When the Cost Index Method parameter in
the CADB is set to OUTFLT (LC=O), the system
automatically uses the value of the MMO Margin
parameter. If the Cost Index Method in the CADB is
set to OUTFLT, but the MMO Margin parameter is set
to 0 or is not defined, the system uses a default value
of five (5) calibrated airspeed (CAS) in knots.
Input value: 0–10 CAS in knots
VMO Margin NOTE This parameter is used with the OUTFLT cost
index cruise method. Cost index cruise methods are
VMOM
This parameter defines the maximum operating
airspeed (VMO) margin, intended to prevent
accidentally exceeding the VMO limit in flight.
The OUTFLT cost index cruise method uses the VMO
Margin parameter when it is set to a non-zero number.
When the Cost Index Method parameter in the CADB
is set to OUTFLT (LC=O), the system automatically
uses the value of the VMO Margin parameter. If the
Cost Index Method in the CADB is set to OUTFLT,
but the VMO Margin parameter is set to 0 or is not
defined, the system uses a default value of five (5)
calibrated airspeed (CAS) in knots.
Input value: 0–10 CAS in knots
Buffet Margin JAR This parameter is not now in use.

BMJAR
Buffet Margin FAR This parameter is not now in use.

BMFAR

812
Database Parameters
Thrust Margin Bank Angle This parameter is not now in use.
TMBA
Rate of Climb with Max Climb Thrust NOTE This parameter is used with the OUTFLT and
FPM cost index cruise methods. Cost index cruise
RCMCL
methods are set in the Customer Aircraft Database
(CADB). See the “Customer Aircraft Database” chapter
in the JetPlan User Manual or the Help file on
JetPlan.com.
This parameter defines the aircraft’s altitude
capability limits or sets a speed limit, using the rate of
climb with maximum climb thrust. When the Cost
Index Method parameter in the CADB is set to
OUTFLT (LC=O), to Golden Section Search (FPM)
(LC=G) or to FMS Matching (FPM) (LC=P), the
system checks the limit set by the Rate of Climb with
Max Climb Thrust at available altitudes during profile
optimization.
Input value: 0–500 feet per minute
Rate of Climb with Max Cruise Thrust NOTE This parameter is used with the FPM cost
index cruise methods. Cost index cruise methods are
RCMCR
This parameter defines the aircraft’s altitude
capability limits, using the rate of climb with
maximum cruise thrust. When the Cost Index Method
parameter in the CADB is set to Golden Section
Search (FPM) (LC=G) or to FMS Matching (FPM)
(LC=P), the system checks the limit set by the Rate of
Climb with Max Cruise Thrust at available altitudes
during profile optimization.
Input value: 0–500 feet per minute
Truncate ECON Speed to Max Speed This parameter is not now in use.
TECON

813
Database Parameters
Cockpit and Cabin Crew Parameters
NOTE The following cockpit and cabin crew parameters support the Minimum Adjusted Cost Index (MACI)
feature. When JetPlan calculates MACI values for flight planning, it uses the crew cost parameter values in the
City Pair Fleet Database (CPFDB) record, combined with the Lateness Cost parameter values in the CPFDB
record. If the CPFDB record does not contain crew cost parameter values, the system uses crew cost parameter
values in the CAPFDB record, combined with the Lateness Cost parameter values in the CPFDB record. If the
CAPFDB also does not contain crew cost parameter values, the system uses crew cost values in the Aircraft Fleet
Database (ACFDB) record. See the “Cost Index Commands” chapter in the JetPlan User Manual for information
about MACI.
Cockpit Crew Count Sets the default cockpit crew count. If no crew count
NCOD is in the flight plan request, the system uses this value
when computing total cost.
ex. NCOD=3
Input value: 0–99
Cockpit Crew Cost On Schedule Rate Sets the fixed cost for the cockpit crew for on-time
OSRO arrivals.
ex. OSRO=2,000 Input value: Dollars/hour, range=0–10,000
Cockpit Crew Cost Over Schedule Rate Sets the fixed cost for the cockpit crew for late
VSRO arrivals.
ex. VSRO =3,000 Input value: Dollars/hour, range=0–10,000
Cabin Crew Count Sets the default cabin crew count. If no crew count is
NCAD in the flight plan request, the system uses this value
when computing total cost
ex. NCAD=3
Input value: 0–99
Cabin Crew Cost On Schedule Rate Sets the fixed cost for the cabin crew for on-time
OSRA arrivals.
ex. OSRA =5,000 Input value: Dollars/hour, range=0–10,000
Cabin Crew Cost Over Schedule Rate Sets the fixed cost for the cabin crew for late arrivals.
VSRA Input value: Dollars/hour, range=0–10,000
ex. VSRA =7,500

814
Database Parameters
ETOPS SCM Datasets (12 Sets)
NOTE Select Clear SCM Dataset to delete all values from the selected SCM data set. Each data set can be
cleared independently of the others. No other options on the page are affected.
General Parameters
Diversion Mode Title This parameter is the customer-specified title of the

DMT1–DMT12 SCM data set. This parameter and ETOPS Deviation
Time together constitute the SCM data set key.
Input value: 1–10 alphanumeric characters. Default is
blank.
Deviation Time This parameter and ETOPS Diversion Mode Title

SD1–SD12 together constitute the SCM data set key. This
parameter indicates the number of minutes that
defines the approved ETOPS diversion time.
Input values: 60, 75, 120, 138, 180, 207, or 240
minutes.
NOTE This parameter corresponds to the ETOPS
Approval Time (ET) parameter in the CADB. For a
description of the ETOPS Approval Time parameter,
see the “Customer Aircraft Database” chapter in the
JetPlan User Manual or the Help file on JetPlan.com.
Descent Speed This parameter enables you to define an ETOPS

DS1-DS12 descent speed. This value is included on the ETOPS
flight plan output in the equal time points (ETPs)
summary section. It provides a reminder to the crew
about the descent speed on which the ETOPS critical
fuel summary is based.
NOTE This descent value is used for inclusion in the
flight plan output and is informational only. It has no
effect on the actual descent speed used by JetPlan for
computation.
Range Ring Radius This distance specifies the radius of the large ETOPS
SR1–SR12 circles. This distance is determined by the customer
(not calculated by JetPlan) based on how far the
airplane can fly on one engine, accounting for 1LE
driftdown within the approved ETOPS deviation time.
Input value: 0–9999 nm

815
Database Parameters
Adequate Airport Radius NOTE This parameter is used only with ETOPS 2
AR1–AR12
This distance specifies the small circle radius for the
ETOPS area of operations entry and exit points
calculation.
Input value: 0–9999 nm
Reference Weight This parameter enables you to specify the weight the
SW1–SW12 airline uses to determine aircraft performance for the
ETOPS range-ring radius. JetPlan does not use this
weight in any calculations. This parameter is simply a
field that you can use as a reference.
Input value: 0–9999999 lbs/kgs
1LE Depressurized ETP TAS This parameter specifies the true airspeed (TAS)
SO1–SO12 JetPlan uses to calculate the location of 1LE
depressurized equal time points (ETPs) between
ETOPS Alternates.
Input value: 0–9999 knots
NOTE The Cruise Mode Begin Flag (CS) and Cruise
Mode End Flag (CE) parameters in the CADB specify
which of the ETOPS Critical Fuel Scenarios (CFS’s)
the system computes for the aircraft. This TAS may not
be used if JetPlan does not need to calculate the 1LE
depressurized ETP TAS scenario.
NOTE This parameter corresponds to the ETP True
Airspeed (EA1) parameter in the CADB. For a
description of the ETP True Airspeed (EA1) parameter,
as well as the Cruise Mode Begin Flag (CS) and Cruise
Mode End Flag (CE), see the “Customer Aircraft
Database” chapter in the JetPlan User Manual or the
Help file on JetPlan.com.
Depressurized Engine-Out Parameters
Initial Emergency Descent NOTE This parameter is used only with ETOPS 2
DO1-DO12
This parameter enables you to store a reference to the
performance data to be used for the initial descent
(emergency descent) for the depressurized engine-out
scenario.
Input value: 3 alphanumeric characters
NOTE If the Initial Emergency Descent parameter is
left blank, the descent is based on zero distance, zero

816
Database Parameters
Cruise Mode This parameter specifies the cruise mode JetPlan uses
CO1–CO12 as the basis for the 1LE depressurized Critical Fuel
Scenario (CFS).
Input value: Valid cruise mode
NOTE This parameter corresponds to the ETP Cruise
Mode (EC1) parameter in the CADB. For a description
of the EC1 parameter, see the “Customer Aircraft
Final Descent NOTE This parameter is used only with ETOPS 2

FO1-FO12
performance data to be used for the final descent for
the depressurized engine-out scenario.
Hold NOTE This parameter is used only with ETOPS 2

HO1-HO12
performance data to be used for the hold calculations
for the depressurized engine-out scenario.
Depressurized All-Engine Parameters
DA1-DA12
(emergency descent) for the depressurized all-engine
scenario.
NOTE If the Initial Emergency Descent value is left
blank, the descent is based on zero distance, zero

817
Database Parameters
Cruise Mode This parameter specifies the cruise mode JetPlan uses
CA1–CA12 as the basis for the all-engine depressurized Critical
Fuel Scenario (CFS).
Input value: Valid cruise mode
NOTE This parameter corresponds to the ETP Cruise
Mode (EC) parameter in the CADB. For a description of
the EC parameter, see the “Customer Aircraft

FA1-FA12
the depressurized all-engine scenario.

HA1-HA12
for the depressurized all-engine scenario.
Pressurized Engine-Out Parameters
DDO1-DDO12
(driftdown) for the pressurized engine-out scenario.
NOTE If the Initial Emergency Descent parameter is
left blank, the descent is based on zero distance, zero
Cruise Mode NOTE This parameter is used only with ETOPS 2

DCO1-DCO12
This parameter enables you to specify the cruise mode
that JetPlan uses to compute the cruise fuel for the
engine-out, pressurized Critical Fuel Scenario (CFS).
Input value: Valid auxiliary cruise mode

818
Database Parameters
DFO1-DFO12
the pressurized engine-out scenario.

DHO1-DHO12
for the pressurized engine-out scenario.
Time-Limited Systems (TLS) Fire Suppression Scenario Parameters
Calculate TLS NOTE This parameter is used only with ETOPS 2

TLSF1-TLSF12
This parameter enables you to include or exclude
Time-Limited Systems (TLS) calculations for the
SCM data set from the ETOPS calculations and from
the flight plan output.
Input options:
• Yes–TLS calculations are included in the ETOPS
calculations, and TLS outputs are included in the
flight plan (format-dependent).
• No–TLS calculation are excluded from the
ETOPS calculations and TLS outputs are
excluded from the flight plan.
Cruise FL NOTE This parameter is used only with ETOPS 2

TFL1-TFL12
This parameter enables you to store a flight level to be
used in the time computations for time-limited
systems (TLS) fire suppression scenario plans.
The purpose of this field is to identify the most likely
nominal flight level at which an all-engine emergency
(medical, fire, or system malfunction) would be
flown.
Input value: A 3-digit value that identifies a flight
level in hundreds of feet. Example: 350

819
Database Parameters
Initial Descent NOTE This parameter is used only with ETOPS 2
TID1-TID12
(driftdown) for the time-limited systems (TLS) fire
suppression scenario computations.
Accounting for the initial descent in the TLS
evaluation can be expected to result in a lower time
value, making the ETOPS plan more likely not to
return negative results.
Cruise Mode NOTE This parameter is used only with ETOPS 2

TCR1-TCR12
performance data (the cruise mode) to be used to
compute the level-flight cruise portion of the time-
limited systems (TLS) fire suppression scenario
computations.
The level-flight cruise—the segment starting at end of
driftdown and ending at beginning of final descent—
is computed at the TLS fire suppression scenario
flight level stored in the SCM data set.
Input value: A valid cruise mode (3 alphanumeric
characters)

TFD1-TFD12
The system enables the user to store a reference to the
the time-limited systems (TLS) fire suppression
scenario computations.

820
Database Management
Database Management

In the JetPlan command-line interface, the ACFDB access command is ACF, which is entered
on the Options command line. The ACF access command always precedes a function
command. Function commands are inputs that instruct JetPlan to store, change, delete, or
display information in the database. The ACF function commands are divided into two
categories: file maintenance and file display.
File Maintenance
• ADD – Creates a record
File Display
• PRI – Displays a record
The ACFDB record key element is fleet type. The order of the inputs when working with
ACFDB records must always be: Access command (ACF), function command, fleet type, and
then any desired parameters. Commas separate the inputs, as shown in the following example:

821
Database Management
ACF,function command,fleet type,parameter 1,parameter 2,parameter 3
NOTE You can include any or all parameters (see Table 28-2) when adding or
changing records in the database. In fact, you can even omit all parameter settings if
you want to have a record in the database for just the airport and fleet type. The
parameter settings for such a record can be addressed at another time using the
CHG function.
ACFDB Commands
The ACFDB function commands are divided into two categories: file maintenance and file
display.

explanation of each maintenance command is shown in the following table.
Table 28-3 ACFDB File Maintenance Commands
Command Description
ACF,ADD This command enables you to add a record of information for a city pair in the ACFDB.
ACF,CHG This command enables you to change a record in the ACFDB.
ACF,DEL This command enables you to delete a record from the ACFDB.
File Display Commands

File display commands enable you to view stored information in the database. An explanation
of each display command is shown in the following table.
Table 28-4 ACFDB File Display Commands
Command Description
ACF,PRI This command provides a display of all specified records in the ACFDB.
ACF,SUM This command enables you to view a list of all records in the ACFDB.

822
C HAPTER 29
Customer Alternate
Database
About the Customer Alternate Database
About the Customer Alternate Database

The Customer Alternate (CALT) Database enables you to store information for user-defined
destination alternate airports (“alternates”). You can define distances and altitudes between
Point-of-Arrival (POA) airports and their alternates or reference specific route records stored
in the Customer Route Database (CRDB).
Once a CALT Database is created, you do not need to do anything to invoke its use other than
include a POA airport and a destination alternate in your flight plan request. Upon submission
of your flight plan request to the JetPlan system, the CALT Database is automatically scanned
for matching records. If your flight plan request contains a POA/alternate combination that
matches a record in the CALT Database, the stored data (distance value, altitude, or customer
route record) is applied to the calculation process. The destination alternate data is used in the
flight plan calculation for the divert leg of the plan.
The CALT Database provides the following benefits:
• Eliminates the need for repetitive inputs of distances or routes to alternate

airports.
• Provides more choices for flight planning. You can store standard alternate
information for typical use and override the standard at any time using ad
hoc inputs.
For definitions of the parameters in the CALT Database, see “Database Parameters” on
page 826.

For detailed information on applying CALT Database records to flight plan requests and
overriding records with ad hoc inputs, see the “Hold-Alternate Commands” chapter in the

825
Database Parameters
Database Parameters
The following table lists the parameters that can be set in the CALT Database. These
parameters appear as options on the CALT Database pages in JetPlan.com. As you perform
database tasks, consult this table for information.

maintenance.
Table 29-1 Customer Alternate Database Parameters
Arrival Airport (Required) The ICAO or IATA identifier of the POA
for which you want to store alternate information.
Example: KLAX or LAX
Alternate Airport (Required) The ICAO or IATA identifier of the airport

you want to designate as the alternate for the POA.
Example: KLAX or LAX
Routing Method Options (Required)

You can enter either a Customer Route Database (CRDB) record name or a distance value in nautical miles.
With either option, you can also enter flight-level information.
Route Name The route record name from the CRDB. The distance
value is derived from the route generation process
when the route is created in the CRDB.
Storing a route in the CALT Database requires that the
route first be generated in the CRDB and then
transferred by referencing the route’s record name.
Input value: The CRDB record name
Distance Mileage (no CRDB route name provided) Lets the user store a flying distance from the POA to
the destination alternate.
Input value: Distance in nautical miles

826
Database Parameters
Table 29-1 Customer Alternate Database Parameters (continued)
Flight Levels (100 * FEET) (Optional) You can add a single flight level or a flight
At Level level range between the two airports. This information
is stored only if you enter it when creating a CALT
- or -
Database record. Otherwise, an optimum flight level
Between Levels is determined for the distance between the two
FLnnn airports in the flight plan calculation process.
For lower/upper enter: FLnnn,nnn NOTE If flight level values for the route are stored in
the CRDB record and also in the CALT Database, the
value in the CALT Database takes precedence.
Input value: Flight level in feet x 100
The value you enter must follow the JetPlan standard
for flight level inputs: 3 digits, in hundreds of feet.
Otherwise, the system returns an error.

827
Database Management
Database Management

To make the CALT Database a data resource for your flight planning needs, you must first
create and manage records of information in the database. To do this, you need to access the
database. The CALT Database access command is ALT, and it is entered on the Options
command line. Any attempt to affect or reference the information in the database must begin
with this command.
The access command always precedes a command function. Function commands are those
inputs that instruct JetPlan to store, change, delete, or display information in the database.
Two categories of command functions are available when accessing the CALT Database.
These functional categories are listed below with the specific commands.
File Maintenance
• ADD – Adds a record to the database
• DEL – Deletes a record from the database
File Display
• PRI – Displays the content of the record
• TOT – Displays the number of records stored in the database

828
Database Management
When applying file maintenance commands, the record you affect in the database is referenced
by the ICAO or IATA identifiers of the POA and alternate. These identifiers together act as the
key (or record name), and they are entered after the function command so that the input
structure has the following syntax:
ALT,function command,POA,ALT,alternate value
The identifier for the POA must precede the identifier for the destination alternate. The
alternate value is either a distance in nautical miles or a record name from the CRDB.
CALT Database Commands

The CALT Database command functions are divided into two categories: file maintenance and
file display. This section describes each command function.

Table 29-2 CALT Database File Maintenance Commands
Command Description
ALT,ADD The ADD function enables you to add a record of information to the CALT Database. To
add a record, enter the POA airport identifier, the destination alternate airport identifier, and
the alternate value (distance value, altitude, or customer route record name) after the
ALT,ADD command.
Example:
Add a record to the database. Make KEWR a destination alternate for KJFK, and specify a
distance (100 nm) between the two airports.
01 OPTIONS ALT,ADD,KJFK,KEWR,100
Example:
Add another alternate record for KJFK. This time make KLGA the destination alternate and
the alternate value another distance input (80 nm).
01 OPTIONS ALT,ADD,KJFK,KLGA,80
Example:
Add a destination alternate record to the database, using KONT as an alternate for KLAX.
The alternate value is CRDB record, A01.
01 OPTIONS ALT,ADD,KLAX,KONT,A01

829
Database Management
Table 29-2 CALT Database File Maintenance Commands (continued)
Command Description
ALT,ADD NOTE The example above applies a record name (A01) as the destination alternate value.
(Continued) The record, A01, must exist in the CRDB before it can be stored in the CALT Database.
Example:
Add a destination alternate record for KSFO. Make KSAT the alternate, specify a distance
(102 nm), and an altitude (FL100).
01 OPTIONS ALT,ADD,KSFO,KSAT,102,FL100
Example:
Add a destination alternate record for KMIA. Make KIAD the alternate, specify a distance
(102 nm), and an altitude range, where 100 is the lower flight level and 230 is the higher
level.
01 OPTIONS ALT,ADD,KMIA,KIAD,A01,FL100,230
ALT,CHG The CHG command enables you to modify an existing CALT Database record. To modify a
record, you must reference the two airports that identify the record you wish to affect. The
real change, if any, is to be made to the destination alternate value (distance, altitude, or
route record).
Example:
Change the destination alternate value for the record that has KJFK as the arrival airport and
KEWR as the alternate. The new alternate value is a distance input (120 nm).
01 OPTIONS ALT,CHG,KJFK,KEWR,120
Example:
Replace the previous alternate value with the route record, A02.
01 OPTIONS ALT,CHG,KLAX,KONT,A02
Example:
Add flight level 100 to the previous alternate value.
01 OPTIONS ALT,CHG,KLAX,KONT,A02,FL100
ALT,DEL The DEL command enables you to remove records from the database by specific POA or by
specific POA - ALT airport combination.
Example:
Delete all alternate records for the (arrival) airport, KJFK.
01 OPTIONS ALT,DEL,KJFK
Example:
Delete the destination alternate record for the POA/ALT combination, KJFK to KLGA.
01 OPTIONS ALT,DEL,KJFK,KLGA

830
C HAPTER 30
Customer Airport
Database
About the Customer Airport Database
About the Customer Airport Database

The Customer Airport Database (CAPDB) enables you to create and manage specific airport
information that supports the flight planning process. The CAPDB gives you control over
basic airport data used in general planning and also enables you to set parameters that support
more advanced functionality, such as the automatic alternate, ETOPS, and single-leg tankering
features.
None of the information you store in the CAPDB is mandatory for the creation of flight plans
on the JetPlan system. However, if used, this database enhances JetPlan’s planning features.

833
Database Parameters
Database Parameters
The following table lists the parameters in the CAPDB. These parameters appear as options on
the CAPDB pages in JetPlan.com. As you perform database tasks, consult this table for
information.

maintenance. For the convenience of JetPlan users, the table below lists JetPlan
command-line database codes under the parameter names.
NOTE Some of the parameters in the CAPDB provide information that can be
displayed in the flight plan output, depending on the flight plan format. For more
information, contact your Jeppesen account representative.
Table 30-1 CAPDB Parameters
Parameter Description Purpose

MISC Parameters
Obstructions Defines whether an obstruction General use.

OB exists at the airport. This parameter provides
ex. OB=Y Input value: Yes or No information in the flight plan
output about whether or not there
is an obstacle. Inclusion in the
flight plan output is format-
dependent.
Special Procedures Defines whether special General use.

SP procedures exist at the airport. This parameter provides
ex. SP=Y Input value: Yes or No information in the flight plan
output about whether or not there
are special procedures. Inclusion
in the flight plan output is format-
dependent.
Special Reserve Policy Defines the application of a special General use.

SR reserve fuel policy for the airport. This parameter provides 120
ex. SR=I Input value: Currently, this minutes of reserve fuel when the
parameter only accepts the letter airport is submitted as the POA in
“I,” which denotes Island the flight plan.
Reserves.

834
Database Parameters
Table 30-1 CAPDB Parameters (continued)

(Approach) Category Input value: A, B, C, or D General use.
CA This parameter provides
ex. CA=A information in the flight plan
output. Inclusion in the flight plan
output is format-dependent.
Hold Time (Minutes) Defines a default hold time. General use.

HT Input value: Time in minutes This parameter provides a hold
ex. HT=10 time when the airport is used as an
alternate. It is applied only when
no other hold time value exists. If
no hold time is specified in the
flight plan inputs, in the aircraft
database, or in the ID/Attribute
File, this value is applied.
AVE Taxi In Minutes Defines the average time of taxiing General use.
TI at the (arrival) airport. This parameter is applied when the
ex. TI=10 Input value: Time in minutes airport is used as a POA.
NOTE This parameter works in
coordination with the TX parameter
(taxi fuel flow) in the Customer
Aircraft database.
AVE Taxi Out Minutes Defines the average time of taxiing General use.
TO at the (departure) airport. This parameter is applied when the
ex. TO=8 Input value: Time in minutes airport is used as a POD.
NOTE This parameter works in
coordination with the TX parameter
(taxi fuel flow) in the Customer
Aircraft Database.
Maximum Takeoff Decibels Defines the maximum degree of General use.

MT loudness allowed for takeoff at the This parameter provides
airport. information in the flight plan
ex. MT=90
Input value: Number of decibels output. Inclusion in the flight plan
Maximum Landing Decibels Defines the maximum degree of General use.

ML loudness allowed for landing at the This parameter provides
airport. information in the flight plan
ex. ML=75
Input value: Number of decibels output. Inclusion in the flight plan

835
Database Parameters

Maximum Crosswinds (Knots) Defines any crosswind that is, on General use.
MC average, typical for the airport. This parameter provides
ex. MC=10 Input value: Knots information in the flight plan
Airport Handling Codes 1, 2, 3 Each of these parameters defines a General use.

H1–H3 code used to exhibit an Airport These parameters provide
Handling capability. information in the flight plan
ex. H1=C
Input value: These codes are for output. Inclusion in the flight plan
display purposes only and the output is format-dependent.
precise meaning of any given
character is up to the user to
decide.
Primary (Airport) Division The airport division defined as The Airport Division parameters
AD primary. Each airport division are stored in the CAPDB but are
defines a pre-selected set of used only by certain GUI dispatch
airports with common attributes. software applications that interface
Input value: 1-6 characters with JetPlan. See the
documentation for the dispatch
software application or contact
your Jeppesen account
representative for more
information.
Secondary (Airport) Divisions 1-5 Up to five secondary airport The Airport Division parameters
SD1-SD5 divisions can be defined. Each are stored in the CAPDB but are
airport division defines a pre- used only by certain GUI dispatch
selected set of airports with software applications that interface
common attributes. with JetPlan. See the
Input value: 1-6 characters documentation for the dispatch
software application or contact
your Jeppesen account
representative for more
information.
RAIM Mask Angle The RAIM mask angle for the In the event of an airport being
GM airport. constrained as to the number of
The required mask angle is visible satellites, for example
obtained from the licensing because of high terrain, a steeper
authority of the airport concerned mask angle can be saved into the
and is shown in the appropriate airport database to make the RAIM
AIP publication. prediction more restrictive.
Input value: Increments of 0.5
from -0.5 to 20.0. Default setting is
0.0.

836
Database Parameters

Fuel Parameters
Fuel Price Currency Defines the monetary unit in which Used in tankering and Cost Index
FC fuel is purchased. (CI) calculations.
ex. FC=JPY Input value: The three-letter ISO The currency code is used in the
code for the currency used. The cost-based tankering
default setting is the U.S. Dollar (TANK2/2X,TANK3/3X) process.
(USD). This parameter must be set for
NOTE ISO currency codes and
both the departure and the arrival
corresponding exchange rates can airports. It is also used in Cost
be acquired using the JPIII Index (CI) flight plans. See the
command on the 01 Options “Payload, POD/POA Weight and
command line. Fuel Commands” and the “Cost
Index Commands” chapters in the
JetPlan User Manual for more
information.
Fuel Unit Defines the measurement unit in Used in tankering calculations.

FU which fuel is acquired. The fuel unit is used in the cost-
ex. FU=GAL Input value: GAL (U.S. gallon) or based tankering
LTR (liters). The default setting is (TANK2/2X,TANK3/3X) process.
GAL. See the “Payload, POD/POA
Weight and Fuel Commands”
chapter in the JetPlan User
Manual for more information.
Fuel Price Defines the price of fuel at the Used in tankering and Cost Index
FP airport. The price entered must be (CI) calculations.
relative to the currency established The fuel price is used in the cost-
ex. FP=3.50
with the FC parameter. based tankering (TANK2/2X,
Fuel Price equates to the “non- TANK3/3X) process and in Cost
bonded” price that includes all Index (CI) flight plans. See the
taxes and fees required for “Payload, POD/POA Weight and
domestic flights, as opposed to the Fuel Commands” and the “Cost
“bonded” fuel price that can be Index Commands” chapters in the
used for international flights that JetPlan User Manual for more
meet certain criteria. See “Bonded information.
Fuel Price” below.
Input value: Fuel price
Example: 3.50
NOTE The display of fuel price
information, including fuel density,
fuel index, currency code, and fuel
unit, does not appear when you
view a record unless set to do so in
the ID/Attribute file. Contact your
Jeppesen account representative
for more information.

837
Database Parameters

Fuel Price Updated This field is automatically filled in See “Fuel Price” above.
LU with a date/time stamp whenever
the fuel price (FP, described
Automatic date/time stamp
above) is changed.
Bonded Fuel Price Bonded Fuel Price is the “non- Used in tankering and Cost Index
BP bonded” (domestic) price minus (CI) calculations.
any taxes and customs fees. Under The bonded fuel price is used in
ex. BP=2.80
certain circumstances, taxes and the cost-based tankering for flights
customs fees can be avoided if a that meet certain criteria. See the
flight can be classified as “Payload, POD/POA Weight and
international. Fuel Commands” and the “Cost
Input value: Bonded fuel price Index Commands” chapters in the
Example: 2.80 JetPlan User Manual for more
information.
Bonded Price Updated This field is automatically filled in See “Bonded Fuel Price” above.
BU with a date/time stamp whenever
the bonded fuel price (BP,
Automatic date/time stamp
described above) is changed.
Fuel Density Defines a non-standard fuel Used in tankering and Cost Index
FD density at the airport. (CI) calculations.
ex. FD=6.78 Fuel density is specified in pounds The fuel density parameter is an
per gallon (lbs/gal). optional parameter used in the
Example: 6.78 cost-based tankering (TANK2/2X,
TANK3/3X) process. It is also
used in Cost Index flight plans.
See the “Payload, POD/POA
Weight and Fuel Commands” and
the “Cost Index Commands”
chapters in the JetPlan User
Manual for more information.
Fuel Index Defines the fuel price at the airport Used in tankering calculations.
FI relative to some standard. The The fuel index is used in the index-
index standard would generally be based tankering (TANK1/1X)
ex. FI=100
set for the airport that represents process. See the “Payload,
your home base of operations. POD/POA Weight and Fuel
Example: 100 Commands” chapter in the JetPlan
User Manual for more
information.

838
Database Parameters

ETOPS Parameters
See the ETOPS User’s Guide: 2-Engine Aircraft on JetPlan.com for more information on ETOPS flight
planning.
ETOPS Early Arrival Delta Defines a length of time. Used in ETOPS flight planning.
E1 Input value: Time in minutes This parameter enables you to set a
ex. E1=90 time cushion for the determination
of the weather condition at the
airport. In this case, the airport is
being used as an enroute divert.
The delta provides a time frame–
between the calculated earliest
arrival time and an earlier time–at
which weather information is
considered for the airport’s
suitability.
See the ETOPS User’s Guide: 2-
Engine Aircraft on JetPlan.com for
more information.
ETOPS Late Arrival Delta Defines a length of time. Used in ETOPS flight planning.
E2 Input value: Time in minutes This parameter enables you to set a
ex. E2=90 time cushion for the determination
of the weather condition at the
airport. In this case, the airport is
being used as an enroute divert.
The delta provides a time frame–
between the calculated latest
arrival time and a later time–at
which weather information is
considered for the airport’s
suitability.
more information.

839
Database Parameters

ETOPS Terminal Area Width Defines a radius distance from the Used in ETOPS/Overwater
E3 airport. Driftdown flight planning.
ex. E3=90 Input value: Nautical miles This parameter only applies when
the airport is used as an enroute
divert from an ETP (specifically
during overwater driftdown
operations). It enables you to
specify a distance at which reserve
fuel adjustments are made. The
distance input acts as a boundary at
which anti-icing operations turn on
or off, depending on customer set
up, which in turn, affects reserve
fuel.
more information.
NOTE Use is limited at this time.
Approach Parameters: Precision, Non-Precision, and ETOPS
Precision Approach Defines the ceiling minimum for General use.

POA Ceiling Minimum the airport in feet or meters. This This parameter provides
parameter is applicable when the information in the flight plan
P1
airport is used as an arrival airport. output. Inclusion in the flight plan
ex. P1=350
Input value: 0–10000 feet or output is format-dependent.
meters
Feet is the default. To specify
meters, you must append the input
with the letter M (P1=500M). To
change from meters to feet, you
must append the input with the
letter F (P1=500F).
Precision Approach Defines the visibility minimum for General use.

POA Visibility Minimum the airport in feet or meters. This This parameter provides
parameter is applicable when the information in the flight plan
P2
airport is used as an arrival airport. output. Inclusion in the flight plan
ex. P2=2400F
Input value: 0–10000 feet or output is format-dependent.
meters
meters, you must append the input
with the letter M (P2=500M). To
change from meters to feet, you
must append the input with the
letter F (P2=500F).

840
Database Parameters

Precision Approach Defines the ceiling minimum for When the Precision Minima
Alternate Ceiling Minimum the airport in feet or meters. This (PMIN) flight plan option is used,
parameter is applicable when the this precision approach parameter
P3
airport is used as an alternate. is a weather criteria check in the
ex. P3=600 automatic alternate selection
Input value: 0–10000 feet or
meters process.
Feet is the default. To specify When the PMIN flight plan option
meters in the command-line is used, JetPlan uses the Precision
interface, you must append the Approach Alternate Ceiling
input with the letter M Minimum and the Precision
(P3=500M). To change from Approach Alternate Visibility
meters to feet, you must append Minimum values to check the
the input with the letter F suitability of alternate airports.
(P3=500F). (When the PMIN option is not
used, JetPlan uses the more
conservative Non-Precision
Approach Alternate Ceiling and
Visibility Minimum values to
check suitability of alternates. See
the definitions of these parameters
below.)
By default, JetPlan first checks the
Airport Fleet database for the
Precision Approach Alternate
Ceiling Minimum value. If the
value in the Airport Fleet database
is zero, JetPlan gets the value from
the CAPDB.
NOTE A customer preference
setting enables you to change the
database used as the default
source of the Precision Approach
Alternate Ceiling Minimum and
Visibility Minimum values. Contact
your Jeppesen Account
See the “Hold-Alternate
Commands” chapter in the JetPlan
information.
This parameter provides
information in the flight plan

841
Database Parameters

Precision Approach Defines the visibility minimum for When the Precision Minima
Alternate Visibility Minimum the airport in feet or meters. This (PMIN) flight plan option is used,
parameter is applicable when the this precision approach parameter
P4
airport is used as an alternate. is a weather criteria check in the
ex. P4=9999F automatic alternate selection
meters process.
Feet is the default. To specify When the PMIN flight plan option
meters in the command-line is used, JetPlan uses the Precision
interface, you must append the Approach Alternate Visibility
input with the letter M Minimum and the Precision
(P4=500M). To change from Approach Alternate Ceiling
meters to feet, you must append Minimum values to check the
the input with the letter F suitability of alternate airports.
(P4=500F). (When the PMIN option is not
used, JetPlan uses the more
conservative Non-Precision
Approach Alternate Ceiling and
Visibility Minimum values to
check suitability of alternates. See
the definitions of these parameters
below.)
Airport Fleet database for the
Visibility Minimum value. If the
the CAPDB.
source of the Precision Approach
Alternate Ceiling Minimum and
Visibility Minimum values. Contact
your Jeppesen Account
information.
This parameter provides
information in the flight plan

842
Database Parameters

Non-Precision Approach Defines the ceiling minimum for For non-precision approaches, this
POA Ceiling Minimum the airport in feet or meters. This parameter provides information in
parameter is applicable when the the flight plan output. Inclusion in
N1
airport is used as an arrival airport. the flight plan output is format-
ex. N1=500 dependent.
meters
meters in the command-line
interface, you must append the
input with the letter M
(N1=500M). To change from
meters to feet, you must append
the input with the letter F
(N1=500F).
Non-Precision Approach Defines the visibility minimum for For non-precision approaches, this
POA Visibility Minimum the airport in feet or meters. This parameter provides information in
parameter is applicable when the the flight plan output. Inclusion in
N2
airport is used as an arrival airport. the flight plan output is format-
ex. N2=3200F dependent.
meters
meters in the command-line
interface, you must append the
input with the letter M
(N2=500F).

843
Database Parameters

Non-Precision Approach Defines the ceiling minimum for NOTE The Precision Minima
the airport in feet or meters. This (PMIN) flight plan option uses the
parameter is applicable when the Precision Approach Alternate
N3 Ceiling and Visibility Minimum
airport is used as an alternate.
ex. N3=800 values to check suitability of
Input value: 0–10000 feet or alternate airports. See definitions of
meters those parameters above.
Feet is the default. To specify This non-precision approach
meters in the command-line parameter is a weather criteria
interface, you must append the check in the automatic alternate
input with the letter M selection process.
When JetPlan checks the
suitability of an airport as an
alternate (departure, en route, or
(N3=500F).
arrival alternate) it may perform a
“TAF check” on that airport. That
is, it compares the TAF forecast
with the landing minima values for
the candidate alternate airport.
Airport Fleet database for the Non-
Ceiling Minimum value. If the
the CAPDB.
source of the Non-Precision
Approach Alternate Ceiling
Minimum and Non-Precision
Approach Alternate Visibility
Minimum values. Contact your
Jeppesen Account Representative
for information.
information.

844
Database Parameters

Non-Precision Approach Defines the visibility minimum for NOTE The Precision Minima
the airport in feet or meters. This (PMIN) flight plan option uses the
parameter is applicable when the Precision Approach Alternate
N4 Ceiling and Visibility Minimum
airport is used as an alternate
ex. N4=9999F values to check suitability of
Input value: 0–10000 feet or alternate airports. See definitions of
meters those parameters above.
Feet is the default. To specify This non-precision approach
meters in the command-line parameter is a weather criteria
interface, you must append the check in the automatic alternate
input with the letter M selection process.
When JetPlan checks the
suitability of an airport as an
alternate (departure, en route, or
(N4=500F).
arrival alternate) it may perform a
“TAF check” on that airport. That
is, it compares the TAF forecast
with the landing minima values for
the candidate alternate airport.
Airport Fleet database for the Non-
Visibility Minimum value. If the
the CAPDB.
source of the Non-Precision
Approach Alternate Ceiling
Minimum and Non-Precision
Approach Alternate Visibility
Minimum values. Contact your
Jeppesen Account Representative
for information.
information.

845
Database Parameters

ETOPS Approach Defines the ceiling minimum for NOTE This parameter is used
the airport in feet or meters. This only with ETOPS 2 flight plan
parameter is applicable when the options. Contact your Jeppesen
ECM account manager for more
information.
meters This parameter is used to
determine if an ETOPS alternate is
suitable based on the TAF weather
between the early arrival time and
later arrival time.
This parameter works in
conjunction with the ETOPS
Ceiling Minimum parameter in the
Customer Airport Fleet database.
If there is not a minimum value in
the Customer Airport Fleet
database, JetPlan checks for the
minimum in the CAPDB. If there
is no minimum value in the
CAPDB, JetPlan uses zero ceiling.
ETOPS Approach Defines the visibility minimum for NOTE This parameter is used
the airport in feet or meters. This only with ETOPS 2 flight plan
parameter is applicable when the options. Contact your Jeppesen
EVM account manager for more
information.
meters This parameter is used to
determine if an ETOPS alternate is
suitable based on the TAF weather
between the early arrival time and
later arrival time.
This parameter works in
conjunction with the ETOPS
Visibility Minimum parameter in
the Customer Airport Fleet
database. If there is not a minimum
value in the Customer Airport
Fleet database, JetPlan checks for
the minimum in the CAPDB. If
there is no minimum value in the
CAPDB, JetPlan uses zero
visibility.

846
Database Parameters

Operational Time Sets 1-8
The Hours of Operation (Open and Close) parameters establish the operational hours for the airport. The Week
Days parameter establishes the days of the week the airport uses the hours set by the Hours of Operation
parameters. The UTC/Local parameter defines the entered time value as UTC or local. The Start Date/Time and
End/Date Time parameters define the period during which the operational set is in effect.
The operational time sets allow you to set variances in the hours of operation schedule for the airport. For
example, you could use the first set of parameters to establish morning hours of operation and the second set to
establish afternoon hours of operation, allowing for a midday shutdown for one hour. The third and fourth sets
could be used to establish weekend operations, and so on.
Hours Operation (Open) Defines the time from which the Used in the automatic alternate
O1-O8 airport is open for the given selection process.
operational time set. There are This parameter, used in
ex. O1=0600
eight sets of opening times. coordination with the other
Input value: Time in HHMM Operational Time set parameters,
format is an availability criteria check in
the automatic alternate selection
process.
Hours Operation (Close) Defines the time at which the Used in the automatic alternate
C1-C8 airport closes for the given selection process.
operational time set. There are This parameter, used in
ex. C1=2200
eight sets of closing times. See the coordination with the other
O1 parameter information above. Operational Time set parameters,
Input value: Time in HHMM is an availability criteria check in
format the automatic alternate selection
process.
Week Days Week Days Available. Defines the Used in the automatic alternate
W1-W8 days of the week the airport is selection process.
open using the hours established This parameter, used in
ex. W1=12345
by the O1-O8 parameters. Monday coordination with the other
is considered day 1. Thus, the Operational Time set parameters,
input, 12345, suggests a Monday is an availability criteria check in
through Friday availability. the automatic alternate selection
process.
UTC/Local Flag Defines the clock used in Used in the automatic alternate
T1-T8 establishing the hours of operation selection process.
(Open/Close) (O1-8/C1-8) for the This parameter, used in
ex. T1=U
given operational time set. coordination with the other
Input value: U (Universal) or L Operational Time set parameters,
(Local). is an availability criteria check in
process.

847
Database Parameters

Start Date/Time Specifies a beginning date and Used in the automatic alternate
DS1-DS8 time for the hours of operation selection process.
entered for the operational time This parameter, used in
ex. DS1=23082007@1300
set. coordination with the other
Input value: Operational Time set parameters,
• Date in DDMMYYYY is an availability criteria check in
format the automatic alternate selection
process.
• Time in HHMM format
End Date/Time Specifies an ending date and time Used in the automatic alternate
DE1-DE8 for the hours of operation entered selection process.
for the set. This parameter, used in
ex. DEI=29082007@1300
Input value: coordination with the other
• Date in DDMMYYYY Operational Time set parameters,
format is an availability criteria check in
• Time in HHMM format
process.
Curfew Time Sets 1-4

These parameter sets allow you to set multiple curfews for the airport.
Curfew Start (Close) (HHMM) This parameter allows a curfew General use.
CS1-CS4 starting time to be set. This parameter provides
ex. CS1=2200 NOTE A curfew start time means information in the flight plan
that applicable operations must output. Inclusion in the flight plan
cease at that time. output is format-dependent.
Input value: Time in HHMM
format.
Curfew End (Open) (HHMM) This parameter allows a curfew General use.
CE1-CE4 ending time to be set. This parameter provides
ex. CE1=0600 NOTE A curfew end time means information in the flight plan
that applicable operations can output. Inclusion in the flight plan
begin at that time. output is format-dependent.
Input value: Time in HHMM
format.
Week Days Defines the days of the week that General use.
CD1-CD4 the curfew is in effect. Monday is This parameter provides
considered day 1. Thus, the input, information in the flight plan
ex. CD1=567
567, indicates the curfew is output. Inclusion in the flight plan
effective Friday, Saturday, and output is format-dependent.
Sunday.

848
Database Parameters

UTC/Local Flag Defines the clock used in General use.
CT1-CT4 establishing the hours of the This parameter provides
curfew (CS1/CE1). information in the flight plan
ex. CT1=L
Input value: U (Universal) or L output. Inclusion in the flight plan
(Local) output is format-dependent.
ATC Tower Time Sets 1-4

These parameter sets allow you to set multiple times of operation for the airport ATC tower.
ATC Tower Start (Open) This parameter allows a tower General use.
TS1-TS4 opening time to be set. This parameter provides
Input value: Time in HHMM information in the flight plan
format. output. Inclusion in the flight plan
ATC Tower End (Close) This parameter allows a tower General use.
TE1-TE4 closing time to be set. This parameter provides
Input value: Time in HHMM information in the flight plan
format. output. Inclusion in the flight plan
Week Days ATC Tower Days of Operation. General use.

TD1-TD4 Defines the days of the week that This parameter provides
the tower is open using the hours information in the flight plan
established by the TS1 and TE1 output. Inclusion in the flight plan
parameters. Monday is considered output is format-dependent.
day 1. Thus, the input, 12345,
indicates that the tower is open
Monday through Friday.
UTC/Local Flag Defines the clock used in General use.
TT1-TT4 establishing the hours of operation This parameter provides
(TS1/TE1). information in the flight plan
Input value: U (Universal) or L output. Inclusion in the flight plan
(Local). output is format-dependent.
Company Frequency Sets (1–10)

These parameter sets allow you to define up to 10 radio frequencies for use at the airport.
Company Frequency Defines the radio frequency your General use.

CF company uses at the airport or in This parameter provides
general. information in the flight plan
ex. CF=123.45
Input value: Value representing the output. Inclusion in the flight plan
frequency output is format-dependent.

849
Database Parameters

Company Frequency Description A description of the frequency General use.
DF specified with the CF parameter. This parameter provides
You can enter up to 30 characters information in the flight plan
ex. DF=textinput
of text. output. Inclusion in the flight plan
(Additional) Company Enables you to define up to nine General use.

Frequencies other frequencies—ten in all, This parameter provides
F1–F9 including the CF parameter—for information in the flight plan
company use. output. Inclusion in the flight plan
ex. F1=123.45
(Additional) Company Frequency Each parameter coincides with General use.

Descriptions parameters F1 through F9. Enter a This parameter provides
D1–D9 plain language description of the information in the flight plan
frequency specified. You can enter output. Inclusion in the flight plan
ex. D7=textinput
up to 30 characters of text. output is format-dependent.

850
Database Management
Database Management

To make the CAPDB a data resource for flight planning, you must first create and manage
records of information in the database. To do this, you need to access the database. In the
JetPlan command-line interface, the CAPDB access command is AP, and it is entered on the
Options command line. Any attempt to affect or reference the information in the database must
begin with this command.
Two categories of command functions are available when accessing the CAPDB. These
functional categories are listed below with the specific commands.
File Maintenance
File Display
• SUM – Displays a list of records (by name)
• PRI – Displays the record of the file name (airport) specified

851
Database Management
The record you affect in the database is referenced by the ICAO or IATA code of the airport.
This code is the file name, and it is entered after the function command so that the input
structure has the following syntax:
AP,function command,filename,parameter 1,parameter 2,parameter 3,and

so on
The following example illustrates the creation of a new record for the airport KLAX. All
parameter inputs are strictly optional. Therefore, the parameters shown are just examples.
EXAMPLE:
01 OPTIONS AP,SAV,KLAX,OB=Y,SP=Y,TI=10,TO=5,CF=123.45
NOTE You can include any or all parameters (see the Database Parameters table
on page 834) when saving or changing records in the database. In fact, you can even
omit all parameter settings if you just want to have a record in the database for the
airport. The parameter settings for such a record can be addressed at another time.
The point is that a record is affected or referenced by the input of the access
command (AP), the function command (for example, SAV), and the file name (Airport
ID).
CAPDB Commands
The CAPDB command functions are divided into two categories: file maintenance and file

Table 30-2 CAPDB File Maintenance Commands
Command Description
AP,SAV The SAV command enables you to create a new record of information for a particular airport
in the database. Specify the airport code as the file or record name and enter any parameter
that you wish to set.
Example:
01 OPTIONS AP,SAV,DEN,TI=15,TO=15,FD=6.78

852
Database Management
Table 30-2 CAPDB File Maintenance Commands (continued)
Command Description
AP,CHG The CHG command enables you to modify the parameter settings of an airport record
previously stored in the database. The input is similar to the SAV input. You can add new
parameter settings to the record, change setting values, or reset values to their original
(default) state. To reset a particular parameter to its default value, enter the parameter
without a value input.
Example:
To reset the fuel density value that was set in the previous example, enter the following:
01 OPTIONS AP,CHG,DEN,FD
AP,DEL As shown above, deleting a parameter setting within a record (setting its value to the default
value) requires the omission of the value input for that parameter within a CHG command
entry. The function command DEL enables you to remove a complete record from the
database. To delete a record, you must explicitly specify the record name.
Example:
To delete the record for the Anchorage, Alaska, airport from the database, enter:
01 OPTIONS AP,DEL,PANC

and example of each display command is shown in the following table.
Table 30-3 CAPDB File Display Commands
Command Description
AP,SUM The SUM command instructs JetPlan to display a listing of all airports stored under your ID.
This listing includes an explanation of the standard parameters and then shows the values
stored for each of those standard parameters per airport record.
NOTE The display of fuel price information (FP), including fuel density (FD), fuel index (FI),
currency code (FC), and fuel unit (FU), does not appear when you view a record (via PRI or
SUM) unless set to do so in the ID/Password Attribute file. Contact your Jeppesen account
Example:
To display a summary listing of all stored airports, enter the following
01 OPTIONS AP,SUM

853
Database Management
Table 30-3 CAPDB File Display Commands (continued)
Command Description
AP,PRI The PRI command displays the entire contents of a record. You must include the file name
of the record you wish to display.
NOTE The display of fuel price information (FP), including fuel density (FD), fuel index (FI),
currency code (FC), and fuel unit (FU), does not appear when you view a record (via PRI or
SUM) unless set to do so in the ID/Password Attribute file. Contact your Jeppesen account
Example:
01 OPTIONS AP,PRI,RJAA

854
Airport Fleet Database
About the Customer Airport Fleet Database
About the Customer Airport Fleet

Database
The Customer Airport Fleet database (CAPFDB) gives you control over parameters that
support various features and functionality. Many of the CAPFDB parameters support the
automatic alternate feature or other operational requirements for “non-standard” or emergency
(divert) situations.
The CAPFDB allows you to store and manage data that is related to a specific airport and a
specific aircraft fleet type. A fleet type is the Jeppesen generic aircraft ID that defines a
specific airframe/engine combination. (For more information about generic aircraft identifiers,
see the “Aircraft Type Commands” chapter in the JetPlan User Manual.)
A CAPFDB record stores default parameter values that apply each time you create a flight
plan request using a given airport/fleet type combination. Each record in the CAPFDB must
contain, at a minimum, the airport and fleet type information. When you create a flight plan
request, the airport and fleet type in the request serve as a key to the data in the CAPFDB
record.
The parameters that you can store in the CAPFDB are covered in “Database Parameters” on
page 859.
About Taxi Time Adjustment Sets

You can set base and adjustment taxi-in and taxi-out values in the CAPFDB and in the City
Pair Fleet database (CPFDB). The CAPFDB and CPFDB taxi-in and taxi-out values are used
only if there is not a taxi value of higher precedence. Precedence for taxi-out and taxi-in values
is determined separately. User input of POD or POA taxi values on a given flight plan request
override CPFDB taxi values, while the CPFDB taxi values take precedence over the CAPFDB
values.
For detailed information about the taxi-time adjustment sets and the order of precedence, see
the “City Pair Fleet Database” chapter in the JetPlan User Manual or the Help topic on
JetPlan.com.

857
About the Customer Airport Fleet Database
About Runway-to-Runway Planning and the Preferred

Runways Parameters
IMPORTANT The Preferred Runways Database is a separate database, but it is

combined with the Airport Fleet database in JetPlan.com as a convenience to
customers. If you use the JetPlan command-line interface to manage your databases,
note that the 01 Option maintenance command for the Preferred Runways Database
is RWY.For complete information on using the command-line interface to maintain
Preferred Runways Database records, see the
The Runway-to-Runway feature uses departure and arrival runway values from the Preferred
Runways Database. In JetPlan.com, the parameters from the Preferred Runways Database
appear on the Runways page in the Airport Fleet Database. (See IMPORTANT note above.)
You can use the departure and arrival runway parameters to define preferred departure and
arrival airports, rank them, and specify maximum allowable crosswind and tailwind values for
them. When these parameters are configured, JetPlan attempts to use your preferred departure
and arrival runways when applying terminal SID and STAR procedures in flight plan
computations. If preferred runway records exist, JetPlan validates them against the predicted
wind speed and direction in the current Terminal Area Forecast (TAF) for the ETD or ETA.
When computing the flight plan, JetPlan uses your highest-ranked preferred departure or
arrival runway that passes the TAF-validation check.
NOTE For more information on the Runway-to-Runway feature, see “Chapter 6,

“Route Commands.”

858
Database Parameters
Database Parameters
The following table lists the parameters that can be set in the CAPFDB. These parameters
appear as options on the CAPFDB pages in JetPlan.com. As you perform database tasks,
consult this table for information.

database codes under the parameter names.
Table 31-1 CAPFDB Parameters
Airport (Required) The ICAO or IATA identifier for the airport.
Clicking the ICAO identifier opens the Change Airport Fleet Record pages.
Fleet Type (Required) Fleet Type refers to a specific airframe/engine combination. The
Fleet Type value is the generic aircraft ID from the JetPlan Aircraft Library.
For instance, 777E is the JetPlan generic ID for the aircraft type with ICAO
identifier B772.
Misc and Cost Index Parameters
Maximum Takeoff Weight This parameter limits the maximum takeoff weight at a given airport for a
TW given fleet type. The value entered here limits the setting in the generic
aircraft database or Customer Aircraft Database (CADB). However, this
ex. TW=689000
parameter can be overridden with an ad hoc input on the POD or POA
weight command line.
Defines a weight value maximum, in pounds or kilos, for the key airport
and fleet type.
Input value: Up to seven digits
NOTE Neither this value, nor the ad hoc value, can exceed the lesser of the
generic aircraft or Customer Aircraft Database (CACDB) Maximum Takeoff
Weight (MTOW) value.
Maximum Landing Weight This parameter limits the maximum landing weight at a given airport for a
LW given fleet type. The value functions in a similar manner to the TW
parameter.
ex. LW=590000
Defines a weight value maximum, in pounds or kilos, for the key airport
and fleet type.
NOTE Neither this value, nor the ad hoc value, can exceed the lesser of the
generic aircraft or Customer Aircraft Database (CACDB) Maximum Landing
Weight (MLDW) value.

859
Database Parameters
Table 31-1 CAPFDB Parameters (continued)
Approach Plate Available Defines the availability of approach plate material for the key airport.
AP Input value: Yes or No. Required to be Y in order for the airport to be
ex. AP=Y considered a candidate Mountain Driftdown alternate.
Type of Operations This parameter defines the key airport’s operational status. It provides
TO information in the flight plan output and is format-dependent.
ex. TO=P Input values:
ex. TO=E • (R)egular – Flights operate at this airport on a regular, scheduled basis.
This is the default setting.
• (A)lternate – Flights can divert to this airport when proceeding to the
intended destination becomes inadvisable. Payload can be de-planed at
this airport, but not loaded.
• Re(F)ueling – Flights can be accepted for refueling purposes only.
Payload can not be removed from or added to the cargo at this airport.
• (P)rovisional – Flights can divert to this airport if the intended
destination becomes unavailable. Payload can be de-planed and
boarded.
• (C)harter – This parameter setting is not currently used and is no
longer required for Mountain Driftdown and Terrain Clearance.
• (E)mergency Only – Flights can divert to this airport only for
emergencies, such as Driftdown, ETOPS, and Reclear operations.
Ferry In Indicator NOTE The Ferry In and Ferry Out parameters are used only by certain
front-end dispatch software applications. Contact your Jeppesen account
FI
representative for more information.
ex. FI=Y
Input Values: Y/N/blank
• Yes – Indicates the dispatcher should ferry fuel into the airport for
administrative reasons.
• No – Indicates the dispatcher should not ferry fuel into the airport.
• Blank – Indicates the dispatcher should ferry fuel into the airport if it
makes economic sense to do so.
Ferry Out Indicator NOTE The Ferry In and Ferry Out parameters are used only by certain
front-end dispatch software applications. Contact your Jeppesen account
FO
representative for more information.
ex. FO=Y
Input Values: Y/N/blank
• Yes – Indicates the dispatcher should ferry fuel out of the airport for
administrative reasons.
• No – Indicates the dispatcher should not ferry fuel out of the airport.
• Blank – Indicates the dispatcher should ferry fuel out of the airport if it
makes economic sense to do so.

860
Database Parameters
Cockpit and Cabin Crew Parameters
City Pair Fleet Database (CPFDB) record, combined with the Lateness Cost parameter values in the CPFDB
record. If the CPFDB record does not contain crew cost parameter values, the system uses crew cost parameter
values in the CAPFDB record, combined with the Lateness Cost parameter values in the CPFDB record. If the
CAPFDB also does not contain crew cost parameter values, the system uses crew cost values in the Aircraft
Fleet Database (ACFDB) record. See the “Cost Index Commands” chapter in the JetPlan User Manual for
information about MACI.
Default Cockpit Crew Number Sets the default cockpit crew count; used when computing total cost if no
NCOD crew count is passed in the flight plan request.
ex. NCOD=3 Input value: 0–99
Cockpit Crew Cost On Sets the fixed cost for the cockpit crew for on-time arrivals.
OSRO
ex. OSRO=2,000
Cockpit Crew Cost Over Sets the fixed cost for the cockpit crew for late arrivals.
VSRO
ex. VSRO =3,000
Default Cabin Crew Number Sets the default cabin crew count; used when computing total cost if no
NCAD crew count is passed in the flight plan request.
ex. NCAD=3 Input value: 0–99
Cabin Crew Cost On Schedule Sets the fixed cost for the cabin crew for on-time arrivals.
OSRA Input value: Dollars/hour, range=0–10,000
ex. OSRA =5,000
Cabin Crew Cost Over Sets the fixed cost for the cabin crew for late arrivals.
VSRA
ex. VSRA =7,500

861
Database Parameters
Climb/Descent Profile Calculation Method
The climb/descent profile calculation parameters are used with the Climb or Descent Method parameters in
the Customer Aircraft Database (CADB). See the Help document for the CADB on JetPlan.com for
information about the Climb/Descent Method parameters.
RALT – Maximum altitude Sets the speed transition altitude. This is the altitude at which the aircraft is:
with speed restriction • Accelerated from the transition climb speed limit to the climb
calibrated airspeed (CAS)
- and/or -
• Decelerated from the descent CAS to the transition descent limit.
Input value: 0–999
NOTE If RALT=0 (is not set) in the CAPFDB, the system defaults to 100
(10000FT) for Boeing and Airbus aircraft.
RIASC – Initial climb speed Sets the transition climb speed limit (altitude is less than the value of the
limit RALT parameter).
NOTE If RIASC=0 (is not set) in the CAPFDB, the system defaults to 250
knots for Boeing and Airbus aircraft.
CASC – Climb speed in CAS Sets the climb Calibrated Airspeed (CAS) (altitude is greater than the value
of the RALT parameter). This is the constant CAS until the MACH number
is equal to the climb speed in MACH at the crossover altitude.
MACHC – Climb speed in Sets the climb speed at the constant MACH number, which is equal to the
MACH cruise MACH number (altitude is greater than the value of the crossover
altitude).
Input value: Mach number in thousands
Example: 780 is expressed as 0.78
RIASD – Final descent speed Sets the transition descent speed limit (altitude is less than the value of the
limit RALT parameter).
NOTE If RIASD=0 (is not set) in the CAPFDB, the system defaults to 250
knots for Boeing and Airbus aircraft.
CASD – Descent speed in Sets the descent constant CAS (altitude is less than the value of the
CAS crossover altitude).
MACHD – Descent speed in Sets the descent speed at the constant MACH number, which is equal to the
MACH cruise MACH number until the CAS speed is equal to CASD (crossover
altitude).
Input value: Mach number in thousands
Example: 780 is expressed as 0.78

862
Database Parameters
Alternate Requirements Parameters
These parameters support the automatic alternate feature. See the “Hold-Alternate Commands” chapter in the
JetPlan User Manual for more information.
Takeoff Alternate Airport This parameter supports the Automatic Alternate feature. It specifies an
TA airport as your preferred (takeoff) alternate when the key airport is a
departure airport in the flight plan. It is the first airport scrutinized as a
ex. TA=KXXX
possible takeoff alternate in the automatic alternate selection process.
Input value: Valid ICAO ID
Max Distance to Takeoff This parameter sets a (radius) distance limit to the proximity search for
Alternate candidate takeoff alternate airports in the automatic alternate selection
MA process. The distance is relative to the key airport when used as a POD.
ex. MA=1000 Input value: Nautical miles, up to four digits (thousands of miles)
Max Distance to Destination This parameter is equivalent to the Max Distance to Takeoff Alternate
Alternate parameter but applies to destination alternates. The distance value is
MD relative to the key airport when used as a POA.
ex. MD=750 Input value: Nautical miles, up to four digits (thousands of miles)
Alternate Proximity List This parameter sets the maximum number of airports returned by the
Length proximity search service.
ALTL Input value: 0–100
ex. ALTL=100
Preferred Destination Each parameter defines an airport identifier.
Alternate Airports (Nos. 1–8) These parameters identify, in succession, airports you wish to designate as
A1–A8 preferred arrival alternates when the key airport is an arrival airport.
ex. A1=KXXX Input value: Valid ICAO IDs
Alternate Availability Parameters

These parameters support the automatic alternate feature. See the “Hold-Alternate Commands” chapter in the
Departure Alternate Defines the key airport as available for use as a departure (takeoff) alternate
DA for the key fleet type.
ex. DA=Y Input value: Yes or No
Enroute Alternate Defines the key airport as available for use as an enroute alternate for the
EA key fleet type.
ex. EA=Y Input value: Yes or No
AIR OPS Enroute Alternate Defines the key airport as available for use as an enroute alternate for
(JAR/EU Operations automatic enroute alternate selection. Applies to AIR OPS only.
Alternate) Input value: Yes or No
EU
ex. EU=Y

863
Database Parameters
Arrival Alternate Defines the key airport as available for use as a destination alternate for the
AA key fleet type.
ex. AA=Y Input value: Yes or No
ETOPS Suitable Alternate NOTE This parameter is used only with ETOPS 2 flight plan options.
ESU
Defines the airport as acceptable for use in the flight plan as an ETOPS
alternate, typically based on its inclusion in the carrier's operations
specification. To be deemed suitable for inclusion in a flight plan as an
ETOPS alternate, the airport requires the following conditions to be true
between the planned earliest and latest arrival times:
• The weather is forecast above minimums.
• Field condition reports indicate that a safe landing can be made.
• The forecast crosswinds and tailwinds do not exceed certified limits
for the aircraft.
Input value: Y/N
ETOPS Adequate Alternate NOTE This parameter is used only with ETOPS 2 flight plan options.
EAD
Defines the airport as an ETOPS adequate alternate, for use in calculating
the ETOPS area of operation. An airport is considered adequate if it is
certified as an FAR Part 139 airport or is equivalent with respect to safety
requirements. It needs to have a runway of sufficient length, width and
strength, airport services, emergency equipment, field reporting conditions
(NOTAMS), hourly weather reporting (METARS) and an instrument
approach other than GPS.
Input value: Y/N
Enroute Alternate in Terrain This parameter activates the key airport as a possible enroute alternate in
Driftdown Operations the automatic alternate selection process when the Mountain Driftdown
TD feature is employed in the flight plan.
ex. TD=N Input value: Yes or No
Enroute Alternate in This parameter activates the key airport as a possible enroute alternate in
ETOPS/Overwater Driftdown the automatic alternate selection process when either the ETOPS or the
Operations Basic (Overwater) Driftdown feature is employed in the flight plan.
ET Input value: Yes or No
ex. ET=N

864
Database Parameters
Approach Parameters
Precision Approach Defines the ceiling minimum for the airport in feet or meters. This
POA Ceiling Minimum parameter is applicable when the airport is used as an arrival airport.
P1 Input value: 0–10000 feet or meters
ex. P1=350 Feet is the default. To specify meters in the command-line interface, you
must append the input with the letter M (P1=500M). To change from
meters to feet, you must append the input with the letter F (P1=500F).
Precision Approach Defines the visibility minimum for the airport in feet or meters. This
POA Visibility Minimum parameter is applicable when the airport is used as an arrival airport.
P2 Input value: 0–10000 feet or meters
ex. P2=2400F Feet is the default. To specify meters in the command-line interface, you
Precision Approach Defines the ceiling minimum for the airport in feet or meters. This
Alternate Ceiling Minimum parameter is applicable when the airport is used as an alternate.
P3 When the Precision Minima (PMIN) flight plan option is used, this
precision approach parameter is a weather criteria check in the automatic
ex. P3=600
alternate selection process.
When the PMIN flight plan option is used, JetPlan uses the Precision
Approach Alternate Ceiling Minimum and the Precision Approach
Alternate Visibility Minimum values to check the suitability of alternate
airports. (When the PMIN option is not used, JetPlan uses the more
conservative Non-Precision Approach Alternate Ceiling and Visibility
Minimum values to check suitability of alternates. See the definitions of
those parameters below.)
By default, JetPlan first checks the Airport Fleet database for the Precision
Approach Alternate Ceiling Minimum value. If the value in the Airport
Fleet database is zero, JetPlan gets the value from the Customer Airport
database.
NOTE A customer preference setting allows you to change the database
used as the default source of the Precision Approach Alternate Ceiling
Minimum and Precision Approach Alternate Visibility Minimum values.
Contact your Jeppesen Account Representative for information.
See the “Hold-Alternate Commands” chapter in the JetPlan User Manual
Input value: 0–10000 feet or meters
Feet is the default. To specify meters in the command-line interface, you

865
Database Parameters
Precision Approach Defines the visibility minimum for the airport in feet or meters. This
Alternate Visibility Minimum parameter is applicable when the airport is used as an alternate.
P4 When the Precision Minima (PMIN) flight plan option is used, this
precision approach parameter is a weather criteria check in the automatic
ex. P4=9999F
alternate selection process.
When the PMIN flight plan option is used, JetPlan uses the Precision
Approach Alternate Visibility Minimum and the Precision Approach
Alternate Ceiling Minimum values to check the suitability of alternate
airports. (When the PMIN option is not used, JetPlan uses the more
conservative Non-Precision Approach Alternate Ceiling and Visibility
Minimum values to check suitability of alternates. See the definitions of
those parameters below.)
By default, JetPlan first checks the Airport Fleet database for the Precision
Approach Alternate Visibility Minimum value. If the value in the Airport
Fleet database is zero, JetPlan gets the value from the Customer Airport
database.
used as the default source of the Precision Approach Alternate Ceiling
Minimum and Precision Approach Alternate Visibility Minimum values.
Non-Precision Approach Defines the ceiling minimum for the airport in feet or meters. This
POA Ceiling Minimum parameter is applicable when the airport is used as an arrival airport.
N1 Input value: 0–10000 feet or meters
ex. N1=500 Feet is the default. To specify meters in the command-line interface, you
must append the input with the letter M (N1=500M). To change from
meters to feet, you must append the input with the letter F (N1=500F).
Non-Precision Approach Defines the visibility minimum for the airport in feet or meters.This
POA Visibility Minimum parameter is applicable when the airport is used as an arrival airport.
N2 Input value: 0–10000 feet or meters
ex. N2=3200F Feet is the default. To specify meters in the command-line interface, you

866
Database Parameters
Non-Precision Approach NOTE The Precision Minima (PMIN) flight plan option uses the Precision
Approach Alternate Ceiling and Visibility Minimum values to check suitability
of alternate airports. See definitions of those parameters above.
N3
Defines the ceiling minimum for the airport in feet or meters. This
ex. N3=800 parameter is applicable when the airport is used as an alternate.
This non-precision approach parameter is a weather criteria check in the
automatic alternate selection process. When JetPlan checks the suitability
of an airport as an alternate (departure, en route, or arrival alternate) it
might perform a “TAF check” on that airport. That is, it compares the TAF
forecast with the landing minima values for the candidate alternate airport.
By default, JetPlan first checks the Airport Fleet database for the Non-
Precision Approach Alternate Ceiling Minimum value. If the value in the
Airport Fleet database is zero, JetPlan gets the value from the Customer
Airport database.
used as the default source of the Non-Precision Approach Alternate Ceiling
Minimum and Non-Precision Approach Alternate Visibility Minimum values.

867
Database Parameters
Non-Precision Approach NOTE The Precision Minima (PMIN) flight plan option uses the Precision
Approach Alternate Ceiling and Visibility Minimum values to check suitability
of alternate airports. See definitions of those parameters above.
N4
Defines the visibility minimum for the airport in feet or meters. This
ex. N4=9999F parameter is applicable when the airport is used as an alternate.
This non-precision approach parameter is a weather criteria check in the
automatic alternate selection process. When JetPlan checks the suitability
of an airport as an alternate (departure, en route, or arrival alternate) it
might perform a “TAF check” on that airport. That is, it compares the TAF
forecast with the landing minima values for the candidate alternate airport.
By default, JetPlan first checks the Airport Fleet database for the Non-
Precision Approach Alternate Visibility Minimum value. If the value in the
Airport Fleet database is zero, JetPlan gets the value from the Customer
Airport database.
used as the default source of the Non-Precision Approach Alternate Ceiling
Minimum and Non-Precision Approach Alternate Visibility Minimum values.
ETOPS Approach NOTE This parameter is used only with ETOPS 2 flight plan options.
ECM This parameter defines the ceiling minimum for the airport in feet or
meters. It is used to determine if an ETOPS alternate is suitable based on
the TAF weather between the Early Arrival Time and later arrival time.
This parameter works in conjunction with the ETOPS Ceiling Minimum
parameter in the Customer Airport database. If there is not a minimum
value in the Customer Airport Fleet database, JetPlan checks for the
minimum in the Customer Airport database. If there is no minimum value
in the Customer Airport database, JetPlan uses zero ceiling.

868
Database Parameters
ETOPS Approach NOTE This parameter is used only with ETOPS 2 flight plan options.
EVM This parameter defines the visibility minimum for the airport in feet or
meters. This parameter is used to determine if an ETOPS alternate is
suitable based on the TAF weather between the Early Arrival Time and
later arrival time.
This parameter works in conjunction with the ETOPS Visibility Minimum
parameter in the Customer Airport database. If there is not a minimum
value in the Customer Airport Fleet database, JetPlan checks for the
minimum in the Customer Airport database. If there is no minimum value
in the Customer Airport database, JetPlan uses zero visibility.
Taxi Time Segment Parameters

You can set base and adjustment taxi-in and taxi-out values in the CAPFDB and in the City Pair Fleet
(CPFDB) database. The CPFDB taxi values take precedence over the CAPFDB taxi values. For detailed
information about the taxi time adjustment sets and the order of precedence, see the “City Pair Fleet
Database” Help topic.
NOTE For the Taxi Time Adjustment values to be used, the Default Block Time (DBT) field in the CPFDB must
be set to a non-zero value, and a Customer Aircraft database record with the Taxi Fuel Flow (TX) value set must
be used.
Set 1 Taxi Time Adjustment Segments
Set 1 Start Date Effective start date of Set 1 taxi time adjustments.
WDM Input value: Day and Month (ddmm)
Set 1 Start Year The year setting is optional. The start date and time apply to each and every
WYR year if year is not set.
Input value: Year (YYYY)
Set 1 Start Time (HHMM) Effective start time of Set 1 taxi time adjustments.
WHM Input value: 0000–2359 (HHMM)
Set 1 Base Taxi Out Time Indicates the average amount of taxi-out time for the specified airport fleet
BTOW for Set 1 taxi time adjustments.
Set 1 Base Taxi In Time Indicates the average amount of taxi-in time for the specified airport fleet
BTIW for Set 1 taxi time adjustments.
Set 1 Segment# Effective start time for the given Set 1 Taxi Time adjustment (1–60) in
Effective Start Time HHMM.
1–60 Input value: 0000–2359
STW#

869
Database Parameters
Set 1 Taxi Out Adjustment Defines the adjustment to the Base Taxi Out Time defined for the airport
1–60 fleet when the flight's scheduled departure time is between the Start Time
TOW# and End Time for the specified taxi adjustment set.
Input value: -99–99 minutes (negative values are possible)
Set 1 Taxi In Adjustment Defines the adjustment to the Base Taxi In Time defined for the airport
1–60 fleet, when the flight's ETD plus DBT is between the Start Time and End
Time for the specified taxi adjustment set.
TIW#
Input value: -99–+99 (negative values are possible)
SDM Input value: day and month (ddmm)
Set 2 Start Year The year setting is optional. The start date and time apply to each and every
SYR year if year is not set.
Input value: Year (YYYY)
Set 2 Start Time (HHMM) Effective start time of Set 2 taxi time adjustments.
SHM Input value: 0000–2359 (HHMM)
Set 2 Base Taxi Out Time Indicates the average amount of taxi-out time for the specified airport fleet
BTOS Set 2 taxi time adjustments.
Set 2 Base Taxi In Time Indicates the average amount of taxi-in time for the specified airport fleet
BTIS Set 2 taxi time adjustments.
Set 2 Segment # Effective start time for the given Set 2 Taxi-In Time adjustment (#1–60) in
Effective Start Time HHMM
#1–60 Input value: 0000–2359
STS#
Set 2 Taxi Out Adjustment Defines the adjustment to the Base Taxi Out Time defined for the airport
#1–60 fleet, when the flight's scheduled departure time is between the Start Time
and End Time for the specified taxi adjustment set.
TOS#
Input value: -99–+99 minutes (negative values are possible)
Set 2 Taxi In Adjustment Defines the adjustment to the Base Taxi In Time defined for the airport
#1–60 fleet, when the flight's ETD plus DBT is between the Start Time and End
Time for the specified taxi adjustment set.
TIS#
Input value: -99–+99 (negative values are possible)

870
Database Parameters
Minimum Fuel On Destination (MFOD) Parameters
Begin Time for Time There are four sets of time ranges, and each time range has a Begin Time
Ranges #1–4 parameter, which is used in conjunction with the End Time parameter to
TB1–TB4 define a time range that is applied to the Minimum Fuel On Destination
parameter.
ex. TB1=1230
Input value: HHMM
ex. TB4=1230
End Time for Time There are four sets of time ranges, and each time range has an End Time
Ranges #1–4 parameter, which is used in conjunction with the Begin Time parameter to
TE1–TE4 define a time range that is applied to the Minimum Fuel On Destination
parameter.
ex. TE1=1530
Input value: HHMM
ex. TE4=1530
Time Flag for Time Defines the clock used in establishing the Minimum Fuel On Destination
Ranges #1–4 Time range for each of the four time ranges.
TF1–TF4 Input value: U (Universal) or L (Local)
ex. TF1=U
ex. TF4=L
Minimum Fuel On Destination Defines a weight, in pounds or kilos, that represents the minimum amount
(MFOD) for Time Ranges #1– of fuel the aircraft should have on landing at the arrival (key) airport.
4 The value you enter is tied to the time range defined by the Begin Time and
MF1–MF4 End Time parameters. You can define multiple time ranges using the time
ex. MF1=5000 range parameters (TB1–TB4 and TE1–TE4), providing different fuel
minimums (using MF1–MF4 parameters) for different times of the day.
ex. MF4=15000
Thus, you can plan for late day delays due to increased traffic or weather
buildup.

871
Database Parameters
Departure and Arrival Biases Parameters
These parameters allow you to apply departure and arrival biases based on the combination of a specific
aircraft fleet type and airport.
Departure Bias For Fuel, Allows you to enter departure biases for one or all of the following: fuel,
Time, and/or Distance time, and minimum distance.
DB Applying biases via the CAPFDB has the following ramifications:
ex. DB=250,4,0 • The biases stored in the CAPFDB override any stored in the Customer
ex. DB=0,15,0 Schedule Database.
or • Any biases applied (ad hoc) to the flight plan request are added to
those stored in the CAPFDB (they accumulate).
DBF
• Any biases stored in the Customer Aircraft Database are added to
ex. DBF=250
DBT
There are two methods for entering bias information. The first method uses
ex. DBT=5 the DB parameter. With this parameter you must enter a value for each bias
DBD factor in the following order: Fuel, Time and Distance. Separate each value
ex. DBD=20 with a comma. To omit one or more factors, you can enter a value of zero
(0). Example: DB=250,4,0
The second method uses suffixes applied to the DB parameter for fuel
(DBF), time (DBT), and distance (DBD) to distinguish between and allow
individual input. With this method, if you wish to omit a particular bias
factor, simply omit the input altogether.
Example: DBF=250
Input values:
• Fuel in pounds
• Time in minutes
• Distance in nautical miles

872
Database Parameters
Arrival Bias For Fuel, Time, Allows you to enter arrival biases for one or all of the following: fuel, time,
and/or MIN Distance and minimum distance.
AB Applying biases via the CAPFDB has the following ramifications:
ex. AB=500,0,20 • The biases stored in the CAPFDB override any stored in the Customer
ex. AB=0,5,0 Schedule Database.
or • Any biases applied (ad hoc) to the flight plan request are added to
ABF
• Any biases stored in the Customer Aircraft Database are added to
ex. ABF=500
ABT
There are two methods for entering bias information. The first method uses
ex. ABT=10 the DB parameter. With this parameter you must enter a value for each bias
ABD factor in the following order: Fuel, Time and Distance. Separate each value
ex. ABD=25 with a comma. To omit one or more factors, you can enter a value of zero
(0). Example: AB=500,0,20
The second method uses suffixes applied to the DB parameter for fuel
(DBF), time (DBT), and distance (DBD) to distinguish between and allow
individual input. With this method, if you wish to omit a particular bias
factor, simply omit the input altogether.
Example: ABF=500
Input values:
• Fuel in pounds
• Time in minutes
• Distance in nautical miles
HUB Defines an airport as high-density or not.
ex. HUB=Y If the hub parameter is set to Y(es) (HUB=Y), then the arrival fuel bias in
the Customer Aircraft Database is used from the POA to the alternate.
If the hub parameter is set to N(o) (HUB=N), then the bias is not used.
Departure and Arrival Runway Parameters

The departure and arrival runway parameters are used in the JetPlan Runway-to-Runway feature. For a
summary of this feature, see “About Runway-to-Runway Planning and the Preferred Runways Parameters” on
page 858.
IMPORTANT The Preferred Runways Database is a separate database, but it is combined with the Airport
Fleet database in JetPlan.com as a convenience to customers. If you are using JetPlan command line
commands to manage the preferred departure and arrival runways, do not use the APF 01 Option. The 01
Option for managing these parameters is RWY. The JetPlan command-line codes for the parameters are under
the parameter names below. For complete information on using command line to maintain the departure and
arrival runway parameters, see Chapter 39, “Preferred Runways Database.”
Departure Runway In JetPlan.com, indicate that a runway is a departure runway by typing

D runway information in the Departure Runways area on the Runways
page.
Arrival Runway In JetPlan.com, indicate that a runway is an arrival runway by typing

A runway information in the Arrival Runways area on the Runways page.

873
Database Parameters
Rank (Required) The ranking order for this runway, where 1 represents the top-
<n> ranked runway, 2 represents the second-ranked runway, and so on.
Example: 1
Runway The runway identifier. Valid input values: 1–3 alphanumeric characters.
RWY= Example: 15R
Max Crosswind The maximum acceptable crosswind for the runway, in knots.
MX= If TAF is enabled, JetPlan checks the crosswinds for the given airport,
runway, and time-window combination and returns only runways that do
not exceed this maximum value. If no acceptable runway is found,
preferred runway data is not used in the flight plan calculation.
If TAF is not enabled, JetPlan returns the runway ranked as number 1 for
the airport.Valid input values: 00-99. Example: 30
Max Tailwind The maximum acceptable tailwind for the runway, in knots.
MT= If TAF is enabled, JetPlan checks the crosswinds for the given airport,
runway, and time-window combination and returns only runways that do
not exceed this maximum value. If no acceptable runway is found,
preferred runway data is not used in the flight plan calculation.
If TAF is not enabled, JetPlan returns the runway ranked as number 1 for
the airport.Valid input values: 00-99. Example: 10

874
Database Management
Database Management
IMPORTANT If you are using JetPlan command line commands to manage the
preferred departure and arrival runways, do not use the APF 01 Option.The 01 Option
for managing the preferred departure and arrival runways is RWY. For complete
information, see Chapter 39, “Preferred Runways Database.”

To make the CAPFDB a data resource for flight planning, you must first create and manage
JetPlan command-line interface, the CAPFDB access command is APF, and it is entered on
the Options command line. Any attempt to affect or reference the information in the database
must begin with this command.
CAPFDB command functions are divided into two categories: file maintenance and file
display. These categories are listed below with the respective functions.
Two categories of command functions are available when accessing the CAPFDB. These
File Maintenance
• CPY – Copies a record to a new record

875
Database Management
File Display
• SUM – Displays a list of records
• RID – Displays the record identifiers
• SRH – Search for records
The record that you affect with a function command can be referenced by an airport, by a fleet
type, or by the combination of the two. When creating a new record you must enter both
reference keys, with the airport listed first. The input structure has the following syntax:
APF,function command,arpt,fleet type,parameter 1,parameter

2,parameter 3,and so on.
The following example illustrates the creation of a new record for the airport, KLAX, and the
fleet type, B747. All parameter settings are strictly optional. Therefore, the parameters shown
are just examples.
Example:
01 OPTIONS APF,SAV,KLAX,B747,TA=KBUR,MA=100,A1=KBUR,MD=400
NOTE You can include any or all parameters (see Table 31-1 on page 859) when
saving or changing records in the database. In fact, you can even omit all parameter
settings if you just want to have a record in the database for the airport and fleet type.
The parameter settings for such a record can be addressed at another time using the
CHG function. The point is that a record is created or affected by the input of the
access command (APF), the function command (SAV), and the file keys (Airport ID
and Fleet type).
The CAPFDB record key elements are described in the following table.
Table 31-2 CAPFDB Record Key Elements
Airport (Required) The ICAO or IATA identifier for the airport.
Fleet Type (Required) Fleet Type refers to a specific airframe/engine combination.

The Fleet Type value is the generic aircraft ID from the JetPlan Aircraft
Library. For instance, 777E is the JetPlan generic ID for the aircraft type
with ICAO identifier B772.

876
Database Management
CAPFDB Commands
The CAPFDB command functions are divided into two categories: file maintenance and file

Table 31-3 CAPFDB File Maintenance Commands
Command Description
APF,SAV The SAV command allows you to create a new record of information for a particular airport
and aircraft fleet type. Specify these keys and any parameter you wish to set.
Example:
01 OPTIONS APF,SAV,KSFO,B747,TA=KOAK,MA=100,A1=KOAK
APF,CHG The CHG command allows you to modify the parameter settings of a previously stored
record. The input is similar to the SAV input. You can add new parameter settings to the
record, change setting values, or reset values to their original (default) state. To reset a
parameter to its default value, enter the parameter without a value input. For example, to
reset the MA parameter to its default value, enter the following:
Example:
01 OPTIONS APF,CHG,KSFO,B747,MA

877
Database Management
Table 31-3 CAPFDB File Maintenance Commands (continued)
Command Description
APF,CHG,$$ The global CHG command can be used to make global changes to various records by using
the wild card variable, $, in place of the airport and/or fleet type identifiers.
To affect records by airport identifier only, substitute the wild card variable for the fleet type
identifier.
Example:
Explanation: Change the Maximum Allowable Distance to Takeoff Alternate (MA
parameter) for all records keyed to KLAX, regardless of fleet type.
01 OPTIONS APF,CHG,KLAX,$,MA=500
To affect records by fleet type only, substitute the wild card variable for the airport
identifier.
Example:
parameter) for all records keyed to the B747 fleet type, regardless of airport ID.
01 OPTIONS APF,CHG,$,B747,MA=350
To affect all records, substitute the wild card variable for both the airport identifier and the
fleet type identifier.
Example:
parameter) for all records.
01 OPTIONS APF,CHG,$,$,MA=350
APF,DEL As shown previously, deleting a parameter setting within a record (setting its value to the
default value) requires the omission of the value input for that parameter within a CHG
command entry. The DEL command, however, allows you to remove a complete record
from the database. Like the global change command, you have multiple ways of deleting
records in this database. You can remove a specific record, all records for one or more
airports, or all records for a particular fleet type. See the examples below.
To delete a particular record, specify both the airport and the fleet type.
Example:
Explanation: Delete the record keyed to KLAX and the fleet type, B747.
01 OPTIONS APF,DEL,KLAX,B747
To delete all records for a particular airport, specify the airport only.
Example:
Explanation: Delete all records keyed to KLAX.
01 OPTIONS APF,DEL,KLAX
To delete all records for a particular fleet type, specify the fleet type. However, in this case
you must fill the airport field with the wild card variable.
Example:
Explanation: Delete all records keyed to the fleet type, B747.
01 OPTIONS APF,DEL,$,B747

878
Database Management
Table 31-3 CAPFDB File Maintenance Commands (continued)
Command Description
APF,CPY The CPY command allows you to copy the contents of a record for one fleet type to a record
for another fleet type.
Example:
01 OPTIONS APF,CPY,B747,B757

Table 31-4 CAPFDB File Display Commands
Command Description
APF,SUM The SUM command instructs JetPlan to display a listing of all records stored under your ID.
This listing includes a brief description of the standard parameters and shows the values
stored for each of those parameters per airport/fleet type record. To display a summary
listing of all stored airport/fleet type records, enter the following:
Example:
01 OPTIONS APF,SUM
You can display the same information, but list the airports by their IATA identifiers by using
the option, IATA, after the SUM command.
Example:
01 OPTIONS APF,SUM,IATA
You can also display listings by airport or fleet type.
Example:
01 OPTIONS APF,SUM,KLAX
Example:
01 OPTIONS APF,SUM,$,B747
APF,RID The RID command displays only the identifiers (only the airport and fleet names) for all
records in the APF database.
Example:
01 OPTIONS APF,RID

879
Database Management
Table 31-4 CAPFDB File Display Commands (continued)
Command Description
APF,PRI The PRI command works in the same manner as the SUM function. The output is similar to
that shown under a SAV function. You can print a display of a particular record by
referencing both the airport and the fleet type, or you can print a display of all records for a
particular airport or a particular fleet type. In the case of a particular fleet type, you must
include the wild card variable, $, in the field reserved for the airport identifier.
Example:
Explanation: Print record for airport, KSFO, and fleet type, B747.
01 OPTIONS APF,PRI,KSFO,B747
Example:
Explanation: Print all records for airport, KSFO.
01 OPTIONS APF,PRI,KLAX
Example:
Explanation: Print all records for fleet type, B747.
01 OPTIONS APF,PRI,$,B747
APF,SRH The SRH command allows a user to filter records based on any of the parameters mentioned
above in “Database Parameters.”
Example:
Explanation: Search for airport records that are ETOPS approved (ET=Y) and have a
maximum landing weight of 550,000 lbs (LW=550000).
01 OPTIONS APF,SRH,ET=Y,LW=550000

880
C HAPTER 32
Generic Airport
Database
Generic Airport Database
About the Generic Airport Database
About the Generic Airport Database

You can use the customer Generic Airport Database to create records for private airfields,
military airports, and other airports that are not already in JetPlan. You can then use your
generic airport records in flight planning.
For example, you might need to create a flight plan to a small airport that has runways shorter
than 5,000 feet. In general, however, JetPlan loads only airports with runways over 5,000 feet
into the system. In this instance, you could add the small airport to your Generic Airport
Database and then use it in your flight plans.
To complete a new generic airport record, you need to determine information such as the
airport’s ARINC 424 area code, latitude and longitude coordinates, magnetic variation, and so
on. For airports that have not been loaded into JetPlan, you can find information in aviation
charts, government documents—such as the Airport/Facility Directory published by the
FAA—and ARINC 424 specification documents published by Aeronautical Radio Inc.
See “Database Parameters” on page 884 for a complete list of the parameters that you need to
define in the airport record.

883
Database Parameters
Database Parameters
The following table lists the parameters that you can set in the Generic Airport Database.
These parameters appear as options on the Change Generic Airport Record page in
JetPlan.com. As you perform database tasks, consult this table for information.
NOTE If you have any questions about locating or recording the data required to
create a generic airport database record, contact your Jeppesen account
representative.

database codes in parentheses beneath the corresponding parameter names. For
example, LA is the JetPlan database code for the Latitude parameter. Some JetPlan
database codes also appear as parameter abbreviations on JetPlan.com pages.
Table 32-1 Generic Airport Database Parameters
Airport (Required) This parameter is the airport identifier.
Input value: The four-character ICAO or three-character IATA code for the
airport
Example: KGDM
Area 424 This parameter is the ARINC Area 424 code for the airport.
(A4) Input value: Two alphanumeric characters
Examples: K2, K6
IATA This parameter is the IATA identifier for the airport.

(AA) Input value: Three alphanumeric characters
Example: GDM

884
Database Parameters
Table 32-1 Generic Airport Database Parameters (continued)
Latitude This parameter is the latitude coordinate for the airport.
(LA) Input value:
Examples: Latitude expressed as [-]DDmmss00, where:
LA=40000000 • [-] denotes South
- or - • DD equals degrees
LA=-40000000 • mm equals minutes
• ss equals seconds
• 00 equals hundredths of seconds
Examples:
• 40N is 40000000
• 40S is -40000000
Longitude This parameter is the longitude coordinate for the airport.

(LO) Input value:
Examples: Longitude expressed as [-]DDDmmss00, where:
LO=102000000 • [-] denotes East
- or - • DDD equals degrees
LO=-013000000 • mm equals minutes
• ss equals seconds
• 00 equals hundredths of seconds
Examples:
• 102W is 102000000
• 130E is -013000000
Elevation This parameter is the field elevation for the airport in feet.
(EL) Input value: Up to five digits are allowed. Negative values are supported.
Examples: 350, -8
Magnetic Variation This parameter is the magnetic variation of the airport.

(MV) Input value:
• Up to three characters, including numbers, a decimal point (if needed),
and a minus sign (if needed).
• East values are prefixed by a minus sign (-). Example: -17
• Decimal values are supported.
ARTCC This parameter is the Air Route Traffic Control Center (ARTCC) for the
(AC) airport.
Input value: Three alphanumeric characters
Example: ZOA

885
Database Parameters
FIR ID This parameter is the Flight Information Region (FIR) for the airport.
(FI) Input value: Four alphanumeric characters
Examples: KZOA, EBUR
UIR ID This parameter is the Upper Information Region (UIR) for the airport.
(UI) Input value: Four alphanumeric characters
Examples: KZOA, EBBU
ICAO Address This parameter is the address used for filing ICAO flight plans.
(IA) Input value: Eight alphanumeric characters
Example: KZBWZQZX
Description This parameter is the airport name.

(DS) Input value: Up to 30 alphanumeric characters
Example: Jones Field
Longest Runway This parameter is the length in feet of the airport’s longest runway.
(LR) Input value: 0-999 feet (in hundreds)
Example: 030 (equals 3000 feet)
Com Type This parameter is the airport’s communication type. The only allowed input is
(CT) “ATI” for ATIS. Can be left blank.
Input value: ATI or blank
Com Frequency This parameter is the airport’s ATIS communication frequency.

(CF) Input value: Up to seven digits, decimal value
Example: 112.50
Time Zone This parameter is the time zone in which the airport is located.
(TZ) Input value: A four-character alphanumeric identifier in ARINC 424 time
zone format, where:
• The first character is a letter that corresponds to different time zone hours
around the world.
• The second and third characters (2-3) represent minutes added to the
time zone hour for selected countries.
• The fourth character is either Y (Yes) or N (No), indicating whether or
not daylight savings time is observed.
Example: U00Y
City This parameter is the city in which the airport is located.

(CY) Input value: Up to 24 alphanumeric characters
Example: Gardner

886
Database Parameters
State This parameter is the code for the state in which the airport is located.
(ST) Input value: Two alphanumeric characters
Example: MA
Country This parameter is the code for the country in which the airport is located.
(CO) Input value: Three alphanumeric characters
Examples: USA, GBR, NZL

887
Database Management
Database Management

To make the Generic Airport Database a data resource for your flight planning needs, you
must first create and manage records of information in the database. To do this, you need to
access the database. The Generic Airport Database access command is CGA, and it is entered
on the Options command line. Any attempt to affect or reference the information in the
database must begin with this command.
Two categories of command functions are available when accessing the Generic Airport
Database. These functional categories are listed below with the specific commands.
File Maintenance
• SAV – Adds a record to the database
• DEL – Deletes a record from the database
File Display
• PRI – Displays the content of the record

888
Database Management
The record you affect in the database is referenced by the ICAO or IATA identifier of the
airport. This identifier is the record name, and it is entered after the function command so that
the input structure has the following syntax:
CGA,function command,recordname,parameter 1=<x>,parameter

2=<x>,parameter 3=<x>
NOTE As long as the airport identifier is provided, you can include any or all other
parameters (see “Database Parameters” on page 884) when saving or changing
records in the database. The parameter settings for the record can be added at
another time.
Generic Airport Database Commands

The Generic Airport Database command functions are divided into two categories: file
maintenance and file display. This section describes each command function.

Table 32-2 Generic Airport Database File Maintenance Commands
Command Description
CGA,SAV The SAV command enables you to create a new record of information for a particular airport
in the database. Specify the airport identifier as the record name and enter any parameter
that you wish to set.
Example:
01 OPTIONS CGA,SAV,MIDA,LA=39450000,LO=105040000,EL=5000
CGA,CHG The CHG command enables you to modify the parameter settings of an airport record
previously stored in the database. The input is similar to the SAV input. You can add new
parameter settings to the record or change existing values.
Example:
To change the description (DS) and add city and state values to the record, enter:
01 OPTIONS CGA,CHG,KOWD,DS=Norwood Meml,CY=Norwood,ST=MA
CGA,DEL The DEL command enables you to remove a complete record from the database. To delete a
record, you must explicitly specify the record name.
Example:
01 OPTIONS CGA,DEL,KOWD

889
Database Management

Table 32-3 Generic Airport Database File Display Commands
Command Description
CGA,SUM The SUM command instructs JetPlan to display a listing of all generic airports stored under
your ID. This listing includes an explanation of the standard parameters and then shows the
values stored for each of those standard parameters per airport record.
Example:
01 OPTIONS CGA,SUM
CGA,PRI The PRI command displays the entire contents of a record. You must include the record
name of the record you wish to display.
Example:
01 OPTIONS CGA,PRI,KOWD

890
C HAPTER 33
City Pair Database

City Pair Database
About the City Pair Database
About the City Pair Database

You can use the City Pair Database to store and manage data related to a city pair, which is a
specific departure and arrival airport combination. A City Pair Database record stores default
parameter values that apply each time you create a flight plan request using the city pair in the
record. For example, if you create a City Pair Database record for the city pair KOAK to
KABQ, JetPlan automatically applies the information in that database record whenever you
create a flight plan request that includes the city pair KOAK to KABQ.
Note that city pairs in the database are directional. The system distinguishes between KOAK–
KABQ and KABQ–KOAK. Any parameters set in a City Pair Database record for
KOAK– KABQ are not applied in a flight plan request for a flight from KABQ to KOAK.
NOTE Some parameter values in the City Pair Database are stored in JetPlan but
are used only by certain Jeppesen front-end dispatch products, such as Jeppesen®
Dispatch Control. Consult the appropriate product documentation or contact your

893
City Pair Database
Database Parameters
Database Parameters
The following table lists the parameters that you can set in the City Pair Database. These
parameters appear as options on the City Pair Database pages in JetPlan.com. As you perform
NOTE As noted in the table below, some parameters in the City Pair Database are
stored in JetPlan but used only by certain Jeppesen front-end dispatch products.
Consult the appropriate product documentation or contact your Jeppesen account

Table 33-1 City Pair Database Parameters
POD This parameter is the ICAO or IATA code for the
(ICAO or IATA code) point of departure (POD) for the city pair.
POA This parameter is the ICAO or IATA code for the

(ICAO or IATA code) point of arrival (POA) for the city pair.
HF Radios Required NOTE This parameter is used only by certain front-

end dispatch software applications. Contact your
(HF)
This parameter indicates the number of HF Radios
required.
This value is used to indicate whether the aircraft
flying any route between the city pair needs to be
equipped with HF Communication Equipment and the
number of radios, up to nine, that are required.
JetPlan generates an alert when a specified city pair
requires HF communications, and the aircraft
specified in the flight plan request is not HF-equipped.
Input value: 0–9. Default is 0.

894
City Pair Database
Database Parameters
Table 33-1 City Pair Database Parameters (continued)
(International) Fuel Reserve Policy This parameter indicates the default international
(RP) reserve policy to apply.
Input value:
• A valid 3-digit JetPlan code for an international
fuel reserve policy. See a list of valid codes and
corresponding policies in “Domestic,
International and Island Reserves” in the
“Payload, POD/POA, Weight and Fuel
• The 4-digit JetPlan code for the B43 international
reserve policy (43xx). Example: IR=4305, where
43 represents the B43 policy and 05 represents an
application rate of 5%.
NOTE If this parameter is set to 43xx for the B43
international reserve policy, Jeppesen Dispatch Control
or another similarly capable user interface is required
to enforce the value. Contact your Jeppesen account
Bonded Fuel NOTE This parameter is stored in JetPlan but is used

only by certain front-end dispatch software
(BFI)
applications. Contact your Jeppesen account manager
The Bonded Fuel parameter indicates which Customer
Airport Database fuel price (bonded or non-bonded)
the system uses in cost index and tankering analysis
for the city pair. This indicator and the Customer
Airport Database values can be overridden on the
flight plan request via the flight planning front-end
application.
The fuel price types are defined as follows:
• Bonded – The bonded fuel price is equivalent to
the domestic (non-bonded) fuel price minus any
taxes and customs fees, which can be avoided if a
flight can be classified as International from a tax
perspective.
• Non-Bonded – The non-bonded fuel price is
equivalent to the cost “at the pump” in either
USD/Gallon or in the user’s currency or user’s
units and includes all applicable federal, state,
and local taxes.
Input value:
• B–Bonded fuel
• N – (Default) Non-bonded fuel
See also the “Customer Airport Database” chapter in

895
City Pair Database
Database Parameters
Overwater When the OWATAN or the OWATAA flight plan
(OWI) option is invoked, JetPlan checks the Overwater
parameter to determine whether an aircraft flying this
flight leg route must be subjected to overwater
consideration during flight plan computation.
The Overwater parameter must be set to Yes for
JetPlan to subject the flight plan computation to
overwater considerations when the Overwater Avoid
(FP, OWATAA) or Overwater Alert (FP, OWATAN)
flight plan option is specified. If the Overwater
parameter is set to No, JetPlan runs the flight plan but
ignores the OWATAA and OWATAN options. For
more information, about OWATAA and OWATAN,
see the “Option Commands” chapter in the JetPlan
User Manual.
Input values:
• Yes – JetPlan subjects the flight plan
computation to overwater considerations when
the Overwater Avoid (FP, OWATAA) option or
Overwater Alert (FP, OWATAN) flight plan
option is specified.
• No – JetPlan does not subject the flight plan
computation to overwater considerations when
the Overwater Avoid (FP, OWATAA) option or
Overwater Alert (FP, OWATAN) flight plan
option is specified.
CCAA Qualify The CCAA Qualify parameter triggers or prevents
automatic application of the CCAAQ functionality to
any flight plan request that includes the CCAA flight
plan option and the applicable city pair combination.
Input values:
• Yes – Invokes the CCAAQ functionality when
the CCAA option and the city pair combination
are present in the flight plan request.
• No – Ensures that the CCAAQ option is not
invoked when the CCAA option is in effect for
the city pair combination.
• Unset (Default) – The CCAAQ parameter has no
influence.
NOTE The CCAA Qualify parameter in the City Pair
Database can be overridden by the CCAA Qualify
parameter in the City Pair Fleet Database. For detailed
information on the order of precedence for these
parameters and on the CCAA Qualify Customer
Preference, see the “4D Avoid and Alert Restrictive
Airspaces” chapter in the JetPlan User Manual.

896
City Pair Database
Database Parameters
International NOTE This parameter is used only by certain front-
(II)
This parameter indicates whether the system treats the
flight as an international or domestic flight for the
purposes of flight plan filing.
Input value:
• International
• Domestic
Optimization Type NOTE This parameter is used only by certain front-

This parameter indicates the default optimization
algorithm to be applied for flights for the city pair.
This value can be overridden on the flight plan
request.
The input values are:
• Minimum Fuel (F)
• Minimum Time (T)
• Minimum Cost (C)
• Minimum Adjusted Cost (M)
• Unset (U)
Air Queue (2 sets) The Air Queue parameters allow the user to adjust the number of minutes for climb or
descent air time produced during flight planning. The number of minutes is added to or subtracted from climb
and descent. Air Queue minutes add to the fuels but do not take away from the fuels.
Air Queue Start Date (DMY) and Start Time (hhmm) Effective start date and time for the Air Queue set.
for Sets 1 and 2 The year is optional.
Input value:
• Day, Month, and Year
• Hours: 0000–2400 (hhmm)

897
City Pair Database
Database Parameters
Air Queue Details for Sets 1 and 2 (24 subsets) • Start Time – Defines the time of day for the start
of the particular Air Queue Data Time Segment.
Input value: 0000–2400; 2400 is unset.
• Air Queue Time – Specifies the number of
minutes that the air time produced during flight
planning calculation is to be adjusted. The
number of minutes represented by the Air Queue
is applied by taking the total number of Air
Queue minutes and dividing by 2. The result is
rounded up to the next whole value and applied
to the number of minutes for descent and
rounded down to the next whole value and
applied to the number of minutes for climb.
Input value: 99–+99
Burn Factor (2 sets)

The Burn Factor option enables the user to modify a percentage fuel burn efficiency factor used for the descent
fuel burn calculation. This is applied in addition to any other descent fuel flow bias applied.
Burn Factor Start Date (DMY) and Start Time Effective start date and time for the Burn Factor set.
(hhmm) for Sets 1 and 2 Day and month must be set. The year is optional.
Input value:
• Hours: 0000–2400 (hhmm)
Burn Factor Details for Sets 1 and 2 (24 subsets) • Start Time – Defines the time of day for the start
of the Burn Factor Details segment.
Input value: 0000–2400 (hhmm); 2400 is unset.
• Adjustment – A percentage fuel burn efficiency
factor used for the descent burn calculation. This
factor is applied in addition to any other descent
fuel flow bias applied. This value is based on
historical data that indicates vectoring or
circuitous routings imposed by ATC for specific
times of day.
Input value: -0.99–+0.99

898
City Pair Database
Database Parameters
Holding Time (2 sets)
NOTE These parameters are used only by certain front-end dispatch software applications. Contact your
Holding is circling in a pattern designated by the airport control tower and might be necessary if unexpected
weather or congestion occurs at the airport. Holding Time allows the user to adjust the amount of holding time
planned for when the flight arrives at its destination.
Holding Time Start Date (DMY) and Start Time Effective start date and time for the Hold Time
(hhmm) for Sets 1 and 2 Adjustment set.
Day and month must be set. The year is optional.
Input value:
• Hours: 0000–2400 (hhmm)
Holding Time Details for Sets 1 and 2 (24 subsets) • Start Time – Defines the time of day for the start
of the Holding Time segment.
Input value: 0000–2400 (hhmm); 2400 is unset.
• Hold Time With Alternate – This hold time is
used to allow the user to adjust the amount of
planned holding time once the flight is at the
destination or alternate airport.
• Hold Time No Alternate – This hold time is used
to allow the user to adjust the amount of planned
holding time once the flight is at the Point of
Arrival (POA) airport.

899
City Pair Database
Database Management
Database Management

To use the City Pair Database when flight planning, you must first create records in the
database. In the JetPlan command-line interface, the City Pair Database access command is
CP, and it is entered on the Options command line. The access command always precedes a
function command. Function commands are inputs that instruct JetPlan to store, change,
delete, or display information in the database.
File Maintenance
• ADD – Creates a new record
File Display
The City Pair Database record key elements are POD and POA. The order of the inputs when
working with City Pair Database records must always be: access command (CP), function
command, POD, POA, and any desired optional parameters. The POD and POA are either the
ICAO or the IATA code or can be $ to indicate All. The inputs are separated by commas as
shown below:
CP,function command,POD,POA,parameter1,parameter2,etc.

900
City Pair Database
Database Management
City Pair Database Commands

The City Pair Database function commands are divided into two categories: file maintenance
and file display. These categories are listed below with the respective functions.

explanation of each maintenance command is shown in the following table.
Table 33-2 City Pair Database File Maintenance Commands
Command Description
CP,ADD This command enables you to add a new record of information for a city pair in the City Pair
Database.
CP,DEL This command enables you to delete a record from the City Pair Database.
CP,CHG This command enables you to change a record in the City Pair Database.

of each display command is shown in the following table.
Table 33-3 City Pair Database File Display Commands
Command Description
CP,PRI This command provides a display of all specified records in the City Pair Database.
CP,SUM This command enables you to view a list of all records in the City Pair Database.

901
C HAPTER 34

About the City Pair Fleet Database

You can use the City Pair Fleet Database (CPFDB) to store and manage data related to a
specific departure and arrival airport combination (a city pair) and a specific aircraft fleet type.
A fleet type is the Jeppesen generic aircraft ID that defines a specific airframe/engine
combination. (For more information about generic aircraft identifiers, see the “Aircraft Type
Commands” chapter in the JetPlan User Manual.)
A CPFDB record stores default parameter values that apply each time you create a flight plan
request for a given city pair/fleet type combination. For example, you can create a CPFDB
record containing parameters for the city pair KOAK–KABQ and a Gulfstream V aircraft.
JetPlan automatically applies the information in the CPFDB record whenever you create flight
plan requests that contain that city pair and aircraft type.
Note that city pairs are directional. KOAK–KABQ is not the same as KABQ–KOAK. Any
parameters in a CPFDB record for the city pair KOAK to KABQ are not triggered in a flight
request for KABQ to KOAK.
Examples of settings you can store in the CPFDB include:
• Additional operating weight value, a cruise mode, route input, an

international reserve policy, primary and alternate driftdown methods, and
two taxi-in and out time adjustment sets with different effective dates.
• An ETOPS Required flag that indicates ETOPS flight plans are requested
for the city pair/fleet type combination by default. An alert is returned when
the flight plan requested is not ETOPS.
• ETOPS Speed/Cruise Mode (SCM) data. For more information on SCM sets
in the CPFDB, see “SCM Sets and the CPFDB” on page 909.
Each record in the database must contain, at a minimum, the departure and arrival airports and
fleet type information for it to be accessible for flight planning. For information on all CPFDB
parameters, see “Database Parameters” on page 911.
About Taxi Time Adjustment Sets

You can set base and adjustment taxi-in and taxi-out values in the CPFDB and in the Customer
Airport Fleet database (CAPFDB). The CPFDB and CAPFDB taxi-in and taxi-out values are
used only if there is not a taxi value of higher precedence. User input of POD or POA taxi
values on a given flight plan request overrides CPFDB taxi values, while the CPFDB taxi

905
values take precedence over the CAPFDB values. Precedence for taxi-out and taxi-in values is
determined separately. For more information on precedence, see “Order of Precedence for
Taxi Time” on page 908.
For taxi values in either the CPFDB or the CAPFDB to be used, the flight plan request must
use a Customer Aircraft database record with the Taxi Fuel Flow (TX) parameter set. In
addition, the Default Block Time (DBT) parameter in the CPFDB must be set to a value
greater than zero.
The CPFDB and the CAPFDB have base taxi-out and base taxi-in values and two sets of taxi
data. Each taxi data set has an effective date. The data set used for the flight plan is the one
with the effective date closest and prior to, or the same as, the flight date and the Estimated
Time of Departure (ETD) or the Estimated Time of Arrival (ETA). The ETA is the ETD plus
the DBT value. If neither taxi data set is in effect, the taxi values from the database are not
used.
Each taxi data set contains up to 60 entries consisting of a start time and taxi-out and taxi-in
adjustment times in start-time order. The taxi adjustment entry to be used is the entry closest
but after or equal to the start time for either the ETD or the ETA.The taxi adjustment time is
added to the base taxi time. If there is not a taxi adjustment entry in the data set in effect, just
the base taxi time is used. If the resulting taxi time is less than zero, zero is used.
NOTE The two taxi data sets can be used to support variations that are typically
seasonal in nature. For example, an airline could have a Winter set and a Summer
set of taxi data. These designations imply no special processing beyond making the
correct use of the active dates for the two data sets. There is no “automated” clearing
of data sets or swapping of set content. The content remains in place until directly
overwritten with modified data by the user.

906
Taxi Time Adjustment Set Examples
CPFDB (For the POD -> POA)
Settings:
• DBT: 4 hours (0400)

• Base Taxi Time In: 7 minutes
• Base Taxi Time Out: 3 minutes
CPFDB Set 1 Set 2

Effective Date, Time: Oct 31, 2008, 0000 Effective Date, Time: Dec 30, 2008, 1200
Entries Start Time Taxi In Taxi Out Start Time Taxi In Taxi Out
1 0000 –1 2 0000 0 3
2 1200 3 4 1000 2 3
3 2000 5 6 1200 3 4
etc. 2400 - - 2400 - -
CAPFDB (for both POD and POA)
• Base Taxi Time In: 4 minutes

• Base Taxi Time Out: 2 minutes
CAPFDB Set 1 Set 2

Effective Date, Time: Jan 1, no year, 0000 Effective Date, Time: Sep 30, 2008, 0000
Entries Start Time Taxi In Taxi Out Start Time Taxi In Taxi Out
1 0000 1 2 0000 0 3
2 1200 4 4 1000 2 3
3 2000 5 6 1200 3 –3
etc. 2400 - - 2400 - -
Explanation:
• For a flight on Oct 31, 2008, with ETD 0133:

– CPFDB Data Set 1, Entry 1 is used for both the taxi-in and the taxi-
out time adjustment (ETA = ETD + DBT=0533).

907
– Taxi-in time = 7 + –1 = 6, and taxi-out time = 3 + 2 = 5.

• For a flight on Dec 30, 2008 with ETD 1000:
– CPFDB Data Set 1 is used for taxi-out value as Data Set 2 does not
become effective until noon, but Data Set 2 is used for the taxi-in
values, as the ETA is in the afternoon.
– The taxi-out data is from Data Set 1, Entry 1, as the ETD is 1000,
and the taxi-in data is from Data Set 2, Entry 3 (ETA = 1400).
– Taxi-in time = 7 + 3 = 10, and taxi-out time = 3 + 2 = 5.
• For a flight on Oct 30, 2008 with ETD 1600:
– There is no effective CPFDB entry, as the flight is prior to the
effective dates.
– For the CAPFDB, both data sets are active, but the second data set
is closest in time. The taxi-in and taxi-out adjustment values are
from CAPFDB Data Set 2, Entry 3, as the ETD is 1600 and the ETA
is 2000.
– Taxi-in time = 4 + 3 = 7, and taxi-out time = 2 + –3 = –1 = 0. Since
the taxi-out time is negative, it is adjusted to 0.
Order of Precedence for Taxi Time

The following table shows the order of precedence for the taxi time values, from highest to
lowest.
Table 34-1 Order of Precedence for Taxi Time
Origin Value Notes

User input for POD and POA Pounds or Minutes To use minutes, a Customer
taxi fuel type and amount on a Aircraft database record with the
specific flight plan request Taxi Fuel Flow parameter (TX) set
is required.
User input for taxi fuel on the POD Weight

or POA command lines (TXxxx)
on a specific flight plan request
Customer City Pair Fleet database Minutes A Customer Aircraft database

record with the Taxi Fuel Flow
parameter (TX) set, an active taxi-
time data set, and a CPFDB
Default Block Time (DBT) greater
than 0 are required.

908
Table 34-1 Order of Precedence for Taxi Time (continued)
Origin Value Notes

Airport Fleet database Minutes A Customer Aircraft database
record with the Taxi Fuel Flow
parameter (TX) set, an active taxi-
time data set, and a CPFDB
Default Block Time (DBT) greater
than 0 are required.
Airport database Minutes A Customer Aircraft database

AVE Taxi Out (TO) record with the Taxi Fuel Flow
parameter (TX) set is required.
AVE Taxi In (TI)
Aircraft database Pounds A Customer Aircraft database

Taxi Out (DT) record must be used.
Taxi In (AT)
Hard Coded Weight For certain customer IDs, Taxi-in

and Taxi-out fuels are set to
constant values.
SCM Sets and the CPFDB

You can use the ETOPS Diversion Mode Title and the ETOPS Deviation Time parameters in
the CPFDB to indicate a default ETOPS SCM data set to apply to a specific city pair/fleet
combination.
NOTE For detailed information about ETOPS, see the ETOPS User’s Guide:
2-Engine Aircraft on JetPlan.com.
About ETOPS SCM Sets
NOTE The ETPRRMFL customer preference is not required if you are using ETOPS
II. ETOPS II flight plans automatically use SCM data sets, regardless of customer
preference or other configuration settings. For information on customer preferences
and ETOPS II, contact your Jeppesen account manager.
Before you can apply ETOPS SCM data sets, the ETPRRMFL (ETP Range Ring Method
Flag) customer preference must be set. This preference activates the SCM sets as a
replacement for a selection of CADB parameters that define the ETOPS area of operation,

909
equal time point location, approved coverage ranges for ETOPS alternates, and suitability
times. In addition to the ETOPS Range Ring Radius, each SCM set also includes
corresponding true airspeeds and cruise modes used for ETP and CFS calculations. The SCM
sets provide a degree of flexibility and control to ETOPS operators that is not available when
only using the CADB parameters. Using SCM sets in the CPFDB, for example, allows you to
apply a slower, more conservative diversion speed for one city pair and a faster speed for
another city pair.
For more detailed information about SCM sets, see the “Aircraft Fleet Database” Help topic
on JetPlan.com or the chapter in the JetPlan User Manual.
Setting a Default ETOPS SCM Set in a City Pair Fleet Record

When you define a default SCM set in a CPFDB record, you are referencing a specific SCM
set in the ACFDB. Up to 12 SCM sets can be defined and stored in the ACFDB. Each SCM set
is uniquely identified by the values of the ETOPS Diversion Mode Title parameter and the
ETOPS Deviation Time parameter (the approved ETOPS diversion time in minutes). You
must ensure that the value of the ETOPS Diversion Mode Title and the ETOPS Deviation
Time parameters in the CPFDB record exactly match the values of those parameters in the
ACFDB SCM set that you want to use as the default for the city pair/fleet.
Order of Precedence for ETOPS SCM Set Data

JetPlan applies the appropriate ETOPS SCM set data to a flight plan using the following logic:
• User-interfaces capable of doing so can identify an SCM set to use as an

override to any stored default.
• If no user input has been submitted as an override, JetPlan uses the default
SCM set identified in the CPFDB (if one has been defined).
• If an SCM set reference cannot be derived from the CPFDB, JetPlan uses
the default ETOPS SCM set in the ACFDB.
• If the ACFDB does not contain a default SCM set, JetPlan fails the flight
plan and returns an error.

910
Database Parameters
Database Parameters
The following table lists the parameters that you can set in the CPFDB. These parameters
appear as options on the CPFDB pages in JetPlan.com. As you perform database tasks, consult
this table for information.

maintenance. For the convenience of JetPlan command-line users, the table below
lists JetPlan database codes in parentheses under the parameter names.
Table 34-2 CPFDB Parameters
POD (Required) The ICAO or IATA identifier for the point
of departure airport.
POA (Required) The ICAO or IATA identifier for the point

of arrival airport.
Fleet Type (Required) “Fleet Type” refers to a specific

airframe/engine combination. The Fleet Type value is
the generic aircraft ID from the JetPlan Aircraft
Library. For instance, 777E is the JetPlan generic ID
for the aircraft type with ICAO identifier B772.
Required Arrival Time Delta in Minutes: Early JetPlan does not currently use this parameter.
(RATE)
ex. RATE=15
Required Arrival Time Delta in Minutes: Late JetPlan does not currently use this parameter.
(RATL)
ex. RATL=10
Driftdown Mode: Primary JetPlan does not currently use this parameter.
(DRFP)
ex. DRFP=2
Driftdown Mode: Alternate JetPlan does not currently use this parameter.
(DRFA)
ex. DRFA=3

911
Database Parameters
Table 34-2 CPFDB Parameters (continued)
CCAA Qualify The CCAA Qualify parameter triggers or prevents
automatic application of the CCAAQ functionality to
any flight plan request that includes the CCAA flight
plan option and the applicable city pair/fleet
combination.
NOTE When set to Yes or No, the CCAA Qualify
parameter in the CPFDB overrides the CCAA Qualify
parameter in the City Pair database. For detailed
information on order of precedence for these
parameters and the CCAA Qualify Customer
Preference, see the “4D Avoid and Alert Restrictive
Airspaces” chapter in the JetPlan User Manual.
Input values:
• Yes – Invokes the CCAAQ functionality when
the CCAA option and the city pair/fleet
combination are present in the flight plan
request.
• No – Ensures that the CCAAQ option is not
invoked when the CCAA option is in effect for
the city pair/fleet combination.
• Unset (Default) – The CCAAQ parameter has no
influence.
HF Comm Equipment This parameter is used to indicate whether the aircraft

(HF) flying any route between the city pair needs to be
equipped with HF Communication Equipment and the
ex. HF=2
number, up to nine, that are required.
JetPlan generates an alert when a specified city pair
requires HF communications, and the aircraft
specified in the flight plan request is not HF equipped.
Input value: 0–9
Default is 0.
Additional Operating Weight This parameter is used when a flight between two
(AOW) specific airports should use a higher than normal
operating weight. The amount entered here is added
ex. AOW=1200
automatically to the aircraft operational weight when
the specified city pair and aircraft type is entered in a
Default is blank.
Contingency Min Rule (minutes) JetPlan does not currently use this parameter.
(CMR)
ex. CMR=45

912
Database Parameters
Default Payload (LBS) This parameter indicates the default amount of
(DP) payload to apply to a flight for the designated city pair
and fleet type in the absence of values entered in the
Input value: 0–999999 in kilos or lbs (based on
kilo/lbs attribute setting in customer attributes file).
Default is 000000.
Default Route Input This parameter indicates the default route entry or
(RTI) route database name that is applied to this city
pair/fleet. (Any text that could be entered for Q6 in
JetPlan line mode. For example: ‘J’ ‘D’ ‘RT/vvvvv’, -
abc ua34 xyx, and so on.)
Input value: 1–11 alphanumeric characters.
Pitch-Catch This parameter determines whether JetPlan uses

(PC) available pitch/catch points when creating a Non-
Restrictive Route (NRR) flight plan for the designated
city pair and fleet type.
When the user requests an NRR-optimized flight plan,
but does not indicate the use of pitch/catch points on
the JetPlan command line or through a front-end flight
planning system, JetPlan looks for the value of the
Pitch-Catch flag in the CPFDB for the city pair and
fleet type for the flight plan in question. If the Pitch-
Catch flag is set to Yes, the system generates a flight
plan request for an NRR-optimized flight plan using
pitch/catch points.
Input value:
• Yes – use Pitch/Catch
• No – do not use Pitch/Catch
Default is No.

913
Database Parameters
International Reserve Policy This parameter indicates the default international
(IR) reserve policy to be applied.
ex. IR=605 NOTE If this parameter is set to 43xx for the B43
international reserve policy, Dispatch Control or
another similarly capable user interface is required to
enforce the value. Contact your Jeppesen account
Input value:
• A valid 3-digit JetPlan code for an international
fuel reserve policy. See a list of valid codes and
corresponding policies in “Domestic,
International and Island Reserves” in the
“Payload, POD/POA, Weight and Fuel
• The 4-digit JetPlan code for the B43 international
reserve policy (43xx). Ex. IR=4305, where 43
represents the B43 policy and 05 represents an
application rate of 5%. See NOTE above.
Cruise Mode This parameter specifies a cruise mode to be used

(CRZ) automatically whenever the specified city pair and
aircraft type are entered in a flight plan request. The
ex. CRZ=M82
cruise mode can be entered as a specific mach number
ex. CRZ=CI55 or as a cost index. See the “Cruise Mode Commands”
chapter in the JetPlan User Manual for more
information.
Input value: 1–6 characters
NOTE A cruise mode parameter specified in the
CPFDB overrides any cruise mode stored in the
Customer Aircraft database.

914
Database Parameters
Default Block Time The DBT indicates the standard amount of time from
(DBT) Out to In time for the fleet type/city pair combination.
The DBT is added to ETD for use in taxi-time
ex. DBT=1015
adjustment look-up.
DBT is also used by the Minimum Adjusted Cost
Index (MACI) process to determine crew costs when a
scheduled time isn’t available.
This parameter is used by the front-end system
(OPSControl, JetPlan.com, and so on) to
automatically determine an ETA when a flight is
created manually.
Input value: 0–2359. Default is 0000. Enter the value
as hhmm. For example, an entry of 1015 means 10
hours and 15 minutes.
NOTE DBT must be set to a value greater than zero
for the CPFDB or CAPFDB taxi time values to be used.
Terrain Analysis Indicator This parameter indicates the default terrain analysis
(TA) computation to be applied to any flight for the
designated city pair and fleet type.
Input values:
• 0 – None
• 1 – Terrain Clearance
• 2 – Mountain Driftdown
• 3 – Both Terrain Clearance and Mountain
Driftdown
Default is 0.
NOTE When set, the value of the Terrain Analysis
Indicator overrides the Anti-Ice Terrain Analysis Rules
defined in the Customer Preference database. In turn,
these City Pair Fleet and Customer Preference
database values can be overridden by ad hoc inputs
entered through the front-end flight planning software.
For more information, see the “Overwater Driftdown
and Terrain Analysis” chapter in the JetPlan User
Manual.
NOTE A terrain analysis scenario for the route to the
destination alternate is always qualified using Terrain
Clearance Anti-Ice ON rules.

915
Database Parameters
ETOPS Required Indicates whether ETOPS is performed by default. If
(ETOP) this parameter is set to require ETOPS, and a flight
plan request does not specify ETOPS, a non-ETOPS
plan is computed and an alert is returned.
Input values:
• 1 – ETOPS is required
• 2 – ETOPS is required
• Any other value: ETOPS is not required
Default is 0
Dispatcher Add Fuel NOTE This parameter is stored in JetPlan but is used
only by certain front-end dispatch software
(DAF)
applications. For more information, consult the
ex.=1555 appropriate front-end product documentation or contact
This parameter sets the default value for discretionary
additional fuel that can be added to the release fuel at
the request of the dispatcher.
Input value: 0–999999. Default is 0.
Cockpit and Cabin Crew Cost Parameters

CPFDB record, combined with the Lateness Cost parameter values in the CPFDB record. If the CPFDB record
does not contain crew cost parameter values, the system uses crew cost parameter values in the Customer Airport
Fleet Database (CAPFDB) record, combined with the Lateness Cost parameter values in the CPFDB record. If the
CAPFDB also does not contain crew cost parameter values, the system uses crew cost values in the Aircraft Fleet
Database (ACFDB) record. See the “Cost Index Commands” chapter in the JetPlan User Manual for information
about MACI.
Default Cockpit Crew Number Sets the default cockpit crew count; used when
NCOD computing total cost if no crew count is passed in the
ex. NCOD=3
Input value: 0–99
Cockpit Crew Cost On Schedule Sets the fixed cost for the cockpit crew for on-time
OSRO arrivals.
ex. OSRO=2,000 Input value: Dollars/hour, range=0–10,000
Cockpit Crew Cost Over Schedule Sets the fixed cost for the cockpit crew for late
VSRO arrivals.
ex. VSRO =3,000 Input value: Dollars/hour, range=0–10,000

916
Database Parameters
Default Cabin Crew Number Sets the default cabin crew count; used when
NCAD computing total cost if no crew count is passed in the
ex. NCAD=3
Input value: 0–99
Cabin Crew Cost On Schedule Sets the fixed cost for the cabin crew for on-time
OSRA arrivals.
ex. OSRA =5,000 Input value: Dollars/hour, range=0–10,000
Cabin Crew Cost Over Schedule Sets the fixed cost for the cabin crew for late arrivals.
VSRA Input value: Dollars/hour, range=0–10,000
ex. VSRA =7,500
Show Lateness Time Segments Parameters
NOTE The following Lateness Cost parameters support the Minimum Adjusted Cost Index (MACI) feature. When
JetPlan calculates MACI values for flight planning, it uses the crew cost parameter values in the CPFDB record,
combined with the Lateness Cost parameter values in the CPFDB record. If the CPFDB record does not contain
crew cost parameter values, the system uses crew cost parameter values in the Customer Airport Fleet Database
(CAPFDB) record, combined with the Lateness Cost parameter values in the CPFDB record. If the CAPFDB also
does not contain crew cost parameter values, the system uses crew cost values in the Aircraft Fleet Database
(ACFDB) record. See the “Cost Index Commands” chapter in the JetPlan User Manual for information about MACI.
LBEB In JetPlan command-line interface, this parameter

activates the Lateness Segments. The effective
start/end time values are a “time of day” range during
which the band times are active, stored as hhmm.
LBEE In JetPlan command-line interface, this parameter de-

activates the Lateness Segments. The effective
start/end time values are a “time of day” range during
which the band times are active, stored as hhmm.
Lateness Time Segments–Sequence Start Time The Lateness Time Segments start/end times define a
Lateness Band Segment Begin (Sequence 0–4) range of “lateness” in minutes. Negative values
(early) are valid. A sequence of up to five lateness
LB0B–LB4B
The Start Time parameter indicates the number of
minutes past the scheduled arrival time at which the
given lateness sequence becomes effective.
Lateness Time Segments–Sequence End Time The Lateness Time Segments start/end times define a
Lateness Band Segment End (Sequence 0–4) range of “lateness” in minutes. Negative values
(early) are valid. A sequence of up to five lateness
LB0E–LB4E
The End Time parameter indicates the number of
minutes past the scheduled arrival time at which the
given lateness time segment ceases to be effective.

917
Database Parameters
Lateness Rate This parameter is the dollar-per-minute value that is
Late Band Segment Rate Per Minute (Sequence 0–4) applied to the given lateness time segment. A
sequence of up to five lateness segments is possible.
LB0R–LB4R
Fixed Lateness Cost This parameter is the fixed dollar value that is applied
Late Band Segment Fixed Rate (Sequence 0–4) to the given lateness time segment. A sequence of up
to five lateness segments is possible.
LB0F–LB4F
Taxi Time Segment Parameters

You can set base and adjustment taxi-in and taxi-out values in the CPFDB and in the Airport Fleet database
(CAPFDB). The CPFDB taxi values take precedence over the CAPFDB taxi values.
NOTE For the Taxi Time Adjustment values to be used, the Default Block Time (DBT) field in the CPFDB must
be set to a non-zero value, and a Customer Aircraft database record with the Taxi Fuel Flow (TX) value set must
be used.

NOTE You do not need to enter the taxi time adjustments in chronological order. JetPlan sorts the data
automatically.
(WDM) Input value: day and month (ddmm)
Set 1 Start Year The year setting is optional. The start date and time
(WYR) apply to each and every year if year is not set.
Input value: year (yyyy)
Set 1 Start Time (hhmm) Effective start time of Set 1 taxi time adjustments.
(WHM) Input value: 0000–2359 (hhmm)
Set 1 Base Taxi Out Time Indicates the average amount of taxi-out time for the
(BTOW) specified airport fleet for Set 1 taxi time adjustments.
Set 1 Base Taxi In Time Indicates the average amount of taxi-in time for the
(BTIW) specified airport fleet for Set 1 taxi time adjustments.
Set 1 Segment# Effective start time for the given Set 1 Taxi Time
Effective Start Time adjustment (#1–60) in hhmm.
#1–60 Input value: 0000–2359
(STW#)

918
Database Parameters
Set 1 Taxi Out Adjustment Defines the adjustment to the Base Taxi Out Time
#1–60 defined for the airport fleet when the flight’s
(TOW#) scheduled departure time is between the Start Time
Input value: –99–99 minutes (negative values are
possible)
Set 1 Taxi In Adjustment Defines the adjustment to the Base Taxi In Time
#1–60 defined for the airport fleet, when the flight’s ETD
plus DBT is between the Start Time and End Time for
(TIW#)
the specified taxi adjustment set.
Input value: –99–+99 (negative values are possible)
(SDM) Input value: day and month (ddmm)
Set 2 Start Year The year setting is optional. The start date and time
(SYR) apply to each and every year if year is not set.
Input value: year (yyyy)
Set 2 Start Time (hhmm) Effective start time of Set 2 taxi time adjustments.
(SHM) Input value: 0000–2359 (hhmm)
Set 2 Base Taxi Out Time Indicates the average amount of taxi-out time for the
(BTOS) specified airport fleet Set 2 taxi time adjustments.
Set 2 Base Taxi In Time Indicates the average amount of taxi-in time for the
(BTIS) specified airport fleet Set 2 taxi time adjustments.
Set 2 Segment # Effective start time for the given Set 2 Taxi-In Time
Effective Start Time adjustment (#1–60) in hhmm
#1–60 Input value: 0000–2359
(STS#)
Set 2 Taxi Out Adjustment Defines the adjustment to the Base Taxi Out Time
#1–60 defined for the airport fleet, when the flight’s
scheduled departure time is between the Start Time
(TOS#)
Input value: –99–+99 minutes (negative values are
possible).

919
Database Parameters
Set 2 Taxi In Adjustment Defines the adjustment to the Base Taxi In Time
#1–60 defined for the airport fleet, when the flight’s ETD
plus DBT is between the Start Time and End Time for
(TIS#)
the specified taxi adjustment set.
Input value: –99–+99 (negative values are possible).
ETOPS SCM Data Set
ETOPS Diversion Mode Title This parameter is the customer-specified title of the
(SN) SCM set used as the default for the designated city
pair and fleet type. This parameter and ETOPS
(ETOPS Multi Speed/Cruise Mode Diversion Mode
Deviation Time together constitute the SCM data set
Title)
key in the CPFDB record. Both parameters are
ex. SN=M80 required if the ETOPS SCM set is used. This title/time
combination must exactly match those of the SCM set
in the Aircraft Fleet database (ACFDB) that is being
referenced as the default for this city pair/fleet type
combination.
Input value: 1–10 alphanumeric characters. Default is
blank.
NOTE JetPlan requires that the ETOPS Diversion
Mode Title and the ETOPS Deviation Time match the
same parameters in one of the SCM sets in the
ACFDB. Otherwise an error occurs.
ETOPS Deviation Time Indicates the number of minutes that defines the
(SD) approved ETOPS diversion time for the designated
city pair and fleet type. This parameter and Diversion
(ETOPS Multi Speed/Cruise Mode Deviation Time)
Mode Title together constitute the SCM data set key
ex. SD=45 in the CPFDB record. Both parameters are required if
the ETOPS SCM set is used. This title/time
combination must match exactly those of the SCM set
in the Aircraft Fleet database (ACFDB) that is being
referenced as the default for this city pair/fleet type
combination.
Input value: 60, 75, 120,138, 180, 207, or 240
minutes. Default is blank.
NOTE JetPlan requires that the ETOPS Diversion
Mode Title and the ETOPS Deviation Time match the
same parameters in one of the SCM sets in the
ACFDB. Otherwise an error occurs.

920
Database Management
Database Management

To use the CPFDB when flight planning, you must first create records in the database. To do
this, you need to access the database. In JetPlan, the CPFDB access command is CPF, and it is
entered on the Options command line. The access command always precedes a function
command. Function commands are those inputs that instruct JetPlan to store, change, delete,
or display information in the database.
Two categories of command functions are available when accessing the CPFDB. These
File Maintenance
• ADD – Creates a new record
• DEL– Deletes an existing record
File Display
• PRI – Displays record

921
Database Management
The order of the inputs when working with CPFDB records must always be: access command
(CPF), function command, departure airport, arrival airport, fleet type, and then any desired
parameters. The inputs are separated by commas as shown below:
CPF,function command,pod,poa,fleet type,parameter1,parameter2,and so

on
NOTE You can include any or all parameters (see Database Parameters table
above) when adding or changing records in the database. In fact, you can even omit
all parameter settings if you just want to have a record in the database for the airport
and fleet type. The parameter settings for such a record can be addressed at another
time using the CHG function.
The CPFDB record key elements are described in the following table.
Table 34-3 CPFDB Record Key Elements
POD (Required) The ICAO or IATA identifier for the point of departure airport.
POA (Required) The ICAO or IATA identifier for the point of arrival airport.

922
Database Management
CPFDB Commands
The CPFDB command functions are divided into two categories: file maintenance and file
CPFDB File Maintenance Commands

Table 34-4 CPFDB File Maintenance Commands
Command Description
CPF,ADD New database records for a particular city pair and aircraft fleet type are created using the
ADD command. Airport identifiers can be either ICAO or IATA.
The following example illustrates the creation of a new record for the city pair KLAX–
RJAA and the fleet type B747. All parameter settings are strictly optional. Therefore, the
parameters shown are just examples.
Example:
01 OPTIONS CPF,ADD,KLAX,RJAA,B747,AOW=25000,HF=2
CPF,CHG You can modify the parameters of a previously stored record by using the CHG command.
The input is similar to the ADD input. You can add new parameter settings to the record,
change existing parameter settings, or reset parameters to their default setting. To reset a
parameter to its default value, enter the parameter without a value input.
Example:
01 OPTIONS CPF,CHG,KLAX,RJAA,B747,DBT=
CPF,CHG,$,$,$ You can make changes to multiple records all at once by using the wild card variable, $, in
place of the POD, POA, or fleet type identifiers. This is very useful if you have hundreds or
even thousands of CPFDB records that need updating.
Example:
Explanation: Change the Added Operational Weight to 1000 for all records departing
KLAX, regardless of arrival airport or fleet type.
01 OPTIONS CPF,CHG,KLAX,$,$,AOW=1000
To change records by fleet type only, substitute the wild card variable for the airport
identifiers.
Example:
Explanation: Change the Added Operational Weight to 15000 for all records with a B747
fleet type, regardless of airport identifiers.
01 OPTIONS CPF,CHG,$,$,B747,AOW=15000

923
Database Management
Table 34-4 CPFDB File Maintenance Commands (continued)
Command Description
CPF,DEL The DEL command allows you to remove an entire record from the database. You can also
use the global change command to delete all records for one or more airports, or all records
for a particular fleet type.
NOTE Use caution when deleting records with the global change command to avoid
accidentally deleting records.
To delete one particular record, specify the city pair airports and the fleet type.
Example:
Explanation: Delete the record with the city pair KLAX–RJAA and the fleet type B747.
01 OPTIONS CPF,DEL,KLAX,RJAA,B747
To delete all records for a particular departure or arrival airport, specify the airport only.
Example:
Explanation: Delete all records with KLAX as an arrival airport.
01 OPTIONS CPF,DEL,$,KLAX,$
NOTE Remember, the order is always POD, POA, fleet type. Make sure you put the wild
card variable in the correct location to avoid deleting the wrong records.
To delete all records for a particular fleet type, specify the fleet type.
Example:
Explanation: Delete all records with the fleet type B747.
01 OPTIONS CPF,DEL,$,$,B747

924
Database Management

Table 34-5 CPFDB File Display Commands
Command Description
CPF,PRI The function command PRI displays the contents of the CPFDB records on the screen. You
can display all records, one specific record, or multiple records by using the wildcard
variable.
Example:
Explanation: Display all records.
01 OPTIONS CPF,PRI
Example:
Explanation: Display the record for the city pair KLAX–RJAA with the fleet type B747.
01 OPTIONS CPF,PRI,KLAX,RJAA,B747
Example:
Explanation: Display all records departing from KSJC.
01 OPTIONS CPF,PRI,KSJC,$,$
NOTE Wildcard variables can be omitted from the end of a request without affecting the
results. In this example, the request CPF,PRI,KSJC produces the same result as
CPF,PRI,KSJC,$,$. However, if you want to display all records arriving at KSJC, the wildcard
must be placed in the departure airport position.
Example:
Explanation: Display all records with a fleet type of 767H.
01 OPTIONS CPF,PRI,$,$,767H
Example:
Explanation: Display all records for the city pair KSFO–KJFK.
01 OPTIONS CPF,PRI,KSFO,KJFK,$
Example:
Explanation: Display all records arriving in KOAK with a fleet type of B737.
01 OPTIONS CPF,PRI,$,KOAK,B737

925
C HAPTER 35
Coded Departure Routes

Database
Coded Departure Routes Database
About the Customer Coded Departure Routes Database
About the Customer Coded Departure

Routes Database
NOTE CDR in the context of this section refers to FAA Coded Departure Routes
and not the European Conditional Routes used with the ERAD flight plan option. For
information on ERAD, see Chapter 6, “Route Commands.”
Coded Departure Routes are:
• Predefined alternate routes for flying between city pairs when a user-
preferred route is not available due to weather or traffic constraints
• Complete routes from departure to arrival, including terminal procedures
The FAA maintains coded departure routes and publishes an updated list of the effective
coded departure routes every 56 days. The updated list is downloaded from the FAA Route
Management Tool and is validated by the JetPlan Navigation Data (NavData®) team. The
downloaded coded departure routes are stored in the generic NavData Coded Departure
Routes database. Each record in the Customer Coded Departure Routes Database is a duplicate
of a coded departure route stored in the generic NavData Coded Departure Routes database,
which is replaced every 56 days.
You can use the Customer Coded Departure Routes database function commands to:
• Populate the Customer Coded Departure Routes Database with an initial list
of coded departure routes and subsequently synchronize your database with
the latest revision of the FAA coded departure route data that is stored in the
generic NavData Database
• Find and list coded departure routes by city pair
• View the details of individual coded departure routes
• Indicate which coded departure routes are “OK to Use” in your flight
operations
NOTE After you have created your initial Customer Coded Departure Routes
Database, you need to manually reconcile it with the generic NavData Coded
Departure Route Database when needed. Your “OK to Use” settings are retained
during reconciliation.
For more information on coded departure routes and how they are applied in flight planning,
see the “Route Commands” chapter in the JetPlan User Manual.

929
Database Parameters
Database Parameters
The following table lists the parameters in the Customer Coded Departure Routes
Database.These parameters appear as options on the Coded Departure Routes Database pages
in JetPlan.com. As you perform database tasks, consult this table for information.

Table 35-1 Customer Coded Departure Routes Database Parameters
FAA Code This is the FAA-assigned 8-character coded departure route code.
(FAA) Characters 1-3 are the ID of the origination airport. Characters 4-6
are the ID for the destination airport. Characters 7 and 8 are
reserved for local adaptation.
Departure Airport This is the ICAO departure airport code.

(POD)
Arrival Airport This is the ICAO arrival airport code.

(POA)
Date Added This is the date that this record was added to the Customer Coded
(ADD) Departure Routes Database.
Date Changed This is the date a user last changed the “OK to Use” status for this
(CHG) coded departure route record.
Effective To This is the date to which the coded departure route is certain to be
(EXP) effective. It could be extended or removed after this date.
Active This parameter indicates whether the referenced coded departure

(ACT) route record exists in the generic NavData Coded Departure
Routes Database.
Values are:
• A – The coded departure route record has been activated and
is in effect.
• E – The coded departure route record has expired and is no
longer in effect.
OK to use Set to Yes (Y) to mark this coded departure route as OK to use in
(USE) flight operations. Set to No (N) to indicate the coded departure
route is not to be used. Changing this option updates the changed
(CHG) date for the coded departure route in the database.

930
Database Management
Database Management

To use the Coded Departure Routes Database when flight planning, you must first create
records in the database. To do this, you need to access the database. In the JetPlan command-
line interface, the Coded Departure Routes Database access command is CDR, and it is
entered on the Options command line. The access command always precedes a function
command. Function commands are those inputs that instruct JetPlan to store, change, delete,
or display information in the database.
File Maintenance
• GEN – Initializes or reconciles records.
File Display
• KEY – Displays specific codes
• TOT – Shows the count of specific records
Coded Departure Routes Database Commands

The Coded Departure Routes Database function commands are divided into two categories:
file maintenance and file display. These categories are listed below with the respective
functions.

931
Database Management

Table 35-2 Coded Departure Routes Database File Maintenance Commands
Command Description
CDR,GEN This command enables you to initialize and reconcile a Coded Departure Routes Database
record.
CDR,CHG This command enables you to change USE (“Ok to Use”) in specific records.
NOTE USE (“Ok to use”) is the only user-alterable record element in this database.
Example:
CDR,CHG[,faa],USE=x[,FLTR/opt[,...]]
where faa is a full or partial FAA code, USE is “Ok to use,” and opt is any of the
parameters listed in the database parameters table above.
Example:
Change “Ok to use” to No in all records whose FAA Code’ starts with V:
CDR,CHG,V,USE=N
Example:
Change “Ok to use” to No in all records whose POD is KATL and whose POA is KGNV:
CDR,CHG,USE=N,FLTR/POA=KGNV,POD=KATL

932
Database Management

Table 35-3 Coded Departure Routes Database File Display Commands
Command Description
CDR,PRI This command enables you to display specific records.
Example:
CDR,PRI[,faa][,FLTR/opt[,...]]
where faa is a full or partial FAA code, and opt is any of the parameters in the database
parameters table above.
Example:
Display all records whose FAA code begins with ATL and whose “OK to use” value is No:
CDR,PRI,ATL,FLTR/USE=N
Example:
Display the FAA codes of all records whose POD is KATL, “OK to use” value is No, and
Active flag value is Active:
CDR,KEY,FLTR/USE=N,POD=KATL,ACT=A
Example:
Display the count of all records whose Active flag value is Active, POA is KEGE, and
Effective To date is 20.12.2013:
CDR,TOT,FLTR/ACT=A,POA=KEGE,EXP=20.12.2013
CDR,KEY This command enables you to display specific FAA codes.

Example:
CDR,KEY[,faa][,FLTR/opt[,...]]
CDR,TOT This command shows the count of specific records.

Example:
CDR,TOT[,faa][,FLTR/opt[,...]]

933
C HAPTER 36
Flight Brief Database

About the Flight Brief Database

IMPORTANT This document contains information on the International Civil Aviation
Organization (ICAO) 2012 Filed Flight Plan (FPL) database parameters. The
Jeppesen cutover to the ICAO 2012 FPL format occurred on November 14, 2012. All
flight plans filed with Jeppesen flight planning products are now filed in the ICAO 2012
format by default. Air Traffic Control (ATC) might reject flight plans not filed in the
ICAO 2012 format.

DOC 4444),” which details the ICAO 2012 FPL requirements.
You can use the Flight Brief Database to define criteria that support the following:
• Automatic inclusion of user-provided text, such as diplomatic clearance

remarks, in all or in specified flight release packages or filing strips.
• Automatic application of conditions, such as the use of bonded or non-
bonded fuel price, to certain types of flight plan requests.
• Automatic output of specific information, such as AIR OPS emissions data,
in certain flight plans.
• Automatic use of a designated flight plan format.
• Automatic output of data on flight plans filed in the ICAO 2012 FPL format.
For more information, see “The Flight Brief Database and the ICAO 2012
FPL Format” on page 938.
When creating a flight brief record, define the flight brief type, which indicates the type of
data or condition that you want to apply automatically. Then use the selection criteria options
in the database to limit application of the data or condition to certain flight plan requests.
For example, to include a remark in certain filing strips, select the (A) Permit Remarks for
ATC Flight Brief Type and then type the remark text in the Flight Brief Text box. Then use
selection criteria options, such as Effective Date, Fleet Type, and Flight Number, to include
the remark output in matching flight plan requests. If you do not define selection criteria, the
remarks in the flight brief record are included automatically in all flight releases or filing
strips.

937
Other flight brief types might require more constraining factors. For example, the (E) EU-
ETOPS Early/Late Override type applies only to ETOPS II flight plan requests, while the (G)
Fuel Price Selection type requires you to set certain parameters and not set others. Otherwise,
the record is not applied to any flight plans. See “Database Parameters” on page 940 for details
on flight brief types and selection criteria parameters.
NOTE You can choose to have remarks in flight brief records displayed in the main
body of the flight plan output. This option is format-dependent. Contact your
The Flight Brief Database and the ICAO 2012 FPL

Format
IMPORTANT This section assumes that you use JetPlan.com to maintain the Flight
Brief Database.
NOTE For a full description of the Jeppesen ICAO 2012 FPL changes and
requirements, see the “ATC Filing” chapter in the JetPlan User Manual.
Jeppesen transitioned to the ICAO 2012 format on November 14, 2012. The ICAO 2012 FPL
format is standard for all of the Jeppesen flight planning software applications.
The (A) Permit Remarks for ATC flight brief type and the ICAO 2012 Item18 output
parameters in the Flight Brief Database enable you to add Item18 Special Handling (STS/) and
18 Originator (ORGN/) data to matching flights filed in the ICAO 2012 FPL format.
Before Using the ICAO 2012 Flight Brief Database Parameters

Before using the ICAO 2012 Flight Brief Database parameters, note the following:
• Configure your Customer Aircraft Database (CADB) with ICAO 2012

parameters. The ICAO 2012 FPL is pre-populated with this data. For
information on setting up the CADB, see the “ICAO 2012 Certification and
Equipment” section in the Help topic for the CADB on JetPlan.com or the
“Customer Aircraft Database” chapter in the JetPlan User Manual.

938
• To avoid ATC rejections, be sure to enter ICAO 2012-specific data only in

the designated ICAO 2012 database fields. For example, do not enter PBN/
values in a type A flight brief record. Enter Item 18 PBN/ values only in the
Item 18 PBN/ (I2) parameter field in the “ICAO 2012 Certification and
Equipment” section of the CADB in JetPlan.com.
• In JetPlan.com, do not enter any of the Item 18 indicators in any Flight Brief
Database field. For example, in the Item 18 ORGN/ text box in
JetPlan.com, do not type the indicator “ORGN” or “ORGN/” or the slash
mark (/). Type only the input value in the ORGN/ text box.
For more information on the Flight Brief Database ICAO 2012 parameters, see “Database
Parameters” on page 940.

939
Database Parameters
Database Parameters
The following table defines the parameters that you can set in the Flight Brief Database. These
parameters appear as options on the Flight Brief Database pages in JetPlan.com. As you
perform database tasks, consult this table for information.

maintenance. For the convenience of JetPlan command-line users, the JetPlan
database codes are included in parentheses in the Parameter column.
Table 36-1 Flight Brief Database Parameters
Flight Brief Name (Required) This parameter lets you assign a name to the Flight Brief Database
record.
Input value: Unique name consisting of up to12 alphanumeric characters
Example: A300ATCDIP
Flight Brief Type (Required)

Select the type that represents the category to which you want to assign the database record. Select only one type
for each record.
(A) Permit Remarks for IMPORTANT Before using the ICAO 2012 parameters in the Flight Brief
ATC Database, read “The Flight Brief Database and the ICAO 2012 FPL Format” on
page 938.
The (A) Permit Remarks for ATC flight brief type enables you to:
• Provide text, such as a diplomatic clearance remark, for inclusion in the
RMK/ field in Item 18 on the ATC filing strip. When creating the flight brief
record, select (A) Permit Remarks for ATC and then enter the remark in
the Flight Brief Text box.
• Output STS/ and ORGN/ data in Item 18 on the filing strip for specified
flights. When creating the flight brief record, select (A) Permit Remarks
for ATC and then provide values for the STS/ and ORGN/ parameters. See
the “ICAO 2012 Item 18 Output Parameters” section of this table below.
• Automatically include the flight number as a remark in Item 18 on the filing
strip. When creating the flight brief record, select (A) Permit Remarks for
ATC and then select Yes for the Display Flight Number parameter.
IMPORTANT Do not enter PBN/ in an (A) Permit Remarks for ATC flight brief
record. Enter Item 18 PBN/ information only in the Item 18 PBN/ parameter in the
“ICAO 2012 Certification and Equipment” section of the CADB. Do not add any
ICAO 2012-specific information to a type A flight brief record other than the values
for STS/ and ORGN/. Do not use any special characters, including a slash (/).

940
Database Parameters
Table 36-1 Flight Brief Database Parameters (continued)
(E) EU-ETOPS Early/Late NOTE The E flight brief type is used only with ETOPS II flight plan options.
Override Contact your Jeppesen account manager for more information.
NOTE If the Flight Brief Database contains two or more matching type E flight
brief records, the system uses the first record it finds.
The (E) EU-ETOPS Early/Late Override flight brief type supports several options
that enable users to be compliant with non-FAA ETOPS rules. To create the flight
brief record, select the EU-ETOPS Early/Late Override option. Then choose
from the following ETOPS options (see the “ETOPS II Output Parameters”
section of this table for more information on all these options):
• Extend early and late arrival times – To extend the early and late arrival
times at ETOPS alternates, set buffer times to be included in ETOPS
calculations for suitable times in matching flight plan requests. Enter the
buffer times in the ETOPS Early Buffer and ETOPS Late Buffer text
boxes. The input value is 000-999 (time in minutes).
• Include the 5% wind penalty – Set the 5% Wind Bias option to On to
include the 5% wind penalty in the ETOPS II calculations in matching flight
plan requests.
• Apply a temperature-based icing penalty – Set the Temp-Based Icing
Penalty option to On to apply a temperature-based icing penalty logic to
ETOPS II calculations in matching flight plan requests.
• Select critical fuel scenario – The Scenario Options let you indicate which
of the three ETOPS critical fuel scenarios (Engine-Out Depressurized, All-
Engine Depressurized, and Engine-Out Pressurized) are computed and used
in the ETOPS uplift calculations and which are displayed in the extended
output block on the flight plan.
• Enter values for the Multi-Segment ETOPS Options – These options
enable you to do the following in matching flight plan requests:
– Treat consecutive ETOPS segments that are beyond a configurable
distance from one another as two separate ETOPS segments, as opposed to
combining them.
– Determine which ETPs the system can omit based on a configurable
distance between the abeam points of the forward and backward alternates.

941
Database Parameters
(F) Override Output Plan The (F) Override Output Plan Format flight brief type lets you store a default
Format flight plan format for a given aircraft fleet type. To create the flight brief record,
select (F) Override Output Plan Format. Then type the flight plan format
output name (for example, aa6) in the Flight Brief Text box and the fleet type in
the Fleet Type box.
NOTE If you specify a flight plan format output name but do not specify a fleet
type, the system applies the indicated format to all flight plans, regardless of the
fleet type.
In the command line interface, to create an F type flight brief record for a specific
fleet type, specify the fleet type identifier (FT) on the command line.
For example, to set the flight plan output format to aa6 for fleet type 777e, type
the following on the command line:
01 OPTIONS fb,sav,fmttest,f,ft=777e
TX=aa6
(G) Fuel Price Selection The (G) Fuel Price Selection flight brief type lets you specify which Customer
Airport Database (CAPDB) fuel price (bonded or non-bonded) to use for flight
plans with a specific flight number or other key parameters.
To create the flight brief record, select the (G) Fuel Price Selection option. Then
type FP=BP in the Flight Brief Text box to specify the bonded fuel price or type
FP=FP to specify the non-bonded fuel price.
NOTE Not all parameters in the flight brief record can be set for (G) Fuel Price
Selection. The expected options are Flight Number, Aircraft Type, POD or POA,
and Tail Number. If an unexpected parameter is set, the record is not used. Also, if
both the POD and the POA are set, the record is not used.
(N) Company Note for The (N) Company Note for Flight Brief type lets you create and store a company
Flight Brief note or a remark for the crew. When creating the flight brief record, select (N)
Company Note for Flight Brief and then type the remark in the Flight Brief
Text box.
(P) Alternate EXEMPT This option is not currently in use.

Fuel Policy]
(R) Permit Note for Flight The (R) Permit Note for Flight Brief type lets you create and store a diplomatic
Brief clearance remark that appears only in the flight crew’s filing package. When
creating the flight brief record, select (R) Permit Note for Flight Brief and then
type the remark in the Flight Brief Text box.
NOTE This functionality is format-dependent.

942
Database Parameters
(S) Set Spill Cost The (S) Set Spill Cost Parameters flight brief type lets you account for forfeited
Parameters cargo revenue (spill cost) in cost comparisons when using autoweight or when
using Optimal Scenario Analysis (OSA) for an unknown payload case.
To create the flight brief record, select (S) Set Spill Cost Parameters and then
type the unit value for forfeited cargo in the Flight Brief Text box. The text must
be in the format <value><currency>/<units of weight>, where:
• value is a numeric value with decimal values. The range of valid values is
0.0–9999.99 with no limit to the number of decimal values. The default is
0.0. Example: 1.0625
• currency is a 3-character abbreviation for a currency. The default is USD.
Examples: USD or EUR.
• unit of weight is LB or KG. The default is LB.
For example, enter a unit value of 2 1/8 dollars per pound in the Flight Brief Text
box as 2.125USD/LB.
Spill cost is calculated as the forfeited cargo unit value (as described above) times
the forfeited cargo weight. The forfeited cargo weight is the difference between
the actual payload weight for the current scenario and a target payload weight.
How the target payload weight is defined depends on the payload value entered in
the flight plan request (Question 14 in the JetPlan command-line interface).
The target weight is one of the following:
• The actual amount (if one is specified) for payload in the flight plan request.
- or -
• If ZF is entered for payload in the flight plan request, target weight is the
difference between the Max Zero Fuel Weight (ZF) value in the CADB and
the aircraft’s operational weight value. The operational weight value is the
combined value of Operational Weight (OP) in the CADB and the
Additional Operating Weight (AOW) in the City Pair Fleet Database. It can
be overridden by an ad hoc entry in the flight plan request.
- or -
• If an actual payload amount or ZF is not specified in the flight plan request,
the target weight is the Max Payload (MP) value from the CADB.
NOTE The cost of the forfeited cargo (when not 0) is included on compatible flight
plan formats. Contact your Jeppesen account manager for information about
compatible flight plan formats or to arrange to have your format modified.

943
Database Parameters
(T) WXE Time Buffer The (T) WXE Time Buffer flight brief type enhances the Enroute Weather Output
(WXE) option to return NOTAMs beyond the window defined by the Estimated
Time of Departure (ETD) to the Estimated Time of Arrival (ETA) at the POA.
The (T) WXE Time Buffer option enables you to extend this window in matching
flight plans to: the ETA at the POA plus the number of hours you specify, up to 48
hours.
NOTE You must include the WXE option in your flight plan request.
When creating the flight brief record, select the (T) WXE Time Buffer option. In
the Flight Brief Text box, type the number of hours to extend the window, up to
48 hours.
NOTE If you specify more than 48 hours in the Flight Brief Text box, the system
defaults to using 4 hours.
(W) Weather Maps for The (W) Weather Maps for Flight Brief type lets you list weather map codes in
Flight Brief the remark text area as a reminder to the crew to retrieve specific flight weather
maps to include in the filing package.
To create the flight brief record, select the (W) Weather Maps for Flight Brief
option. In the Flight Brief Text box, enter only Fax Forwarding (FF) map codes
and include a space between each code entry. For example, the FF code for the
High-level Significant Weather map for Europe is EUHISIG12. For more
information on FF codes, see the “Graphic Weather” chapter in the JetPlan User
Manual.
(X) Enroute Weather The (X) Enroute Weather Airports and FIRS flight brief type lets you list airports
Airports and FIRS or FIRs for extra weather reports.
NOTE You must include the Enroute Weather Output (WXE) option in your flight
plan request.
To create the flight brief record, select the (X) Enroute Weather Airports and
FIRS option and then list airport or FIR identifiers in the Flight Brief Text box.
Separate each identifier with a space. Example: KLVK KDEN KRBL.
JetPlan scans the codes, and then retrieves reports (if available) from those
stations or regions listed and includes them in the flight brief package.

944
Database Parameters
(Z) Reports and NOTE The political boundary report includes country boundary crossings only for
Diagnostics countries with Customer Controlled Avoid and Alert (CCAA) database records in
which the avoid level is set to either Avoid or Alert. The FIR boundary report
includes FIR crossings only for FIRs with CCAA database records in which the
avoid level is set to either Avoid or Alert. See the “Customer Controlled Avoid and
Alert Database” Help topic on JetPlan.com.
The (Z) Reports and Diagnostics flight brief type lets you include FIR/UIR and
geopolitical country boundary crossing reports on flight plans for matching
flights.
When creating the flight brief record, select the (Z) Reports and Diagnostics
option and then select Yes for one or both of the following options:
• Display Political Boundary Report
• Display FIR/UIR Boundary Report
See descriptions of these options below in the “Output Parameters” section of this
table.
Selection Criteria Parameters
Effective Date (Optional) This option defines the date on which the record becomes effective.
(ddmmyyyy or UFN) NOTE If you type only one date in your flight brief record command-line input,
JetPlan assumes that it is an effective date. The expiration is then considered UFN.
For more information, see “Using JetPlan to Manage the Database” on page 956.
Input value: Date in ddmmyyyy format or UFN (for Until Further Notice). No
entry or UFN makes the record effective immediately.
Example: 31122002
Fleet Type The Fleet Type option links the dissemination of a Flight Brief Database remark
(FT) to any flight plan containing the specified aircraft fleet type.
Input value: The four-character Jeppesen ID for the aircraft fleet type
Expiration Date (Optional) This option defines the date on which the record expires (is no longer
(ddmmyyyy or UFN) effective).
NOTE If you type only one date in your flight brief record command-line input,
JetPlan assumes that it is an effective date. The expiration date is then considered
UFN. For more information, see “Using JetPlan to Manage the Database” on
page 956.
Input value: Date in ddmmyyyy format or UFN (for Until Further Notice). No
entry or UFN makes the record effective immediately.
Example: 31122006
Tail Number The Tail Number option links the dissemination of a Flight Brief Database remark
(AC) to any flight plan containing the specified aircraft tail number.
Input value: The tail number (up to 12 characters)

945
Database Parameters
Flight Number The Flight Number option links the dissemination of a Flight Brief Database
(FN) remark to any flight plan containing the specified flight number.
Input value: The flight number (up to 12 characters)
Enroute FIR The Enroute FIR option links the dissemination of a Flight Brief Database remark
(EFIR) to any flight plan that transits the specified FIR along the enroute portion of its
computed route.
Input value: The ICAO identifier for the FIR
POD The POD option links the dissemination of a Flight Brief Database remark to any
(POD) flight plan containing the specified departure airport identifier.
Input value: The four-character ICAO identifier for the POD
Departure FIR The Departure FIR option links the dissemination of a Flight Brief Database
(DFIR) remark to any flight plan that departs from the specified FIR.
POA The POA option links the dissemination of a Flight Brief Database remark to any
(POA) flight plan containing the specified arrival airport identifier.
Input value: The four-character ICAO identifier for the POA
Arrival FIR The Arrival FIR option links the dissemination of a Flight Brief Database remark
(AFIR) to any flight plan that arrives within the specified FIR.
APT The APT (Associated Airport) option links the dissemination of a Flight Brief
(AP) Database remark to any flight plan containing the specified airport identifier.
Input value: The four-character ICAO identifier for the airport
FIR The FIR option links the dissemination of a Flight Brief Database remark to any
(FIR) flight plan that transits the defined FIR along the computed route, including the
departure, enroute, and arrival areas.
Output Parameters
These parameters control inclusion of the selected information on flight plans.
Display EU-ETS When the Display EU-ETS Emissions option is set to Yes, the system includes
Emissions EU ETS CO2 calculations on formatted flight plans for requests that meet the
(EUETS=Y/N) criteria defined by the flight brief record.
If the parameter is set to No, the EU ETS information does not appear on the
flight plan automatically. However, you can still include the information in a
flight plan request by submitting the EUETS flight plan option.
NOTE The Fuel Type parameter in the CADB must also be set.

946
Database Parameters
Display Flight Number NOTE This option can only be used with the (A) Permit Remarks for ATC flight
brief type.
(OFN=Y/N)
When the Display Flight Number option is set to Yes, the flight number is
automatically included as a remark in Item 18 on the filing strip for requests that
meet the criteria defined by the flight brief record.
When this option is set to Yes and no additional selection criteria are defined, the
flight number is automatically included in all filing strips.
Display Political IMPORTANT The Political Boundary Crossing Report flight plan options
Boundary Report (PBNDC=Yes/No) override the value of this parameter in the Flight Brief Database.
The PBNDC=N(o) flight plan option directs the system to suppress the boundary
(PBNDC=Y/N) crossing report, while the PBNDC=Y(es) flight plan option directs the system to
generate the border crossing report.
NOTE This option can be used only with (Z) Reports and Diagnostics flight brief
type records.
NOTE The political boundary report includes country boundary crossings only for
countries with CCAA database records in which the avoid level is set to either Avoid
or Alert. The boundary crossing report requires a specific format. You might need to
request a format change to use this report. Contact your Jeppesen account
manager for information.
Input value: Yes/No
• When the Display Political Boundary Report option is set to Yes, the
geopolitical boundary crossing report is automatically included on
supporting flight plan formats for requests that meet the criteria in the flight
brief record. This setting can be overridden on a per-flight plan basis by the
PBNDC=N flight plan option.
• When this option is set to No, the boundary crossing report is not
automatically included on supporting flight plan formats for requests that
meet the criteria in the flight brief record. This setting can be overridden on a
per-flight plan basis by the PBNDC=Y flight plan option.

947
Database Parameters
Display FIR/UIR IMPORTANT The FIR/UIR Boundary Crossing Report flight plan options
Boundary Report (FBNDC=Y/N) override the value of this parameter in the Flight Brief Database. The
FBNDC=N flight plan option directs the system to suppress the boundary crossing
(FBNDC=Y/N) report, while the FBNDC=Y flight plan option directs the system to generate the
border crossing report.
NOTE This option can be used only with (Z) Reports and Diagnostics flight brief
type records.
NOTE The FIR boundary report includes only FIR crossings for FIRs for which
records exist in the CCAA database with the avoid level set to either Avoid or Alert.
See the CCAA Database Help topic on JetPlan.com.
NOTE The boundary crossing report requires a specific format. If you want to use
this report, you might need to request a format change. Contact your Jeppesen
account manager for information.
Input value: Yes/No
• When the Display FIR/UIR Boundary Report option is set to Yes, the
FIR/UIR boundary crossing report is automatically included on supporting
flight plan formats for requests that meet the criteria in the flight brief
record. This setting can be overridden on a per-flight plan basis by the
FBNDC=N flight plan option.
• When this option is set to No, the boundary crossing report does not appear
on matching flight plans automatically. This setting can be overridden on a
per-flight plan basis by the FBNDC=Y flight plan option.
ETOPS II Output Parameters

NOTE The ETOPS II Output parameters are used with the (E) EU-ETOPS Early/Late Override flight brief type.
(See “(E) EU-ETOPS Early/Late Override” on page 941.) The E flight brief type and the following ETOPS II output
parameters are used only with ETOPS II flight plan options. Contact your Jeppesen account manager for more
information.
ETOPS Early Buffer NOTE This option can be used only with (E) EU-ETOPS Early/Late Override flight
brief type records and ETOPS II flight plan options.
The ETOPS Early Buffer option extends the early arrival time at an ETOPS
alternate.
Input value: 000–999 (time in minutes)
ETOPS Late Buffer NOTE This option can be used only with (E) EU-ETOPS Early/Late Override flight
The ETOPS Late Buffer option extends the late arrival time at an ETOPS
alternate.
Input value: 000–999 (time in minutes)

948
Database Parameters
5% Wind Bias NOTE This option can only be used with (E) EU-ETOPS Early/Late Override flight
(WIND=Y/N)
NOTE In the JetPlan
When the 5% Wind Bias option is set to On (the default), the system includes the
command-line interface, 5% wind penalty in matching ETOPS II flight plan requests (the wind adjustment
Y=on (the wind adjustment is applied.) The average wind component is computed using the forecast winds
is applied), and N=off (the for the following ETOPS II scenarios associated with each diversion:
wind adjustment is not • Depressurized Engine Out
applied.) The default
setting is Y. • Depressurized All Engine
• Pressurized Engine Out
When this option is set to Off, no wind adjustment is applied.
NOTE If no matching Flight Brief Database record exists, the system
automatically applies a 5% bias (5% higher headwinds and 5% lower tailwinds).
Input values: On and Off. On is the default setting.
Temp-Based Icing Penalty NOTE This option can only be used with (E) EU-ETOPS Early/Late Override flight
(ICE=Y/N)
NOTE In the JetPlan
When the Temp-Based Icing Penalty option is set to On, the system applies
command-line interface, temperature-based icing penalty logic to compute icing penalties in matching
Y=on (the temperature- ETOPS II flight plan requests.
based icing penalty logic is Anti-ice and ice-drag penalties are computed using the following Customer
applied), and N=off (the Aircraft database (CADB) parameter values:
non-temperature-based
icing penalty logic is • Icing Temperature (IT)
applied.) The default • Anti-Ice Flag (AI)
setting is N.
• Ice Drag Flag (ID)
When this option is set to Off (the default), the system applies non-temperature-
based icing penalty logic.
For more information, see the “Aircraft Record - ETOPS Section” and the
“ETOPS Flag and Factor Codes” tables in the CADB Help topic on JetPlan.com.
See also the ETOPS II Startup Guide.
Input values: On/Off. Off is default setting.

949
Database Parameters
(ETOPS II) Scenario NOTE These options can be used only with (E) EU-ETOPS Early/Late Override
Options flight brief type records and ETOPS II flight plan options. Contact your Jeppesen
account manager for more information.
(D1LEF – Engine-Out
Depressurized scenario NOTE These parameters replace the Cruise Mode Begin Flag (CS) and Cruise
Mode End Flag (CE) parameters in the Customer Aircraft Database in ETOPS II
DLRCF – All-Engine flight plans only. Any values set for those parameters are not used in ETOPS II
Depressurized scenario flight plan calculations. However, CS and CE are still used in legacy ETOPS flight
P1LEF – Engine-Out plans.
Pressurized scenario The (ETOPS II) Scenario Options enable you to control:
Options for each scenario: • Which ETOPS critical fuel scenarios are computed and used in the ETOPS
1 – Output in plan, Use in uplift calculations. (Uplift is a fuel that is added to takeoff fuel to
uplift (default value) compensate for ETOPS fuel short fall.)
2 – Output in plan, • Which ETOPS critical fuel scenarios are displayed in the extended output
Exclude in uplift block on the flight plan.
3 – Do not output, Exclude You can choose one or all of the following scenarios:
in uplift • Engine-Out Depressurized
Ex: D1LEF=1 DLRCF=2 • All-Engine Depressurized
P1LEF=1)
• Engine-Out Pressurized
For each of the scenarios above, you can choose one of the following options:
• Output in plan, Use in uplift – (Default) The TOTAL fuel for the selected
scenario is used in the calculation of the total fuel required for the Equal
Time Point (ETP). The data column for the scenario is output in the EQUAL
TIME POINT DATA section of the flight plan if it was included in the flight
plan request.
• Output in plan, Exclude in uplift – The TOTAL fuel for the selected scenario
is not used in the calculation of the total fuel required for the ETP. The data
column for the scenario is output in the EQUAL TIME POINT DATA
section of the flight plan if it was included in the flight plan request.
• Do not output, Exclude in uplift – The TOTAL fuel for the selected scenario
is not used in the calculation of the total fuel required for the ETP. The data
column for the scenario is not output in the EQUAL TIME POINT DATA
section of the flight plan if it was included in the flight plan request. See also
the following IMPORTANT note.
IMPORTANT If all three scenarios are set to Do not output, Exclude in uplift,
the system computes the flight plan without ETOPS and outputs an alert that all
three scenarios have been excluded and that a fuel deficit might exist. The system
does not output any ETOPS data on the flight plan.
NOTE If a flight has a matching flight brief record, but one or more of these
scenarios is not set in the record, the system defaults to Output in Plan, Use in
Uplift for the scenarios that are not set. If no matching Flight Brief Database record
exists for the flight, the system automatically uses all three scenarios in the critical
fuel calculation and outputs all three scenarios in the extended output block on the
flight plan.

950
Database Parameters
(ETOPS II) Multi-Segment ETOPS Options
NOTE These options can only be used with (E) EU-ETOPS Early/Late Override flight brief type records and
ETOPS II flight plan options. Contact your Jeppesen account manager for more information.
These Flight Brief Database options support multi-segment ETOPS flight planning functionality, which enables
you to do the following:
• Treat consecutive ETOPS segments that are beyond a configurable distance from one another as two
separate ETOPS segments, as opposed to combining them
• Determine which ETPs the system can omit based on a configurable distance between the abeam points of
the forward and backward alternates
Combine ETOPS This option lets you specify a maximum distance in nautical miles between
segments less than <n> consecutive ETOPS segments. If the distance between any two ETOPS segments
nm apart is less than or equal to the value of this parameter, the system considers the two
ETOPS segments and the route in between them as one ETOPS segment.
NOTE If you do not enter a value for this parameter, the system uses 9999 nm as
the default value. In this case, the system considers the two ETOPS segments and
the entire route between them as one ETOPS segment.
Input values: 1–9999 nautical miles. The default value is 9999.
Include ETP in This option lets you specify a factor that the system multiplies by the range ring
computation for alternates radius used in the flight plan to define a maximum distance between two
closer than <n> times the sequential ETOPS alternates. The system uses the distance value to determine
range-ring radius whether to include the ETP between the alternates in the flight plan.
The system computes the ETP, associated critical fuel, and early and late arrival
time (EAT/LAT) values for each ETOPS alternate pair that is closer together than
the maximum distance. The system also includes these ETPs in the ETP summary
output on the flight plan and as waypoints in the navigation log. ETPs for
alternate pairs that are farther apart than the maximum distance are omitted from
the flight plan results unless they occur during an ETOPS segment.
NOTE The applicable range ring radius is stored in the Speed Cruise Mode
(SCM) data set that is used to compute ETOPS for the flight plan. (The SCM sets
are stored in the City Pair Fleet and Aircraft Fleet Databases. See the Help files for
these databases on JetPlan.com.)
NOTE If you do not enter a value for this parameter, the system applies no limit to
the distance between two sequential ETOPS alternates. In this case, the system
computes ETPs and the associated critical fuel and EAT/LAT values between each
alternate.
NOTE If you enter 0.000 for this parameter, the system treats each sequential
ETOPS alternate as a standalone alternate and does not compute the ETP
between them.
Input values: 0.000–99.999

951
Database Parameters
Flight Brief Text Output Parameters
Flight Brief Text The Flight Brief Text option enables you to enter up to 2,000 characters of text.
NOTE In the command-
This parameter is used with several flight brief types. See “Flight Brief Type
line interface, JetPlan (Required)” on page 940.
prompts you for your
remark text once you
submit the FB,SAV or CHG
command.
ICAO 2012 Item 18 Output Parameters

Use the Item 18 Output Parameters with the (A) Permit Remarks for ATC flight brief type to add ICAO 2012
Item 18 STS/ and ORGN/ data to the filing strip for specified flights.
IMPORTANT Before using the ICAO 2012 parameters in the Flight Brief Database, read “The Flight Brief
Database and the ICAO 2012 FPL Format” on page 938.
Do not enter PBN/ information in a Flight Brief Database type A flight brief record. Enter Item 18 PBN/ information
only in the Item 18 PBN/ parameter in the “ICAO 2012 Certification and Equipment” section of the CADB. Do not
add any ICAO 2012-specific information to a Flight Brief Database type A flight brief other than the values for STS/
and ORGN/. Do not use any special characters, including a slash (/).
PBN/ IMPORTANT This option is reserved for future use if and when certain countries
decide to use non-ICAO PBN/ codes.
(PBNT)
IMPORTANT Flight plans are rejected if this parameter is used with ATC Centers
that comply with the ICAO 2012 4444 specification.
NOTE This option can only be used with the (A) Permit Remarks for ATC flight
brief type.
(For future use) This option lets you enter Performance Based Navigation (PBN)
information to account for regional differences when filing using the ICAO 2012
FPL format. You are able to specify PBN/ values that are not in the ICAO 2012
section of the CADB.
If the flight plan request matches the other selection criteria that you set in the
Flight Brief Database record, the value you specify in the PBN/ box is appended
to the CADB PBN/ data or overrides it, according to the settings of the PBN
Append and PBN Override options in the Flight Brief Database (see below). The
information you enter is output in Item 18 PBN/ on the filing strip.
Input value: Up to 100 alphanumeric characters, if needed.
IMPORTANT The current ICAO limit is eight PBN codes (16 characters) in the
PBN/ indicator, but that might change in the future. It is your responsibility to ensure
that the information entered for this parameter complies with the current ICAO 4444
Amendment. If the allowed maximum is exceeded, your flight plans might be
rejected.
NOTE Do not use any special characters, including a slash (/) or a hyphen (-) in
any Item18 text. Doing so might result in rejected flight plan filings.

952
Database Parameters
PBN Append to CADB NOTE This option is reserved for future use if and when certain countries decide
PBN/ to use non-ICAO PBN/ codes
or IMPORTANT Flight plans are rejected if this parameter is used with ATC Centers
PBN Override CADB
PBN/ NOTE This option can only be used with the (A) Permit Remarks for ATC flight
brief type.
(PBNF =A/O)
(For future use) This parameter lets you indicate whether data that is entered in
the PBN/ box (see above) is appended to or overrides the value of the PBN/
parameter (I2) in the ICAO 2012 section of the CADB database. If the flight plan
request matches the other selection criteria that you set in the Flight Brief
Database record, this information is output in Item 18 PBN/ on the filing strip.
Input values:
• Append – (Default) Select to append the PBN/ value from the Flight Brief
Database to the value stored in the CADB.
• Override – Select to override the PBN/ value in the CADB with the value
from the Flight Brief Database.

953
Database Parameters
Special Handling NOTE This option can be used only with the (A) Permit Remarks for ATC flight
Information (STS/) brief type.
(STS) The Special Handling Information (STS/) parameter lets you enter special
handling (STS/) information on the filing strip. Multiple selections are supported.
If the flight plan request matches the other selection criteria set in the Flight Brief
Database record, this information is output in Item 18 STS/ on the filing strip.
Separate values by a space.
Input Values – One or more of the following descriptors:
• ALTRV – Used for a flight operated in accordance with an altitude
reservation
• ATFMX – Used for a flight approved for exemption from ATFM measures
by the appropriate ATS authority
• FFR – Used for fire-fighting
• FLTCK – Used for flight check for calibration of NAVAIDs
• HAZMAT – Used for a flight carrying hazardous material
• HEAD – Used for a flight with Head of State status
• HOSP – Used for a medical flight declared by medical authorities
• HUM – Used for a flight operating on a humanitarian mission
• MARSA – Used for a flight for which a military entity assumes
responsibility for separation of military aircraft
• MEDVAC – Used for a life critical medical emergency evacuation
• NONRVSM – Used for a non-RVSM capable flight intending to operate in
RVSM airspace
NOTE JetPlan automatically adds STS/NONRVSM to Item 18 of the ICAO 2012
FPL format when the RVSM parameter in the CADB is set to Exempt.
• SAR – Used for a flight engaged in a search and rescue mission
• STATE – Used for a flight engaged in military, customs, or police

954
Database Parameters
Item 18 STS/ (Regional) IMPORTANT This option is reserved for future use if and when certain countries
decide to use non-ICAO STS/ codes in the future.
(OSTS)
IMPORTANT Flight plans are rejected if this parameter is used with ATC Centers
NOTE This option is used with the (A) Permit Remarks for ATC flight brief type.
(For future use) The Item 18 STS/ (Regional) parameter lets you enter additional
special handling (STS/) information to account for regional differences when the
list of Special Handling Information items (see above) is not sufficient. If the
flight plan request matches the other selection criteria that you set in the Flight
Brief Database record, this information is output in Item 18 STS/Data on the
filing strip.
Input value: Up to 256 alphanumeric characters. Separate codes by a space.
NOTE If you enter an unauthorized code or duplicate indicator, the ATC rejects
the flight plan.
IMPORTANT If the Flight Brief Database STS/ option is blank, STS/ is not output
in Item 18.
ORGN/ NOTE This option can only be used with the (A) Permit Remarks for ATC flight
brief type.
(ORGN)
The ORGN/ parameter lets you identify the eight-character AFTN address of the
originator or other appropriate contact details. If the flight plan request matches
the other selection criteria set in the Flight Brief Database record, this data is
output for Item 18 ORGN/ in the ICAO-specified order on the filing strip.
NOTE Do not enter the indicator “ORGN” or “ORGN/” or “/”, followed by the input
value. Enter only the input value
NOTE If the Flight Brief Database ORGN/ option is blank, ORGN/ is not output in
Item 18.

955
Database Management
Database Management
NOTE This section covers using the JetPlan command-line interface to manage the
Flight Brief Database. However, JetPlan.com is the recommended interface for
managing the customer databases. See the JetPlan.com Help file for detailed
information.

In the JetPlan command-line interface, you can create and maintain records in the Flight Brief
Database by entering commands on the Options command line, starting with the command
FB. FB accesses the database and is followed by a command function, the record name, a
remark type, an effective and expiration date, and any other key parameters needed.
The system automatically prompts you for your remark text once you submit the command to
save the flight brief record (if the flight brief type supports remarks). Remarks can be up to
2,000 characters of text.
Example:
01 Options FB,<function command,recordname,type,effdate,expdate,
parameter 1,parameter 2,>
TX=enter your remark text here
Flight Brief Database Commands

Two categories of command functions are available for the Flight Brief Database: file
maintenance and file display. The following paragraphs describe these commands and provide
examples of their use.
File maintenance commands enable you to create, modify, and delete records in the database.
The file maintenance commands for the Flight Brief Database are as follows:


956
Database Management

• DEX – Deletes all existing records that have expired
• CPY – Copies a record to another record
• RN – Renames an existing record
The following table contains explanations and examples of each file maintenance command.
Table 36-2 Flight Brief Database File Maintenance Commands
Command Explanation Example

FB,SAV The Save command enables you to Example:
create and store a record in the Explanation: Save the flight brief record,
database. You must include a record ALGERIA1, in the Flight Brief Database. The
name and indicate a flight brief type. record is defined as a diplomatic clearance
All other inputs, including the remark for ATC (A). It is set to be effective
effective and expiration dates are immediately (UFN) and available indefinitely
optional. (UFN). The remark is keyed to output only when
For Type A records, JetPlan prompts the flight plan contains a specific flight number
you for your remark or other text (TEST1), a specific fleet type (757B), and a
after you enter the Save command. specific arrival FIR (DGAC).
01 OPTIONS FB,SAV,ALGERIA1,A,UFN,UFN,
FN=TEST1,FT=757B,AFIR=DGAC
TX=Algeria DGAC1234
FB,CHG The Change command enables you Example:

to modify an existing record in the Explanation: Modify the flight brief record,
database. You must include the ALGERIA1. The Flight Number parameter is the
name of the record that you want to only change made (TEST1 is now TEST2). The
modify and the parameter or remark text remains the same.
parameters that you want to add or
01 OPTIONS FB,CHG,ALGERIA1,FN=TEST2
change.
FB,DEL The Delete command enables you to Example:
remove an existing record from the Explanation: Delete the ALGERIA1 record from
database. You must include the the database.
name of the record that you want to
01 OPTIONS FB,DEL,ALGERIA1
delete.
FB,DEX The Delete-Expired command Example:
enables you to remove all expired Explanation: Delete all expired records in the
records in the database (based on the database.
defined expiration date). Since you
01 OPTIONS FB,DEX
are deleting all expired records, you
do not need to specify a record
name.

957
Database Management
Table 36-2 Flight Brief Database File Maintenance Commands (continued)

FB,CPY The Copy command enables you to Example:
copy the contents of one record into Explanation: Copy the contents of ALGERIA1
another record that has a different into the new record ALGERIA2. Both
record name. This action requires ALGERIA1 and ALGERIA2 are now in the
two record name inputs: the name of database.
the record being copied and a name
01 OPTIONS FB,CPY,ALGERIA1,ALGERIA2
for the record being created. The
name of the record being created
must not already exist in the
database.
FB,RN The Rename command enables you Example:
to change the name of an existing Explanation: Rename the record, ALGERIA1, to
record in the database. The new the new name, TEMP1. ALGERIA1 no longer
name must not already exist in the exists in the database.
database.
01 OPTIONS FB,RN,ALGERIA1,TEMP1

The file display commands enable you to view the stored information in the database. The
display commands for the Flight Brief Database are as follows:
• PRI – Displays all existing records

• SUM – Displays a list of records by name
• PEX – Displays all expired records
The following table contains explanations and examples of each file display command.
Table 36-3 Flight Brief Database File Display Commands

FB,PRI The Print command lets you Example:
display the contents of one or all Explanation: The first example requests a printout of
records in the database. Specify a every record in the database. The second example
record name to see one record. requests a printout of the record named ALGERIA1.
Omit the record name, and all
01 OPTIONS FB,PRI
records are displayed.
01 OPTIONS FB,PRI,ALGERIA1

958
Database Management
Table 36-3 Flight Brief Database File Display Commands (continued)

FB,SUM The Summary command lets you Example:
display a list of all record names 01 OPTIONS FB,SUM
in the database.
FB,PEX The Print-Expired command lets Example:
you display the contents of all 01 OPTIONS FB,PEX
expired records in the database.

959
C HAPTER 37
Master Database (MDB)

About the Master Database
About the Master Database

The following sections cover creation and maintenance of the customer Master Database
(MDB) and its application in flight plan computations.
The MDB allows you to assign performance degradations and equipment limitations to
individual aircraft. These degradations and limitations are generically referred to as Minimum
Equipment List (MEL) items and include such factors as increased fuel flow, decreased
airspeed, takeoff weight limitations, and so on.
When you add a record to the MDB, you cite a specific Customer Aircraft Database (CADB)
record name, the appropriate filename from the MEL Database, and the MEL type. This
information identifies the individual aircraft and its problem. The following is a list of
available MEL types:
• Minimum Equipment List (MEL)

• Configuration Deviation List (CDL)
• Deferred Maintenance Item (DMI)
• Non-Essential Furnishings (NEF)
• Special Equipment List (SEL)
The MDB allows you to specify a time frame for the resolution of the problem and to add
notes related to the issue and its resolution.
For example, assume that you have several B757 aircraft in your fleet and that one of the
aircraft has a minor fuel flow problem due to a sticky valve. Assume also that your MEL
database contains a fuel flow degradation MEL record that applies to the B757 fleet type.
Using the MDB, you can create a record that references the individual B757 CADB record
name, the name of the MEL record that contains a fuel flow bias appropriate for the situation,
and the MEL Type (see list above). You can also define the expected suspense time until the
problem is resolved and note any other information necessary. Because the MDB record you
create is tied to a specific CADB record name, every time that aircraft is used in a JetPlan
flight plan computation, the fuel flow bias is included in the plan computation until the
suspense period ends or until you delete the MDB record from the MDB.

963
Database Parameters
Database Parameters
The following table defines the parameters that can be set in the MDB. These parameters
appear as options on the MDB pages in JetPlan.com. As you perform MDB tasks, consult this
table for information.

maintenance. See the JetPlan.com Help file for directions. For the convenience of
JetPlan command-line users, the table below lists JetPlan database codes under the
parameter names.
Table 37-1 MDB Parameters
Effective Date/Time The Effective Date and Time parameter allows you to set the
EFF chronological start point of the aircraft’s problem. The value must be
entered in the following format: DDMMYYYY@HHMM. The time input
ex. EFF=23082002@0100
(HHMM) is UTC. JetPlan disregards an MDB record that is not yet
effective when you run the flight plan.
Expiration Date/Time The Expiration Date and Time parameter allows you to set the
EXP chronological end point of the aircraft’s problem. The value must be
entered in the following format: DDMMYYYY@HHMM. The time input
ex. EXP=31122002@2359
(HHMM) is UTC. JetPlan disregards an MDB record that is no longer in
effect when you run the flight plan.
Duration Type This option allows you to enter eight characters of text information. The
(DURTYPE application of this option is at your discretion and has no effect on the
ex. DURTYPE=text)
Duration Time This option allows you to enter eight characters of text information. The
(DURTIME application of this option is at your discretion and has no effect on the
ex. DURTIME=text)
Airplane Grounded (Required) This option allows you to specify the status of the aircraft.
(GRND Choices are Yes and No. This option has no effect on the flight plan
computation.
ex. GRND=Y)
NOTE This parameter is for informational purposes only. No warning or
alert is provided if a flight plan is generated using a grounded aircraft.
Location Code The Location Code option allows you to enter text identifying the location
(LC on the aircraft to which the MEL item applies—for example, “Left,”
Right,” “Fore,” Aft,” and so on. This option has no effect on the flight
Ex. LC=text)
plan computation.
Value: A maximum of 10 characters is allowed.

964
Database Parameters
Table 37-1 MDB Parameters (continued)
MEL Multiplier The MEL Multiplier option allows you to apply the MEL degradation
(MX specified in the MEL record multiple times to one aircraft. The total is
included in the flight plan calculation. You can apply the multiplier value
ex. MX=02)
against one or more of the following options by selecting the associated
Subject to Multiplier checkbox on the Add a Minimum Equipment
List Code page in JetPlan.com:
• Fuel Flow Bias
• Enroute Weight Factor
• Enroute Weight Penalty
Example: In the MEL database record, the Enroute Weight Factor penalty
is set to 0.9, and the Subject to Multiplier checkbox for Enroute Weight
Factor is selected. The MEL Multiplier option in the associated MDB
record is set to 02, so the Enroute Weight Factor penalty value is applied
twice in the flight plan calculation.
For more information on the Subject to Multiplier option, see the
Minimum Equipment List Database” chapter in the JetPlan User Manual.
Input value: A two-digit number between 01 and 99. The default value is
01.
Tracking Number The Tracking Number option allows you to enter a free-form code that
(TN combines with the A/C name to identify a unique MEL Assignment
record in the system. This information has no effect on flight plan
ex. TN=text)
computations, but is displayed in the flight planning system and might
appear on the flight plan output, depending on format.
Input value: A maximum of 14 characters
Department/Personnel Allows you to enter 24 characters of text at your discretion.

(DEPT
ex. DEPT=text)
Comments Allows you to enter 50 characters of text at your discretion.

(CMNT
ex. CMNT=text)

965
Database Management
Database Management

To make the MDB a data resource for flight planning, you must first create and manage
JetPlan command-line interface, the MDB access command is MDB, and it is entered on the
Two categories of command functions are available when accessing the CAPDB. These
File Maintenance
• DEL – Deletes an existing record or records
File Display
• SUM – Displays a summary record or records
• PRI – Displays a detailed record or records
The record you affect in the database is referenced by its name. The record name, referred to in
the MDB as the A/C tail number, must be the aircraft’s Customer Aircraft database (CADB)
record name. Using the aircraft’s CADB record name ties the MDB record to the specific

966
Database Management
aircraft with a problem. This forces the application of the MDB record and the MEL within it
every time the aircraft is used in a flight plan. The CADB record name input immediately
follows the function command input.
Since the purpose of the MDB is to apply MELs, an existing MEL type and MEL Database
record name must be referenced to properly save or change an MDB record. This input
immediately follows the CADB record name, so that the input structure has the following
syntax:
MDB,function command,CADB record name,MEL type,MEL name,parameter

NOTE The MEL name must reference an existing MEL record or an error occurs. If
you are unsure of the file name (or its existence), perform the command MEL,PRI on
the Options command line to see what is available in the MEL Database.
The MDB record key elements are described in the following table.
Table 37-2 MDB Record Key Elements
A/C tail number (CADB Record (Required) The CADB record name identifies the aircraft.
Name)
NOTE The CADB record name
is created by the user and can be
the same as the A/C Tail
Number.
MEL Type (Required) This element identifies the type of MEL item.
To assign an MEL item to an aircraft, you must specify both the MEL
name and the MEL Type. Otherwise, no degradations are applied.
For each record, you can input one of the following values:
Possible values:
• M – MEL (the default)
• C – Configuration Deviation List (CDL)
• D – Deferred Maintenance Item (DMI)
• N – Non-Essential Furnishings (NEF) – JetPlan does not accept
performance degradations if the MEL record is designated as type N.
• S – Special Equipment List (SEL) – JetPlan does not accept
performance degradations if the MEL record is designated as type S.

967
Database Management
Table 37-2 MDB Record Key Elements (continued)
MEL Name (Required) This is the name of the MEL database record you are
referencing. This is typically the ATA code.
If the MDB references an MEL item that does not exist in the MEL
database, JetPlan generates an alert when you run the flight plan.
NOTE MEL names created in the JetPlan command-line interface can
contain up to 24 alphanumeric characters. MEL names created in the
JetPlan.com interface can contain up to 16 alphanumeric characters. A
planned release of JetPlan.com supports creation of an MEL Name that has
24 characters.

968
Database Management
MDB Commands
The MDB command functions are divided into two categories: file maintenance and file

Table 37-3 MDB File Maintenance Commands
Command Description
MDB,SAV The SAV function command allows you to create a new record of
information for a particular aircraft in the MDB Database. Specify the
CADB record name and the MEL type and MEL name you want to apply
before entering any parameters.
EXAMPLE:
Explanation: Save record, N1234, with the degradations assigned in MEL
record, SS1234, MEL type M, to the MDB Database. Apply the MEL for
a period of 27 days (beginning 4 September 2009 and ending 30
September 2009).
01 OPTIONS
MDB,SAV,N1234,M,SS1234,EFF=04092009@0000,EXP=30092009
@2359
JetPlan displays the new record upon completion of the input.
NOTE “Tail Number” in the output corresponds (in this case) to the CADB
record name for the aircraft. Although the CADB record name can be the
same as the tail number, it does not need to be.
To include more details, enter other parameter options as needed
(see“Database Parameters” on page 964).
EXAMPLE:
01 OPTIONS MDB,SAV,CADB RECORD
NAME,TYPE,MELNAME,DEPT=,CMNT=,GRND=,DURTIME=,DURTYPE=
MDB,CHG The CHG command allows you to modify the parameter settings of an
existing record. The input is similar to the SAV input. You can add new
parameter settings to the record or change previous settings to new
values.
EXAMPLE:
01 OPTIONS MDB,CHG, N1234,
D,SS1234,EXP=01102002@2359,GRND=Y

969
Database Management
Table 37-3 MDB File Maintenance Commands (continued)
Command Description
MDB,DEL The DEL command allows you to delete individual records from the
database. To delete a record, enter the CADB record name, MEL type,
and the MEL name after the function command.
EXAMPLE:
01 OPTIONS MDB,DEL,N1234,D,SS1234

Table 37-4 MDB File Display Commands
Command Description
MDB,SUM The SUM function allows you to display records in a list format. File
information is abbreviated with this command, showing only the CADB
record name (tail number), MEL type, MEL name, effective date, and
expiration date.
To display all records in the database, enter the command, SUM.
EXAMPLE:
01 OPTIONS MDB,SUM
To display records with the same CADB record name, enter the CADB
record name after the SUM command.
EXAMPLE:
01 OPTIONS MDB,SUM,N1234
To display an individual record, enter the CADB record name, MEL type,
and MEL name after the SUM command.
EXAMPLE:
01 OPTIONS MDB,SUM,N5678,M,SS1234

970
Table 37-4 MDB File Display Commands (continued)
Command Description
MDB,PRI The PRI function allows you to display the entire contents of one or more
records.
To display the contents of all records, enter the PRI command only.
EXAMPLE:
01 OPTIONS MDB,PRI
To display the contents of records with the same CADB record name,
enter the CADB record name after the PRI command.
EXAMPLE:
01 OPTIONS MDB,PRI,N1234
To display the contents of a single record, enter the CADB record name
and the MEL type and name after the PRI command.
EXAMPLE:
01 OPTIONS MDB,PRI,N5678,M,SS1234

Because an MDB record includes the specific CADB record name of the aircraft being
affected, there is no input that applies the MDB record to the flight plan other than the use of
the aircraft record name in the flight plan request. The MDB record is effective until the record
expires or until you deactivate (delete) it.

971
C HAPTER 38
Minimum Equipment
List Database
Minimum Equipment List Database
About the MEL Database

IMPORTANT This document contains information on ICAO 2012 Filed Flight Plan
(FPL) database parameters. The Jeppesen cutover to the ICAO 2012 FPL format
occurred on November 14, 2012. All flight plans filed with Jeppesen flight planning
products are now filed in the ICAO 2012 format by default. Flight plans not filed in the
ICAO 2012 format might be rejected by ATC.

The Minimum Equipment List (MEL) database enables you to create and manage records of
performance degradations and equipment shortcomings for aircraft of a given fleet type (a
specific airframe/engine combination). Examples of degradations include increased fuel flow,
decreased airspeed, and takeoff weight limitations. These degradations can be identified by
standard ATA codes.
The purpose of the MEL database is only to store predefined MEL items for subsequent
assignment to specific aircraft. When you create an MEL database record, you provide the
degradation and fleet type information and give the record a name. You can then use the MEL
record name when assigning the MEL item to an aircraft, either through the Master Database
(MDB) or by including the MEL record name on the flight plan request. For more information
on the MDB, see the “Master Database (MDB)” chapter in the JetPlan User Manual.
The primary benefit of using the MEL database is that you do not have to define the
degradations to be applied for each flight plan. Instead, degradations can be applied by
reference to a predefined MEL record. One MEL record can apply to a fleet of aircraft, all
having the same characteristic shortcoming or need for limitation.
For example, assume you have a fleet of B747-400s and that you have used the generic aircraft
ID, 747M, from the JetPlan Aircraft Library as the basis for the B747-400 fleet in your
Customer Aircraft Database (CADB). You can define degradations for your fleet of 747-400s
by using the generic aircraft ID (747M) to define a fleet type in your MEL database record.
Once stored in the MEL database, the MEL record is available for assignment to an aircraft of
this fleet type.

975
For information on applying MEL records, see “Flight Plan Application” on page 997.
NOTE Your flight plan output format can be customized to display information from
the MEL database. For more information, contact your Jeppesen account manager.
How the MEL Database Supports the ICAO 2012 FPL
NOTE This section assumes that you use JetPlan.com to maintain the MEL
database.
Jeppesen transitioned to the ICAO 2012 format on November 14, 2012. Since then, the ICAO
2012 FPL format has been the Jeppesen standard used by all of the Jeppesen flight planning
applications. The MEL database contains parameters that allow you to degrade or override the
following ICAO 2012-specific parameters in the “ICAO 2012 Certification and Equipment”
section of the CADB:
• 10a/b EQUIPMENT
• Item 18 COM/
• Item 18 PBN/
• Item 18 SUR/
• Item 18 CODE/
• Item 18 PER/
For detailed definitions and input values for the ICAO 2012 MEL database parameters, see
“Database Parameters” on page 978.

976
Before Using the ICAO 2012 MEL Database Parameters

Before using the ICAO 2012 MEL Database parameters, note the following:
• You must configure your CADB with ICAO 2012 parameters. The ICAO
2012 FPL is pre-populated with this data. For information on setting up the
CADB, see the “ICAO 2012 Certification and Equipment” section in the
Help topic for the CADB on JetPlan.com or the “Customer Aircraft
Database” chapter in the JetPlan User Manual.
• Entering any of the Item 18 indicators themselves in a database parameter
text box might cause the flight plan to be rejected. For example, in the
COM/ Override text box, do not enter “COM” or “COM/” or “/”, followed
by the input value. Enter only the input value for the parameter, using only
numbers and letters—for example, F10000.

977
Database Parameters
Database Parameters
The following table lists the parameters in the MEL database. These parameters appear as
options on the MEL database pages in JetPlan.com. As you perform MEL database tasks,
consult this table for information.
NOTE Depending on your customer preference settings, some options might not be
available. For more information, contact your Jeppesen account manager.

database codes under the associated parameter names.
Table 38-1 MEL Database Parameters
MEL Name (Required) The MEL Name option enables you to assign a name to the
MEL database record.
To assign an MEL to an aircraft, you must specify both the MEL Name
and the MEL Type. Otherwise, no degradations are applied
Input value: 1–24 alphanumeric characters using the JetPlan command-
line interface or 1-16 characters using JetPlan.com.
NOTE A planned release of JetPlan.com supports creation of an MEL
Name that has 24 characters.
NOTE Clicking MEL Name on the Minimum Equipment List Record
page opens the Change Minimum Equipment List Record page.
Degradation Type (Required) The Degradation Type option enables you to indicate the type
of MEL item.
NOTE The ICAO 2012 parameters are not available for SEL and NEF
MEL types.
To assign an MEL to an aircraft, you must specify both the MEL Name
and the MEL Type. Otherwise, no degradations are applied.
Input values:
• MEL – Minimum Equipment List.
• CDL – Configuration Deviation List.
• SEL – Special Equipment List. JetPlan does not accept performance
degradations if the MEL record is designated as an SEL type.
• NEF – Non-Essential Furnishings. JetPlan does not accept
performance degradations if the MEL record is designated as an NEF
type.
• DMI – Deferred Maintenance Item.

978
Database Parameters
Table 38-1 MEL Database Parameters (continued)
Max Fuel Capacity (LBS) The Max Fuel Capacity option enables you to set a limitation to the
FC amount of fuel an aircraft can load on board. If the MEL is applied to the
aircraft, this value overrides the maximum fuel capacity figure stored in
ex. FC=145950
the CADB.
True Airspeed Bias The True Airspeed Bias option enables you to set an airspeed degradation
TAS factor. The value you enter must be a percentage decrease based on a
factor of 1 (100%). For example, a 2% decrease in TAS is expressed by
the input value 1.02.
MEL true airspeed biases are in addition to any TAS biases already stored
in a CADB file. For example, using an aircraft from the CADB that has a
3% TAS bias stored and invoking an MEL file that has a 3.5% bias results
in a cumulative TAS bias of 6.5%.
Max Airspeed The Max Airspeed (MAS) value and the Max Airspeed Type must be
MAS entered together.
- and - Input values for airspeed type include Mach (M), Calibrated (C), and True
(T).
Max Airspeed Type
The Max Airspeed (MAS) value option enables you to set the airspeed for
T, C, M
a fleet type to a maximum limit based on a specific type of speed measure.
ex. MAS=T250 Max speed values need to be relative to the selected type and not out of
ex. MAS=C220 line with the aircraft’s capabilities.
ex. MAS=M72
Max Airspeed Type See Max Airspeed above.
Max Zero Fuel Wt (LBS) The Max Zero Fuel Weight option enables you to set a zero fuel weight
ZF limitation for the fleet type. If the MEL is applied to the aircraft, this value
overrides the MZFW figure stored in the CADB.
ex. ZF=189950
Ballast (LBS) The Ballast option enables you to set a specific amount of fuel on the
BAL aircraft, increasing the basic operating weight of the aircraft.
ex. BAL=8900
Max Takeoff Wt (LBS) The Max Takeoff Wt option enables you to set a takeoff weight limitation
TO for the fleet type. If the MEL is applied to the aircraft, this value overrides
the maximum takeoff weight figure stored in the CADB.
ex. TO=369000

979
Database Parameters
Max Flight Level The Max Flight Level option enables you to set a maximum altitude for
FL the aircraft.
ex. FL=250 Input value: The value you enter must follow the JetPlan standard for
flight level inputs (three digits, in hundreds of feet). For example, the
input 250 represents 25,000 feet. This input prevents the aircraft from
exceeding the specified MEL maximum in a flight plan computation.
Max Landing Wt (LBS) The Max Landing Wt option enables you to set a landing weight
LA limitation for the fleet type. If the MEL is applied to the aircraft, this value
overrides the maximum landing weight figure stored in the CADB.
ex. LA=350000
Min Temperature The Min Temperature option enables you to specify a minimum
TMN temperature threshold that, if exceeded at any waypoint within a flight
plan, results in an alert about the extreme condition.
NOTE This alert feature is designed for specific customer usage. Contact
your Jeppesen account manager if you have questions.
Flat Fuel Amount (LBS) The Flat Fuel Amount (LBS) option enables you to set a fuel burn penalty,
FA specified in pounds. JetPlan treats this as unburnable fuel. Unlike ballast,
this fuel could be present in any fuel tank. It is most often associated with
a fuel pump that is inoperative or that must be kept submerged.
Input value range: 0–99999 lbs. Default is 0.
Max Temperature The Max Temperature option enables you to specify a maximum
TMX temperature threshold that, if exceeded at any waypoint within a flight
plan, results in an alert about the extreme condition.
NOTE This alert feature is designed for specific customer usage. Contact
your Jeppesen account manager if you have questions.
Operational Code NOTE This parameter is stored in the JetPlan database for use by GUI
software applications that interface with JetPlan. This parameter has no
OC
JetPlan functionality. Contact your Jeppesen account manager for more
information.
For users of a front-end flight planning GUI interface, the Operational
Code option enables storage of a value that has meaning in their
operations. This value has no effect on flight plan computation.
Input value: 1–6 alphanumeric characters

980
Database Parameters
Overwater Restriction When set to Yes, this parameter degrades the overwater certification or
OW capability of the aircraft, overriding the values of the CADB Overwater
Equipped (OW) and Overwater Capability (OA) parameters.
Input options:
• Yes – Indicates that the aircraft is unable to perform up to the
standard of the overwater certification/capability, overriding both the
Overwater Equipped (OW) and the Overwater Capability (OA)
parameters in the CADB when the MEL is applied to the aircraft.
• No – Indicates that the MEL item does not affect the aircraft’s
overwater certification or capability setting in the CADB. No is the
default value.
RVSM Degradation The RVSM Degradation option enables you to indicate how the MEL item
RV affects the aircraft’s Separation Minimums capability to perform as
certified. Degrading RVSM causes the system to seek flight levels outside
of the RVSM flight levels when in RVSM airspace, or to alert you when
you force an invalid flight level.
Input value: Yes/No
standard of the RVSM certification, overriding the RVSM Certified
(RV) parameter in the CADB when the MEL is applied to the
aircraft. This setting causes an automated edit to remove the “W”
character from Item 10a of the ICAO filing strip.
• No – Indicates that the MEL item does not affect the aircraft’s
RVSM capability setting in the CADB. No is the default value
RNP Degradation The RNP Degradation option enables you to indicate how the MEL item
RP affects the aircraft’s area navigation capability to perform as certified.
Degrading RNP causes the system to require flight levels outside of those
required in RNP areas or on RNP routes.
Input value: Yes/No
standard of the RNP certification, overriding the RNP Certified (RP)
parameter setting in the CADB when the MEL is applied to the
aircraft.
NOTE You must use the PBN Degradation parameter (see below) to
exclude “R” from Item 10a and “PBN/” from Item 18 on the ICAO filing strip.
• No – Indicates that the MEL item does not affect the aircraft’s RNP
capability setting in the CADB. No is the default value.

981
Database Parameters
MNPS Degradation NOTE “MNPS Equipped” is being renamed “NAT HLA” in 2016.
ME The MNPS Degradation option enables you to indicate how the MEL item
affects the aircraft’s Minimum Navigation Performance Specification
(MNPS) capability to perform as certified. Degrading MNPS causes the
system to require flight levels above or below those required in MNPS
areas or to alert you if you force an MNPS flight level.
Input value: Yes/No
standard of the MNPS certification, overriding the NAT HLA
Equipped (ME) parameter setting in the CADB when this MEL is
applied to the aircraft. This setting causes an automated edit to
remove the “X” character from Item 10a of the ICAO filing strip.
• No – Indicates that the MEL item does not affect the aircraft’s NAT
HLA capability setting in the CADB. No is the default value.
Dispatcher Concurrence NOTE This parameter is stored in the JetPlan database for use by GUI
DC
information.
The Dispatcher Concurrence option enables you to require that the
dispatcher agree with the assignment of the MEL to the aircraft. The
system checks and logs the concurrence.
Input value: Yes/No
Yes indicates dispatcher concurrence is required. No is the default value.
RNAV Degradation The RNAV Degradation option enables you to indicate how the MEL item
RN affects the aircraft’s RNAV capability to perform as certified.
Input values:
• None – Indicates that the MEL item does not affect the aircraft’s
RNAV capability as it is set in the CADB. None is the default value.
• Terminal Degraded/Enroute OK – Indicates that flight plans are
calculated with no Terminal RNAV capability, regardless of the
aircraft’s settings in the CADB.
• Terminal & Enroute Degraded – Indicates that flight plans are
calculated as if the aircraft had no RNAV capabilities.
NOTE RNAV degradation only affects the flight plan computation as
described above. It does not remove “I” and “G” from Item 10a on the ICAO
filing strip. You must use the 10a/b Equipment Degradation parameter (see
below) to remove “I” and “G” codes from Item 10a on the ICAO filing strip.
NOTE The RN and NORN flight plan options override the Customer
Aircraft Database (CADB) setting for RNAV and ignore any MEL
degradations that have been applied to RNAV. See the “Option

982
Database Parameters
ICAO 2012 Parameters
The following parameters are used with ICAO 2012 filings.
IMPORTANT Before using the ICAO 2012 parameters, read “How the MEL Database Supports the ICAO 2012
FPL” on page 976.
NOTE The ICAO 2012 parameters are not available for SEL and NEF MEL types.
10a/b Equipment Degradation The 10a/b Equipment Degradation option enables you to indicate how the
EQD MEL affects the aircraft’s equipment and surveillance equipment
capabilities as defined by the values of the ICAO 2012 10a/b Equipment
(NC2) parameter in the CADB. When the MEL DB10a/b Equipment
Degradation parameter is populated with a given 10a or 10b code, that
code is automatically removed from Item 10a/b on the filing strip.
Input values: Up to 100 characters, selected from the list of 10a and 10b
codes in the “ICAO 2012 Certification and Equipment” section of the
CADB. The “/” 10a/b delimiter (slash) is used in the same way that it is
used in the CADB Equipment 10a/b parameter definition—to separate
equipment capabilities and surveillance equipment. To enter just 10a
codes, type the codes and do not include a slash (/). To enter just 10b
codes, type a slash followed by the codes. If you enter both 10a and 10b
codes, type the 10a codes before the slash (/) and the 10b codes after the
slash (/). For example:
• To exclude “C” from the 10a Equipment item in the filing strip, enter
the following in the MEL DB 10a/b Equipment Degradation box: C.
• To exclude “C” from 10b Surveillance Equipment, enter the
following in the MEL DB 10a/b Equipment Degradation box: /C.
• To exclude “C” from both 10a and 10b, enter the following in the
MEL 10a/b Equipment Degradation box: C/C.
The following is a sample 10a/b Equipment Degradation entry using
several 10a codes and one 10b code: SXJCZWHGRY/C.
Input values – For a list of the 10a/b codes and their definitions, see the
10a/b EQUIPMENT parameter in the CADB Help topic on JetPlan.com.

983
Database Parameters
10a/b Equipment Addition The 10a/b Equipment Addition parameter enables you to store Item 10a/b
10aba Equipment codes in the MEL DB record.
The system adds codes stored in the10a/b Equipment Addition parameter
to CADB Item 10a/b Equipment codes and outputs the combined codes in
alphanumeric order in Item 10a/b on the filing strip, subject to the
following conditions:
• The system does not replace codes or duplicate codes derived from
the CADB 10a/b Equipment parameter with codes derived from the
10a/b Equipment Addition parameter.
• The codes stored in the 10a/b Equipment Addition parameter are
affected by MEL degradation. When the 10a/b Equipment
Degradation parameter in the MEL DB is populated with a given 10a
or 10b code, that code is automatically removed from Item 10a/b on
the filing strip, regardless of the source of the code (MEL DB or
CADB).
Input value: Up to 100 characters, selected from the list of 10a and 10b
codes in the “ICAO 2012 Certification and Equipment” section of the
CADB. The “/” 10a/b delimiter (slash) is used in the same way that it is
used in the CADB Equipment 10a/b parameter definition—to separate
equipment capabilities and surveillance equipment. When entering the
codes, follow these guidelines:
• To enter just 10a codes, type the codes and do not include a slash (/).
Example: J1
• To enter just 10b codes, type a slash (/) followed by the codes.
Example: /B2
• To enter both 10a and 10b codes, type the 10a codes followed by a
slash. Then type the 10b codes after the slash. Example: J1/B2
For a list of the 10a/b codes and their definitions, see the 10a/b
EQUIPMENT parameter in the CADB Help topic on JetPlan.com.

984
Database Parameters
PBN Degradation The PBN Degradation option enables you to indicate how the MEL item
FPBN affects the aircraft’s Performance Based Navigation (PBN) ability to
perform as certified as indicated by the setting of the PBN Certified (I1)
parameter in the “ICAO 2012 Certification and Equipment” section of the
CADB. When this parameter is selected, an automatic edit removes the
“R” designator from Item 10a and the PBN/ indicator from Item 18 in the
filing strip.
NOTE PBN Degradation does not affect how the system computes a flight
plan.
Input options:
• Selected (Yes) – Indicates that the aircraft is unable to perform up to
the standard of the PBN certification. This setting overrides the
setting of the PBN Certified (I1) parameter in the CADB when the
MEL item is applied to the aircraft and causes an automated edit to
remove the “R” designator from Item 10a and the PBN/ indicator
from Item 18 in the filing strip.
• Not selected (No) – Indicates that the MEL item does not affect the
aircraft’s PBN Certification setting.

985
Database Parameters
PBN/ Degradation NOTE This parameter is not available when the MEL DB PBN
Degradation parameter has been selected.
PBND
The PBN/ Degradation parameter enables you to remove specific PBN/
equipment values from Item 18 in the filing strip. Depending on the
setting of the PBN Degradation parameter, the PBN/ Degradation
parameter value has the following effect:
• If the CADB PBN Certified parameter equals Yes and the MEL DB
PBN Degradation parameter also equals Yes (is selected), the system
excludes “PBN/” output from Item 18 on the filing strip. In this case,
the PBN/ Degradation parameter is not available in JetPlan.com and
has no effect.
• If the CADB PBN Certified parameter equals No, the system
automatically excludes “PBN/” from the Item 18 output—that is, the
MEL PBN/ Degradation parameter is ignored even if it has a value.
• If the CADB PBN Certified parameter equals Yes, and the MEL DB
PBN Degradation parameter is not selected, PBN codes in the MEL
DB PBN/ Degradation parameter trigger a removal of those
particular CADB PBN/ codes from Item 18 PBN/ on the filing strip.
NOTE PBN/ Degradation does not affect how the system computes a
flight plan.
Input values – For a list of the PBN/ codes and their definitions, see the
Item 18 PBN/ parameter in the “ICAO 2012 Certification and Equipment”
section of the CADB Help topic on JetPlan.com.
NOTE The current ICAO limit is eight codes (16 characters), but that
might change in the future. For that reason, there is no limit to the number
of codes that can be selected.
NOTE Do not use any special characters, including a slash (/) or a hyphen
(-) in any Item18 text. Doing so might result in rejected flight plan filings.

986
Database Parameters
PBN/ Addition The PBN/ Addition parameter enables you to store Item 18 PBN/ codes in
PBNA an MEL DB record. The MEL PBN/ Addition parameter is used in
conjunction with the MEL PBN/ Degradation entries when an MEL item
removes certain PBN codes but adds others.
If the MEL PBN/ Addition parameter is populated, the system adds the
codes to the existing CADB Item 18 PBN/ codes and outputs all in Item
18 on the filing strip in alphanumeric order.
The PBN/ Addition parameter interacts with the CADB PBN Certified
parameter, the MEL DB PBN Degradation parameter, and the MEL DB
PBN/ Degradation parameters as follows:
• If the CADB PBN Certified parameter equals No, the system
automatically excludes “PBN/” from the Item 18 output—that is, the
MEL PBN/ Addition parameter is ignored even if it has a value.
• If the CADB PBN Certified parameter equals Yes and the MEL PBN
Degradation parameter also equals Yes (is selected), the system
excludes “PBN/” output from Item 18 on the filing strip. In this case,
the PBN/ Addition parameter has no effect.
PBN Degradation parameter is not selected, PBN codes in the PBN/
Addition parameter are added in alphanumeric order to the CADB
PBN/ codes in Item 18 PBN/ on the filing strip.
PBN Degradation parameter is not selected, and the MEL PBN/
Degradation parameter does not contain a matching code, PBN
codes in the PBN/ Addition parameter are added to the CADB PBN/
codes in Item 18 PBN/ on the filing strip. Any Item 18 PBN/code that
is in the PBN/ Degradation parameter is excluded from the Item 18
output, even if it is in the PBN/ Addition parameter or in the CADB
Item 18 parameter.
Input values – For a list of the PBN/ codes and their definitions, see the
Item 18 PBN/ parameter in the “ICAO 2012 Certification and Equipment”
section of the CADB Help topic on JetPlan.com.
IMPORTANT JetPlan does not verify that your PBN/ Addition entries are
valid PBN codes. Item 18 PBN/ codes consist of two alphanumeric
characters. Do not use any special characters, including a slash (/) or a
hyphen (-) in any Item18 text. Doing so might result in rejected flight plan
filings.
NOTE If a non-degraded code is in both the PBN/ Addition parameter and
the CADB Item 18 PBN/ parameter, it is not added twice to the Item 18
output.
NOTE All Item 18 PBN/ codes are entered in Item 18 on the filing strip in
alphanumeric order.

987
Database Parameters
COM/ Override Enables you to store an Item 18 COM/ override in an MEL DB record. If
COMO the MEL DB COM/ Override parameter is populated, the system uses the
MEL DB COM/ value in the Item 18 COM/ output instead of the COM/
value in the “ICAO 2012 Certification and Equipment” section of the
CADB. See the CADB Help topic on JetPlan.com for information about
the COM/ parameter.
Input values: Up to 100 alphanumeric characters, if needed. However,
EUROCONTROL accepts only 50.
NOTE Entering an asterisk (*) in COM/ Override triggers the exclusion of
the COM/ indicator from Item 18 with the following exception:
COM/EXM833 is still output if the CADB parameter 83 833 KHZ COMM
parameter is set to E (for Exempt).
DAT/ Override Enables you to store an Item 18 DAT/ override in an MEL DB record. If
DATO the MEL DB DAT/ Override parameter is populated, the system uses the
MEL DB DAT/ value in the Item 18 DAT/ output instead of the DAT/
the DAT/ parameter.
EUROCONTROL accepts only 50.
NOTE Entering an asterisk (*) triggers the exclusion of the DAT/ indicator
from Item 18.
SUR/ Override Enables you to store an Item 18 SUR/ override in an MEL DB record. If
SURO the MEL DB SUR/ Override parameter is populated, the system uses the
MEL DB SUR/ value in the Item 18 SUR/ output instead of the SUR/
the SUR/ parameter.
EUROCONTROL accepts only 50
NOTE Entering an asterisk (*) triggers the exclusion of the SUR/ indicator
from Item 18.

988
Database Parameters
CODE/ Override Enables you to store an Item 18 CODE/ override in an MEL DB record. If
CODEO the MEL DB CODE/ Override parameter is populated, the system uses the
MEL DB CODE/ value in the Item 18 CODE/ output instead of the
CODE/ value in the “ICAO 2012 Certification and Equipment” section of
the CADB. See the CADB Help topic on JetPlan.com for information
about the CODE/ parameter.
Input values: Up to six (6) alphanumeric characters.
NOTE Entering an asterisk (*) triggers the exclusion of the CODE/
indicator from Item 18.
PER/ Override Enables you to store an Item 18 PER/ override in an MEL DB record. If
PERO the MEL DB PER/ Override parameter is populated, the system uses the
MEL DB PER/ value in the Item 18 PER/ output instead of the PER/ value
in the CADB. See the CADB Help topic on JetPlan.com for information
about the PER/ parameter.
Input values: One (1) alphanumeric character only.
NOTE Entering an asterisk (*) triggers the exclusion of the PER/ indicator
from Item 18.
Miscellaneous Parameters
Dispatch UI NOTE This parameter is stored in the JetPlan database for use by GUI
DUI
information.
The Dispatch UI option enables you to indicate whether the MEL is
displayed to dispatchers on the front-end flight-planning user interface.
This option has no effect on flight plan computation.
Input value: Yes/No
Flight Plan Output NOTE This parameter is stored in the JetPlan database for use by GUI
FPI
information.
The Flight Plan Output option indicates whether the MEL is listed on the
flight plan output.
Input value: Yes/No

989
Database Parameters
Phase of Flight The Phase of Flight option enables you to limit the flight phase or phases
(CFS Indicator) to which the MEL applies. The Phase of Flight indicator applies only to
the fuel flow bias. You can select more than one option.
CFS (ETOPS Critical Fuel
Scenario) Input values:
CLB • ETOPS Critical Fuel (CFS) – The system considers the MEL
degradation in the critical fuel scenario calculations (ETOPS flight
CRZ
plans).
DES
• Climb – The system considers the MEL degradation when
TXI calculating the climb phase of the flight plan.
• Cruise – The system considers the MEL degradation when
calculating the cruise phase of the flight plan.
• Descent – The system considers the MEL degradation when
calculating the descent phase of the flight plan.
• Hold – The system considers the MEL degradation when calculating
the hold phase of the flight plan.
• Alternate – JetPlan does not currently use this parameter.
• Taxi Out – The system considers the MEL degradation when
calculating the taxi out phase of the flight plan.
Documentation Reference URL The Documentation Reference URL option enables storage of a URL
RL reference to a file location. The front-end system uses this value to
provide a link to the file, allowing the dispatcher to view the related
Master MEL data directly from the flight-planning application.
Input value: URL address or text up to 100 characters
MEL Display Name Enables you to specify a unique and meaningful name for the MEL type.
Input value: 1–24 alphanumeric characters using the JetPlan command-
line interface or 1-16 characters using JetPlan.com.
NOTE A planned release of JetPlan.com supports creation of an MEL
Display Name that has 24 characters.

990
Database Parameters
Multiplier Penalties
Multiplier Description This is a text field for adding notes about the multiplier.
DDSC Input value: Up to 100 characters
Fuel Flow Bias The Fuel Flow Bias option enables you to set a fuel burn degradation
FF factor. The value you enter is a percentage increase based on a factor of 1
(100%). For example, a 4.5% increase in fuel flow is expressed by the
input value, 1.045. Values are applied in the measure of pounds (or kilos)
per hour per engine (lbs/hr/engine or kgs/hr/engine).
Alternatively, you can enter the bias value as an integer, expressing a
mass/time bias.
MEL fuel biases apply in addition to any fuel biases already stored in the
CADB record. For example, using an aircraft from the CADB that has a
3% bias stored and invoking an MEL file that has a 2.5% bias results in a
cumulative fuel flow bias of 5.5%.
Fuel Flow Bias is subject to a multiplier and/or a Phase of Flight
degradation if you select that option when you create the MEL record.
Penalty Subject to Multiplier When selected, this option indicates that the Fuel Flow Bias (FF) is
MFF subject to a multiplier and/or a Phase of Flight degradation.
Enroute Weight Factor The Enroute Weight Factor option enables you to set a penalty to be
EF applied to the aircraft gross weight at the decision point for Mountain
Driftdown computations and over the entire route for Terrain Clearance.
The value is a percentage by which the gross weight is increased.
Input value range: 0.00000–1.00000. The default is 0.
This penalty is subject to a multiplier degradation if you select that option
when you create the MEL record.
Penalty Subject to Multiplier When selected, this option indicates that the Enroute Weight Factor is
MEF subject to a multiplier.
Enroute Weight Penalty (LBS) The Enroute Weight Penalty (LBS) option enables you to set a penalty in
EP pounds to be added to the aircraft gross weight for Terrain Analysis
(Mountain Driftdown and Terrain Clearance).
Input value: 0–999,999 pounds. Default is 0.
This penalty is subject to a multiplier degradation if you select that option
when you create the MEL record.

991
Database Parameters
Penalty Subject to Multiplier When selected, this option indicates that the Enroute Weight Penalty
MEP (LBS) is subject to a multiplier.
Add Biases When a parent MEL record is applied to an aircraft, the biases in parent
AMB and child records are applied cumulatively when Add Biases is selected.
NOTE Add Biases is selected by default. To turn off the automatic
cumulative application of biases in parent and child MELs, clear the Add
Biases checkbox.
For more information about parent-child records and how Add Biases is
applied, see “Child MEL Parameters” on page 992.
Description This is a text field for adding notes about the MEL.
DSC Input value: Up to 200 characters
Child MEL Parameters

NOTE Parent-child MELs only apply to Fuel Flow Bias, Enroute Weight Factor, and Enroute Weight Penalty
values.
You can associate one or more MEL records with one parent MEL record. The child records are applied to an
aircraft when the parent record is applied.
When the Add Biases parameter is selected in the parent record or any of the associated child records, JetPlan
applies any indicated multipliers to the value of Fuel Flow Bias, Enroute Weight Factor, and Enroute Weight
Penalty parameters in each MEL record and then sums up all of the degradation values for application to the
aircraft. The sum total is output on the flight plan.
NOTE Only a parent and its second-generation child records are applied to the aircraft. If a parent record has a
child record which in turn has a child record, that third-generation record is not counted in the cumulative
application of MELs to the aircraft.
NOTE When the parent MEL record is applied to an aircraft in a flight plan, the biases in parent and child
records are applied cumulatively when Add Biases is selected. Add Biases is selected by default. To turn off the
automatic cumulative application of biases in parent and child MELs, clear the Add Biases checkbox.
(Child MEL) Name Select (recommended) or type the name of the child MEL record. You can
click See Candidates to select the child record from a list of MEL records
that apply to the given fleet type. The child MEL record name must
already exist in the MEL database and must apply to the same fleet type as
the parent MEL.
Input value: The name of the existing MEL record you are using as a child
MEL.
NOTE MEL names created in the JetPlan command-line interface can
contain up to 24 alphanumeric characters. MEL names created in the
JetPlan.com interface can contain up to 16 alphanumeric characters. A
planned release of JetPlan.com supports creation of an MEL Name that has
24 characters.
Type Select the Degradation Type for the child MEL record. The Degradation
Type setting for the child MEL must be the same as the Degradation Type
setting for the parent MEL record.

992
Database Management
Database Management

To apply MEL data in your flight plan requests, you must first create and manage records of
information in the database. To do this, you need to access the database. The MEL Database is
accessed by the command MEL on the Options command line. Any attempt to affect or
reference the information in the database must begin with the MEL command.
Two categories of command functions are available when accessing the MELDB. These
File Maintenance
• DEL – Deletes an existing record or records
File Display
• SUM – Displays a record or records
• PRI – Displays a record or records
The fleet type, MEL type, and MEL name are the key elements that define the MEL record.
They follow function commands, such as SAV, and precede any optional parameters in the
command-line input. MEL Database functions use the following syntax:
MEL,function command,fleet type,MEL type,MEL name,parameter


993
Database Management
MEL Database Commands

The MEL Database command functions are divided into two categories: file maintenance and
file display. This section describes each command function.

Table 38-2 MEL Database File Maintenance Commands
Command Description
MEL,SAV The SAV command allows you to create a new record of information for a particular fleet type
in the MEL Database. Specify the fleet type and the MEL type and provide a file MEL name
before entering the parameters you wish to set.
You can include any other parameters when saving records in the database. You can even omit
all optional parameter inputs if you just want to set up a record in the database for future
refining. The point is that a record is created or affected by the input of the access command
(MEL), the function command (SAV), the fleet type, the MEL type, and the MEL name.
NOTE To assign an MEL to an aircraft, you must specify both the MEL name and the MEL
Type. Otherwise, no degradations are applied.
Example:
01 OPTIONS MEL,SAV,747M,D,FILEABC,FF=1.02
MEL,CHG The CHG function allows you to modify the parameter settings of an existing record. The
input is similar to the SAV input. You can add new parameter settings to the record, change
previous settings to new values, or reset values to the default state. To reset a parameter value
to a default state, you must provide a zero (0) value to the parameter (for example, ff=0).
Example:
01 OPTIONS MEL,CHG,747M,D,FILEABC,FF=0,MAS=T300
NOTE Changing the MAS parameter to its default value requires you to include the Type
prefix (T, C, or M) before the zero value (for example, MAS=T0). If you try to reset the MAS
parameter without the Type prefix, no change occurs.

994
Database Management
Table 38-2 MEL Database File Maintenance Commands (continued)
Command Description
MEL,DEL The DEL function command allows you to delete any or all records stored in the database.
To delete a specific record, enter the fleet type, the MEL type, and the file name after the DEL
command.
Example:
01 OPTIONS MEL,DEL,747M,D,FILEABC
To delete all records by fleet type, enter just the fleet type after the DEL command.
Example:
01 OPTIONS MEL,DEL,747M
To delete all records, just specify the DEL command (without anything further).
Example:
01 OPTIONS MEL,DEL

Table 38-3 MEL Database File Display Commands
Command Description
MEL,SUM The SUM command displays a summary of MEL record information.
To display summary information for all records in the database, enter MEL,SUM.
Example:
01 OPTIONS MEL,SUM
To display summary records by fleet type, enter the fleet type after the SUM command.
Example:
01 OPTIONS MEL,SUM,747M
To display a summary for a specific record, enter the fleet type, MEL type, and MEL name
after the SUM command.
Example:
01 OPTIONS MEL,SUM,747M,M,SS1234

995
Database Management
Table 38-3 MEL Database File Display Commands (continued)
Command Description
MEL,PRI The PRI function allows you to display detailed information about the content of the MEL
Database.
To display detailed information for all records in the database, enter MEL,PRI.
Example:
01 OPTIONS MEL,PRI
To display detailed records by fleet type, enter the fleet type after the PRI command.
Example:
01 OPTIONS MEL,PRI,747M
To display detailed information for a specific record, enter the fleet type, MEL type, and MEL
name after the PRI command.
Example:
01 OPTIONS MEL,PRI,747M,M,SS1234

996

The application of an MEL database record to a flight plan computation requires the inclusion
of the record’s name in the flight plan request. The record name is specified on the Cruise
Mode command line, after other cruise mode inputs. The input must be preceded by the
option, MEL=, which identifies the input to the JetPlan system as an MEL entry.
Example:
11 CRZ MODE LRC,MEL=ABCD
In addition, you can create Master Database (MDB) records that apply MEL records to
particular aircraft, referencing the aircraft record names in the Customer Aircraft database
(CADB). Because an MDB record includes the specific CADB record name of the aircraft
being affected, there is no input that applies the MDB record to the flight plan other than the
use of the aircraft record name in the flight plan request. The MDB record is effective until the
record expires or until you deactivate (delete) it. For more information, see the “Master
Database (MDB)” chapter in the JetPlan User Manual.
NOTE Use of the MDB is required to apply MEL multiplier penalties to aircraft. See
“Applying Multipliers to Fuel Flow Bias and Weight Penalties” on page 999.
Applying True Airspeed and Fuel Flow Biases

You can apply MEL biases for true airspeed and for fuel flow to flight plans. The fuel flow
bias and true airspeed bias are entered as multipliers based on a factor of 1 (100%). For
example, you would input 1.05 for a 5% fuel flow bias and 0.95 for a negative 5% fuel flow
bias. For detailed definitions of these and other MEL DB parameters, see “Database
Parameters” on page 978.
Biasing a flight through the MEL database must be done with caution. The JetPlan system
assumes that any MEL bias applied to a flight plan is in addition to any ad hoc bias input or
Customer Aircraft database (CADB) bias.
NOTE Ad hoc biases that are cruise-mode-specific override biases stored in the
CADB.

997
The following examples demonstrate the application of an MEL record (ABCD) with a fuel
flow bias and the interaction between this MEL bias and other biases. Assume the use of a
CADB file (N1234) with a fuel flow bias set at 2% (1.02). The MEL record has a fuel flow
bias set at 3% (1.03).
Example:
Explanation: Without an MEL record specified, the flight plan incurs a fuel flow bias of 2%
(from CADB file, N1234).

11 CRZ MODE LRC
Example:
Explanation: With the MEL record, ABCD, specified, the flight plan incurs a fuel flow bias of
5% (2% from CADB file, N1234, plus 3% from MEL record, ABCD).

11 CRZ MODE LRC,MEL=ABCD
Example:
Explanation: Without an MEL record specified, the flight plan incurs a fuel flow bias of 4%
(the ad hoc bias on the Cruise Mode command line overrides the bias set in the CADB file).

11 CRZ MODE LRC,FFLRC=1.04
Example:
Explanation: With an MEL record specified, the flight plan incurs a fuel flow bias of 7% (the
ad hoc bias overrides the CADB bias, but is added to the MEL bias).

11 CRZ MODE LRC,FFLRC=1.04,MEL=ABCD

998
Applying Multipliers to Fuel Flow Bias and Weight

Penalties
The MEL Multiplier parameter in the MDB allows you to apply one or more of the following
MEL items multiple times to one aircraft in a flight plan.
• Fuel Flow Bias

• Enroute Weight Factor
• Enroute Weight Penalty
The MEL item must be given a value in the MEL database and its corresponding Subject to
Multiplier parameter, also in the MEL database, must be set to Yes. In addition, the MEL
item’s associated MEL Multiplier parameter in the Master database (MDB) must be set to a
multiplier value. The total value is included in the flight plan calculation.
For example, a 777 aircraft has a normal complement of 16 feet of inboard flap center track
fairing seals. Assume that an MEL item in the operator’s MEL book states a fuel flow penalty
of 0.1% per foot of missing seal. The MEL record for this aircraft would be created with (1) a
fuel flow penalty of 0.1%, and (2) with the Subject to Multiplier indicator set, and (3) with
“Per foot” stored in the multiplier description field. If maintenance work identified 4 feet of
missing seal in the aircraft, the MDB record would be created with a multiplier of 4. Flight
plans including this aircraft would then be computed with a fuel flow penalty of 0.4%.
MEL fuel biases apply in addition to any fuel biases already stored in the CADB record or ad
hoc entries on the flight plan, as explained in “Applying True Airspeed and Fuel Flow Biases”
on page 997. Similarly, all weight penalties included in an ad hoc flight plan request are
summed with all Enroute Weight Penalty values and all Enroute Weight Factor values
contained in each type M or C MEL currently assigned to the aircraft.
For detailed definitions of the MEL parameters, see “Database Parameters” on page 978. For
more information on the MDB, see the “Master Database (MDB)” chapter in the JetPlan User
Manual.
Applying the Phase of Flight Parameter

The Phase of Flight parameter in the MEL database applies only to Fuel Flow Bias. It allows
you to limit the flight phase or phases to which the Fuel Flow Bias applies. When you create
the MEL record, you can select more than one of the following phases:
• CFS – The MEL degradation is considered for the critical fuel scenario
calculations (ETOPS flight plans).

999
• Climb – The MEL degradation is considered when calculating the climb

phase of the flight plan.
• Cruise – The MEL degradation is considered when calculating the cruise
• Descent – The MEL degradation is considered when calculating the descent
• Hold – The MEL degradation is considered when calculating the hold phase
of the flight plan.
• Taxi Out – The MEL degradation is considered when calculating the taxi-
out phase of the flight plan.
• Alternate – JetPlan does not currently use this parameter.
Note that you can create an MDB record that applies a multiplier to the Fuel Flow Bias and
that MEL fuel biases apply in addition to any fuel biases already stored in the CADB record or
ad hoc entries on the flight plan. For more information, see “Applying True Airspeed and Fuel
Flow Biases” on page 997 and “Applying Multipliers to Fuel Flow Bias and Weight Penalties”
on page 999.
Applying Weight Penalties to Terrain Analysis Flight

Plans
The MEL database contains two weight penalty parameters that apply to Terrain Analysis
(Terrain Clearance and Mountain Driftdown) flight plans.
• The Enroute Weight Factor parameter allows you to set a penalty to be

applied to the aircraft gross weight over the entire route for Terrain
Clearance computations and at the decision point for Mountain Driftdown
computations. The value of this parameter is a percentage by which the
gross weight is increased.
• The Enroute Weight Penalty (LBS) option allows you to set a penalty in
pounds to be added to the aircraft gross weight for Terrain Clearance and
Mountain Driftdown.
Both of these MEL parameters can be made subject to a multiplier effect. See “Applying
Multipliers to Fuel Flow Bias and Weight Penalties” on page 999.

1000
When JetPlan computes Terrain Clearance flight profiles, the total enroute weight penalty is
applied as follows:
• Any ad hoc enroute weight penalty contained in the flight plan request, plus
• Any enroute weight penalty contained in each type M or C MEL currently
assigned to the aircraft, plus
weight factor (%) * aircraft gross weight.
NOTE Because aircraft gross weight changes due to fuel burn off, the enroute
weight factor penalty is computed using a gross weight at each mileage marker.
When JetPlan computes the Mountain Driftdown gradient, the total enroute weight penalty is
applied as follows:
• Any ad hoc enroute weight penalty contained in the flight plan request, plus
• Any enroute weight penalty contained in each type M or C MEL currently
assigned to the aircraft, plus
weight factor (%) * aircraft gross weight at the decision point.
The correct gradient penalty percentage must be determined for each MEL. The following is a
sample formula for deriving an enroute weight penalty factor from the enroute gradient
penalty in the published MEL:
EWF = 1 + (GP / (1 / LDR + NG)), where:
• EWF is the Enroute Weight Factor percentage that is to be stored in the

MEL record.
• GP is the Gradient Penalty as defined in the manufacturer’s MEL.
• LDR is the Lift to Drag Ratio.
• NG is the Net/Gross Performance Factor. A standard value for NG is 0.011
(or 1.1%) for two-engine aircraft.

1001
For example, using the formula above, for an MEL that specifies a 0.032% gradient penalty
for a 737-800 at 160,000 pounds at the decision point, the weight penalty derived would be
751 pounds, assuming that LDR is 17.5 and NG is 0.011. (This equates to a 0.469% Enroute
Weight Factor if the gradient penalty were instead calculated against the aircraft weight
without the L/D formula.)
Applying Equipment and Certification Degradations

The MEL Database contains several parameters which, when applied to a flight plan, override
the aircraft’s corresponding equipment and certification settings in the CADB. See full
descriptions in Table 38-1, “MEL Database Parameters,” on page 978.

1002
C HAPTER 39
Preferred Runways
Database
Preferred Runways Database
About the Preferred Runways Database
About the Preferred Runways Database

IMPORTANT Although the Preferred Runways Database is a separate database, it
is combined with the Airport Fleet Database in JetPlan.com as a convenience to
customers. If you use JetPlan.com to manage your databases, you can find the
preferred runway parameters on the Runways page in the Airport Fleet Database. If
you use the JetPlan command-line interface, note that the 01 Option maintenance
command for the Preferred Runways Database is RWY. For information on using
JetPlan.com to manage these parameters, see the Help file for the Airport Fleet
Database on JetPlan.com. For complete information on using the command-line
interface to maintain Preferred Runways Database records, see “Database
Management” on page 1008.
You can use parameters in the Preferred Runways Database to define preferred POD and POA
runways, rank them, and specify maximum allowable crosswind and tailwind values for them.
When you submit a flight plan request, JetPlan looks in the Preferred Runways Database for
preferred runway records for the requested airport and fleet type combination. If preferred
runway records exist, JetPlan validates them against the predicted wind speed and direction in
the current Terminal Area Forecast (TAF) for the ETD or ETA. When computing the flight
plan, JetPlan uses your highest-ranked preferred POD or POA runway that passes the TAF-
validation check.
NOTE For complete information on the Runway to Runway feature, including

prerequisites, see the “Route Commands” chapter.

1005
Database Parameters
Database Parameters
The following table lists the parameters in the Preferred Runways Database. As you perform
IMPORTANT In JetPlan.com, the Preferred Runways parameters are displayed on

the Runways page in the Airport Fleet Database. See the Airport Fleet Database
Help file on JetPlan.com for detailed information on managing these parameters
using JetPlan.com. The table below lists JetPlan Preferred Runways database codes
under the parameter names.
Table 39-1 Preferred Runway Parameters

Departure Airport Identifies the runway as a departure runway. In the
D JetPlan command-line interface, use this code: D.
NOTE In JetPlan.com, the departure runway is added
to the Departure Runways area of the Runways page
in the Airport Fleet database.
Arrival Airport Identifies the runway as an arrival runway. In the

A JetPlan command-line interface, use this code: A.
NOTE In JetPlan.com, the arrival runway is added to
the Arrival Runways area of the Runways page in the
Airport Fleet database.
Rank (Required) The ranking order for this runway, where 1

<n> represents the top-ranked runway, 2 represents the
second-ranked runway, and so on. Example: 1
Runway The runway identifier. Valid input values: 1-3

RWY= alphanumeric characters. Example: 15R
Max Crosswind The maximum acceptable crosswind for the runway,

MX= in knots.
If TAF is enabled, JetPlan checks the crosswinds for
the given airport, runway, and time-window
combination and returns only runways that do not
exceed this maximum value. If no acceptable runway
is found, preferred runway data from the Airport Fleet
database is not used in the flight plan calculation.
If TAF is not enabled, JetPlan returns the runway
ranked as number 1 for the airport.Valid input values:
00-99. Example: 30

1006
Database Parameters
Table 39-1 Preferred Runway Parameters

Max Tailwind The maximum acceptable tailwind for the runway, in
MT= knots.
If TAF is enabled, JetPlan checks the crosswinds for
the given airport, runway, and time-window
combination and returns only runways that do not
exceed this maximum value. If no acceptable runway
is found, preferred runway data from the Airport Fleet
database is not used in the flight plan calculation.
If TAF is not enabled, JetPlan returns the runway
ranked as number 1 for the airport.Valid input values:
00-99. Example: 10

1007
Database Management
Database Management
IMPORTANT This section covers using the JetPlan command line interface to
manage this database. Although the Preferred Runways Database is a separate
database, it is combined with the Airport Fleet Database in JetPlan.com as a
convenience to customers. In JetPlan.com, the preferred runways parameters are
displayed on the Runways page in the Airport Fleet Database. See the Airport Fleet
Database Help file on JetPlan.com for detailed information on managing these
parameters using JetPlan.com.

To use the Preferred Runways Database when flight planning, you must first create records in
the database. To do this, you need to access the database. In the JetPlan command-line
interface, the Preferred Runways Database access command is RWY, and it is entered on the
Options command line. The access command always precedes a function command. Function
commands are those inputs that instruct JetPlan to store, change, delete, or display information
in the database.
File Maintenance
• RWY,SAV – Creates a record
• RWY,CHG – Modifies an existing record
• RWY,DEL – Deletes all records in the database
• RWY,DEL,<ICAO> – Deletes all records for the airport
• RWY,DEL,$,<FLEET> – Deletes all records for the fleet type
File Display
• RWY,PRI – Displays all records in the database
• RWY,PRI,<ICAO> – Displays all preferred runway records for the airport.
• RWY,PRI,$,<FLEET> – Displays all preferred runway records for the fleet
type.

1008
Database Management
Preferred Runways Database Commands

The Preferred Runways Database function commands are divided into two categories: file
maintenance and file display. These categories are listed below with the respective functions.

File maintenance commands create, modify, and delete records in the database. The key
parameters that define the preferred runway record are the airport ICAO identifier, the fleet
type, the arrival or departure indicator, the preference rank of the runway, and the runway
identifier. These elements are followed by the maximum crosswind and maximum tailwind
parameters, in any order.
The command-line syntax for saving a preferred runway record is as follows:
01 OPTIONS RWY,SAV,<ICAO>,<FLEET>,<A or D>,<rank>,RWY=<XXX>,

MT=<n>,MX=<n>
where
• RWY is the Preferred Runways Database maintenance command.

• SAV is the save function command.
• <ICAO> is the ICAO or IATA airport code. Example: KDEN
• <FLEET> is the aircraft fleet type name. Example: 777E
• <A or D> is an arrival runway (A) or a departure runway (D).
• <rank> is a number representing preference order. Example: 1
• RWY=<xxx> is the runway identifier. Example: RWY=15R
• MX=<n> is the maximum crosswind value in knots. Example: MX=30
• MT=<n> is the maximum tailwind value in knots. Example: MT=10
Example:

1009
Database Management
Table 39-2 lists the file maintenance commands for the Preferred Runways Database.
Table 39-2 Preferred Runways Database File Maintenance Commands
Command Description
RWY,SAV This command enables you to create a Preferred Runways Database record.
Examples:
01 OPTIONS RWY,SAV,KBOS,777E,A,1,RWY=15R,MX=15,MT=10
01 OPTIONS RWY,SAV,KDEN,B737,A,2,RWY=16R,MX=30,MT=10
RWY,CHG This command enables you to change a Preferred Runways Database record.
Example:
01 OPTIONS RWY,CHG,KBOS,777E,A,1,RWY=15R,MX=30,MT=10
RWY,DEL This command deletes all preferred runway records in the database.
RWY,DEL,<ICAO> This command deletes all preferred runway records for the airport.
RWY,DEL,$,<FLEET> This command deletes all preferred runway records for the fleet type.

Table 39-3 lists the file display commands for the Preferred Runways Database.
Table 39-3 Preferred Runways Database File Display Commands
Command Description
RWY,PRI This command displays all preferred runway records in the database.
RWY,PRI,<ICAO> This command displays all preferred runway records for the airport.
RWY,PRI,$,<FLEET> This command displays all preferred runway records for the fleet type.

1010
C HAPTER 40
Restricted Area
Database
Restricted Area Database
About the Restricted Area Database
About the Restricted Area Database

NOTE The Restricted Area Database is used with the RST option command and
inputs on the 05 Restricted Area command line This functionality is separate from the
4D Avoid and Alert feature and the Customer Controlled Avoid and Alert Database.
The Restricted Area Database is a feature created and maintained by the user and provides
storage and access to “avoid region” files. JetPlan recognizes a request using a stored
Restricted Area Database record during both dynamic and canned route selection. The
following considerations apply to the use of the Restricted Area Database:
• The Restricted Area Database works with the dynamically created routes of
JetPlan’s Route Optimizer and the canned routes found in the Customer
Route Database.
• The Restricted Area Database does not work with JetPlan’s SRS route
development tool.
• The Restricted Area Database cannot be used with the Customer Route
Database command “RT,GEN.”

1013

The following sections describe how to apply the RST command in flight plans.
Flight Plan Request

After FP and any other command inputs, continue the Options command line with the
following command: RST, slash (/), Restricted Area Database record name. For example, to
invoke the restricted area record name “XNAT1,” make the following input:
Example:
01 OPTIONS FP,RCC,CS/JD1,CPT/S SMITH,DSP/R JONES,RST/XNAT1
You can also enter the RST command on the Options command line without specifying a
Restricted Area record name. Enter the record name in the appropriate position later in the
request.
Example:
01 OPTIONS FP,RCC,CS/JD1,PCT/S SMITH,DSP/R JONES,RST
Schedule Database Request

At the Options command line, input SC,FLT,(FILE NAME), and RST. Specify the Restricted
Area file name in the appropriate position later in the request. You can also specify the record
name after RST/ on the Options command line if preferred.
Example:
01 OPTIONS SC,FLT,CUN-MAD,RST

1014
Overriding a Restricted Area Database record Built

Into a Schedule
Specify RST as the final input on the Options command line. When JetPlan prompts with the
05 RESTRICTED AREA, hit <ENTER> and then continue answering the rest of the
questions.
Example:
01 OPTIONS SC,FLT,NRT-LAX-R001,RST
05 RESTRICTED AREA (hit <ENTER> and continue on)

1015
Database Management
Database Management

To make the Restricted Area Database a data resource for flight planning, you must first create
and manage records of information in the database. To do this, you need to access the
database. The Restricted Area Database access command is RST, and it is entered on the
NOTE Help instructions on how to build or maintain the Restricted Area Database
are available by entering RST,HELP on the Options command line.
The RST access command followed by a slash (/) is used to create a new Restricted Area
record. The RST access command precedes a command function to delete or display
information in the database.
Two categories of command functions are available when accessing the Restricted Area
Database. These functional categories are listed below with the specific commands.
File Maintenance
• RST/X<NAME> – Creates a new record
File Display
• SUM – Displays a list of all records
• PRI – Displays the contents of the record or records specified

1016
Database Management
Restricted Area Database Commands

The Restricted Area Database command functions are divided into two categories: file
maintenance and file display. This section describes each command function.

File maintenance commands create and delete records in the database. An explanation and
example of each maintenance command is shown in the following table.
Table 40-1 Restricted Area Database File Maintenance Commands
Command Description
RST/X<NAME> To create a Restricted Area Database record, enter the following on the Options command
line: RST, a slash (/), a three to eight character record name starting with X, another slash,
and the avoid region boundaries. The following rules apply:
• A slash separates each input item.
• The file name must begin with the letter X, followed by two to seven characters (three
to eight characters total).
• The restricted area boundaries can be defined as a three- to five-sided enclosed area or
a radius distance about a coordinate.
• A minimum of three coordinates and a maximum of five coordinates can be specified
to define an enclosed restricted area.
• The coordinates must be specified as they would be drawn on a chart. The segments
must define an enclosed area with no line crossing another line.
• You must indicate south latitude and east longitude by using either a hyphen (-) or the
letters “S” and “E.” North latitude and west longitude are default entries, meaning no
designation is necessary. However, a plus sign (+) or the letters “N” and “W” can be
used.
Example:
Explanation: Create a Restricted Area Database record
01 OPTIONS RST/XNAT1/5700,05000,5700,01000,4800,02000,4800,05000
Example:
Explanation: A radius about a coordinate is specified by stating a single latitude/longitude
coordinate followed by the distance of the radius (in miles or kilometers) and the letter R.
01 OPTIONS RST/XAVOID2/N3640,E12136,100R

1017
Database Management
Table 40-1 Restricted Area Database File Maintenance Commands (continued)
Command Description
RST/X<NAME> Example:
(continued) Explanation: You can specify more than one restricted area in one Restricted Area record.
However, each area entry must be separated by a slash (/), and cannot use more than 200
characters to define the region. Control the line break by ending the line with a comma. Do
not end the last line with a comma. The first example below creates one restricted area. The
second creates two restricted areas.
Example:
01 OPTIONS RST/XNAT1/5700,05000,5700,01000,4800,02000,4800,05000
- or -
01 OPTIONS RST/XAVOID1/N6000,E16000,N6500,W16500,N4000,W16000,
N4300,E16500/N4200,E17500,300R
RST/DEL The DEL function allows you to delete a Restricted Area Database record by name or
serial number.
Example:
Explanation: To delete a Restricted Area Database record by name, enter the following on
the Options command line: RST, DEL, slash, and the record name. (A comma or slash can
be used to separate the RST command from the DEL option.)
01 OPTIONS RST/DEL/XAVOID3
Example:
Explanation: To delete a Restricted Area Database record by serial number, enter the
following on the Options command line: RST/DEL/SN=, followed by the serial number of
the restricted area.
01 OPTIONS RST/DEL/SN=12345
NOTE A record’s serial number can be found by requesting a summary output (RST,SUM)
of all records.

Table 40-2 Restricted Area Database File Display Commands
Command Description
RST/SUM To display a list of all Restricted Area Database records, enter the following on the Options
command line: RST, slash(/), and SUM.
Example:
Explanation: Display a list of all records.
01 OPTIONS RST/SUM

1018
Database Management
Table 40-2 Restricted Area Database File Display Commands (continued)
Command Description
RST/PRI To display the contents of a particular Restricted Area Database record, enter the following
on the Options command line: RST, slash, PRI, slash, and the record name.
Example:
Explanation: Display the contents of the XAVOID3 record.
01 OPTIONS RST/PRI/XAVOID3
To display the contents of a particular Restricted Area Database record in complete detail,
add the /FULL parameter. This parameter applies more readily to restricted areas created for
JetPlan’s 3D Avoid option.
Example:
Explanation: Display the XAVOID3 record in full.
01 OPTIONS RST/PRI/XAVOID3/FULL

1019
C HAPTER 41
Customer Route
Database
Customer Route Database
About the Customer Route Database

The Customer Route Database provides a way to create and manage route information that is
used regularly in your flight plan requests. This database enables you to create and manage
two types of records: “route” records and “route segment” records.
NOTE The Customer Route Database is intended to be controlled and managed by

the customer. The customer can apply as much control as necessary over who, within
their organization, manages the information stored in the Customer Route Database.
Upon request, Jeppesen can assign extra passwords specifically intended for
database management. Contact your Jeppesen account manager for more
information.
Route Records
You can create route records in the Customer Route Database by providing standard JetPlan
route inputs, which in turn are used to generate stored routes. Standard inputs refer to entries
that properly define, access, and select the route structure you want through the Route
Optimizer (RO), the Specific Route Selector (SRS), or the combination of these two methods
of route input. (For more information on route inputs, see the “Route Commands” chapter in
the JetPlan User Manual).
Once a route record is created, you can enter the name of the record on the Route line of a
flight plan request. This type of input, which is generally much shorter than the typical string
of elements needed to generate a specific route, provides a “canned” track between two
airports. When you store multiple route records in the Customer Route Database between the
same POD and POA combination, you can direct JetPlan to utilize (1) a specific record, (2) the
best record from a selected few, or (3) the best one from all available for that airport pair.
A route record can be copied to your Customer Alternate database and invoked in the flight
plan computation as a divert route. This occurs automatically when the arrival and alternate
airports from the flight plan request match the airport pair of a record stored in the Alternate
Database.
NOTE To use a Customer Route Database record as a route input to an alternate

airport, you must copy the record into your Customer Alternate Database. See the
“Customer Alternate Database” chapter in the JetPlan User Manual or the Help topic
on JetPlan.com for more information.

1023
Route Segment Records
NOTE JetPlan.com is the recommended interface for creating and maintaining

route segment records.
In addition to route records, you can also create and manage escape route and reclear route
segment records. In JetPlan.com, these records are accessed on the Customer Route Database
page, using the ROUTE SEGMENTS menu commands.
Escape routes are used with Jeppesen’s Terrain Analysis feature. An escape route is a user-
defined approach route to a mountain driftdown alternate designed to route the aircraft safely
through high terrain. For a discussion of the use of escape routes with Terrain Analysis flight
planning, see the “Overwater Driftdown and Terrain Analysis” chapter in the JetPlan User
Manual.
NOTE The Driftdown Escape Routes customer preference controls use of escape
routes. For information, contact your Jeppesen account manager.
A reclear flight plan enables you to legally reduce the reserve fuel required on an international
flight. This affords a corresponding increase in the amount of payload a flight can carry or the
distance it can cover. For more information on reclear flight plans, see the “Reclear
NOTE Reclear route records in the Route Segment Database are not yet available
for use in all Jeppesen “front-end” flight planning applications, such as JetPlanner and
the New Flight Planner in JetPlan.com. Contact your Jeppesen account manager for
information.
When creating and maintaining route segment records, you define the begin and end points
(waypoints or airports or latitude/longitude coordinates), provide a route string input, select
the route segment group (escape route or reclear route), and then submit the information to
create the record.
For example, you could create an escape route segment record using airports as the begin and
end points with the following input:
• Route segment record name: RT1

• Begin point airport: KCOS

1024
• End point airport: KABQ

• Route segment group: Escape Route (ES)
• Route string: -ALS ESPAN FLYBY FRIHO ABQ
The following image shows the Create a New Route Segment dialog box in JetPlan.com with
the sample inputs listed above.
Figure 41.1. Create a New Route Segment Dialog Box in JetPlan.com
The equivalent inputs in line mode for this sample escape route record are:
01 OPTIONS CS,GEN,KCOS,KABQ/RT1,ES
06 ROUTE -ALS ESPAN FLYBY FRIHO ABQ
If you want the route to start and/or end at a waypoint (rather than an airport), you must
provide the waypoint name, area, and type. This information can be looked up on JetPlan.com,
using the Airport & Navigation Info menu command on the Customer Route Database
page.
For detailed instructions on route segment records using JetPlan.com, see the Help file for the
Customer Route Database on JetPlan.com.

1025
The Pre-Effective Database Feature
NOTE When the Pre-effective Database is available, authorized users can access it
on the Customer Route Database page in JetPlan.com.
Your account must be configured to allow you to access the Pre-Effective Database, which is a
non-production route database that authorized customers can use to maintain company route
records prior to the effective date of the next AIRAC cycle update. The data in the Pre-
Effective Database is readied for eventual release but is made available before implementation
to those customers who request it. Any changes made to routes in the Pre-Effective Database
will become effective with the next AIRAC cycle update (and not before then).
If your user privileges give you access to the Pre-Effective Database and if there is a Pre-
Effective Database available for use, you will see a Route Database dialog box above the
menu on the Customer Route Database page in JetPlan.com. Typically, when you first open
the database page, the Route Database dialog box is green and contains a LIVE button,
indicating that the currently effective “Live” Database is in use.
Figure 41.2. Route Database Dialog Box in JetPlan.com
Clicking the LIVE button opens the AIRAC Database Options page, which enables you to
switch between the Live Database and the Pre-Effective Database in JetPlan.com. When you
are using the Pre-Effective Database, the Route Database dialog box is red (not green) and
contains a button you can use to return to the AIRAC Database Options page, where you can
switch back to the Live Database.

1026
Getting Help on Using the Pre-Effective Database

When the Pre-Effective Database is available, the Customer Route Database page in
JetPlan.com contains the Route Database dialog box. Clicking the button in the Route
Database dialog box opens the AIRAC Database Options page. Click the Help icon on
the AIRAC Database Options page to open a document that explains how to use the Pre-
Effective Database.
NOTE The Pre-effective Database feature is available upon request. Contact your
Sending FMS Route Output to Jeppesen NavData
IMPORTANT The Send to FMS option is visible on the Route Database menu in
JetPlan.com only if your account has been configured to enable this option.
If the Send to FMS option is visible on the Route Database menu in JetPlan.com, you have
arranged with your Jeppesen NavData representative to enable automatic forwarding of your
FMS routes from your Customer Route Database to Jeppesen’s FMS data team. In that case,
when you click Send to FMS, all routes that have been added to groups FMS1 through FMS9
are sent to Jeppesen, so they can be added to your custom NavData for the next cycle update.
NOTE For more information on the Send to FMS feature, contact your NavData
representative.

1027
Database Parameters
Database Parameters
This section contains the following topics:
• “Route Parameters” on page 1028 lists the parameters used to create

customer route records.
• “Route Segment Database Parameters” on page 1034 lists the parameters
used to create route segment records (for escape routes and reclear routes).
Route Parameters
NOTE The following table describes the parameters used to create routes in the
Customer Route Database. For information on the route segment parameters, see
“Route Segment Database Parameters” on page 1034.
Required parameters must be included in a command input to reference a file specifically.

Other parameters are “optional,” depending on the situation and the command function. Some
of the parameters are simply input fields for information. They have no identifying prefix or
parameter code.

maintenance. See the Help file for the Customer Route Database on the Customer
Route tab in JetPlan.com. The table below provides information specific to the
JetPlan command-line interface. JetPlan database codes are listed under the
parameter names.

1028
Database Parameters
Table 41-1 Route Parameters
RT Name (Required) Use the RT Name parameter to create a
/<xx> record name for the stored route.
ex. /R1 Input value: The RT Name can be 2–11 characters in
length and must contain at least one letter.
ex. /RT01
NOTE In the JetPlan command-line interface, the file
ex. /JFKGLL
name input typically follows the POD and POA inputs. It
ex. /A1234567890 must begin with a slash (for example, /RT66).
Group (Optional). Use the Group parameter to identify a

GP group or category to which you want to assign the
route record. When adding a new group name to a
ex. GP=BLUERTES
route record, the criteria you use to categorize the
ex. GP=.RED RTES. record is left to your discretion.
Input value: Up to 20 characters.
Names can include spaces between characters—like a
phrase or sentence—if enclosed with periods.
NOTE In the JetPlan command-line interface, this
input (if used) is always the final entry.The Group
parameter is only applied when creating a new route
record (when using the RT,GEN command).
Otherwise, this parameter is unavailable. Use the
Group Database access command, RG, to affect
preexisting route records.
Expiration Date (Optional) Use the Expiration Date parameter to set

ddmmyy the date that the route record is no longer valid for use.
If no expiration date is specified, the route remains
ex. 311205
available indefinitely.
Input value: A date in the following format: ddmmyy
NOTE In the JetPlan command-line interface, this
parameter is the final entry if the FL and GP
parameters are omitted.
POD (Required) Use the POD parameter to specify the

<XXXX> or <XXX> departure airport identifier.
ex. KJFK or JFK Input value: The valid ICAO or IATA identifier for the
POD station you are defining as the route’s start point.
NOTE In the JetPlan command-line interface, you
can omit the POD parameter input if you want to use a
user-defined airport. If the POD is omitted, the system
prompts you to enter your airport on the POD
command line. Enter the airport input using the
guidelines stipulated in the “Point of Arrival/Departure

1029
Database Parameters
Table 41-1 Route Parameters (continued)
POD Bias (Optional). Use the Departure Distance parameter to
DD=#(##) apply a distance bias (pad) to the route.
ex. DD=20 Input value: One to 3 digits (1 to 999), entered in
nautical miles or kilometers, depending on your
preferred unit of measure when flight planning.This
bias is included in the flight plan before Top of Climb
(TOC) is reached.
POA (Required) Use the POA parameter to specify the

<XXXX> or <XXX> arrival airport identifier.
ex. EGLL or LHR Input value: The valid ICAO or IATA identifier for the
POA station you are defining as the route’s end point
NOTE In the JetPlan command-line interface, you
can omit the POA parameter input if you want to use a
user-defined airport. If the POA is omitted, the system
prompts you to enter your airport on the POA command
line. Enter the airport input using the guidelines
stipulated in the “Point of Arrival/Departure
POA Bias (Optional). Use the Arrival Distance parameter to

AD=#(##) apply a distance bias (pad) to the route.
ex. AD=35 Input value: One to 3 digits (1 to 999), entered in
nautical miles or kilometers, depending on your
preferred unit of measure when flight planning. This
bias is included in the flight plan after Top of Descent
(TOD) is reached.

1030
Database Parameters
Navigation Data Source Use the Navigation Database codes to identify a
<XX> requested change in the source data for navigational
information. The code can request the elimination of
ex. MA
certain types of airways or a complete switch to
ex. RN another navigation data source.
ex. AX Code choices include:
NOTE The default navigation information source is • LA – Use the low-altitude navigation data
the High Altitude Database. source. Lower airspace applies worldwide. This
NOTE In the JetPlan command-line interface, the option is not relevant when creating a route
Navigation Data Source parameter code is entered record with SRS inputs.
between the function command and the POD input • MA – Use the mid-altitude navigation data
only. source. Middle airspace applies to portions of
airspace in Western Europe. This option is not
relevant when creating a route record with SRS
inputs.
• AX – Allow time-sensitive airway consideration
(regardless of the time restriction). This option is
not relevant when creating a route record with
SRS inputs.
• RN – Consider RNAV route segments. The RN
parameter is required when generating routes in
Europe or any RNAV segments. RNAV routes
are not available with low or mid-altitude
airspace. This parameter is not relevant when
creating a route record with SRS inputs.
• RP – Display output in Route Proof format,
which provides a simple route summary of the
generated route rather than a point-by-point
detailed output.
NOTE Follow Route Optimizer syntax when entering
route inputs (no SRS inputs).

1031
Database Parameters
Primary Flight Levels (Optional). Use the Primary Flight Levels parameter
FL to apply a profile constraint on the route file. Unlike
the Alternate Flight Levels parameter, this parameter
ex. FL
applies the profile constraint to the primary flight plan
(POD to POA).
Input value:
In the JetPlan command-line interface, the value is
simply the two letter code, FL. This parameter is
generally the last entry in a route generation command
input, unless the Group Name parameter is included.
By entering FL in the route command, you notify
JetPlan that you intend to include a profile input. The
Profile command line prompts you for the actual
flight-level entries.
The entry must follow standard JetPlan syntax for
flight level entries. You can enter a single altitude (for
example, 170), or an altitude range (for example,
100,170). See the “Profile Commands” chapter in the
Alternate Flight Levels (Optional) Use the Alternate Flight Levels parameter
FL=###(,###) to apply a profile constraint on the route file for
alternate calculations. This parameter applies to route
ex. FL=100,150
files used as diversion segments only (POA to
ex. FL=170 Alternate) and only if the route is stored in the
Customer Alternate Database. It does not apply to
files used for primary route purposes (POD to POA).
The Primary Flight Levels parameter applies to the
primary route.
Input value: The input value must follow standard
JetPlan syntax for flight level entries. You can enter a
single altitude (for example, 170), or an altitude range
(for example, 100,170).
NOTE Route files intended for use as divert
segments must be copied to the Customer Alternate
Database before they can be used in a flight plan for
this purpose. JetPlan selects the optimum altitude
within that range.
Remarks Section (Optional) Use the Remarks Section parameter to add

RMK remarks to the route record.
NOTE In the JetPlan command-line interface, the

This option lets you add or modify an internal remark
RMK parameter is used with the RG (Rename Group) associated with the group name. In the JetPlan
function command. command-line interface, view the remark by using
one of the List Route options.
Example: RMK=Rte valid from 12Z to 18Z only.
Input value: Up to 52 characters

1032
Database Parameters
Routing In JetPlan.com, use the Routing box to enter your
route inputs, which, when submitted to JetPlan,
generate the stored track.
In the JetPlan command-line interface, the system
prompts you to enter the route inputs on the
06 ROUTE line when you are creating or modifying
the route record.
Entries must be valid JetPlan input types: Route
Optimizer, SRS, or Route Optimizer/SRS
combination inputs. See the “Route Commands”
chapter in the JetPlan User Manual for the types of
route inputs that you can make in the JetPlan system.
Reclear Data The Reclear Data parameter is not currently in use by

JetPlan.
NOTE For information on creating reclear route
segments, see “Route Segment Records” on
page 1024.
Airway Search (Optional). The Airway Search parameter only applies

AWY=(route string) to the file display commands in the JetPlan command-
line interface: LST, RP, SUM, and TOT. It enables you
ex. AWY=UB12
to define the route files you want to display by
ex. AWY=UB12 SIT identifying certain airways or airway intersections
ex. AWY=UB12 SIT UA14 within the stored route.
The input values include an individual airway
identifier, an airway and checkpoint identifier
combination, an airway, checkpoint, airway
combination, and so on. In all cases, it must begin
with an airway identifier.
Checkpoint Search (Optional). The Checkpoint Search parameter, like the

CPT=(route string) Airway Search parameter, only applies to the file
display commands in the JetPlan command-line
ex. CPT=TANSA
interface: LST, RP, SUM, and TOT. It enables you to
ex. CPT=TANSA UB12 define the route files you want to display by
ex. CPT=TANSA UB12 SIT identifying certain checkpoints or checkpoint
segments within the stored route.
The input values include an individual checkpoint
identifier, a checkpoint and airway identifier
combination, a checkpoint, airway, checkpoint
combination, and so on. In all cases, it must begin
with a checkpoint identifier.

1033
Database Parameters
Route Search SRH,POD=xxxx... (Optional). In the JetPlan command-line interface, the
POA RTN (route name) Route Search parameter enables you to display the
routes stored in the Customer Route Database that
GP (group name)
match the specified criteria. A wildcard search can
CH (change date) also be performed using an asterisk (*). For example:
LU (last used) RT,SRH,EXP=*2009 returns routes that expire
EXP (expiration date) anytime in 2009.
NU (number of times used) Although group names (GP) can contain spaces when
enclosed within periods, they cannot be searched for
ex. SRH,POD=KLVK in that form. When searching for a group name that
contains more than one word, input one or more
letters of the first word. For example, if searching for
the group name “FAR EAST,” any of the following
inputs work: RT,SRH,GP=FRT,SRH,GP=FAR
However, entering GP=.FAR EAST. returns an error.
Route Segment Database Parameters
NOTE The following table describes the parameters used to create routes
segments for escape routes and reclear routes. For information on route parameters,
see “Route Parameters” on page 1028.

maintenance.
Table 41-2 Route Segment Database Parameters
Route Segment Name This is the name you give to the route segment record in the
database.
Input value: Up to six alphanumeric characters

1034
Database Parameters
Table 41-2 Route Segment Database Parameters (continued)
Route Segment Group Name This parameter indicates the group to which the route segment
ES - Escape Route record belongs.
RC- Reclear Route Input options:
• Escape Routes – A user-defined approach route to a
mountain driftdown alternate designed to route the aircraft
safely through high terrain. Supports the JetPlan Terrain
Analysis feature.
• Reclear Routes – A user-defined route from the reclear
point to the reclear airport.
Begin Point and End Point Parameters

These parameters enable you to define the begin point and end point of the route segment. A begin or end
point can be one of the following:
• An airport
- or -
• A waypoint
- or -
• Latitude/Longitude coordinates
Airport The route segment can begin or end at an airport. This parameter
enables you to specify the ICAO or IATA code for the airport
used as the route departure (begin) or arrival (end) point.
Input value: Three or four alphanumeric characters (ICAO or
IATA code)
NOTE When the Airport parameter is defined, do not set the
Waypoint or Latitude/Longitude parameters for the same point.
Waypoint The route segment can begin or end at a waypoint. This

parameter enables you to specify the name of the waypoint used
as the begin or end point of the route segment.
Input value: Up to six alphanumeric characters
NOTE When the Waypoint parameters are defined, do not set
the Airport or Latitude/Longitude parameters for the same point.
(Waypoint) Area This parameter enables you to specify the two-character A424
area code for the waypoint.
point is a waypoint. If the point is not a waypoint, do not set this
parameter.

1035
Database Parameters
Table 41-2 Route Segment Database Parameters (continued)
(Waypoint) Type This parameter enables you to specify the waypoint type.
point is a waypoint. If the point is not a waypoint, do not set this
parameter.
Input options:
• VOR (D)
• Enroute Waypoint (EA)
• Terminal NDB (PN)
• Terminal Waypoint (PC)
• NDB (DB)
For information on the waypoint types, see the “Route
Latitude The route segment can begin or end at a point defined by

latitude/longitude coordinates. This parameter enables you to set
the latitude value.
Input value: Full degree and minute and/or tenths of minutes.
Use the same syntax as used in SRS routing. For information on
syntax, see the “Route Commands” chapter in the JetPlan User
Manual.
Example: N3712.4
Longitude The route segment can begin or end at a point defined by

latitude/longitude coordinates. This parameter enables you to set
the longitude value.
Input value: Full degree and minute and/or tenths of minutes.
Use the same syntax as used in SRS routing. For information on
syntax, see the “Route Commands” chapter in the JetPlan User
Manual.
Example: W9823.6
Custom Name (Optional) This parameter enables you to associate a name with the
Latitude/Longitude point. The name appears in the route output
in lieu of the Latitude/Longitude point or together with the
Latitude/Longitude point.
Input value: Up to six characters, including alphanumeric and
special characters
Example: MYPNT1
Routing This parameter enables you to specify the SRS route string. For
information on SRS syntax, see the “Route Commands” chapter
in the JetPlan User Manual.
Example: -ALS ESPAN FLYBY FRIHO ABQ

1036
Database Management
Database Management

Before you can apply Customer Route Database files to your flight plan requests, you must
first create and manage records of information in the database. To do this, you need to access
the database. The Customer Route Database access command is RT, and it is entered on the
Example:
Explanation: Customer Route Database Access Command
01 OPTIONS RT
NOTE Any attempt to affect or reference the information in the database must begin
with the RT command.
Customer Route Database command functions are divided into three categories: file
maintenance, file display, and file verification. These categories are listed below with the
respective functions.
File Maintenance
• GEN – Generates the route and creates a new record
• DEL – Deletes a record or records
• RN – Renames a record
• UPD – Updates route inputs on a global scale

1037
Database Management
• RG – Adds, changes or deletes the group name of a record
NOTE RG is an access command like RT. It is not a function command. It works like
a separate database.
File Display
• PRI – Displays the complete information of an individual route record
• LST – Displays route inputs and summaries
• RP – Displays route names and other information
• SUM – Displays the airports and other information
• TOT – Displays the number of records in the database
• RID – Displays the record identifier
• SRH – Searches for records
File Verification
• CHK – Checks route files against recent navigation updates
• OK – Marks route files as being verified and approved
To affect the content of any individual record, you need to reference the record’s identifier. In
this case, it is the name you give the route file (see the File Name parameter in previous table).
In most cases, you must include the departure and arrival stations. These items are typically
required for all maintenance functions (for example, GEN, CHG, DEL, and RN). Hence, the
proper syntax of a basic Customer Route Database input is:
RT,function command,POD,POA/filename
The command syntax for an input that includes all of the parameter options is:
RT,function command,XX,POD,POA/filename,
FL=###,###,DD=###,AD=###,DDMMYY,FL,GP=XXXXXXX

1038
Database Management
Example:
Explanation: The following Customer Route Database command input requests the generation
(create and save) of a new route between the airports, KJFK and EDDF. The new route is
being saved under the file name, RT01. The request includes a consideration for RNAV route
segments (RN), a departure distance bias (DD=), an arrival distance bias (AD=), and an
expiration date (Dec. 31, 2005). It also categorizes the route file in the group, BLUE.
01 OPTIONS RT,GEN,RN,KJFK,EDDF/RT01,DD=20,AD=5,123105,FL,GP=BLUE
Customer Route Database Commands

The Customer Route Database command functions are divided into three categories: file
maintenance, file display, and file verification. These commands are described below.

File maintenance commands are those that affect the content of a file, the existence of a file, or
the name of a file. This section reviews the maintenance commands, GEN, CHG, DEL, RN,
and UPD. In addition, this section reviews the Route Group command, RG. The RG command
is an access command like RT, but its function is similar to the other maintenance commands
and is therefore included here.
Generate Command (RT,GEN)

The function command, GEN, enables you to create and save new route files in the database.
When this function is applied, the command must be followed by the route inputs that define
the course of travel you want to store. Your route inputs must be entered on the Route
command line (similar to the way route inputs are entered in a flight plan request).
The following list provides some tips and rules to remember.
• A slash (/) always precedes the Customer Route Database route file name.
• If you want to include a Navigation Source Data parameter code, it must be
entered between the function command, GEN, and the POD input.
• If you want to apply a profile constraint to a file intended for use as an
alternate route (between a POA and ALT), use the parameter,
FL=###(,###). Enter this parameter after the File Name input.

1039
Database Management
• If you want to apply a profile constraint to a file intended for use as a

primary route (between a POD and POA), enter the code, FL, at the end of
your command input (unless a Group Name input is to be included, in which
case, the FL code is the second to last entry).
• Customer Route Database files can be stored in special categories (of your
choosing) by using the Group Name parameter in the RT,GEN command. If
used, it is the final entry on the RT,GEN command.
• When entering your route inputs, you can use the Route Optimizer method,
the SRS method, or a combination of the two methods to create a route file
in the database.
• The inputs that create the route are saved for your review and reference.
The following examples illustrate RT,GEN command inputs. Each example includes a Route
command line input.
NOTE The inputs shown on the Route command lines of the following examples
below might or might not be applicable to a real flight plan today. Jeppesen attempts
to keep the route inputs valid, but navigation structure constantly changes over time.
Therefore, these route inputs serve as examples only. Plan accordingly.
Example:
Explanation: This RT,GEN command shows the minimum required inputs (no optional
parameters are used). It creates the route file, R001, with a route from San Francisco, USA
(KSFO) to Seoul, South Korea (RKSI). The Route command line inputs request jet airways to
a North Pacific track (R220, via NUBDA), and jet airways the rest of the way.
01 OPTIONS RT,GEN KSFO,RKSI/R001

06 ROUTE J/P/J,NUBDA,KPO

1040
Database Management
Example:
Explanation: This RT,GEN command creates the route file, R002, between KSJC and RJAA.
The Route command line inputs are made using the SRS route selection method. Optional
parameter entries include the profile constraint parameter (FL) and a group name input (GP=).
The input of the FL code mandates a Profile command line input, where IFR rules are applied
and the profile is constrained to be between FL280 and FL390.
01 OPTIONS RT,GEN,KSJC,RJAA/R002,FL,GP=TEAM1
06 ROUTE -OSI V25 PYE V27 ENI C1486 GUTTS KLARK BEGUN CDB A342 PINSO
\A590 PABBA OTR6 KETAR OTR10 CVC
Example:
Explanation: This RT,GEN command creates the route file, R003, between VTBD and RJAA.
The Route command line inputs request jet airways with overflight of waypoints: IDOSI, CH,
ELATO, and MAMAS. Because one of the possible airways is time restricted, the AX
parameter is included in the command input to allow consideration of that airway. Other
optional inputs include an expiration date and a group name.
01 OPTIONS RT,GEN,AX,VTBD,RJAA/R003,311210,GP=TEAM2
06 ROUTE J,IDOSI,CH,ELATO,MAMAS
Example:
Explanation: This RT,GEN command creates the route file, A001, between LFPG and EDDF.
The MA parameter is applied to access the mid-altitude database as the navigation source data.
A profile constraint (FL=130,210) is applied to the route for times when the file is used as a
divert route resource. Departure (DD) and arrival (AD) distance biases are also applied to the
route.
01 OPTIONS RT,GEN,MA,LFPG,EDDF/A001,FL=130,210,DD=10,AD=20
06 ROUTE J
NOTE The route file, A001 (shown above), cannot be used as a divert route until it
is copied to the Customer Alternate Database.

1041
Database Management
Example:
Explanation: This RT,GEN command demonstrates how to enter user-defined airports into a
route file. By excluding the POD and POA input from the GEN command, you instruct JetPlan
to prompt for the airport inputs. Using the POD and POA command lines, you can enter any
valid type of airport input. See the POD and POA Commands chapter for more information on
valid types of airport inputs with user-defined airports.
01 OPTIONS RT,GEN/H01
02 POD PODX,3950,10653,FL063
03 POA KSFO
06 ROUTE D//J,D,EKR
Modify Command (RT,CHG)

The function command, CHG, enables you to amend and update previously created route files.
The input is similar to the GEN input. In fact, you can enter all of the same types of inputs with
certain exceptions. The following list provides some rules to remember when using this
command.
When modifying a Customer Route Database file, all original parameter inputs must be
included (reentered) in the command input if you want to retain them (as is) in the modified
file. The following exceptions to this are:
• The Flight Level parameter code, FL. The flight level information is carried
over from the original file without reentering FL. If you do enter the FL
code in the RT,CHG command, you need to reenter a flight level input. The
reentered input can be the same value as before or a new value.
• The Group Name parameter, GP=(xxxx). This parameter cannot be
modified using the RT,CHG command; an error occurs if it is used. If you
want to change a route file’s grouping identification, you must use the Route
Group access command, RG.
Of course, you can omit any other optional parameter from the original file if you no longer
want to include it in the modified file.
• Like the parameter inputs, route inputs must be reentered in their entirety in
order to retain them as originally set. However, you can invoke the Route
Line Edit program to avoid the hassle of reentering your route inputs. To do
this, enter @6C on the Route command line. JetPlan displays the original
route inputs and mark each entry with a field number. You can make
changes to the entries (by field number) if you want; but, more importantly,

1042
Database Management
you can hit the ENTER key and retain the original route inputs without
having to reenter the entire line. See the Route Commands chapter for more
information on Route Line Editing.
• Before making any changes to a Customer Route Database file, Jeppesen
suggests you employ the RT,LST command to compare and verify the
current route inputs. You can also invoke the Route Line Edit program to
see the route inputs before deciding on modifications.
The following examples illustrate the RT,CHG command by providing scenarios in which
route files are created and then modified.
NOTE The inputs shown on the Route command lines of the following examples
below might or might not be applicable to a real flight plan today. We (Jeppesen)
attempt to keep the route inputs valid, but navigation structure constantly changes
over time. Therefore, these route inputs serve as examples only. Plan accordingly.
CASE 1
Assume the original Customer Route Database file, R01, is created using the inputs in this first
example. The MA parameter is the only optional entry.
Example:
01 OPTIONS RT,GEN,MA,LFPG,EDDF/R01
06 ROUTE J
Using the RT,CHG command, modifications to R01 are made. The change in this case is the
addition of an expiration date (Jun. 30, 2009). Please note that all inputs from the RT,GEN are
reentered in order to maintain the original file’s previous settings.
Example:
01 OPTIONS RT,CHG,MA,LFPG,EDDF/R01,300609
06 ROUTE J
CASE 2
The Customer Route Database file, R001, is created with the following inputs.

1043
Database Management
Example:
01 OPTIONS RT,GEN,AX,KSFO,RKSI/R001,311205,FL,GP=TEAM2
06 ROUTE J,ENI/P/J,OATIS,KPO
Using the RT,CHG command, the route is modified. Note that the optional parameters from
the original file, AX and 311209 (expiration date), are reentered in order to retain these values
in the modified file. Also note that the Flight Level parameter (FL) and the Group Name
parameter (GP=) are omitted. The flight level information is carried over to the modified file
automatically. The file’s grouping identification cannot be modified through the RT,CHG
command.
Example:
01 OPTIONS RT,CHG,AX,KSFO,RKSI/R001,311209
06 ROUTE J,ENI/P/J,NUBDA,JEC,KAE
NOTE Be sure to review the flight level information carried over from an original
route file to a modified route file, especially when route inputs are changed. Route
input changes could conflict with the stored altitude constraints, depending on various
factors. For example, if the flight level information carried over from the original route
file contains specific waypoints (used as constraint points for altitude ascents and/or
descents), the route inputs in the modified file might change the route significantly
enough to invalidate the flight level information.
Delete Command (RT,DEL)

The function command, DEL, enables you to remove route files from the Customer Route
Database. You can delete one or more files at a time, depending on the qualifications you
apply to the command input. There are six ways to delete a route file or files.
• Delete a specific route (POD,POA/FILENAME)

• Delete all routes from a specific POD to a specific POA (POD,POA/ALL)
• Delete all routes to/from a specific airport (ARPT/ALL)
• Delete all expired routes (/ALL)
• Delete all routes not used in the last X number of days (/###D)
• Delete all routes by group name (/GP=xxxx)
The following list provides some rules to remember when using this command.
• A slash (/) must precede the deletion qualifier.

1044
Database Management
• Deleting by group name requires the slash and the following

string:GP=NAME or GP=NAME1,NAME2,NAME3
To delete a specific route file, enter the identifiers of the POD and POA, a slash, and the file
name after the DEL command.
Example:
Explanation: Delete route file, R001, for the airport pair: KSFO to RKSI.
01 OPTIONS RT,DEL,KSFO,RKSI/R001
To delete all route files for a specific airport pair, enter the identifiers of the POD and POA, a
slash, and the option, ALL, after the DEL command.
Example:
Explanation: Delete all route files for the airport pair: KSFO to RKSI.
01 OPTIONS RT,DEL,KSFO,RKSI/ALL
To delete all route files that fly to or from a specific airport, enter the airport identifier, a slash,
and the option, ALL, after the DEL command.
Example:
Explanation: Delete all route files that fly to or from KSFO.
01 OPTIONS RT,DEL,KSFO/ALL
To delete all route files that have expired, enter a slash and the option, EXP, after the DEL
command.
Example:
Explanation: Delete all routes that have expired under the user's ID.
01 OPTIONS RT,DEL/EXP
To delete all route files that have not been used for a specific length of time, enter a slash and
the option, xxxD, (where xxx is a value indicating the number of days) after the DEL
command.

1045
Database Management
Example:
Explanation: Delete all routes not used in the last 300 days.
01 OPTIONS RT,DEL/300D
To delete all route files that belong to a specific group, enter the identifiers of the POD and
POA, a slash, and the option, GP=xxx, (where xxx is the group or category name) after the
DEL command.
Example:
Explanation: Delete all routes within the category, TEAM1.
01 OPTIONS RT,DEL/GP=TEAM1
Rename Command (RT,RN)

The function command, RN, enables you to change the name of a route file in the Customer
Route Database.
The following example illustrates the application of the rename function.
To rename a route file, enter the identifiers of the POD and POA, a slash, the original file
name, another slash, and the new file name.
Example:
Explanation: The route file, 04F, is renamed to R001.
01 OPTIONS RT,RN,KSEA,KLAX/04F/R001
Update Command (RT,UPD)

The function command, UPD, enables you to modify the route inputs contained within route
files. This capability is not unique to the Customer Route Database because you can do the
same thing using the RT,CHG command. However, the CHG command requires you to
reenter every element on the Route command line, not just the ones that have changed, and it
affects only one file at a time. The CHG command also forces you to reenter almost all of the
parameters you originally applied to the file if you want to keep it basically the same.

1046
Database Management
With the RT,UPD command, you can affect only those individual route elements, or strings of
route elements, that need amending. You do not have to reenter the entire input on the Route
command line, nor do you have to bother with reentering other file parameters. In addition,
with one UPD command input, changes can be applied to every file in the database that
contains the obsolete route element or elements without affecting any other information within
those files (global change capability). With this command you can easily clean up scores of
files that need amending due to periodic route structure changes.
NOTE A route element is the identifier of an individual checkpoint or airway. A route

string is a series of two or more route elements that define a route segment, an airway
intersection, or a combination of the two.
The following list provides some tips and rules to remember when applying the UPD
command.
• Updating route inputs requires the use of the Airway/Checkpoint Search

option (AWY= or CPT=). Use the checkpoint search option, CPT=, if the
input element is a checkpoint (a waypoint or navaid) or if the input string
begins with a checkpoint. Use the airway search option, AWY=, if the input
element is an airway or if the input string begins with an airway.
NOTE See “Airway/Checkpoint Search Option” in this chapter for more information.
• The UPD command input must provide both the element or string you want
to change and its replacement, using the following sequence: [old
element],[new element] or [old string],[new string].
• Route element (or string) inputs, both old and new, must be enclosed by
brackets (for example, CPT=[old string],[new string]).
• You must separate the old input string from the new input string with a
comma between the close bracket and the open bracket.
• When using the UPD command, the route files you affect can be defined
using filtering options. You can specify target route files by an individual
airport, by an airport pair (POD/POA combination), by an airport pair and a
file name, or use the /ALL option to target all files. The wildcard, $ALL,
can be used in place of one of the airports (the POD or the POA) to target
files by departure station or by arrival station only.

1047
Database Management
• Route files that have been updated are flagged with the message: “Route
Inputs Need to be Verified”. You must verify and approve (RT,OK) these
files before they can be considered valid routes.
NOTE See “File Verification Commands” for more information on verification and
approval.
• If the route input being updated is an SRS type of entry, it must be preceded
with a dash (-). Since Standard Instrument Departures (SIDs) are considered
SRS airway elements, the input for a SID would include a dash prefix (for
example, [-BODO3E]).
• Route string updates that include SRS/Route Optimizer combinations must
follow standard JetPlan rules of input, including the use of a double dash
(--) between SRS and Route Optimizer entries.
NOTE See the Route Commands chapter for more information on Combination
Routing.
• All route inputs must follow standard JetPlan route syntax rules.
The following examples illustrate the use of the UPD command.
NOTE The route element (or string) inputs do not reflect actual route structure. They
are example characters only.
To update all route files that contain the specified “old” route element, enter the option, /ALL,
after the UPD command.
Example:
Explanation: Update all route files that contain the checkpoint, ABC, by replacing it with the
checkpoint, XYZ.
01 OPTIONS RT,UPD/ALL,CPT=[ABC],[XYZ]

1048
Database Management
Example:
Explanation: Update all route files that contain the airway, UB111, by replacing it with the
airway, UG999.
01 OPTIONS RT,UPD/ALL,AWY=[UB111],[UG999]
To update all route files that contain the specified “old” route string, enter the option, /ALL,
after the UPD command.
Example:
Explanation: Update all route files that contain the route string, ABC UB111 XYZ, by
replacing it with the route string, DEF UG999 TUV. Since the string begins with a checkpoint,
the option, CPT=, is used.
01 OPTIONS RT,UPD/ALL,CPT=[ABC UB111 XYZ],[DEF UG999 TUV]
If the route string begins with SRS type of inputs, be sure to identify the input as SRS by
starting the string with a dash (-). Likewise, if the string includes combination routing
(switching back and forth between SRS and Route Optimizer types of inputs), be sure to
identify the switch from one type to the other by entering two dashes (--) between the types.
Example:
Explanation: Update all route files that contain the route string, -BODO3E BODOK--
J,TOMUK, by replacing it with the route string, -SAMALA SAMAN--J,TOMUK. Since the
original string begins with a SID, which is an airway identifier and an SRS type of route input,
the airway search option, AWY=, is applied and the input value begins with a dash. In
addition, because the route string switches from an SRS to a Route Optimizer type of input,
double dashes are entered to denote the switch.
01 OPTIONS RT,UPD/ALL,AWY=[-BODO3E BODOK--J,TOMUK],[-SAMALA SAMAN--

J,TOMUK]
NOTE The previous examples of a route string update can be applied similarly to
the examples that follow.
To update all route files that contain a particular airport (POD or POA) and the specified “old”
route element, enter the identifier for the airport after the UPD command.

1049
Database Management
Example:
Explanation: Update all route files that contain the checkpoint, ABC, and the airport, EGLL
(as a POD or POA), by replacing ABC with the checkpoint, XYZ.
01 OPTIONS RT,UPD,EGLL,CPT=[ABC],[XYZ]
To update all route files that contain a particular airport pair (POD/POA combination) and the
specified “old” route element, enter the identifiers for the POD and POA after the UPD
command.
Example:
Explanation: Update all route files with a departure of EGLL and an arrival of KJFK that
contain the airway, UG111, by replacing it with the airway, UG999.
01 OPTIONS RT,UPD,EGLL,KJFK,AWY=[UG111],[UG999]
To update a specific route file that contains the specified “old” route element, enter the
identifiers for the POD and POA and the route’s file name after the UPD command.
NOTE Do not forget to prefix the file name with a slash (/).
Example:
Explanation: Update the route file, R001, with a departure of EGLL and an arrival of KJFK,
that contains the checkpoint, ABC, by replacing it with the checkpoint, XYZ.
01 OPTIONS RT,UPD,EGLL,KJFK/R001,CPT=[ABC],[XYZ]
To update all route files that contain the specified “old” route element and that depart or arrive
at a specific airport, enter the identifier for either the POD or POA and the wildcard, $ALL, for
the airport not specified.
Example:
Explanation: Update all route files with a departure of EGLL and an arrival of anything else,
that contain the checkpoint, ABC. Replace the element with the checkpoint, XYZ.
01 OPTIONS RT,UPD,EGLL,$ALL,CPT=[ABC],[XYZ]

1050
Database Management
To update multiple route elements (or route strings) within a file, you only need to specify one
Airway/Checkpoint Search option for all changes, as long as the first element (or route string)
remains consistent to the option prefix. For example, if you had two (or more) changes within
a route file that need to be updated – one beginning with an airway, the other beginning with a
checkpoint – you can minimize your input by specifying both updates using one search option
(AWY= or CPT=). However, that option must coordinate with the first element being
changed. If you use the AWY= option, then you need to specify an old route element (or
string) that begins with an airway. It does not matter what any subsequent element or string
changes begin with, as long as the first is correct.
Example:
Explanation: This example demonstrates multiple changes within a route file. Since the first
input value is an airway (a SID to be precise), the search option used is AWY=. It does not
matter that the next change begins with a checkpoint. If the changes have been reversed, the
search option would have had to be CPT=.
01 OPTIONS RT,UPD,KEWR,VHHH,AWY=[-SID01E],[-SID02E],[-UESO G495

AL],[-UESO G495 UEEA]
Route Group Command (RG)

The Route Group command, RG, is a database access command similar to the Route Database
access command, RT. It enables you to manage and maintain the categories under which route
files can be stored.
Typically, to apply a group name to a route file, you include the Group Name parameter in
your command input when creating a new route file. For example, if you want to create a new
route file (R001) for the airport pair, KSAN to KSEA, and include the file in the group, BLUE,
you would enter the following command.
RT,GEN,KSAN,KSEA/R001,GP=BLUE
Unfortunately, there is no way to affect a route file’s group name using the RT access
command, other than the original input that creates the route file (the RT,GEN command).
However, with the Route Group command, you can add group names to and delete group
names from route files that already exist. In addition, the RG command enables you to include
remarks in a route file, and assign responsibility labels to a route file.

1051
Database Management
Route Group Parameters

The following table lists the parameters associated with the Route Group (RG) command.
Table 41-3 Route Group Parameters
Parameter Explanation
Group Name (Optional). The Group Name parameter enables you
GP=xxxxxxx... to identify a group or category to which a route file is
to be added or from which a route file is to be deleted.
ex. GP=BLUERTES
When assigning a new group name to a route file, the
ex. GP=.RED RTES. criteria you use to categorize the file is left to your
discretion.
You can enter names that are up to 20 characters long.
Names can include spaces between characters – like a
phrase or sentence – if enclosed with periods.
Remarks (Optional). The Remarks parameter enables you to

RMK=xxxxxxx... include remarks in the route file. These remarks are
internal and can only be viewed when displaying the
ex. RMK=Rte valid from 12Z to 18Z only.
route file via a RT,PRI or RT,LST command.
You can enter up to 52 characters of text as the input
value.
Responsibility Label (Optional). The Responsibility Label parameter

RSP=xxxxxxx... enables you to identify yourself or another as the
person who created or who maintains the information
ex. RSP=Disp. J Fray
within the route file. This information is internal and
can only be viewed when displaying the route file via
a RT,PRI or RT,LST command.
You can enter up to 32 characters of text as the input
value.
Group Name Database Management

The Route Group command enables you the functionality of adding or deleting group names,
remarks, and responsibility information to or from a route file. This section reviews these
functions for each option.
Add Command (RG,ADD)

To add a route file to a group (assign a group name to a route file), enter the Route Group
access command, RG, followed by the function command, ADD, the identifiers for the POD
and POA, the file name of the route, and the Group Name parameter, GP=, with the name of
the group to which you want to add the file.
Example:
01 OPTIONS RG,ADD,KSAN,KSEA/R001,GP=TEAM1

1052
Database Management
To add a remark to a route file, enter the Route Group access command, RG, followed by the
function command, ADD, the identifiers for the POD and POA, the file name of the route, and
the Remarks parameter, RMK=, with the remark text.
Example:
01 OPTIONS RG,ADD,KSAN,KSEA/R001,RMK=ROUTE VALID FOR SUMMER ONLY!
To add a responsibility label to a route file, enter the Route Group access command, RG,
followed by the function command, ADD, the identifiers for the POD and POA, the file name
of the route, and the Responsibility Label parameter, RSP=, with the text input.
Example:
01 OPTIONS RG,ADD,KSEA,KSAN/R001,RSP=J Q DISPATCHER
Delete Command (RG,DEL)

To delete a route file from a group, enter the Route Group access command, RG, followed by
the function command, DEL, the identifiers for the POD and POA, the file name of the route,
and the Group Name parameter, GP=, with the name of the group from which you want to
remove the file.
Example:
01 OPTIONS RG,DEL,KSAN,KSEA/R002,GP=.TEAM1 VS TEAM2.
To delete a remark from a route file, enter the Route Group access command, RG, followed by
the function command, DEL, the identifiers for the POD and POA, the file name of the route,
and the Remarks parameter, RMK=, without any text.
Example:
01 OPTIONS RG,DEL,KSAN,KSEA/R001,RMK=
To delete a responsibility label from a route file, enter the Route Group access command, RG,
followed by the function command, DEL, the identifiers for the POD and POA, the file name
of the route, and the Responsibility Label parameter, RSP=, without any text.
Example:
01 OPTIONS RG,DEL,KSAN,KSEA/R001,RSP=
Using Group Names to Select Route Files in a Flight Plan

As stated in the introduction to this chapter, JetPlan can be directed “to use (1) a specific route
file, (2) the best (optimum) file from a selected few, or (3) the best one from the entire lot.”
The group name parameter is a prime example of the second option.

1053
Database Management
By grouping route files you create selected sets of routes. If these sets of routes have two or
more files between the same airport pair (POD/POA combination), you can use the group
name to identify a list of routes from which JetPlan can determine the optimum choice.
For example, assume you have your route files stored under the group names, Blue, Red, and
Green. Each of these route groups has several route files for the airport pair, VABB to EGLL.
When you enter your input on the flight plan’s Route command line, you could direct JetPlan
to select the best route between VABB and EGLL from the Blue group.
Example:
Explanation: Select the optimum route from those route files in the Blue group.
01 OPTIONS FP,CS/SS1234
02 VABB
03 EGLL
06 RT/ALL,GP=BLUE
...
20 COMPUTING 1234
Likewise, you can use group names to eliminate sets of route files from the flight planning
process. To do this, prefix the group name value with a minus sign (–).
Example:
Explanation: Select the optimum route from those route files not in the Red or Green groups.
Effectively, this input has identified the Blue group again as the set from which you want the
route file to come.
01 OPTIONS FP,CS/SS1234
02 VABB
03 EGLL
...
06 RT/ALL,GP=–RED,–GREEN
...
20 COMPUTING 1234

1054
Database Management

Display commands are those that print (to screen) the content of the database. This section
reviews the various ways of displaying the data stored in the Customer Route Database.
Print Command (RT,PRI)

The function command, PRI, enables you to display the entire contents of a single Customer
Route Database file.
Example:
Explanation: Display the contents of route file, R001, for KSJC to KABQ.
01 OPTIONS RT,PRI,KSJC,KABQ/R001

1055
Database Management
CUSTOMER ROUTE R001 KSJC TO KABQ

FOR USERNAME
LAST CHANGED 29.08.2007 LAST USED 29.08.2007
ROUTE INPUTS
J
CPT LAT LONG A/W MCS DIST
001 D303B 3723.9 12158.1 SUNOL6 302.6 0003
002 SUNOL 3736.3 12148.6 SUNOL6 008.6 0015
003 TRACY 3743.9 12127.6 SUNOL6 050.5 0018
004 ECA 3750.0 12110.3 SUNOL6 050.6 0015
005 DUGLE 3751.9 12040.1 J58 069.6 0024
006 TIOGA 3756.0 11925.7 J58 072.8 0059
007 OAL 3800.2 11746.2 J58 073.0 0079
008 ILC 3815.0 11423.7 J58 071.6 0160
009 MLF 3821.6 11300.8 J58 071.2 0066
010 RSK 3644.9 10805.9 J58 100.4 0253
011 PUMPS 3613.1 10741.6 J15 137.6 0037
012 TANER 3552.1 10725.7 J15 138.8 0024
013 CURLY 3525.1 10705.5 CURLY2 138.0 0032
014 ABQ 3502.6 10649.0 CURLY2 138.2 0026
015 KABQ 3502.4 10636.6 CURLY2 081.3 0010

1056
Database Management
List Command (RT,LST)

The function command, LST, provides a sort of summary that includes the customer’s route
input, a route summary (in an ATC format), and basic information about the file, its use, and
its expiration date (if any). This output lacks the point-by-point listing displayed with a PRI
command. The LST command must be entered with accompanying specifications that define
the files you want to see. The LST command by itself does not produce any output.
NOTE The option, $ALL, can be entered as a wildcard value in place of the POD,
the POA, the POD/POA combination, or in place of a route’s file name in order to
display information when an item is unknown. You can use only one $ALL option per
command input.
To see every route file stored in your database, enter the option, /ALL, after the LST
command.
Example:
Explanation: List all route files in the database.
01 OPTIONS RT,LST/ALL
NOTE Because the /ALL option displays every file in your database, this input might
provide too much information at one time, depending on the number of files in your
database. Using more selective options with the LST command might be more useful.
To see a list of all route files for a specific airport pair, enter the identifiers for the POD and
POA after the LST command.
Example:
Explanation: List all route files stored for the airport pair, KSEA to KLAX.
01 OPTIONS RT,LST,KSEA,KLAX

1057
Database Management
RT,LST AIRPORT PAIR EXAMPLE
12.09.2007 TRACKS KSEA TO KLAX

FOR USERNAME
--------------------------------------------------------------
POD POA TRACK GEN/CHG LAST USED EXPIRES

KSEA KLAX R001 11.09.2007 11.09.2007
ROUTE INPUTS
J
KSEA VECTOR BTG J189 AVE SADDE6 KLAX

DIST 869 NM
--------------------------------------------------------------

KSEA KLAX R002 12.09.2007 12.09.2007 31.12.2009
ROUTE INPUTS
J,LIN
FLT LVLS 290 330

DIST 869 NM
To see a list display for a specific route file with a specific airport pair, enter the identifiers for
the POD and POA and the route’s file name after the LST command. Do not forget to prefix
the file name with a slash (/).
Example:
Explanation: List the route file, R001, for the airport pair, KSEA to KLAX.
01 OPTIONS RT,LST,KSEA,KLAX/R001

1058
Database Management
RT,LST SPECIFIC ROUTE FILE EXAMPLE
12.09.2007 TRACK R001 KSEA TO KLAX

FOR USERNAME
-------------------------------------------------------------

KSEA KLAX R001 11.09.2007 11.09.2007
ROUTE INPUTS
J

DIST 869 NM
-------------------------------------------------------------
To see a list of all route files associated with a particular airport, enter the identifier for the
airport after the LST command.
Example:
Explanation: List all route files that have RKSI as a POD or POA.
01 OPTIONS RT,LST,RKSI
To see a list of all route files with the same file name (for assorted airport pairs), enter the
routes’ file name after the LST command. Do not forget to prefix the file name with a slash (/).
Example:
Explanation: List all route files named R001.
01 OPTIONS RT,LST/R001

1059
Database Management
RT,LST ALL ROUTES BY FILENAME EXAMPLE
12.09.2007 SUMMARY OF TRACK R001

FOR USERNAME
--------------------------------------------------------------

KSEA KLAX R001 11.09.2007 11.09.2007
ROUTE INPUTS
J

DIST 869 NM
--------------------------------------------------------------

KVNY KDEN R001 12.09.2007 12.09.2007
ROUTE INPUTS
J,EKR
KVNY NUAL6 DAG J100 EKR TOMSN3 KDEN

DIST 826 NM
--------------------------------------------------------------
Route Proof Command (RT,RP)

The function command, RP, provides a display called a Route Proof. This display includes the
file name, a route summary (in an ATC format), and a total distance value. Use the options
shown in the examples below to discriminate between files.
command input.
To display all route files in a route proof format, enter the option, /ALL, after the RP
command.

1060
Database Management
Example:
Explanation: Display a route proof for all route files in the database.
01 OPTIONS RT,RP/ALL
To display a route proof for all route files with a specific airport pair, enter the identifiers for
the POD and POA and the option, /ALL, after the RP command.
Example:
Explanation: Display the route proofs for all route files stored in the database with the airport
pair, CYVR to RKSI.
01 OPTIONS RT,RP,CYVR,RKSI/ALL
To display a route proof for a specific route file, enter the identifiers for the POD and POA and
the route’s file name after the RP command.
Example:
Explanation: Display the route proof of route file, R001, for the airport pair, KVNY to KDEN.
01 OPTIONS RT,RP,EDDF,OEJN/R004
RT,RP SPECIFIC ROUTE FILE EXAMPLE
R001
KVNY NUAL6 DAG J100 EKR TOMSN3 KDEN
DIST 826 NM
To display a route proof for all route files associated with a specific airport, enter the identifier
for the airport after the RP command.
Example:
Explanation: Display the route proof for all route files that have EDDF as the POD or POA.
01 OPTIONS RT,RP,EDDF

1061
Database Management
Summary Command (RT,SUM)

The function command, SUM, provides another display of route files stored in the Customer
Route Database. The information displayed does not deviate far from what has been shown so
far. It summarizes the information in another format. Use the options shown in the examples
below to discriminate between files.
command input.
To view a display of all airports used as POD or POA in all route files, enter the function
command, SUM, only.
Example:
Explanation: Display a summary of all airports in the Customer Route Database.
01 OPTIONS RT,SUM
RT,SUM ALL AIRPORTS EXAMPLE
12.09.2007 SUMMARY OF AIRPORTS IN ROUTE FILE

FOR USERNAME
KBOS KDEN KEWR KJFK KLAX KSAC KSEA KSFO KVNY
9 ROUTES ARE STORED UNDER THIS ID
To view a display of all route files, enter the option, /ALL, after the SUM command.
Example:
Explanation: Display a summary of all route files in your database.
01 OPTIONS RT,SUM/ALL

1062
Database Management
RT,SUM ALL ROUTE FILES EXAMPLE
12.09.2002 SUMMARY OF ALL TRACKS PAGE 01

FOR USERNAME
POD POA TRACK GROUP GEN/CHG LAST USED EXPIRES USED

KJFK KBOS ALTJFKBOS 04.09.2007 17.04.2007 30
KJFK KEWR ALTJFKEWR 04.09.2007 21.05.2007 119
KSEA KLAX R001 11.09.2007 11.09.2007 0
KSEA KLAX R002 12.09.2007 12.09.2007 31.12.2007 0
KSFO KSAC ALTSFOSAC 04.09.2007 17.04.2006 27
KSFO KSAC ALTSFOSAC2 04.09.2007 17.09.2006 9
KVNY KDEN R001 12.09.2007 12.09.2007 0
KVNY KDEN RT01 09.09.2007 09.09.2007 0
KVNY KDEN RT02 10.09.2007 09.09.2007 0
TOTAL 9
To view a display of all dormant route files, enter the option, /###D (where ### is the number
of days not used value), after the SUM command.
Example:
Explanation: Display all routes not used in the last 120 days.
01 OPTIONS RT,SUM/120D
RT,SUM DORMANT TRACKS EXAMPLE
12.09.2007 DORMANT TRACKS PAGE 01

FOR USERNAME

KJFK KBOS ALTJFKBOS 04.09.2007 17.04.2007 30
KSFO KSAC ALTSFOSAC 04.09.2007 17.04.2007 27
KSFO KSAC ALTSFOSAC2 04.09.2007 17.04.2007 9
TOTAL 3
To view a display of all expired route files, enter the option, /EXP, after the SUM command.
Example:
Explanation: Display all expired route files in the database.
01 OPTIONS RT,SUM/EXP

1063
Database Management
To display all route files associated with a particular airport, enter the identifier for the airport
Example:
Explanation: Display all route files that have EDDF as a POD or POA.
01 OPTIONS RT,SUM,EDDF
To display all route files for a specific airport pair, enter the identifiers for the POD and POA
Example:
Explanation: Display all route files with the airport pair, EDDF to OEJN.
01 OPTIONS RT,SUM,EDDF,OEJN
To display a single route file, enter the identifiers for the POD and POA, and the route’s file
name after the SUM command.
Example:
Explanation: Display the route file, R01, with the airport pair, EDDF to OEJN.
01 OPTIONS RT,SUM,EDDF,OEJN/R01
To display all route files with the same file name, enter the routes’ file name after the SUM
command. Do not forget to prefix the file name with a slash (/).
Example:
Explanation: Display all route files with the file name, R001.
01 OPTIONS RT,SUM/R001
To display all route files stored under a specific group name, enter the option, GP=(group
name), after the SUM command.
Example:
Explanation: Display all route files with the group name, SIERRA.
01 OPTIONS RT,SUM,GP=SIERRA

1064
Database Management
If the database contains a large number of records, you can limit the number of records
displayed by entering a range with the PAGE command as shown below. This can be used
with any of the above commands.
Example:
Explanation: Display records 25 - 50 that contain the group name SILVER.
01 OPTIONS RT,SUM,GP=SILVER,PAGE=25,50
Example:
Explanation: Display the first 10 records that contain KMEM as a POD or POA, and display a
count of the total number of records found.
01 OPTIONS RT,SUM,KMEM,PAGE=1,5,YES

CYWG KMEM PRIMARY 24.12.2003 24.12.2003 0
CYYC KMEM PRIMARY 24.12.2003 24.12.2003 0
CYYZ KMEM HANDY ARR 06.01.2004 06.01.2004 0
CYYZ KMEM PRIMARY 24.12.2003 24.12.2003 0
EDDF KMEM PRIMARY 24.12.2003 24.12.2003 0
TOTAL RECORDS 589
Total Command (RT,TOT)

The function command, TOT, provides a simple total “number of files” figure. The figure
displayed varies with the option you use to discriminate between files. Option application is
similar to the SUM command. There is no other output displayed with the TOT command, just
the lone number of files figure.
command input.

1065
Database Management
Example:
Explanation: Display the total number of route files in your database.
01 OPTIONS RT,TOT/ALL
Example:
Explanation: Display the total number of route files in your database that have not been used
in the last 90 days.
01 OPTIONS RT,TOT/090D
Example:
Explanation: Display the total number of route files that have expired.
01 OPTIONS RT,TOT/EXP
Example:
Explanation: Display the total number of route files with the airport, WSSS, stored as a POD
or POA.
01 OPTIONS RT,TOT,WSSS
Example:
Explanation: Display the total number of route files in the database with the specific airport
pair, WSSS to RJAA.
01 OPTIONS RT,TOT,WSSS,RJAA
Example:
Explanation: Display the total number of route files with the file name, R001.
01 OPTIONS RT,TOT/R001

1066
Database Management
Example:
Explanation: Display the total number of route files stored under the group name, ALPHA.
01 OPTIONS RT,TOT,GP=ALPHA
NOTE You can also get a total figure based on group name by using the RG
command (see example below).
Example:
01 OPTIONS RG,TOT,GP=BRAVO
Record Identifier Command (RT,RID)

The RID command displays only the identifiers (only the POD, POA, and route names) for all
records in the route database.
Example:
01 OPTIONS RT,RID
Search Command (RT,SRH)

The Route Search feature enables a user to display the routes stored in the Customer Route
Database that match specified criteria. Search criteria can include:
• POD=
• POA=
• RTN= (route name)
• GP= (group name)
• CH= (change date)
• LU= (last used)
• EXP= (expiration date)
• NU= (number of times used)

1067
Database Management
Example:
Explanation: Search for route files that contain the airport KLVK as a POD.
01 OPTIONS RT,SRH,POD=KLVK
A wildcard search can also be performed using an asterisk (*).
Example:
Explanation: Search for route files that expire anytime in 2009.
01 OPTIONS RT,SRH,EXP=*2009
NOTE Although group names (GP) can contain spaces when enclosed within
periods, they can not be searched for in that form. When searching for a group name
that contains more than one word, input one or more letters of the first word. For
example, if searching for the group name “FAR EAST,” any of the following inputs
work:
RT,SRH,GP=F
RT,SRH,GP=FA
RT,SRH,GP=FAR
However, entering GP=.FAR EAST returns an error.
Airway/Checkpoint Search Option

The function commands, LST, SUM, RP, and TOT have an option that can be applied to your
command inputs to further the search capability for route files down to specific route
segments. The Airway/Checkpoint Search option enables you to retrieve and display only
those files that contain certain airways, checkpoints, airway segments, or intersections.
The Airway/Checkpoint search option has two prefixes, AWY= and CPT=. The use of one
over the other depends on the input value you want to enter. If you want to begin your input
string with an airway, then the AWY= prefix must be entered. If you want to begin your input
string with a checkpoint, then the CPT= prefix is required.

1068
Database Management
The following examples illustrate the application of the Airway search option.
NOTE To minimize text and time, the examples given below use the RT,LST
command. Keep in mind that the Airway/Checkpoint search option also applies to the
SUM, RP, and TOT commands.
To retrieve a display of all route files that contain a specific airway, enter the option,
AWY=awyid, at the end of the command.
Example:
Explanation: List all route files that contain the airway, UB12.
01 OPTIONS RT,LST/ALL,AWY=UB12
To retrieve a display of all route files that contain a specific intersection, regardless of
direction, enter the option, AWY=awyid cptid, at the end of the command.
Example:
Explanation: List all route files that contain the route intersection, UB12 to SIT.
01 OPTIONS RT,LST/ALL,AWY=UB12 SIT
To retrieve a display of all route files that contain a specific intersection, in a particular
directional sequence, enter the option, AWY=awyid cptid awyid, at the end of the command.
Example:
Explanation: List all route files that contain the route intersection, UB12 to SIT to UA14.
01 OPTIONS RT,LST/ALL,AWY=UB12 SIT UA14
To retrieve a display of all route files that contain an airway or intersection, for a specific
airport pair, enter the identifiers for the POD and POA, and the option, AWY=awyid (cptid
(awyid)), at the end of the command.
Example:
Explanation: List all route files for the airport pair, HECA to LGAT, that have the intersection,
UB12 to SIT.
01 OPTIONS RT,LST,HECA,LGAT,AWY=UB12 SIT

1069
Database Management
To retrieve a display of all route files that contain an airway or intersection, for a specific
airport with any other airport, enter the identifier for one of the airports (POD or POA), the
wildcard, $ALL, for the other airport, and the option, AWY=awyid (cptid (awyid)), at the end
of the command.
Example:
Explanation: List all route files that contain the departure airport, LGAT, and airway or SID
identifier, KEA1D.
01 OPTIONS RT,LST,LGAT,$ALL,AWY=KEA1D
Example:
Explanation: List all route files that contain the arrival airport, LGAT, and airway or STAR
identifier, MIL2K.
01 OPTIONS RT,LST,$ALL,LGAT,AWY=MIL2K
The following examples illustrate the application of the Checkpoint search option.
NOTE To minimize text and time, the examples given below use the RT,SUM
command. Keep in mind that the Airway/Checkpoint search option also applies to the
LST, RP, and TOT commands.
To retrieve a display of all route files that contain a specific checkpoint, enter the option,
CPT=cptid, at the end of the command.
Example:
Explanation: Display a summary of all route files that contain the checkpoint TANSA.
01 OPTIONS RT,SUM/ALL,CPT=TANSA
To retrieve a display of all route files that contain a specific route segment, regardless of
direction, enter the option, CPT=cptid awyid, at the end of the command.
Example:
Explanation: Display a summary of all route files that contain the route segment, TANSA to
UB12.
01 OPTIONS RT,SUM/ALL,CPT=TANSA UB12

1070
Database Management
To retrieve a display of all route files that contain a specific route segment, in a particular
direction, enter the option, CPT=cptid awyid cptid, at the end of the command.
Example:
Explanation: Display a summary of all route files that contain the route segment, TANSA to
UB12 to SIT.
01 OPTIONS RT,SUM/ALL,CPT=TANSA UB12 SIT
To retrieve a display of all route files, for a particular airport pair, that contain a specific route
segment, enter the identifiers for the POD and POA, and the option, CPT=cptid awyid cptid, at
the end of the command.
NOTE The wildcard, $ALL, can be used in place of one of the airports (POD or
POA) to screen for all files containing one particular airport.
Example:
Explanation: Display a summary of all route files that contain the airport pair, HECA to
LGAT, and that contain the route segment, TANSA to UB12 to SIT.
01 OPTIONS RT,SUM,HECA,LGAT,CPT=TANSA UB12 SIT
Customer Route Database File Content Verification

Jeppesen navigational data provides the JetPlan system with route structure information for
two separate databases. One database supports Route Optimizer (RO) inputs. The other
database is used for Specific Route Selector (SRS) inputs. These databases serve as the source
of information for the two methods of route selection on the JetPlan system. Both databases
are updated regularly as changes in navigation structure become effective.
NOTE The Customer Route Database obviously applies as a route selection

method, but only after files have been created using one of the two methods
mentioned above (the Route Optimizer or the Specific Route Selector).
Upon the update of these two databases, the JetPlan system attempts to automatically update
all Customer Route Database files. This automated service relieves customers from the time it
takes to review all of their route files manually.

1071
Database Management
The automatic update process is composed of two steps: Regeneration and Verification.
Regeneration refers to the automated process of submitting the route inputs from your stored
route files for recalculation. It is akin to you rerunning RT,GEN commands on all of your
route files, except that JetPlan performs the process for you. Once a route has gone through the
regeneration process, it is internally flagged with a verification status message.
Verification refers to the status of regenerated route files. Once a route is verified, it can be
approved (OK) for use. Regenerated routes generally end up with one of three verification
status messages attached.
• Automatically Verified
• Needs to be Verified
• Failed Automatic Regeneration
An “automatically verified” route is one in which the route summary line precisely matches
the previous version of the file. JetPlan compares the route with its predecessor and applies the
“verified” status to save you time from reviewing it yourself. Route files that have this status
only await your approval (RT,OK) for use.
A route that “needs to be verified” is one in which a functional route is produced, but the route
summary line deviates from the file’s previous version. Route files that have this status must
be manually verified before approval for use.
A route that has “failed automatic regeneration” is no longer valid. The inputs stored in the file
no longer produce a functional route (an error occurs). You can review the file and the updated
route structure to come up with new inputs (see below) or delete the file.
The verification process serves to ensure the quality of the information in your files. All
regenerated routes, whether verified automatically or verified manually, must ultimately be
approved before they can be used with high assurance of validity.
NOTE If the verification flag is not removed (not okayed) and the file is used in a
flight plan, JetPlan inserts a warning message in the output of the flight plan, letting
you know that the information might not be valid.
NOTE SRS routes that regenerate properly (do not fail regeneration) are always
automatically verified. This is due to the fact that SRS route summary lines only
change when the route inputs change (they are the same).

1072
Database Management
Check Command (RT,CHK)

The function command, CHK, enables you to determine the number of Customer Route
Database records affected by a recent update to the navigation structure. Command options
enable you to display those files that have been (1) automatically verified by JetPlan or (2)
need manual verification (both successful and unsuccessful regenerations) by you.
The CHK options, LST and RP, display output of those records that need manual verification.
The difference between the two options is simply the amount of information shown in the
output (see “Route Database Management” in this chapter for information on display
differences).
The CHK option, AV, which must be entered in coordination with the LST or RP options,
displays output of those records that have been automatically verified by JetPlan.
Check List (RT,CHK,LST)

The LST option shows those route files that need manual approval. This includes routes that
have been successfully regenerated, but have changed to some degree over the previous
version, and routes that have failed regeneration. The LST option provides more information
than the RP option. The following output is an example of a basic RT,CHK,LST request.
Example:
01 OPTIONS RT,CHK,LST

1073
Database Management
WHEN CHART CHANGES ARE MADE, YOUR ROUTES

ARE CHECKED TO SEE IF THEY ARE AFFECTED.
WHEN POSSIBLE, THEY WILL BE CHANGED FOR YOU.
THE FOLLOWING COULD NOT BE CHANGED

------------------------------------------------------------------
POD POA TRK# GROUP GEN/CHG LAST USED EXPIRES

RJFM RKPK P001 17/10/06 12/08/07
ROUTE INPUTS FAILED AUTOMATIC REGENERATION

J,D,SHX,D,OLE,APELA,D,PSN
RJFM..SHX..OLE V40 FU W12 IKE A582 APELA..PSN..RKPK

DIST 274NM
------------------------------------------------------------------
THE FOLLOWING WERE CHANGED
------------------------------------------------------------------

KLAX KBFL A01 06/02/07 15/01/07
ROUTE INPUTS ROUTE NEEDS TO BE VERIFIED

J,EHF,D
KLAX V23 EHF..KBFL

DIST 106NM
------------------------------------------------------------------
Additional options can be applied after the LST option to invoke a more restrictive search for
records and limit the output to certain information. The following list gives you an idea of the
criteria by which you can display information.

1074
Database Management
List (LST) Options

Table 41-4 List (LST) Options
Example Explanation
RT,CHK,LST,GP=X Display a list of all affected routes with the group
name, X.
RT,CHK,LST,ARPT Display a list of all affected routes associated with a
specific airport.
RT,CHK,LST,ARPT,GP=Y Display a list of all affected routes with the group
name, Y, associated with a specific airport.
RT,CHK,LST,POD,POA Display a list of all affected routes associated with a
specific airport pair (POD/POA combination).
RT,CHK,LST,POD,POA,GP=Z Display a list of all affected routes with the group
name, Z, associated with a specific airport pair.
RT,CHK,LST,POD,POA/FNAME Display a list of all routes with the same file name and
associated with a specific airport pair.
NOTE You can enter the option, AV, at the end of any of these command examples
to retrieve a display of those records which were automatically verified by JetPlan.
For example:
RT,CHK,LST,GP=X,AV Display a list of all affected routes with the group

name X that were automatically verified by JetPlan.
RT,CHK,LST,ARPT,AV Display a list of all affected routes associated with a
specific airport that were automatically verified by
JetPlan.
Check Route Proof (RT,CHK,RP)

The RP option, like LST, shows those route files that need manual approval. However, the RP
option provides less information than the LST option. The following output is an example of a
basic RT,CHK,RP request.
Example:
01 OPTIONS RT,CHK,RP

1075
Database Management
WHEN CHART CHANGES ARE MADE, YOUR ROUTES

ARE CHECKED TO SEE IF THEY ARE AFFECTED.
WHEN POSSIBLE, THEY WILL BE CHANGED FOR YOU.
THE FOLLOWING COULD NOT BE CHANGED

------------------------------------------------------------------
P001 FAILED AUTOMATIC REGENERATION

RJFM..SHX..OLE ATS IK A582 APELA..PSN..RKPK
DIST 274NM
------------------------------------------------------------------
THE FOLLOWING WERE CHANGED
------------------------------------------------------------------
A01 NEEDS TO BE VERIFIED

KLAX V23 EHF..KBFL
DIST 106NM
------------------------------------------------------------------

REQUEST NO. 4567
Additional options can be applied after the RP option to invoke a more restrictive search for
records and limit the output to certain information. See the examples for the LST option to get
an idea of the criteria by which you can display information using the RP option.
OK Command (RT,OK)
The function command, OK, enables you to finalize the verification process by approving
verified route files for use. Once a route file is OK’d, the internal verification flag is removed.
NOTE All route verification approvals need to be completed within ten days of the
route structure update. Any route file not okayed within this time frame might be
internally flagged for verification with the next route structure update, even if not
affected by route structure changes.
All successfully regenerated routes that have been verified (manually or automatically) can be
approved by entering a RT,OK command. Like the CHK command, you can apply other
options to the OK command to define the specific routes you want to approve. The following
list illustrates the OK command with various options.

1076
Database Management
Table 41-5 OK Option
Example Explanation
RT,OK/ALL Approves all updated routes.
RT,OK/ALL,GP=XRAY Approves all updated routes with the group name,

XRAY.
RT,OK,ARPT/ALL Approves all updated routes associated with a specific
airport.
RT,OK,ARPT/ALL,GP=XRAY Approves all updated routes associated with a specific
airport and within a specific group (XRAY).
RT,OK,POD,POA/ALL Approves all updated routes associated with a specific
airport pair (POD/POA combination).
RT,OK,POD,POA/ALL,GP=XRAY Approves all updated routes associated with a specific
airport pair and within a specific group (XRAY).
RT,OK,POD,POA/FNAME Approves all updated routes associated with a specific
airport pair and having a specific file name.
NOTE Enter the option, AV, at the end of any of these command examples to
approve records that were automatically verified by JetPlan.
For example:
RT,OK/ALL,AV Approves the updated routes that were

automatically verified by JetPlan.
RT,OK,ARPT/ALL,GP=XRAY,AV Approves all updated routes associated with a
specific airport and within a specific group
(XRAY) that were automatically verified by
JetPlan.
Changing Failed Routes

If you want to rectify routes that fail the regeneration process, you must determine the cause of
the failure and make the appropriate changes. Generally, Customer Route Database files fail
regeneration because the stored route input contains an input element (a waypoint, navaid, or
airway ID) that has changed with the recent navigation structure update. You must review the
new route structure and determine new inputs for your route file. Jeppesen customer service is

1077
Database Management
available to assist you with this process. Once the problem is solved, you simply perform a
RT,UPD command on the failed route file and replace the obsolete or bad route inputs with
new ones.
Customer Route Database Usage

The examples that follow illustrate various route database command inputs and output.
Creating a Customer Route Database File
Example:
01 OPTIONS RT,GEN,RJAA,RKSI/R001,311202,FL,GP=AONE
06 ROUTE J,HME,D,KCC,KPO

1078
Database Management
CUSTOMER ROUTE R001 RJAA TO RKSS GROUP A

AAAA ID AND PASSWORD
LAST CHANGED 31/01/07 LAST USED 31/01/07
ROUTE INPUTS
J,HME,D,KCC,KPO
FLT LVLS 280 310
001 HME 3532.8 -13946.6 SID 254.0 0054
002 KCC 3515.7 -13655.1 .. 270.1 0141
003 JEC 3531.7 -13306.0 V26 282.3 0188
004 SAPRA 3549.3 -13043.6 G585 286.4 0017
005 KPO 3558.5 -12928.5 G585 286.4 0062
006 REBIT 3646.5 -12804.0 G585 312.5 0083
007 KALMA 3718.2 -12707.1 G585 312.6 0055
008 SEL 3724.7 -12655.9 G585 312.6 0012
009 RKSS 3733.3 -12648.0 STAR 332.6 0035
TOTAL DISTANCE 0747
Changing a Customer Route Database File
Example:
01 OPTIONS RT,CHG,RJAA,RKSI/R001,310605,GP=ATHREE
06 ROUTE J,HME,D,KCC,KPO
NOTE Group code and expiration date changed

1079
Database Management
CUSTOMER ROUTE R001 RJAA TO RKSS GROUP 3

ROUTE INPUTS
J,HME,D,KCC,KPO//
001 HME 3532.8 -13946.6 SID 254.0 0054
002 KCC 3515.7 -13655.1 .. 270.1 0141
003 JEC 3531.7 -13306.0 V26 282.3 0188
004 SAPRA 3549.3 -13043.6 G585 286.4 0017
005 KPO 3558.5 -12928.5 G585 286.4 0062
006 REBIT 3646.5 -12804.0 G585 312.5 0083
007 KALMA 3718.2 -12707.1 G585 312.6 0055
008 SEL 3724.7 -12655.9 G585 312.6 0012
009 RKSS 3733.3 -12648.0 STAR 332.6 0035
TOTAL DISTANCE 0747
Displaying a Customer Route Database File
Example:
01 OPTIONS RT,PRI,KSEA,KLAX/R001

1080
Database Management
CUSTOMER ROUTE R001 KSEA TO KLAX GROUP 1

ROUTE INPUTS
J,FIM--V107 SADDE
001 BTG 4544.9 12235.4 VECTOR 166.7 0103
002 LMT 4209.2 12143.6 J189 151.9 0219
003 LIN 3804.5 12100.2 J189 155.5 0246
004 AVE 3538.8 11958.7 J189 145.7 0154
005 FIM 3421.4 11852.8 J1 130.6 0066
006 GINNA 3413.4 11849.9 V107 148.9 0009
007 SADDE 3402.3 11845.8 V107 149.0 0012
008 KLAX 3356.5 11824.4 .. 094.9 0019
TOTAL DISTANCE 0856
Renaming a Customer Route Database File
Example:
01 OPTIONS RT,RN,RJAA,RKSI/01W/001R
ROUTE 01W FROM RJAA TO RKSS HAS BEEN RENAMED 001R

REQUEST NO. 4801

1081
Database Management
Deleting a Customer Route Database File
Example:
01 OPTIONS RT,DEL,RJAA,RKSI/001R
1 ROUTE(S) DELETED

REQUEST NO. 5070
Displaying a Route Proof of All Files
Example:
01 OPTIONS RT,RP,CYVR,RKSI/ALL
R33
CYVR..YVR J500 ARRUE..YZT J523 YZP TRK18 KATCH B327 EHM..OZZIE R580 OATIS ATS SNAIL
OTR3 GOC W18 KCC V26 JEC G585 SEL STAR RKSS
DIST 4860NM
R580
CYVR..YZT TRK17 GUPEY G585 FOXES G469 ORDON R580 OATIS ATS KETAR OTR10 CVC..KCC V26
JEC G585 SEL STAR RKSS
DIST 4850NM
S001
CYVR..YVR J500 ARRUE..YZT J523 YZP TRK18 KATCH B327 OYSTA R580 OATIS ATS SNAIL OTR3
GOC W18 KCC V26 JEC G585 SEL STAR RKSS
DIST 4827NM

1082
Database Management
Displaying a Route Proof of a Specific File
Example:
01 OPTIONS RT,RP,KSFO,RKSI/R001
KSFO VECTOR ENI D FOT C1416 DAASH B453 KATCH B327 NUKKS R220 NOGAR V51 GTC V30 JEC
G585 SEL STAR RKSS

REQUEST NO. 5074
Displaying a Summary of All Airports in Customer Route Database
Example:
01 OPTIONS RT,SUM
SUMMARY OF AIRPORTS IN ROUTE FILE
KLAX KSEA KSFO OMSJ RJAA RKSS VABB
13 ROUTES ARE STORED UNDER THIS ID
Displaying a Summary of All Stored Routes in Customer Route Database
Example:
01 OPTIONS RT,SUM/ALL

1083
Database Management
21/01/07 PAGE 01
SUMMARY OF ALL TRACKS

KLAX KSEA R001 G 15/01/07 20/01/07 31/12/11
KLAX KSEA R002 S 15/01/07 19/01/07 31/12/11
KSEA KLAX R001 1 15/01/07 20/01/07 31/12/11
KSFO RKSS A001 1 16/01/07 19/01/07 31/06/08
KSFO RKSS A002 1 16/01/07 20/01/07 31/06/08
VABB OMSJ 001 A 17/01/07 20/01/07 31/12/10
TOTAL 6

REQUEST NO. 6010
Displaying a Summary of All Stored Routes To/From an Airport
Example:
01 OPTIONS RT,SUM,KSEA
21/01/07 PAGE 01
SUMMARY OF ALL TRACKS FROM OR TO KSEA

KLAX KSEA R001 G 15/01/07 20/01/07 31/12/11
KLAX KSEA R002 S 15/01/07 19/01/07 31/12/11
KSEA KLAX R001 1 15/01/07 20/01/07 31/12/11
TOTAL 3

REQUEST NO. 6015
Displaying a Summary of All Stored Routes Between Two Airports
Example:
01 OPTIONS RT,SUM,KSFO,RKSI

1084
Database Management
21/01/07 PAGE 01
SUMMARY OF ALL TRACKS KSFO TO RKSS

KSFO RKSS A001 1 16/01/07 19/01/07 31/06/08
KSFO RKSS A002 1 16/01/07 20/01/07 31/06/08
TOTAL 2

REQUEST NO. 7013

Illustrated below are five examples showing different ways to enter a route database file on the
Route command line of your flight plan request.
NOTE If the “Default Route String” customer preference is set and the user enters a
blank input on the Route command line, the route selector first looks for any ATC
preferred routes. If there are none, it then searches for stored Customer Route
Database routes. Finally, if there are no stored routes, JetPlan optimizes a route.
Contact your Jeppesen account manager for details on this preference setting.
Example:
Explanation: This input considers all route files that contain the same POD and POA
identifiers as entered in the flight plan request.
06 ROUTE RT/ALL

1085
C HAPTER 42
Route Constraint
Database
Route Constraint Database
About the Route Constraint Database

The Customer Route Constraint Database supports the concept of fleet-dependent routing,
which means that the system qualifies usable routes based on an aircraft’s equipment or
navigational capabilities. An airline can choose to restrict certain routes to particular aircraft in
its fleet, unless an aircraft has the necessary equipment or certifications to fly the route.
The Route Constraint Database lets you create and maintain records of customer-specific
information that defines a stored (or replacement) route and the aircraft characteristics
required to use the route. Used in conjunction with both the Customer Aircraft Database
(CADB) and the Customer Route Database (CRDB), the Route Constraint Database lets you
identify, for any given CADB record, the existence of data that potentially affects the
qualification of a route.
You can find the qualifying parameters in the “Equipment” and “Certified” sections of your
CADB records. The following table lists these parameters.
Table 42-1 Qualifying Parameters in the CADB
On-Board Equipment Certification Stamps

Number VHF radios (VR) Overwater Certification (OW)
Number HF radios (HR) MNPS Equipped (ME)

NOTE MNPS Equipped is being renamed “NAT HLA”
in 2016.
Dual ADF Equipped (DA) RVSM Certification (RV)
Dual INS Equipped (DI) RNP Certification (RP)
RNAV Equipped (RE)
FMS Equipped (FM)
OMEGA Equipped (OM)
GPS Equipped (GP)
TCAS Equipped (TE)
As stated above, the Route Constraint Database enables you to automatically identify for any
given tail-number (CADB record) the existence of data that potentially affects the
qualification of your route input. If the aircraft type does not qualify based on its equipment or
certifications, your route input is either replaced with the constraining route found in the Route
Constraint Database (in the case of random route optimization) or is prevented from using a
particular canned route (in the case of a canned route optimization—for example, RT/ALL)
for the specified airport pair. These options are explained in more detail in the following
sections.

1089
Canned Route Optimization Versus Random Route

Optimization
The Route Constraint Database enables you to identify two types of route constraint options
for a given airport pair. The first option, known as canned route optimization, puts constraints
on stored routes in the CRDB. When JetPlan receives an RT/ALL input or something similar,
the system checks the Route Constraint Database for the appropriate records. If there is a
match with the airport pair, aircraft type, and the use of a canned route record, the system
performs a check against the CADB to verify presence of the necessary equipment or
certifications.
If all qualifications are satisfied, the Route Constraint Database is dismissed, and the system
selects the optimum route record from the CRDB. However, if a qualification is not satisfied,
the canned route specified in the Route Constraint Database record (for example, RT01) is
omitted from the list of available and applicable CRDB records. The system then selects the
optimum route record from the CRDB, minus the constrained canned route (RT01).
The second option, known as random route optimization, puts constraints on routes other than
those found in the CRDB. The random route method is performed using either a Customer
Restricted Area Database entry or a user-specified route input, or a combination of the two. In
this case, when a qualification is not satisfied, the route (or restricted area) stored in the Route
Constraint Database is applied as an override to whatever route input you entered in the flight
plan request.
Both of these constraint options are stored as individual records, with basically the same
information. The difference between the records lies in the applicability of certain fields. The
Customer Route name field does not apply to a random route constraint record, while the
restricted area name and substitute route (Route command line input) fields do not apply to a
canned route constraint record.

1090
Route Constraint Records

The examples in this section include constraint records for the canned route option and the
random route option. In addition, the random route option breaks down into three different
examples: one with the substitute route by itself, one with the restricted area by itself, and one
with both.
Canned Route Optimization
Example:
• Generic aircraft type: 472C
• POD: KSFO
• POA: RJAA
• Customer route name: RT123 (stored route from the CRDB)
Required aircraft characteristics:
• Number of HF radios: 1
• Number of VHF radios: 2
• DUAL ADF: Y
• DUAL INS: Y
• FMS: N
• GPS: N
• OMEGA: N
• RNAV: Y
• TCAS: N
• MNPS (NAT HLA): N
• RVSM: N
• OWTR: Y
• Restricted area name: Not applicable (NA)
• Substitute Route command line entry (Question 6) input: NA
Note that the restricted area name and substitute Route command line input fields are not
applicable since this is an example of a stored route (or canned) constraint record.

1091
The example record applies to any flight plan with the specified POD and POA (KSFO and
RJAA), a routing input of RT/ALL, or a variation or RT/ALL, and an aircraft with the 472C as
its generic type. If all three factors are satisfied, the record is further evaluated to determine
whether to apply a route constraint. This involves cross checking the individual characteristics
of the selected customer aircraft against the required aircraft characteristics found in the
constraint record.
In this case, the required aircraft characteristics are the following:
• DUAL ADF: Yes
• DUAL INS: Yes
• RNAV: Yes
• OWTR: Yes
If the selected customer aircraft does not possess all of the defined characteristics shown
above, then the route constraint is automatically applied. In this case, the route constraint is the
elimination of customer route RT123 from consideration in the RT/ALL optimization request.
It does not matter what the selected customer aircraft settings are for the parameters FMS,
GPS, OMEGA, RNAV, TCAS, MNPS (NAT HLA) or RVSM. These are set to No in the
record, making them irrelevant characteristics.
Random Route Optimization (Route Only)

Example:
• POD: KSFO
• POA: RJAA
• Customer route name: NA
• DUAL ADF: N

1092
• DUAL INS: N
• FMS: N
• GPS: Y
• OMEGA: N
• RNAV: N
• TCAS: N
• RVSM: N
• OWTR: Y
• Restricted area name: No entry
• Substitute Route command line entry (Question 6) input: J,ABC
Because this is an example of a user-specified route constraint record, the customer route
name is labeled not applicable. Also, this example omits a restricted area name entry.
The record applies to any flight plan with the specified POD and POA, a routing input of
anything other than RT/ALL (or a variation of RT/ALL) and an aircraft with the 472C as its
generic type. If all three of these factors are satisfied, the record is further evaluated to
determine whether to apply a route constraint. The selected customer aircraft is cross-checked
against the required aircraft characteristics found in the constraint record.
• GPS: Yes
• OWTR: Yes
If the selected customer aircraft does not possess all of the defined characteristics, the route
constraint is automatically applied. In this case, the route constraint is the input J,ABC, which
replaces whatever you entered as the route input.

1093
Random Route Optimization (Restricted Area Only)
Example:
• POD: KSFO
• POA: RJAA
• DUAL ADF: N
• DUAL INS: N
• FMS: N
• GPS: N
• OMEGA: N
• RNAV: Y
• TCAS: N
• RVSM: N
• OWTR: Y
• Restricted area name: XAREA1
• Substitute Route command line entry (Question 6) input: No entry
Again, the customer route name is not applicable and the substitute Question 6 input field is
left empty in this example.
The record applies to any flight plan with the specified POD and POA, a routing input of
anything other than RT/ALL (or a variation of RT/ALL), and an aircraft with the 472C as its
generic type. If all three of these factors are satisfied, the record is further evaluated to
determine whether to apply a route constraint.

1094
• RNAV: Yes
• OWTR: Yes
If the selected customer aircraft does not possess all of the defined characteristics, then the
route constraint is automatically applied. In this case, the route constraint is the activation of
the customer-restricted area XAREA. This has the same affect as specifying a customer-
restricted area manually.
Random Route Optimization (Route & Restricted Area)
Example:
• POD: KSFO
• POA: RJAA
• DUAL ADF: N
• DUAL INS: N
• FMS: N
• GPS: Y
• OMEGA: N
• RNAV: Y
• TCAS: N
• RVSM: N
• OWTR: Y

1095
• Restricted area name: XAREA1

• Substitute Route command line entry (Question 6): J,XYZ
This record applies to any flight plan with the specified POD and POA, a routing input of
anything other than RT/ALL, and an aircraft with the 472C as its generic type. If all three of
these factors are satisfied, the record is further evaluated to determine whether to apply a route
constraint.
• GPS: Yes
• RNAV: Yes
• OWTR: Yes
If the aircraft does not meet the criteria, the route constraint is automatically applied. In this
case, the route constraint involves the substitution of J,XYZ for your route input and the
activation of the restricted area XAREA1.
NOTE You can use the canned route optimization option to create multiple
constraint records for a given combination of POD, POA, and generic aircraft type, as
long as each customer route name is unique. Conversely, you can use the random
route optimization choice to create only one constraint record of that type for a given
combination of POD, POA, and aircraft. Thus, if you created a Route Constraint
Database based on the above examples, the first example could be loaded in
coordination with the second, third, or fourth examples. However, the second, third,
and fourth examples could not be combined for a given airport pair and generic
aircraft type. These examples are mutually exclusive entries.

1096
Database Parameters
Database Parameters
The following table lists the parameters that can be set in the Route Constraint Database.
These parameters appear as options on the Route Constraint Database pages in JetPlan.com.
As you perform database tasks, consult this table for information.

Table 42-2 Route Constraint Database Parameters
POD ICAO or IATA airport identifier
POA ICAO or IATA airport identifier
A/C Type Generic aircraft identifier

xxxx
Override Database Override Flag. Enables you to ignore and

OVR override the application of the Route Constraint
Database.
Input value: Yes or No
On-Board Equipment Parameters

NOTE The following parameters can be entered with a (Y)es or (N)o value. If the parameter is entered on the
command line without a value, JetPlan assumes you are setting the value to (Y)es by default. The equal sign
following the parameters is optional.
VHF Radios Very high frequency radios

VHF=x Input value: The number of radios on board the
aircraft
HF Radios High frequency radios

HF=x Input value: The number of radios on board the
aircraft
Dual ADF Dual ADF equipped

ADF=x Input value: Yes or No
Dual INS Dual INS equipped

INS=x Input value: Yes or No
RNAV RNAV equipped

RNAV=x Input value: Yes or No

1097
Database Parameters
Table 42-2 Route Constraint Database Parameters (continued)
FMS FMS equipped
FMS=x Input value: Yes or No
OMEGA OMEGA equipped

OMEGA=x Input value: Yes or No
GPS GPS equipped

GPS=x Input value: Yes or No
TCAS TCAS equipped

TCAS=x Input value: Yes or No
Certification Stamps
MNPS (NAT HLA) MNPS (NAT HLA) certification
MNPS=x Input value: Yes or No
Overwater Overwater certification

OWTR=x Input value: Yes or No
RVSM RVSM certification

RVSM=x Input value: Yes or No
COST=x,yyy Cost and Currency

Input values: The x value is a cost and the yyy value is
a currency. The comma between the two is required.
Canned Route Optimization Parameter
Route Name Customer Route database record name

yyyy NOTE If no CRDB file is used, then leave the field
empty by entering two commas in a row.
Random Route Optimization Parameters
Restricted Area Name Restricted Area

RST=xxxx Input value: The record name (8-character maximum)
Route Input Route input. This input must be the last entry in the
Q6=Text command.
Input value: No more than 52 characters of route
input.

1098
Database Management
Database Management

To make the Route Constraint Database a data resource for flight planning, you must first
create and manage records of information in the database. To do this, you need to access the
database. The Route Constraint Database access command is RTC, and it is entered on the
NOTE Help instructions on how to build or maintain the Route Constraint Database
are available by entering RTC,HELP on the Options command line.
Two categories of command functions are available when accessing the Route Constraint
database. These functional categories are listed below with the specific commands.
File Maintenance
File Display
• SUM – Displays a list of records (by POD/POA)
• PRI – Displays the contents of the record or records specified

1099
Database Management
Route Constraint Database Commands

The Route Constraint command functions are divided into two categories: file maintenance
and file display. This section describes each command function.

Table 42-3 Route Constraint Database File Maintenance Commands
Command Description
RTC,SAV The SAV command enables you to create a new record of information in the database.
Specify the POD, POA, and aircraft type as the elements that define the file, and include any
parameter applicable for implementing a route constraint.
To build a Route Constraint Database record, define one or more route constraints that can
be applied automatically when the selected aircraft is lacking specific characteristics (for
example, missing certain equipment or certifications). A record in the database contains the
• POD
• POA
• Generic aircraft type
• Customer route database record name
• Required aircraft characteristics (equipment and certifications)
• Constraint type (1/rte only, 2/restricted area only, 3/both)
• Override flag
• Restricted area record name
• Substitute Question 6 input
EXAMPLE:
01 OPTIONS RTC,SAV,POD,POA,XXXX,YYYY,K1,K2
– or –
01 OPTIONS RTC,SAV,POD,POA,XXXX,,K1,K2
01 OPTIONS RTC,SAV,POD,POA,XXXX,,K1,K2
Where:
• RTC is the Customer Route Constraint Database access command.

1100
Database Management
Table 42-3 Route Constraint Database File Maintenance Commands (continued)
Command Description
RTC,SAV • SAV is the Save function. Other commands such as CHG, DEL, PRI, and SUM follow
(continued) the RTC access command when you want to apply those functions.
• POD is the ICAO or IATA airport identifier.
• POA is the ICAO or IATA airport identifier.
• XXXX is the Generic aircraft identifier.
• YYYY is the Customer Route database record name.
NOTE If no CRDB file is used, then leave the field empty by entering two commas in a row.
• K1,K2 is the Constraint parameters and associated inputs. See “Database Parameters”
on page 1097.
The remaining parameters can be entered with a (Y)es or (N)o value. If the parameter is
entered without a value, JetPlan assumes you are setting the value to (Y)es by default.
RTC,CHG The CHG command enables you to modify or update a previously created database record.
The command is entered in the same manner as the SAV command. You can add new
settings to the record or change previously stored settings to new values in the record.
EXAMPLE:
01 OPTIONS RTC,CHG,KSFO,RJAA,472C,RST=XNPAC
RTC,DEL The DEL command enables you to remove a record, or records in several different ways.
EXAMPLE:
Explanation: Delete a specific record.
01 OPTIONS RTC,DEL,POD,POA,ACTYPE,RTE
EXAMPLE:
Explanation: If no CRDB file is stored, delete by POD/POA/ACTYPE combination.
01 OPTIONS RTC,DEL,POD,POA,ACTYPE
EXAMPLE:
Explanation: Delete all records for a given aircraft type.
01 OPTIONS RTC,DEL,POD,POA,ACTYPE,$ALL
EXAMPLE:
Explanation: Delete by POD/POA combination.
01 OPTIONS RTC,DEL,POD,POA
EXAMPLE:
Explanation: Delete by POD (or POA).
01 OPTIONS RTC,DEL,POD
NOTE If all records need to be deleted, contact Jeppesen Customer Service.

1101
Database Management

Table 42-4 Route Constraint Database File Display Commands
Command Description
RTC,SUM The SUM command provides a list of all records requested.
EXAMPLE:
Explanation: Display a list of all records.
01 OPTIONS RTC,SUM
EXAMPLE:
Explanation: Display a list of all records that includes the specified POD.
01 OPTIONS RTC,SUM,POD
EXAMPLE:
Explanation: Display a list of all records that includes the specified POD/POA combination.
01 OPTIONS RTC,SUM,POD,POA
RTC,PRI The PRI command displays the entire contents of a record or records. It includes every
parameter and value stored within the record.
EXAMPLE:
Explanation: Print a complete record for every file stored in the Route Constraint Database.
01 OPTIONS RTC,PRI
EXAMPLE:
Explanation: Print a complete record for every file stored in the Route Constraint Database
with the specified POD.
01 OPTIONS RTC,PRI,POD
EXAMPLE:
with the specified POD/POA combination.
01 OPTIONS RTC,PRI,POD,POA
EXAMPLE:
with the specified POD/POA/AC type combination.
01 OPTIONS RTC,PRI,POD,POA,ACTYPE
EXAMPLE:
with the specified POD/POA/AC type combination and the specified CRDB file name.
01 OPTIONS RTC,PRI,POD,POA,ACTYPE,RTE

1102

Whether route constraints are applied to a flight plan or not depends entirely on the existence
of data stored in the Route Constraint Database. If the Route Constraint Database exists, then
the function of comparing and matching stored information with flight plan inputs occurs
automatically. You do not explicitly request this application. A comparison is made between
the stored data and the data entered in the flight plan request. If the combination of POD, POA,
and generic aircraft matches the flight plan's inputs, and the stored characteristics of the
aircraft do not, then a constraint is applied to the routing.
If a flight plan’s route inputs are substituted for the route inputs found in the Route Constraint
Database, the substitute inputs are not stored in the P file. The P file is a storage area on the
JetPlan computer where the day's requests are held temporarily for recall convenience. By not
storing the request with the constraint record's substitute route inputs, you can recall the flight
plan and insert a customer aircraft that might not be subjected to the route constraint. The same
rule applies when the activation of a restricted area is forced by an entry in the Route
Constraint Database. If you recall the flight plan, the constraint record's restricted area is not
included.
Also, it is important to keep in mind that the canned route and random route type of route
constraints are mutually exclusive. In other words, a route substitution or restricted area
activation can never occur for flight plans where your routing input is RT/ALL; only canned
route constraints can apply.
Precedence and Overrides

A route constraint is applied to a flight plan based on data stored in the applicable route
constraint record. If the constraint record includes a Restricted Area database file, then the
constraint record takes precedence over your explicitly specified restricted area named on the
For example, suppose you specify the Restricted Area database file, XOPN, on a flight plan
request. However, a Route Constraint Database record is applied to the plan request, and the
aircraft in the flight plan does not pass all of the requirements necessary for the flight plan to
proceed; hence a stored Restricted Area database file within the Route Constraint Database
record, XAREA5, is activated. In this case, the Restricted Area database record (XAREA5)
would take precedence over XOPN.
It is possible to override the application of route constraints by answering Y(es) to the

Override Flag parameter (OVR). If OVR=Y, you can explicitly prevent the application of a
record's route constraints. If OVR is set to N, then no explicit override is possible.

1103
An explicit override is specified by entering NRTC on the Options command line.
EXAMPLE:
01 OPTIONS FP,SP,NRTC
This input prevents the application of route constraints, regardless of the characteristics of the
selected customer aircraft.

1104
C HAPTER 43
Scenario Database
Scenario Database
About the Scenario Database
About the Scenario Database

The Scenario Database is intended to be used in conjunction with Optimal Scenario Analysis
(OSA or 4D) planning and lets you repeat OSA flight plans quickly and easily. You can use
the Scenario Database to store flight plan input variations for routing, area restrictions, and
other airway limitations that are used in 4D planning to provide other flight possibilities. The
system compares the computed differences, evaluates them for time, distance, or cost, and
returns the optimum results.
When using the Scenario Database, be aware of the following conditions:
• Only 4D flight plans use Scenario Database records.

• The generic aircraft name must match during OSA flight plan computations,
or the record is ignored.
• Only the first non-blank secondary format is used, even though each
Scenario Database record can have its own secondary format.
• During scenario optimization, only valid inputs are used. A Scenario
Database record that has invalid inputs stored is skipped, and the final
output does not indicate a problem with the inputs exists.
• Answering the Restricted Area command line or the Route command line
prompt with a blank <Return> results in the initial inputs being used. Type
NONE on the Restricted Area command line if a non-restricted area plan is
desired.

1107
Scenario Database
Database Parameters
Database Parameters
The following table lists the parameters in the Scenario Database. These parameters appear as
options on the Scenario Database pages in JetPlan.com. As you perform Scenario Database
tasks, consult this table for information.

maintenance. The table below lists JetPlan database codes under the associated
parameter names.
Table 43-1 Scenario Database Parameters
Scenario Name This parameter enables you to enter a name for the
new scenario record.
POD This parameter defines the point of departure for the

scenario.
Input value: IATA or ICAO code
POA This parameter defines the point of arrival for the

scenario.
Input value: IATA or ICAO code
Optimization Type NOTE The Trajectory Optimized RAD Compliant

Route Selection option is not used with 4D Airspace
(F – Trajectory Optimized RAD Compliant Route
Avoidance (CCAA).
Selection)
This parameter defines the optimization type used by
the scenario:
• Enhanced lateral route selection (VBBR) –This
option is not currently used.
• Trajectory Optimized RAD Compliant Route
Selection – This parameter invokes a new route
selector that is designed to be fully compliant
with Euro RAD rules, CDRs and other four-
dimensional conditional routing schemes
imposed in Europe and other parts of the world.
For information on ERAD, see the “Route
• None – None of the above optimization types
applies.

1108
Scenario Database
Database Parameters
Table 43-1 Scenario Database Parameters (continued)
Customer Controlled Avoid/Alert (CCAA): NOTE 4D Airspace Avoidance (CCAA) is not used
with the following Optimization Type: Trajectory
(CCAA)
Optimized RAD Compliant Route Selection.
This parameter invokes 4D Avoid and Alert
(CCAA/CCAAN) functionality.
Input options:
• 4D Airspace Avoidance – Invokes 4D Avoid
(CCAA) functionality, which instructs JetPlan to
avoid avoid-level Special Use Airspaces (SUAs),
user-defined airspaces, or Jeppesen turbulence
airspaces when determining an optimum route
and profile. JetPlan allows “notify-level” SUAs,
user-defined airspaces, or Jeppesen turbulence
airspaces to be traversed by the optimum route
and profile, but alerts must be posted for each
such traversal.
• 4D Airspace Alerting – Invokes 4D Alert
(CCAAN) functionality, which instructs JetPlan
to allow transversal of “avoid” and “notify-level”
Special Use Airspaces (SUAs), user-defined
airspaces, or Jeppesen turbulence airspaces when
determining an optimum route and profile. Alerts
must be posted for each such traversal. Alerts for
traversal of avoid-level SUAs, user-defined
airspaces, or Jeppesen turbulence airspaces must
be distinguishable from alerts for traversal of
notify-level SUAs, user-defined airspaces, or
Jeppesen turbulence airspaces.
• None – Ensures JetPlan does not invoke 4D
Avoid and/or Alert (CCAA/CCAAN)
functionality.
NOTE For additional information, see the “4D Avoid
and Alert Restrictive Airspaces” chapter in the JetPlan
User Manual.
Use Fine Grid for 4D Airspace Avoidance When this option is selected together with the CCAA
(CCAAF) option, the system uses a finer latitude/longitude grid
for avoidance of “avoid-level” airspaces when “D”
routing has been specified on the flight plan.
User Manual.

1109
Scenario Database
Database Parameters
Pre-qualify Optimized Route As Needing 4D NOTE This parameter is not used with the following
Airspace Avoidance Optimization Type: Trajectory Optimized RAD
Compliant Route Selection.
(CCAAQ)
When this option is selected together with the CCAA
option, the system computes the route from the POA
to the POD, looking for any avoid-level SUA, user-
defined, or Jeppesen turbulence airspace incursions. If
such an incursion occurs, the system automatically
reruns the flight plan as a CCAA plan.
User Manual.
Produce Error if Route Selection Fails Due to 4D NOTE This parameter is not used with the following
Airspaces Optimization Type: Trajectory Optimized RAD
(AVDERR)
When this option is selected together with the CCAA
option, JetPlan alerts the user when JetPlan cannot
find a valid route due to incursions of avoid-level
SUAs and/or user-defined airspaces, and/or Jeppesen
turbulence airspaces. The system also lists the specific
route segment and airspace name for each incursion.
User Manual.

1110
Scenario Database
Database Parameters
Suppress Airspace Incursion Alerts Invokes CCAA/CCAAN functionality with specific
(EXSS: Suppress when on a SID or a STAR) exceptions.
(EXCD: Suppress on segments prior to TOC or after Input options are:
TOD) • When on a SID or STAR – When this option is
selected together with the CCAA or CCAAN
option, standard CCAA and CCAAN
functionality applies except that alerts for
traversal of SUAs are suppressed for any
segment that is part of a SID or STAR.
• On segments prior to TOC or after TOD – When
this option is selected together with the CCAA or
CCAAN option, segments that start before Top
of Climb (TOC) or end after Top of Descent
(TOD) are not checked for incursions of Generic
Restrictive Airspaces.
• Never – Ensures that JetPlan does not suppress
airspace alerts for incursions of SIDS and
STARS or on segments prior to TOC or after
TOD.
Information Only – Does Not Affect Flight Plan Indicates the plan should not be selected as the best
Ranking plan as the results are for information purposes only.
(INFO) Input values: Yes/No
Millibar Levels – Max 9, Comma Separated NOTE This parameter is not used with the
Optimization Type options (see above).
(MB/xxx[,xxx])
This parameter enables you to specify Millibar (mb)
levels for the scenario.
Input value: Maximum of nine comma-separated mb
entries in following format: xxx,xxx,xxx.
Profile This parameter enables you to enter a flight profile.

(PRF) Input value: Valid flight rule and altitude control
entry.
Example: I,100,400
NOTE For additional information, see the “Profile
NOTE This value is only used if the route does not
begin with RT/.

1111
Scenario Database
Database Parameters
RAD Ignore NOTE This parameter is applicable only when the
Trajectory Optimized RAD Compliant Route Selection
Optimization Type option has been selected.
This parameter enables you to instruct JetPlan to
ignore specific European Route Availability
Document (ERAD) rules for this scenario.
Input value: Name of rule(s) to ignore. Example:
EHAM1002B EFAKE
Secondary Format This parameter enables you to enter the name of a

(FMT) secondary format.
Input value: Format name, up to four alphanumeric
characters
Allow Time Restricted Airways This parameter controls the use of time-restricted
(AX/NX) airways. When the parameter is set to Yes, time-
restricted airways are allowed. When the parameter is
set to No, time-restricted airways are not allowed.
Input values: Yes/No
Use National Route Program NOTE This parameter is not used with the following
Optimization Type: Trajectory Optimized RAD
(NRP/NONRP)
This parameter controls the use of National Route
Program (NRP) routing. When the parameter is set to
Yes, use of NRP is allowed. When the parameter is set
to No, use of NRP is not allowed.
Tanker Flight Plan When set to Yes, this parameter defines the scenario
(TKR) as a tanker flight plan and allows for these additional
input values:
• Generic Aircraft – Up to four alphanumeric
characters. Example: 777A
• Payload – Up to six digits
• Departure Weight – Up to six digits
• Reserve Fuel – Up to six digits

1112
Scenario Database
Database Parameters
Restricted Area Name NOTE This parameter is not used with the
Optimization Type options (see above).
This parameter enables you to specify a restricted area
type, as you would in a flight plan request. The
following types are allowed:
• Delineated boundaries (polygonal and circular)
• Route structure elements (FIR/UIR boundaries,
airways, and checkpoints)
• Customer Restricted Area Database records
Input value: A valid restricted area value. Up to 60
characters are allowed.
Example: XIR=UHPP
NOTE For detailed information on valid restricted
area input values, see the “Restricted Area
Route Input This parameter enables you to enter a route string.

Input value: Up to 480 characters
NOTE For information on route syntax, see the
“Route Commands” chapter in the JetPlan User
Manual.

1113
Scenario Database
Database Management
Database Management

To use the Scenario Database when flight planning, you must first create records in the
database. To do this, you need to access the database. In the JetPlan command-line interface
the Scenario Database access command is SDB, and it is entered on the Options command
line. The access command always precedes a function command. Function commands are
those inputs that instruct JetPlan to store, change, delete, or display information in the
database.
File Maintenance
File Display
Scenario Database Commands

The Scenario Database function commands are divided into two categories: file maintenance
and file display. This section describes each function command.

1114
Scenario Database
Database Management

Table 43-2 Scenario Database File Maintenance Commands
Command Description
SDB,SAV The create and save command SDB,SAV provides the means for initially building and
storing a new Scenario Database record. Specify the airports (POD and POA), the file name,
and the options to be included in the record.
EXAMPLE:
01 OPTIONS SDB,SAV,KLAX,RKSO,LAXKSO,AX
05 RESTRICTED AREA XIR=UHPP
06 ROUTE J/P/J,KCC
20 COMPUTING 19978
SCENARIO SAVED
REQUEST NO. 19978
SDB,CHG The modify command SDB,CHG provides the ability to affect changes on SDB records that
already exist.
EXAMPLE:
01 OPTIONS SDB,CHG,KLAX,RKSO,LAXKSO,NX
05 RESTRICTED AREA <RETURN>
06 ROUTE GO
20 COMPUTING 19980
SCENARIO SAVED
REQUEST NO. 19980

1115
Scenario Database
Database Management
Table 43-2 Scenario Database File Maintenance Commands (continued)
Command Description
SDB,DEL The delete command SDB,DEL can be applied to individual records, to multiple records
(using wild card entries), or to the entire database.
EXAMPLE:
Explanation: This input deletes the matching record.
01 OPTIONS SDB,DEL,KLAX,RKSO,LAXKSO
EXAMPLE:
Explanation: This input deletes all records with matching POD and POA.
01 OPTIONS SDB,DEL,KLAX,RKSO,$
EXAMPLE:
Explanation: This input deletes all entries with matching POD’s, no matter what the POA or
name of the SDB record is.
01 OPTIONS SDB,DEL,KLAX,$,$
EXAMPLE:
Explanation: This input deletes all entries with matching POA.
01 OPTIONS SDB,DEL,$,RKSO,$
EXAMPLE:
Explanation: This input deletes all entries with matching names.
01 OPTIONS SDB,DEL,$,$,LAXKSO
EXAMPLE:
Explanation: This input deletes all entries in the SDB.
01 OPTIONS SDB,DEL,ALL

1116
Scenario Database
Database Management

Table 43-3 Scenario Database File Display Commands
Command Description
SDB,PRI The print command SDB,PRI is the only output display command available. However, all of
the options are the same as the delete command. When displaying the records, the route
inputs are displayed as well.
EXAMPLE:
Explanation: This input displays the matching record.
01 OPTIONS SDB,PRI,KLAX,RKSO,LAXKSO
EXAMPLE:
Explanation: This input displays all records with matching POD and POA.
01 OPTIONS SDB,PRI,KLAX,RKSO,$
EXAMPLE:
Explanation: This input displays all entries with matching POD’s, no matter what the POA
or name of the SDB record is.
01 OPTIONS SDB,PRI,KLAX,$,$
EXAMPLE:
Explanation: This input displays all entries with matching POA.
01 OPTIONS SDB,PRI,$,RKSO,$
EXAMPLE:
Explanation: This input displays all entries with matching names.
01 OPTIONS SDB,PRI,$,$,LAXKSO
EXAMPLE:
Explanation: This input displays all entries in the SDB.
01 OPTIONS SDB,PRI,ALL

1117
C HAPTER 44
Customer Schedule
Database
Customer Schedule Database
Overview
Overview
JetPlan’s Customer Schedule Database (CSDB) provides a way to create, store, and maintain
files containing flight plan requests. It helps in the planning process by eliminating the need to
repeatedly re-enter the required and optional inputs of standard flight plan requests. The files
you create can save you valuable planning time for those flights that are out of the ordinary.
The CSDB allows you to create a flight plan request in the same manner that you normally
would using JetPlan. However, instead of immediately submitting the request for computation,
you store it in the database for use at another time. This is particularly useful for flights that are
repeated on a regular basis.
With the CSDB, you can store completed or partially completed flight plan requests. You can
defer those inputs that might be variable or currently unknown, and enter them when known or
at the time that you submit the file to compute the flight plan.
NOTE The CSDB is intended to relieve you from the monotony of repeated inputs.
However, Jeppesen recommends that you have a firm understanding of the JetPlan
request set (those inputs that create a flight plan request) before you use the CSDB.

1121
Interaction Between the CSDB and the Customer Aircraft Database
Interaction Between the CSDB and the

The CSDB interacts with the Customer Aircraft Database (CADB) in certain ways with regard
to biases and taxi fuel. Consider the following rules when applying CADB files to CSDB files:
• Bias Rules – The following rules apply to the interaction of aircraft database
biases with schedule database biases. You must observe these distinctions
when storing biases in a schedule file.
– When a CSDB file contains a CADB file as the aircraft type input,
the CADB file bias settings override any biases built into the
schedule file. This is true even when the CADB file has no bias
parameters set. The mere lack of bias settings in the CADB
overrides any biases stored in the CSDB file.
• Taxi Fuel Rules – Departure and arrival taxi fuel values stored in a schedule
file override all default taxi fuel values, including those stored in a CADB
file.

1122
Database Management
Database Management

To make the CSDB a data resource for flight planning, you must first create and manage
records of information in the database. To do this, you need to access the database. The CSDB
access command is SC, and you enter it on the Options command line. Any attempt to affect or
reference the information in the database must begin with this command.
CSDB functions are divided into two categories: file maintenance and file display. These
categories are listed below with the respective functions.
File Maintenance
File Display
• PRI – Displays the content of a record
• SUM – Displays a list of records (by name)
A database record is referenced by its file name. A CSDB file name can be any string of
alphanumeric characters that helps you identify the record. The file name cannot exceed 12
characters. It typically follows the function command when performing a file maintenance
action.

1123
Database Management
CSDB Commands
The CSDB functions are divided into two categories: file maintenance and file display. These
commands are described below.

Table 44-1 CSDB File Maintenance Commands
Command Description
SC,SAV The SAV command allows you to create a new record of information in the database.
Example:
01 OPTIONS SC,SAV,FILENAME
When you create a new CSDB file, you can add an expiration or effective date to the record.
This allows you to set a period of usefulness for the file or defer its use for a while. All date
entries must adhere to the following format: DDMMYY; where DD is the day input (01-31),
MM is the month input (01-12), and YY is the year input. The expiration date input always
precedes the effective date. Commas separate the two inputs.
Example:
01 OPTIONS SC,SAV,FILENAME,311204,101002
If you choose to omit the expiration date, but still include an effective date, you must show
the omission of the expiration date by entering consecutive commas before the effective
date input.
Example:
01 OPTIONS SC,SAV,FILENAME,,101002
Once the SAV command is entered, you must then enter the flight plan inputs. You can defer
an input by entering the dollar symbol ($) in lieu of an actual value.
The following notes apply to using the dollar symbol ($) to defer an input:
• If the A/C Type command line is deferred (the dollar symbol, $, is entered in place of a
Customer Aircraft Database [CADB] file), you must address those items normally
provided for by a CADB file (Performance Index, Departure Bias, and Arrival Bias).
How you address these items is up to you. You can enter values or defer the answers to
these items to a later time.
• If an A/C Type value is entered (a CADB file is specified) and a Payload value is
entered, JetPlan requires a Reserve fuel entry (for a departure case plan) or a Max Fuel
entry (for an arrival case plan). You enter values for these items or defer them.

1124
Database Management
Table 44-1 CSDB File Maintenance Commands (continued)
Command Description
SC,SAV The following examples illustrate the creation of a CSDB file. The first two examples
(continued) demonstrate the inclusion of a CADB file input for both a departure and an arrival case
flight plan (note the RES and MVR inputs respectively). The last example defers the A/C
Type input, meaning the information normally provided by the CADB file must now be
addressed with either a valid input or the dollar symbol ($).
The following is an example of inputs for a departure weight case flight plan:
01 OPTIONS SC,SAV,SEL-JFK,311208
02 POD RKSS/RJAA,TX1700
03 POA KJFK/PACD
06 ROUTE J,SEL,KAE,JEC/P/J
07 HOLD,ALTERNATE/DIST 30,KPHL
08 ETD 0130
09 PROFILE C
14 PAYLOAD ZW
17 RESERVE $
The following is an example of inputs for an arrival fuel case flight plan:
01 OPTIONS SC,SAV,NRT-LAX,311208
02 POD RJAA/RJCC/PACD,TX1500
03 POA KLAX/PACD/KSFO
06 ROUTE RT/ALL
07 HOLD,ALTERNATE/DIST 30,KLAS
08 ETD 1025
09 PROFILE I
14 PAYLOAD 100000
17 MAX FUEL $
The following example defers the Route, Hold, and Aircraft inputs.
01 OPTIONS SC,SAV,JFK-ANC,311208
02 POD KJFK
03 POA PANC
06 ROUTE $
07 HOLD,ALTERNATE/DIST $
08 ETD 0600
09 PROFILE I
10 A/C TYPE/REGN $
12 PRFM INDEX F
14 PAYLOAD ZW
16 POD OR POA WT AM,I
17 MAX FUEL $
18 CLIMB FUEL,TIME,DIST BIAS <Enter>
19 DESCENT FUEL,TIME,DIST BIAS <Enter>

1125
Database Management
Table 44-1 CSDB File Maintenance Commands (continued)
Command Description
SC,CHG The CHG command allows you to correct, amend, or update a previously created CSDB
file. The command input is similar to the SAV command. Once initiated, you can re-enter
each input or select the specific item to change. To select a specific item, follow these steps:
1. At the 02 POD prompt, enter the “At” symbol (@) followed by the line number of the
item to be modified. JetPlan prompts that command line for your new input value.
NOTE If the POD is the item that you want to change, then enter the new airport identifier.
You are prompted for the next item (03 POA) after you enter the POD. You can then use the
@line# method for the next item or follow the standard sequence of inputs.
2. When all changes are finalized, enter the GO command at your current command line,
and JetPlan executes the modification, and stores the changes in the file.
Example:
Explanation: The file, SEL-LAX, is modified with new route and cruise mode input values.
01 OPTIONS SC,CHG,SEL-LAX
02 POD @6
06 ROUTE J,SEL,KAE/P/J,FIM
11 CRUISE MODE LRC,LRC
12 PRFM INDEX GO
SC,DEL The DEL command allows you to remove files stored in the CSDB.
To delete an individual file, enter the name of the file that you wish to delete after the
SC,DEL command.
Example:
Explanation: Delete the schedule database file, NRT-SJC3.
01 OPTIONS SC,DEL,NRT-SJC3
To delete all files that have expired, enter the option EXP after the SC,DEL command.
Example:
Explanation: Delete all expired schedule files.
01 OPTIONS SC,DEL,EXP

1126
Database Management

Table 44-2 CSDB Database File Display Commands
Command Description
SC,SUM The SUM command instructs JetPlan to display various lists of information from the
database, depending on the option applied.
To display a list of all departure and arrival airports included in the database files stored
under your ID, enter the SC,SUM command.
Example:
Explanation: List every airport that is either a POD or a POA in the database. The dollar
symbol ($) is listed for any deferred POD or POA entries.
01 OPTIONS SC,SUM
To display a list of all schedule files available to or from a particular airport, enter the
identifier of the airport of interest after the SC,SUM command.
Example:
Explanation: List every schedule file that has RJAA as either the POD or the POA.
01 OPTIONS SC,SUM,RJAA
To display a list of all schedule files available to or from deferred airports, enter the dollar
symbol $ after the SC,SUM command.
Example:
Explanation: List every schedule file that has an airport deferment for either the POD or the
POA.
01 OPTIONS SC,SUM,$
or
01 OPTIONS SC,SUM/ALL
To display a list of all schedule files available with a specific airport pair, enter the
identifiers for the POD and POA after the SC,SUM command.
Example:
Explanation: List all schedule files that have VTBD as the POD and LOWW as the POA.
01 OPTIONS SC,SUM,VTBD,LOWW
SC,PRI The function command PRI allows you to display the contents of an individual schedule
file.
To display the contents of a CSDB file, enter the name of the file after the SC,PRI
command.
Example:
01 OPTIONS SC,PRI,LAX-NRT

1127

Using a schedule file to create a computed flight plan differs from the standard method of
computing a flight plan, in that the flight plan command, FP, is replaced with the schedule
database access command, SC. Furthermore, to indicate this is to be a flight plan computation
(rather than some database management action), you must add the function command FLT.
Hence, the command to compute a flight plan using a schedule database file is SC,FLT on the
Options command line. Additional inputs that define the file you wish to apply vary,
depending on the file’s construction (whether deferred inputs exist or not).
Using CSDB Files (Without Deferred Inputs)

To apply a schedule database file that does not contain any deferred inputs, enter the command
SC,FLT followed by the name of the file that you wish to use (and any applicable options) on
the Options command line.
Example:
Explanation: Compute a flight plan using the CSDB file, TRIP313. This example includes a
crew name option, identifying the flight’s captain.
01 OPTIONS SC,FLT,TRIP313,CPT/M. JONES
Using CSDB Files (With Deferred Inputs)

To apply a schedule database file that contains one or more deferred inputs, enter the
command SC,FLT followed by the name of the file that you wish to use (and any applicable
options) on the Options command line. Once you enter the command, you must then enter
values for the items that were deferred in the schedule file.
The following examples illustrate flight plan requests based on schedule files with deferred
input values for various input items. The deferred items must be given input values before you
submit the plans for computation.

1128
Example:
01 OPTIONS SC,FLT,SEL-LAX,.FLT 123/15.
14 PAYLOAD 106000
Example:
01 OPTIONS SC,FLT,SEL-SFO,RC,CS/JDI123,CPT/JS JONES,.FLT 456/16.
06 ROUTE RT/ALL
14 PAYLOAD ZF
Ad Hoc Restricted Area/Restricted Area Database File

You can include an ad hoc restricted area input or a Customer Restricted Area Database
(CRAD) file input in a CSDB flight plan by adding the option RST on the Options command
line. This instructs JetPlan to expect a restricted area input on the Restricted Area command
line.
Example:
01 OPTIONS SC,FLT,CUN-MAD,ETOPX,RST
or
05 RESTRICTED AREA 5700,05000,5700,01000,4800,02000,4800,05000
A CRAD file can also be entered after the RST option on the Options command line. To do
this, add a slash and the file name after the RST option.
Example:
01 OPTIONS SC,FLT,CUN-MAD,ETOPX,RST/XNAT1

1129
Overriding CRAD Files Stored in CSDB Files

If you want to override the inclusion of a CRAD file stored in your schedule file, enter the
option RST as the final entry of your SC,FLT command. When JetPlan prompts for a
restricted area input on the Restricted Area command line, press the ENTER key. This non-
entry overrides the CRAD file stored in your CSDB file.
Example:
01 OPTIONS SC,FLT,NRT-LAX-R001,RST
05 RESTRICTED AREA <ENTER> (continue with deferred prompts, if any)

1130
C HAPTER 45
Customer Controlled
Avoid and Alert
Database
Customer Controlled Avoid and Alert Database
About the CCAA Database

The Customer Controlled Avoid and Alert (CCAA) database is required for the JetPlan 4D
Avoid and Alert feature, which is invoked by the CCAA, CCAAN, CCAAF, ORTRKA, and
ORTRKN flight plan options.
The 4D Avoid and Alert feature governs JetPlan’s behavior when it is:

vertical profile
The CCAA Database allows users to create and manage records that reference pre-defined
restrictive airspace records residing in several source restrictive airspace databases. The pre-
defined restrictive airspace records contain data originating in sources such as an ARINC 424
extract, a customer-provided source, or an online electronic service (for example, organized
track updates or customer or vendor-provided turbulence forecasts). For this reason, these
databases are referred to as “source” restrictive airspace databases. Records in the source
restrictive airspace databases are referred to as “referenced” records, and records in the CCAA
Database are referred to as “referencing” records.
While the CCAA Database does not allow you to alter restrictive airspace records stored in
source restrictive airspace databases, you can set and modify the following two important
parameters in the referencing CCAA Database records:
• Avoid Level – JetPlan uses the avoidance level to determine how to treat the
referenced restrictive airspace when computing a flight plan—as an Avoid
or Notify airspace or as an airspace that can be ignored.
• Special Customer Airspace Type (SCA Type) – The SCA Type is a unique,
user-editable value. You can use the SCA Type to invoke an ad hoc override
of a restrictive airspace’s avoidance level on a specific flight plan request.

1133
Customer Controlled Avoid and Alert Database
You can instruct JetPlan to account for generic, user-defined, Jeppesen turbulence, and
FIR/UIR restrictive airspaces by specifying the CCAA, CCAAN, or CCAAF flight plan
options. You can direct JetPlan to account for organized track restrictive airspaces by
specifying the ORTRKA or ORTRKN flight plan options and geopolitical country restrictive
airspaces by specifying the GCAA or GCAN flight plan options.
For complete information on the 4D Avoid and Alert feature, as well as a full description of
the CCAA Database and the various source restrictive airspace databases, see Chapter 5, “4D
Avoid and Alert Restrictive Airspaces.”
For information on creating and maintaining CCAA and User-Defined Restrictive Airspace
database records, including specifications for all the database parameters, see the JetPlan.com
Help file for the Customer Controlled Avoid and Alert Database page.

1134
C HAPTER 46
User-Defined Restrictive
Airspace Database
User-Defined Restrictive Airspace Database
About the User-Defined Restrictive Airspace Database
About the User-Defined Restrictive

Airspace Database
The User-Defined Restrictive Airspace Database is one of the source restrictive airspace
databases referenced by the Customer Controlled Avoid and Alert (CCAA) Database. The
CCAA Database is used by the JetPlan 4D Avoid and Alert feature, which governs JetPlan’s
behavior when it is:

vertical profile
The CCAA Database is initially populated and subsequently updated through automatic
reconciliation with several source restrictive airspace databases, including the User-Defined
Restrictive Airspace Database. A customer-authorized user can use the “User-Defined
Restricted Areas” options on the Customer Controlled Avoid and Alert Database page in
JetPlan.com to set up restrictive airspaces and define their vertical and lateral boundaries,
operational times, and avoidance levels. Once created, a user-defined restrictive airspace
record is automatically referenced by a record in the CCAA Database, where the information
is accessible for flight planning with the 4D Avoid and Alert flight plan options.
For complete information on the 4D Avoid and Alert feature, as well as a full description of
the CCAA Database and the various source restrictive airspace databases, see Chapter 5, “4D
Avoid and Alert Restrictive Airspaces.”
For information on creating and maintaining CCAA and User-Defined Restrictive Airspace
database records, including specifications for all the database parameters, see the JetPlan.com
Help file for the Customer Controlled Avoid and Alert Database page.

1137
C HAPTER 47
Weather Introduction
Overview
Overview
Jeppesen's aviation weather service provides worldwide weather information to airlines,
corporate flight departments, government agencies, and individual users. The following types
of weather products are available:
• Text weather reports

• High-resolution graphic weather maps
• Worldwide infrared and visible satellite imagery
• NEXRAD radar imagery
Subscribers can access briefings and charts through various JetPlan user interfaces such as
JetPlanner, Jeppesen Dispatch Control, and JetPlan.com or by ARINC/SITA message.
Jeppesen provides you with the capability to receive, store, manipulate, and retrieve weather
information so that you can tailor briefings to your specific operational requirements.
Jeppesen's professional meteorologists analyze current worldwide weather information
consisting of satellite imagery, radar analyses, surface and upper air weather observations, and
numerical prognoses on a 24 x 7 basis to produce the most accurate weather maps possible. All
of Jeppesen's weather information conforms to the recommended practices contained in ICAO
Annex 3/WMO Technical Regulations, Chapter 9, and are in compliance with FAR 91, 121,
and 135.
Jeppesen receives text weather reports from the U.S. National Weather Service (NWS) and the
U.K. Met Office. Custom forecasting is available for those locations that do not provide
Terminal Forecasts over the above mentioned weather sources. This text weather information
is available on a global basis. Jeppesen also uses a weather workstation and staff
meteorologists to create a variety of graphic weather maps. Jeppesen receives weather
information from the NWS, the U.K. Met Office, and private weather companies, allowing us
to provide innovative aviation-specific weather maps.
Jeppesen's meteorologists are available for consultations and verbal weather briefings 24
hours a day. If you need assistance or have any questions concerning weather data, contact our
meteorology department at 1-408-963-2000 or 1-877-537-7487.

1141
Weather Commands and Options

This section lists and explains all of the JetPlan Options command line choices available for
retrieving weather information from Jeppesen.
Respond to all questions that the system prompts when requesting weather information.
NOTE Press the ENTER key after each question has been answered.
ENTER ID Not a weather service question, but an important prompt during the
logon procedure. With some access methods the ID is a pre-stored
and automatic input.
ENTER Not a weather service question, but an important prompt during the
PASSWORD logon procedure. With some access methods the Password is a pre-
stored and automatic input.
01 OPTIONS Specify WX and any weather option command. WX is a mandatory

weather request command. The Options command line choices listed
below can be combined in any order following the mandatory “WX”
entry on the Options command line.
User inputs after 01 OPTIONS prompt:
Table 47-1 Weather Commands and Options
Command/Option Explanation/Description
WX Weather request - mandatory command to request any
type of weather, text or graphic, information.
WX,CO Compresses weather information or removes line returns

within a weather brief. This helps to reduce the length of
a briefing when forwarding weather information to
stations.
WX,NH Provides weather data only without header on the

printout.
WX,.xxxxxxxxxxxx. Twelve spaces between periods are available to print a

heading in the top line of the weather briefing.

1142
Table 47-1 Weather Commands and Options (continued)
Command/Option Explanation/Description
WX####[,####][,####][,####]... Weather request appended to one or more flight plans (or
messages) already calculated.
EXAMPLE:
WX1234
or
WX1234,3456,6789
WXE####[,####][,####][,####]... Recall Enroute Weather for one or more flight plans

already calculated. This information provides a full
enroute briefing. A copy is attached to the bottom of the
fight plan.
EXAMPLE:
WXE1234
or
WXE1234,3456,6789
INFO,METAR Information to decode a METAR.
INFO/TAF Information to decode a TAF.
02 STATIONS Specify stations and weather report types that you require. All
weather information is only available in the format provided by the
NWS or U.K. Met Office. Weather information for up to 16
stations/airports can be retrieved in one request.
All locations: Either the three-letter IATA station identifier or the

four- letter ICAO station identifier can be used to retrieve METARs
and TAFs.
Three different methods can be used to request non-graphic weather reports:
1. Specify the NWS report type after the station identifier(s). Use SA for MET
AR's, and FT for TAFs.
Example:
02 STATIONS LAX SA,SFO FT,RJAA NO
2. Specify the Jeppesen multiple report code after the station identifier(s):
Example:
02 STATIONS LAX 1,SFO 0,RJAA 4,WSSS 5

1143
3. Specify the NWS report type, followed by a series of station identifiers.

More than one report type can be included in this type of request. More than
one series of reports can be requested, and other request types can precede
or follow a series of requests.
Example:
02 STATIONS SA6 RKSS RKSM,FD RKSS
RJAA,RJAA,RJTT,RJCC,KWBC UAPA
(Requests the last 6 hours of METARs for RKSS and RKSM; the
winds/temps aloft forecasts for RKSS and RJAA; TAFs and METARs for
RJAA, RJTT, and RJCC; and PIREPs for the Pacific as covered by HNL
and OAK.)

1144
Quick Reference Information
Hourly Reports, Special Observations, and Terminal

Forecasts
Example:
02 STATIONS KJFK,YQX,BIKF,EINN
Single Report Types

Example:
02 STATIONS FT KJFK KMIA CYQX EGKK RJAA
Table 47-2 Single Report Types
Report Code
Surface Observations (METARs) SAa
Area Forecast FA
Terminal Forecast (TAFs) FT/FC/FT1/FC1
Winds and Temperatures Aloft FD
NOTAMs NO
PIREPs UA
SIGMETs (All) WS
AIRMETs WA
Convective Outlook AC
Severe Weather Warnings WW
Severe Weather Alert AW
Typhoon Reports WT
Hurricane Reports WT
High Surf Advisory WO
Radar Reports SD
Short-term European TAFs FC

1145
Table 47-2 Single Report Types (continued)
Report Code
Recall current and previous TAFs FT1
Recall current and previous short-term TAFs FC1
a.METAR reports can be requested for the latest observation and

up to 24 hours in the past. Using a number after the code SA indi-
cates how many past hours worth of METAR observations you are
requesting. For example, SA0 would only provide the most recent
observation. SA12 would provide the past 12 hours of METAR
observations. If SA is entered without a number, the default is the
last 3 hours.
Multiple Reports/Complete Briefings

Example:
02 STATIONS KJFK 1, KMIA 3, CYQX 0
Table 47-3 Multiple Reports Codes
Report Types Code Level

All Reports 0
TAF, METAR, NO 1
TAF, METAR, NO, UA, FD 2
TAF, METAR, NO, UA, AC, AW, WA, WO, WS, WT, 3
WW
UA, FD 4
TAF, METAR, UA, FD 5
TAF, METAR, UA, AC, AW, WA, WO, WS, WT, 6

WW, FD
AC, AW, WA, WO, WS, WT, WW 7
UA, AC, AW, WA, WO, WS, WT, WW 8
FD, UA, AC, WA, WS, WT, WW 9

1146
Great Circle Weather Briefing

Example:
02 STATIONS G/JFK-MIA
- or -
02 STATIONS G/KJFK-EBBR

1147
C HAPTER 48
Text Weather
Text Weather
Overview
Overview
Text weather is available through various JetPlan user interfaces such as JetPlanner, Jeppesen
Dispatch Control, and JetPlan.com or via SITA/ARINC.
Types Of Weather Reports

You can retrieve a variety of text weather reports through the Jeppesen Weather Service. Each
type of report has a unique code to identify the specific request. This section reviews all of the
available report types and the associated codes.
Terminal Forecasts And Surface Observations

To request current station forecasts (TAF) and the last two hours of surface observations
(METARs) plus special reports (SPECI), enter the station's ICAO or IATA identifier on the
Stations command line. ICAO or IATA identifiers can be used for both U.S. and International
stations. If more than one station is requested, separate each station identifier by a comma.
Example:
01 OPTIONS WX
02 STATIONS OEJN,LFPG,EINN,CYYR,YYZ,ORD
Surface Observations And Special Reports

The NWS code for surface observations is SA. To request the last two hours of METARs, plus
any SPECI reports, enter the station's ICAO identifier, a space, and SA on the Stations
command line. If more than one station is requested, separate each request with a comma. Or,
enter SA followed by a space and one or more station identifiers, each separated with a space.
If more than the last two hours of METARs are desired, input the number of hours desired
after SA. This feature allows up to the last 24 hours of observations to be output. If more than
one station is desired, separate each station by a space.
Example:
01 OPTIONS WX
02 STATIONS EDDF SA,EGLL SA,KJFK SA,BOS SA
- or -

1151
Text Weather
02 STATIONS SA EDDF EGLL KJFK BOS
- or -
02 STATIONS SA12 EDDF EGLL KJFK BOS
Regional Reports
Regional Surface Observations (METARs)

Regional surface observations (METARs) are obtained by specifying the NWS weather
bulletin code BU, a slash, and the area number. A list of codes and the associated areas
covered is provided below.
Table 48-1 NWS Weather Bulletins: Regional Surface Observations (METARs)
Bulletin Area Bulletin Area

BU/200 New England States BU/210 Southwestern States
BU/201 Eastern States BU/211 Pacific NW States
BU/202 Mid-Atlantic States BU/212 Pacific States
BU/203 Southeastern States BU/213 Western Military Bases
BU/204 Great Lakes States BU/214 Eastern Military Bases
BU/205 Ohio Valley BU/215 Eastern Canada
BU/206 Northern Plains BU/216 Western Canada
BU/207 Great Plains States BU/217 Mexico and Caribbean
BU/208 Gulf Coast States BU/290 Alaska
BU/209 Northern Rockies BU/291 Hawaii
Example:
01 OPTIONS WX
02 STATIONS BU/201,BU/205

1152
Text Weather
Terminal Forecasts (TAFs)

To obtain regional Terminal Forecasts (TAFs), use the following NWS weather bulletin
number.
Table 48-2 NWS Weather Bulletins: Regional Terminal Forecasts (TAFs)
Bulletin Area Bulletin Area

BU/246 New England States BU/255 Northern Rockies
BU/247 Eastern States BU/256 Southwestern States
BU/248 Mid-Atlantic States BU/257 Pacific Northwest States
BU/249 Southeastern States BU/258 Pacific States
BU/251 Ohio Valley BU/259 Eastern States
BU/252 Northern Plains BU/260 Western States
BU/253 Great Plains States BU/292 Alaska
BU/254 Gulf Coast States BU/293 Hawaii
Example:
01 OPTIONS WX
02 STATIONS BU/246,BU/255
In addition, the following stations provide hourly weather reports in the Mexico region.
Table 48-3 Mexico Region: Hourly Reports
City Station City Station

Mexico City MMMX Cozumel MMCZ
Guadalajara MMEX Durango MMDO
Hermosillo MMHO Torreon MMTC
La Paz (Baja) MMLP Veracruz MMVR
Mazatlan MMMZ Nuevo Laredo MMNL
Monterrey MMMY Guaymas MMGM
Chihuahua MMCU Merida MMMD
Culiacan MMCL Tampico MMTM
Cancun MMUN Tijuana MMTJ
Puerto Vallarta MMPR Manzanillo MMZOD.

1153
Text Weather
Terminal Forecasts
The NWS code for terminal forecasts is FT. To request the current station forecast (TAF)
information, specify the station's ICAO identifier, a space, and FT on the Stations command
line. If more than one station request is needed, separate each request by a comma. Another
entry method is to specify FT followed by a space and one or more station identifiers. Separate
each station identifier with a space.
NOTE To specify both a current and previous TAF, use the command FT1.
Example:
01 OPTIONS WX
02 STATIONS CYYR FT,BIKF FT,EINN FT
- or -
02 STATIONS FT CYYR BIKF EINN
Area Forecast
The NWS code FA provides Area Forecasts. The stations listed after the examples all provide
area forecast information. (The entries in parentheses indicate special function sites.)
Example:
01 OPTIONS WX
02 STATIONS SFO FA,YYZ FA,MMMX FA
- or -
02 STATIONS FA SFO YYZ MMMX
Table 48-4 United States: Area Forecast Stations
Area Station
West Coast SFO
Rocky Mountains SLC
Great Lakes CHI
South Gulf Coast DFW
Florida MIA

1154
Text Weather
Table 48-4 United States: Area Forecast Stations (continued)
Area Station
New England BOS
Anchorage ANC
Fairbanks FAI
Juneau JNU
Hawaii PHFO
Table 48-5 International: Area Forecast Stations
Area Station
Southern Brazil SBBR
South Pacific NFFN
Trinidad Tobago TTPP
Caribbean and Gulf of Mexico KKCI
Mexico MMMX
Bahamas MYNN
NOTAMs - Jeppesen NOTAM Service

To retrieve various NOTAM information, use the following codes on the Stations command
line.
Table 48-6 NOTAM Codes
Format Code
Jeppesen's NOTAM format NO
ICAO NOTAM format NOI
FIR/UIR Jeppesen's NOTAM format NOF
FIR/UIR ICAO format NOFI

1155
Text Weather
Example:
01 OPTIONS WX
02 STATIONS LAX NO,DEN NOI,EBBU NO,LFPG NOI
- or -
02 STATIONS NO LAX DEN EBBU LFPG
- or -
02 STATIONS EBBU NOF, EBUR NOFI
- or -
02 STATIONS NOF EDLL EBBU SAEF
The following is a list of electronic source NOTAMs and paper source published NOTAMs
contained in official publications available through the Jeppesen NOTAM Service.
• ICAO International Class I/System NOTAMs

• U.S. “D” NOTAMs
• U.S. FDC NOTAMs
• U.S. Military NOTAMs
• SNOWTAMs
• ICAO International Class II NOTAMs
• Aeronautical Information Publications (AIP)
• AIP Supplement
• Aeronautical Information Circular (AIC)
• U.S. Airport Facility Directory (AF/D)
• U.S. National Flight Daily Digest (NFDD)
• U.S. International Notices To Airmen
• U.S. Notices to Airmen

1156
Text Weather
Winds and Temperatures Aloft

The NWS code for winds and temperatures aloft is FD. To request winds and temperatures
aloft information, specify the station's identifier, a space, and FD on the Stations command
line. If more than one station is requested, separate each request by a comma. Another entry
method is to specify FD followed by a space and one or more station identifiers. Separate each
station identifier with a space. The standard winds and temps aloft report provides winds and
temps forecast for winds between 6,000 ft and 39,000 ft. The forecast uses NWS GRIB
numerical forecast data from the global GFS model, which is the same model used to provide
winds and temps in the JetPlan flight planning system.
Example:
01 OPTIONS WX
02 STATIONS LAX FD,DEN FD,JFK FD
- or -
02 STATIONS FD LAX DEN JFK
- or -
02 STATIONS KLAX FD,KDEN FD,EBBR FD,RJAA FD
- or -
02 STATIONS FD KLAX KDEN EBBR RJAA
Jeppesen winds and temperatures aloft are derived using GRIB numerical forecast data that is
interpolated to the airport location. The standard wind and temperature format provides for
altitudes between FL060 and FL390. Jeppesen also provides a low-level format (FDL) that
provides winds and temperatures from FL030 to FL240, as well as a high level format (FDH)
that provides winds and temperatures from FL120 to FL500.
To obtain-high altitude forecast winds and temperatures between 12,000 and 50,000 ft., use
the code FDH in place of FD.

1157
Text Weather
Example:
01 OPTIONS WX
02 STATIONS KLAX FDH,EBBR FDH,RJAA FDH
- or -
To obtain low altitude forecast winds between 3,000 and 24,000 ft, use the code FDL in place
of FD.
02 STATIONS FDL KLAX EBBR RJAA
Pilot Reports - PIREPs
U.S. PIREPs
The NWS code for U.S. PIREPs is UA. To access PIREPs, enter the IATA or ICAO airport
identifier followed by the UA code. If listing multiple stations, separate each station request
with a comma. Another entry method is to specify the code first followed by one or more
stations with a space separating each entry.
Example:
01 OPTIONS WX
02 STATIONS LAX UA, DEN UA, KJFK UA
- or -
02 STATIONS UA LAX DEN JFK

1158
Text Weather
SIGMETs
SIGMETs, AIRMETs - U.S.

The NWS code for SIGMETs is WS. The NWS code for AIRMETs is WA. Enter the IATA
three-letter airport identifier followed by the appropriate NWS code to receive SIGMET
and/or AIRMET information. Reports are available in the U.S. for the following areas.
Table 48-7 United States: SIGMET/AIRMET Stations
AREA STATION AREA STATION

West Coast SFO Northeast U.S. BOS
Inter-Mountain West SLC Fairbanks FAI
Great Lakes and CHI Anchorage ANC

Great Plains
Southern Plains DFW Juneau JUN
Southeast U.S. MIA
Example:
01 OPTIONS WX
02 STATIONS SLC WS, CHI WA
Convective SIGMETs - U.S.

Convective SIGMETs (NWS code: WS) are available for the following U.S. areas.
Table 48-8 United States: Convective SIGMET Stations
AREA STATION
Central U.S. KKCI WSUS32
Western U.S. KKCI WSUS33
Eastern U.S. KKCI WSUS31
Example:
01 OPTIONS WX
02 STATIONS KKCI WSUS31

1159
Text Weather
Convective Outlook - U.S.

The NWS code for a convective outlook is AC. A convective outlook report is available for
the United States through the following station only.
Table 48-9 United States: Convective Outlook Stations
AREA STATION
United States KWNS
Example:
01 OPTIONS WX
02 STATIONS KWNS AC
SIGMETs - Atlantic, Pacific, Caribbean and Canadian

Areas
To recall the latest significant weather for Atlantic, Pacific, Caribbean and Canadian areas, use
the NWS code for SIGMETs (WS). The following stations are available for reports.
Table 48-10 Atlantic, Pacific, Caribbean, and Canadian: SIGMET Stations
Area Station Area Station

Caribbean Area KMIA Eastern Quebec CWXK
Eastern Pacific Area KSFO Western/Northern Quebec CWUL
North Atlantic Area KJFK Ontario CWTO
Caribbean Area TJSJ Manitoba/Saskachewan/Alberta CWEG
Central Pacific Area PHNL Northern Territory/Arctic CWNT
Canadian Maritimes CYQX British Columbia/Yukon CWLW
Example:
01 OPTIONS WX
02 STATIONS TJSJ WS, CYXY WS

1160
Text Weather
Severe Weather Watches and Warnings

The NWS code for Severe Weather Warnings is WW. Severe Weather Watches and
Warnings, as posted by NSSFC, are available for the United States through the following
station.
Table 48-11 United States: Severe Weather Watches and Warnings Stations
Area Station
United States KWNS
Example:
01 OPTIONS WX
02 STATIONS KWNS WW
In addition, Severe Weather Warnings (WW) for other regions are available by specifying the
following stations.
Table 48-12 Other Regions: Severe Weather Warnings Stations
AREA STATION
North Atlantic, Gulf of Mexico and Caribbean for KWBC
Tropical Storms
Western Pacific for Tropical Storms PGTW
Japan and Western Pacific Area for Tropical Storms RJTD
Example:
01 OPTIONS WX
02 STATIONS KWBC WW, RJTD WW
Typhoon, Hurricane Reports

The NWS code for typhoon and hurricane activity information is WT. Reports are available
for the following areas.
Table 48-13 Other Regions: Typhoon and Hurricane Report Stations
AREA STATION
Central Pacific PHNL
Philippines RPMM
Western Pacific PGTW

1161
Text Weather
Table 48-13 Other Regions: Typhoon and Hurricane Report Stations
AREA STATION
South Pacific NFFN
Eastern Pacific, Western Atlantic, Gulf of Mexico and Caribbean KNHC
Example:
01 OPTIONS WX
02 STATIONS KNHC WT, PHNL WT
Volcanic Ash Reports

The NWS code for volcanic ash information is FV. Reporting stations are Volcanic Ash
Advisory Centers (VAACs). Reports are available for the VAACs and areas listed in
Table 48-14.
Table 48-14 Other Regions: Volcanic Ash Report Stations
VAAC AND AREA STATION

Washington: United States, Mexico, Hawaii, Central America, and the KNES
Caribbean
Anchorage: Alaska PAWU
Montreal: Canada and Greenland CWAO
London: Iceland and the United Kingdom EGRR
Toulouse: Europe, Middle East, and Africa LFPW
Buenos Aires: South America SABM
Wellington: New Zealand and the South Pacific NZKL

Darwin: Australia and Indonesia ADRM
Tokyo: Western Pacific and Asia RJTD
Example:
01 OPTIONS WX
02 STATIONS RJTD FV

1162
Text Weather
NWS Meteorological Forecast Discussion

The NWS code FP provides the public forecasts for U.S. stations that have NWS forecast
offices. Information includes a short term forecast, a long term forecast, maximum and
minimum temperatures for up to three days, and the chance of precipitation.
Example:
01 OPTIONS WX
02 STATIONS BOU FP
NWS Offshore Marine Forecast

The NWS code FZ provides the public forecasts for coastal U.S. stations that have NWS
forecast offices. Information includes marine warnings and advisories.
Example:
01 OPTIONS WX
02 STATIONS MTR FZ
ATC Center Weather Summary

The NWS code which provides weather reports from Air Traffic Control Centers within the
U.S. is the same as the area forecast code. To obtain this information, the Air Traffic Control
Center station identifier must be specified along with the FA code. These reports are known as
Meteorological Impact Statements and are issued by a NWS forecaster stationed within the
ARTCC.
Example:
01 OPTIONS WX
02 STATIONS KZMP FA

1163
Text Weather
Multiple Reports
Multiple report combinations can be obtained through a unique numeric identifier. By entering
the station and the numeric code desired, several reports can be gathered at once while
minimizing keystrokes and time. The report combinations and the associated code numbers
are listed below.
Table 48-15 Multiple Reports Codes
Report Types Code Level

All Reports 0
FT, SA, NO 1
FT, SA, NO, UA, FD 2
FT, SA, NO, UA, AC, AW, WA, WO, WS, WT, WW 3
UA, FD 4
FT, SA, UA, FD 5
FT, SA, UA, AC, AW, WA, WO, WS, WT, WW, FD 6
AC, AW, WA, WO, WS, WT, WW 7
UA, AC, AW, WA, WO, WS, WT, WW 8
FD, UA, AC, WA, WS, WT, WW 9
Example:
01 OPTIONS WX
02 STATIONS SFO 3,MIA 0,DEN 4
Table 48-16 lists the individual reports available and their NWS codes.
Table 48-16 NWS Report Codes
Report Code
Surface Observation (METAR) SA
Area Forecast FA
Terminal Forecast (TAF) FT
Winds and Temperature Aloft FD
NOTAMs NO
PIREPs UA
AIRMETs WA
SIGMETs WS

1164
Text Weather
Table 48-16 NWS Report Codes (continued)
Report Code
Convective Outlook AC
Severe Weather Warning WW
Typhoon/Hurricane Reports WT
Radar Reports SD
Volcanic Ash Reports FV
Meteorological Forecast Discussion FP
Offshore Marine Forecast FZ
Great Circle Weather

The Great Circle weather option provides terminal forecasts, surface observations, PIREPs,
NOTAMs, wind and temperature aloft forecasts, and SIGMETs for enroute stations, departure
airports, arrival airports, and alternate airports.
The enroute segment information directly corresponds to the subset of Great Circle
checkpoints using weather reporting stations located usually within 50 nautical miles of those
checkpoints. The subset of checkpoints that is selected provides an approximately equal
distance between reporting stations. The magnitude of this distance is determined from the
total Great Circle mileage and adequately covers significant geographic variations in current
and forecasted weather.
To enter a great circle weather request, input the letter G, followed by a slash, and the station
identifiers. Use IATA three-letter codes for U.S., Canada, and Mexico stations. Use ICAO
codes for all other stations.
Example:
01 OPTIONS WX
02 STATIONS G/SFO-LAX
- or -
02 STATIONS G/JFK-EBBR
The Great Circle feature automatically incorporates weather information for three reporting
stations closest to the POA airport. However, you can also specify your own alternate stations.

1165
Text Weather
Example:
01 OPTIONS WX
02 STATIONS G/SFO-LAX(ONT+LAS+PSP)
- or -
02 STATIONS G/JFK-EBBR(EHAM+ELLX+LFPG)
The Great Circle feature allows additional text weather briefings to be requested on the same
line.
Example:
01 OPTIONS WX
02 STATIONS G/SFO-LAX,SAN 3,SNA NO
- or -
02 STATIONS G/JFK-EBBR(EHAM+ELLX),LFPG NO,LFPO FD
Weather Enroute
Flight planning users can customize text weather reports along their actual route of flight. The
WXE option provides a user-defined set of reports for terminal and enroute stations. Users can
customize the list of reports by selecting the Databases tab on JetPlan.com and then selecting
the WXE tab. If users do not create their own set of reports, a default set of reports is
provided.
The enroute segment information directly corresponds with a subset of flight plan checkpoints
using weather reporting stations located within approximately 75 nautical miles of those
checkpoints. The checkpoints are selected to provide equal distance separation between
reporting stations. This distance is based on the total flight plan mileage so that the number of
points adequately covers significant geographic variations in current and forecasted weather.
For Point-of-Arrival entries in the United States and Canada, weather for three surrounding
stations within 100 miles is provided when possible.
A flight plan request for the enroute weather can be made by entering WXE after FP on the
Example:
01 OPTIONS FP,WXE

1166
Text Weather
To add enroute weather information to a flight plan that has already been computed, enter
WXE followed by the flight plan transaction number (no space) on the Options command line.
Example:
01 OPTIONS WXE1234
This example requests enroute weather for flight plan number 1234, which was already
computed. Enroute weather can also be appended to multiple flight plans that have been
previously computed by separating the plan numbers with commas.
Example:
01 OPTIONS WXE1234,5678,4567

1167
C HAPTER 49
Graphic Weather
Graphic Weather
Overview
Overview
Jeppesen has a full-service meteorology department that produces and supports a robust
selection of weather maps.
The Jeppesen Weather Service is a 24 x 7 operation that is fully staffed with qualified aviation
meteorologists. It conforms to the recommended practices outlined in the ICAO Annex
3/WMO Technical Regulations (Chapter 9), and it is run in compliance with Federal Aviation
Regulations (FAR 91, 121, and 135).
Our meteorologists utilize every available data source to produce the most accurate and up-to-
date weather maps in the industry today. They develop forecast and analysis maps and use
advanced computer resources to process and disseminate a full line of weather products,
including: NEXRAD radar, GOES, MTSAT, and MeteoSat satellite images, and a wide
variety of other specialty maps.
All weather maps produced by the Jeppesen Weather Service are listed in this chapter. Many
of these maps can be accessed through the JetPlan system, given the proper option codes,
equipment, and/or software. Most of these maps are available through fax forwarding from the
JeppFax® system.
Accessing Weather Maps Through JetPlan

To access the weather maps produced by the Jeppesen Weather Service, you must use a
Jeppesen-provided application, such as JetPlan.com, JetPlanner, or Jeppesen Dispatch
Control. The FF maps codes provided below are used to fax forward a map.
NOTE You can also save the FF code to the Flight Brief database so that it can be
used in EasyBrief. For example, the FF code for the High-level Significant Weather
map for Europe would be EUHISIG12.

1171
Graphic Weather
Weather Maps
Weather Maps
This section provides table listings of all maps available through the Jeppesen Weather
Service. The maps are listed alphabetically by region and are categorized by the type of map
produced (satellite, radar, and so on). The items in the table column, FF CODE, are the
product identifiers for retrieving maps through the JetPlan system using the fax forwarding
option. These codes are relatively new to the JetPlan system; therefore, old product identifiers
are included in parentheses (if applicable). While the old codes are still usable, the new codes
provide many more map options. Either set of codes (old or new) can be specified in a fax
forwarding request to retrieve a map.
Africa
Table 49-1 Type: Satellite (Africa)
Title Description Update FF Code

MeteoSat IR Image Current 12km infrared Every 6 hrs AFSATIR00 (G890)
satellite image
Table 49-2 Type: Surface & Low-level Significant Weather (Africa)

Surface Analysis Current surface analysis Every 6 hrs AFSFCWX00
Surface Depiction Depicts current flight Every hr AFWXDEP00

conditions at selected
airports for Africa
Surface Wx 24 Depicts 24 hour surface Every 12 hrs AFSFCWX24
Hour Forecast weather forecast

conditions
Table 49-3 Type: High-level Significant Weather (Africa)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs AFHISIG12 (NT18)
of significant features
between FL240 and
FL600

1172
Graphic Weather
Weather Maps
Table 49-4 Type: Winds And Temps Aloft (Africa)

FL 050 Wind & Temp AVN wind and Every 6 hrs AFWT05024 (AR85)
Forecast temperature 24 hour
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-5 Type: Aviation Hazards (Africa)

Tropical Cyclone Tracks Depicts current and Every 6 hrs AFHURCN00
forecast positions of
tropical systems

1173
Graphic Weather
Weather Maps
Asia
Table 49-6 Type: Satellite (Asia)

GMS IR Image Current GMS 5km Every hr ASSATIR00 (G841)
infrared satellite image
GMS Visible Image Current GMS 5km Every hr (daylight hrs) ASSATVS00
visible satellite image
GMS IR & Single Site Current GMS 5km Every hr ASSATRA00

Radar Composite infrared satellite and
NEXRAD 2km single
site (Guam) base
reflectivity composite
Table 49-7 Type: Surface & Low-level Significant Weather (Asia)

Surface Analysis Current surface analysis Every hr ASSFCWX00
Surface Depiction Depicts current flight Every hr ASWXDEP00

airports for Asia
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs ASSFCWX24

Forecast weather forecast
conditions
Table 49-8 Type: High-level Significant Weather (Asia)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs ASHISIG12 (AS10)
between FL240 and
FL600

1174
Graphic Weather
Weather Maps
Table 49-9 Type: Winds And Temps Aloft (Asia)

FL 050 Wind & Temp AVN wind and Every 6 hrs ASWT05024
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
FL 340 Wind & Temp AVN wind and Every 6 hrs ASWT34024 (AS25)
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-10 Type: Aviation Hazards (Asia)

Hurricane/Typhoon Depicts current and Every 6 hrs ASHURCN00 (WPWT)
Tracks forecast positions of
tropical systems

1175
Graphic Weather
Weather Maps
Australia
Table 49-11 Type: Satellite (Australia)

GMS IR Image Current GMS 12km Every 3 hrs AUSATIR00 (G843)
GMS Visible Satellite Current GMS 12km Every 3 hrs (daylight AUSATVS00
Image visible satellite image hrs)
Table 49-12 Type: Surface & Low-level Significant Weather (Australia)

Surface Analysis Current surface analysis Every hr AUSFCWX00
Surface Depiction Depicts current flight Every hr AUWXDEP00

airports for Australia
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs AUSFCWX24

conditions
Table 49-13 Type: High-level Significant Weather (Australia)

Significant Wx Forecast Depicts 12 hour forecast Every 12 hrs AUHISIG12 (AP10)
between FL240 and
FL600
Table 49-14 Type: Winds And Temps Aloft (Australia)

FL 050 Wind & Temp AVN wind and Every 6 hrs AUWT05024 (AF85)
forecast at FL 050

1176
Graphic Weather
Weather Maps
Table 49-14 Type: Winds And Temps Aloft (Australia) (continued)

forecast at FL 100
forecast at FL 180
FL 240 Wind & Temp AVN wind and Every 6 hrs AUWT24024
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-15 Type: Aviation Hazards (Australia)

Tropical Cyclone Tracks Depicts current and Every 6 hrs AUHURCN00
tropical systems

1177
Graphic Weather
Weather Maps
Canada
Table 49-16 Type: Satellite (Canada)

GOES IR Image GOES 8km infrared Every 30 min CNSATIR00 (G800)
satellite image
GOES Visible Satellite GOES 8km visible Every 30 min (daylight CNSATVS00 (G900)
Image satellite image hrs)
Table 49-17 Type: Surface & Low-level Significant Weather (Canada)

Surface Analysis Current surface analysis Every hr CNSFCWX00
Surface Depiction Depicts current flight Every hr CNWXDEP00 (CNWX)

airports for Canada
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs CNSFCWX24 (CN03)

conditions
Table 49-18 Type: High-level Significant Weather (Canada)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs CNHISIG12 (CN10)
between FL240 and
FL600
Table 49-19 Type: Winds and Temps Aloft (Canada)

FL 050 Wind & Temp AVN wind and Every 6 hrs CNWT05024 (CF85)
forecast at FL 050

1178
Graphic Weather
Weather Maps
Table 49-19 Type: Winds and Temps Aloft (Canada) (continued)

forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-20 Type: Aviation HazardS (Canada)

Hurricane Tracks Depicts current and Every 6 hrs CNHURCN00 (NTWT)
tropical systems
Caribbean
Table 49-21 Type: Satellite (Caribbean)

GOES IR Image GOES 24km infrared Every 30 min CASATIR00 (G804)
satellite image

1179
Graphic Weather
Weather Maps
Table 49-21 Type: Satellite (Caribbean) (continued)

GOES Visible Satellite GOES 24km visible Every 30 min (daylight CASATVS00 (G910)
GOES IR & Single Site GOES 4km infrared Every hr CASATRA00

Radar Composite satellite and NEXRAD
2km single site (San
Juan) base reflectivity
composite
Table 49-22 Type: Surface & Low-level Significant Weather (Caribbean)

Surface Analysis Current surface analysis Every hr CASFCWX00
Surface Depiction Depicts current flight Every hr CAWXDEP00

airports for Caribbean
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs CASFCWX24

conditions
Table 49-23 Type: High-level Significant Weather (Caribbean)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs CAHISIG12 (US10)
between FL240 and
FL600
Table 49-24 Type: Winds And Temps Aloft (Caribbean)

FL 050 Wind & Temp AVN wind and Every 6 hrs CAWT05024
forecast at FL 050
forecast at FL 100

1180
Graphic Weather
Weather Maps
Table 49-24 Type: Winds And Temps Aloft (Caribbean) (continued)

forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-25 Type: Aviation Hazards (Caribbean)

Hurricane Tracks Depicts current and Every 6 hrs CAHURCN00 (NTWT)
tropical systems
East Pacific
Table 49-26 Type: Satellite (East Pacific)

GOES IR Image Current GOES 4km Every 30 min EPSATIR00 (G877)
GOES Visible Satellite Current GOES 1km Every 30 min (daylight EPSATVS00

1181
Graphic Weather
Weather Maps
Table 49-27 Type: Surface & Low-level Significant Weather (East Pacific)

Surface Analysis Current surface analysis Every hr EPSFCWX00
Surface Depiction Depicts current flight Every hr EPWXDEP00

airports for East Pacific
Surface Wx Forecast 24 hour surface weather Every 12 hrs EPSFCWX24 (US03)

forecast
Table 49-28 Type: High-level Significant Weather (East Pacific)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs EPHISIG12
between FL240 and
FL600
Table 49-29 Type: Winds And Temps Aloft (East Pacific)

FL 050 Wind & Temp AVN wind and Every 6 hrs EPWT05024
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300

1182
Graphic Weather
Weather Maps
Table 49-29 Type: Winds And Temps Aloft (East Pacific) (continued)

forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-30 Type: Aviation Hazards (East Pacific)

Hurricane Tracks Depicts current and Every 3 hrs EPHURCN00
tropical systems
Europe
Table 49-31 Type: Satellite (Europe)

MeteoSat IR Image Current composite 24km Every 3 hrs EUSATIR00
MeteoSat Hi-Res IR Current MeteoSat 5km Every 6 hrs EUSATHR00 (G891)

Image infrared satellite image
Table 49-32 Type: Surface & Low-level Significant Weather (Europe)

Surface Analysis Current surface analysis Every 6 hrs (valid at 00, EUSFCWX00 (EUSF)
06, 12, 18 UTC)

1183
Graphic Weather
Weather Maps
Table 49-32 Type: Surface & Low-level Significant Weather (Europe) (continued)

Surface Depiction Depicts current flight Every hr EUWXDEP00 (EUWX)
airports for Europe
Surface Wx Forecast 24 hour surface weather Every 12 hrs EUSFCWX24 (EU03)

forecast
Table 49-33 Type: High-level Significant Weather (Europe)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs EUHISIG12 (EU18)
between FL240 and
FL600
850mb (FL 050) 850mb height and Every 12 hrs EUUA05000

Analysis temperature analysis


400mb (FL 240) 400mb height and wind Every 12 hrs EUUA24000
Analysis speed analysis
Table 49-34 Type: Winds And Temps Aloft (Europe)

FL 050 Wind & Temp AVN wind and Every 6 hrs EUWT05024 (EF85)
forecast at FL 050

1184
Graphic Weather
Weather Maps
Table 49-34 Type: Winds And Temps Aloft (Europe) (continued)

forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Europe/Asia
Table 49-35 Type: Satellite (Europe/Asia)

MeteoSat IR Image Current composite 24km Every 3 hrs EASATIR00 (G824)
Table 49-36 Type: Surface & Low-level Significant Weather (Europe/Asia)

Surface Analysis Current surface analysis Every hr EASFCWX00

1185
Graphic Weather
Weather Maps
Table 49-36 Type: Surface & Low-level Significant Weather (Europe/Asia) (continued)

Surface Depiction Depicts current flight Every hr EAWXDEP00
airports for Europe/Asia
Surface Wx Forecast 24 hour surface weather Every 12 hrs EASFCWX24

forecast
Table 49-37 Type: High-level Significant Weather (Europe/asia)

Significant Wx Forecast Depicts 12 hour forecast Every 12 hrs EAHISIG12 (AS10)
between FL240 and
FL600
Table 49-38 Type: Winds And Temps Aloft (Europe/Asia)

FL 050 Wind & Temp AVN wind and Every 6 hrs EAWT05024 (AS85)
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390

1186
Graphic Weather
Weather Maps
Table 49-38 Type: Winds And Temps Aloft (Europe/Asia) (continued)

forecast at FL 450
Table 49-39 Type: Aviation Hazards (Europe/asia)

Tropical Depicts current and Every 6 hrs EAHURCN00
Cyclone/Typhoon Tracks forecast positions of
tropical systems
Indian Ocean
Table 49-40 Type: Satellite (Indian Ocean)

MeteoSat IR Image Current MeteoSat 5 8km Every hr IOSATIR00
MeteoSat Visible Current MeteoSat 5 8km Every hr (daylight hrs) IOSATVS00

Satellite Image visible satellite image
Table 49-41 Type: Surface & Low-level Significant Weather (Indian Ocean)

Surface Analysis Current surface analysis Every hr IOSFCWX00
Surface Depiction Depicts current flight Every hr IOWXDEP00

airports for Indian Ocean
Surface Wx Forecast 24 hour surface weather Every 12 hrs IOSFCWX24

forecast

1187
Graphic Weather
Weather Maps
Table 49-42 Type: High-level Significant Weather (Indian Ocean)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs IOHISIG12 (IO10)
between FL240 and
FL600
Table 49-43 Type: Winds and Temps Aloft (Indian Ocean)

FL 050 Wind & Temp AVN wind and Every 6 hrs IOWT05024 (IO85)
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450

1188
Graphic Weather
Weather Maps
Table 49-44 Type: Aviation Hazards (Indian Ocean)

Hurricane Tracks Depicts current and Every 3 hrs IOHURCN00
tropical systems
Mexico
Table 49-45 Type: Satellite (Mexico)

GOES IR Image GOES 24km infrared Every 30 min MXSATIR00 (G800)
satellite image
GOES Visible Satellite GOES 24km visible Every 30 min (daylight MXSATVS00 (G900)
Table 49-46 Type: Surface & Low-level Significant Weather (Mexico)

Surface Analysis Current surface analysis Every hr MXSFCWX00
Surface Depiction Depicts current flight Every hr MXWXDEP00

airports for Mexico
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs MXSFCWX24

conditions
Table 49-47 Type: High-level Significant Weather (Mexico)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs MXHISIG12
between FL240 and
FL600

1189
Graphic Weather
Weather Maps
Table 49-48 Type: Winds And Temps Aloft (Mexico)

FL 050 Wind & Temp AVN wind and Every 6 hrs MXWT05024
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-49 Type: Aviation Hazards (Mexico)

Hurricane Tracks Depicts current and Every 6 hrs MXHURCN00 (NTWT)
tropical systems

1190
Graphic Weather
Weather Maps
Middle East
Table 49-50 Type: Satellite (Middle East)

MeteoSat IR Image Current MeteoSat 5 8km Every hr MESATIR00
MeteoSat Visible Current MeteoSat 5 8km Every hr (daylight hrs) MESATVS00

Satellite Image visible satellite image
Table 49-51 Type: Surface & Low-level Significant Weather (Middle East)

Surface Analysis Current surface analysis Every 6 hrs MESFCWX00
Surface Depiction Depicts current flight Every hr MEWXDEP00

airports for Middle East
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs MESFCWX24

conditions
Table 49-52 Type: High-level Significant Weather (Middle East)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs MEHISIG12
between FL240 and
FL600
Table 49-53 Type: Winds And Temps Aloft (Middle East)

FL 050 Wind & Temp GFS wind and Every 6 hrs MEWT05024
forecast at FL 050

1191
Graphic Weather
Weather Maps
Table 49-53 Type: Winds And Temps Aloft (Middle East) (continued)

forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-54 Type: Aviation Hazards (Middle East)

Hurricane Tracks Depicts current and Every 6 hrs MEHURCN00
tropical systems
North Atlantic
Table 49-55 Type: Satellite (North Atlantic)

IR Image Current composite 24km Every 3 hrs NTSATIR00 (G831)

1192
Graphic Weather
Weather Maps
Table 49-56 Type: Surface & Low-level Significant Weather (North Atlantic)

Surface Analysis Current surface analysis Every hr NTSFCWX00
Surface Depiction Depicts current flight Every hr NTWXDEP00

airports for North
Atlantic
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs NTSFCWX24
conditions
Table 49-57 Type: High-level Significant Weather (North Atlantic)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs NTHISIG12 (NT10)
between FL240 and
FL600
ABC NAT Tracks Depicts current 2300 UTC NTNTABC00

westbound North
Atlantic Tracks
XYZ NAT Tracks Depicts current 1400 UTC NTNTXYZ00

eastbound North Atlantic
Tracks
ABC NAT Tracks Depicts current 2300 UTC NTMRABC00 (NATA)

(Mercator) westbound North
Atlantic Tracks on
Mercator projection
XYZ NAT Tracks Depicts current 1400 UTC NTMRXYZ00 (NATZ)

(Mercator) eastbound North Atlantic
Tracks on Mercator
projection

1193
Graphic Weather
Weather Maps
Table 49-58 Type: Winds and Temps Aloft (North Atlantic)

FL 050 Wind & Temp AVN wind and Every 6 hrs NTWT05024 (TF85)
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-59 Type: Aviation Hazards (North Atlantic)

Hurricane Tracks Depicts current and Every 6 hrs NTHURCN00
tropical systems

1194
Graphic Weather
Weather Maps
North Pacific
Table 49-60 Type: Satellite (North Pacific)

IR Image Current composite 24km Every 3 hrs NPSATIR00 (G825)
Table 49-61 Type: Surface & Low-level Significant Weather (North Pacific)

Surface Analysis Current surface analysis Every hr NPSFCWX00 (PNSF)
Surface Depiction Depicts current flight Every hr NPWXDEP00

airports for North Pacific
Surface Wx Forecast 24 hour surface weather Every 12 hrs NPSFCWX24 (PN03)

forecast
Table 49-62 Type: High-level Significant Weather (North Pacific)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs NPHISIG12 (PN10)
between FL240 and
FL600
North Pacific Tracks Depicts current 2100 UTC NPNPOTE00

eastbound North Pacific
Tracks
North Pacific Tracks Depicts current 1100 UTC NPNPOTW00

westbound North Pacific
Tracks
North Pacific Tracks Depicts current 2100 UTC NPMROTE00

(Mercator) eastbound North Pacific
Tracks on Mercator
projection
North Pacific Tracks Depicts current 1100 UTC NPMROTW00

(Mercator) westbound North Pacific
Tracks on Mercator
projection

1195
Graphic Weather
Weather Maps
Table 49-63 Type: Winds and Temps Aloft (North Pacific)

FL 050 Wind & Temp AVN wind and Every 6 hrs NPWT05024 (PF85)
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-64 Type: Aviation Hazards (North Pacific)

Hurricane/Typhoon Depicts current and Every 6 hrs NPHURCN00 (WPWT)
Tracks forecast positions of
tropical systems

1196
Graphic Weather
Weather Maps
South America
Table 49-65 Type: Satellite (South America)

GOES IR Image GOES 8km infrared Every 3 hrs SASATIR00 (G846)
satellite image
GOES Visible Satellite GOES 8km visible Every 3 hrs (daylight SASATVS00
Table 49-66 Type: Surface & Low-level Significant Weather (South America)

Surface Analysis Current surface analysis Every hr SASFCWX00
Surface Depiction Depicts current flight Every hr SAWXDEP00

airports for South
America
Surface Wx Forecast 24 hour surface weather Every 12 hrs SASFCWX24

forecast
Table 49-67 Type: High-level Significant Weather (South America)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs SAHISIG12 (SA10)
between FL240 and
FL600
Table 49-68 Type: Winds And Temps Aloft (South America)

FL 050 Wind & Temp AVN wind and Every 6 hrs SAWT05024 (SF85)
forecast at FL 050

1197
Graphic Weather
Weather Maps
Table 49-68 Type: Winds And Temps Aloft (South America) (continued)

forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-69 Type: Aviation Hazards (South America)

Hurricane Tracks Depicts current and Every 3 hrs SAHURCN00
tropical systems
South Pacific
Table 49-70 Type: Surface & Low-level Significant Weather (South Pacific)

Surface Analysis Current surface analysis Every hr SPSFCWX00

1198
Graphic Weather
Weather Maps
Table 49-70 Type: Surface & Low-level Significant Weather (South Pacific) (continued)

Surface Depiction Depicts current flight Every hr SPWXDEP00
airports for South Pacific
Surface Wx Forecast 24 hour surface weather Every 12 hrs SPSFCWX24

forecast
Table 49-71 Type: High-level Significant Weather (South Pacific)

Significant Wx Forecast Depicts 12 hour forecast Every 12 hrs SPHISIG12
between FL240 and
FL600
Table 49-72 Type: Winds and Temps Aloft (South Pacific)

FL 050 Wind & Temp AVN wind and Every 6 hrs SPWT05024
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390

1199
Graphic Weather
Weather Maps
Table 49-72 Type: Winds and Temps Aloft (South Pacific) (continued)

forecast at FL 450
Table 49-73 Type: Aviation Hazards (South Pacific)

Hurricane Tracks Depicts current and Every 3 hrs SPHURCN00
tropical systems
United States
Table 49-74 Type: Satellite (U.S.)

GOES IR Image Current GOES 8km Every 30 min USSATIR00 (G800)
GOES Visible Image Current GOES 8km Every 30 min (daylight USSATVS00 (G900)
visible satellite image hours)
IR & Radar Composite GOES infrared satellite Every 30 min USSATRA00

& NEXRAD base
Table 49-75 Type: Radar (U.S.)

Base Reflectivity NEXRAD 4km base Every 5 min USRADBR00 (R001)
reflectivity
Composite NEXRAD 8km radar Every 30 min USRADCP00 (USRA)

composite

1200
Graphic Weather
Weather Maps
Table 49-76 Type: Surface & Low-level Significant Weather (U.S.)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, USSFCWX00 (USSF)
03, 06, 09, 12, 15, 18, 21
UTC)
Surface Depiction Depicts current flight Every hr USWXDEP00 (USWX)

U.S. airports
Surface Wx Forecast 24 hour surface weather Every 12 hrs USSFCWX24 (US03)

forecast
Low-level Significant 12 hour low-level Every 6 hrs USLOSIG12 (US02)
Wx Forecast forecast conditions
Low-level Significant 24 hour low-level Every 12 hrs USLOSIG24 (US04)

Wx Forecast forecast conditions
Table 49-77 Type: High-level Significant Weather (U.S.)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs USHISIG12 (US10)
between FL240 and
FL600
850mb (FL 050) 850mb height and Every 12 hrs USUA05000 (US8W)
400mb (FL 240) 400mb height and wind Every 12 hrs USUA24000
300mb (FL 300) 300mb height and wind Every 12 hrs USUA30000 (US3W)
250mb (FL 340) 250mb height and wind Every 12 hrs USUA34000 (US2H)
200mb (FL 390) 200mb height and wind Every 12 hrs USUA39000 (US2W)

1201
Graphic Weather
Weather Maps
Table 49-77 Type: High-level Significant Weather (U.S.) (continued)

150mb (FL 450) 150mb height and wind Every 12 hrs USUA45000
Table 49-78 Type: Winds and Temps Aloft (U.S.)

FL 050 Wind & Temp AVN wind and Every 6 hrs USWT05024 (US85)
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-79 Type: Aviation Hazards (U.S.)

IFR & Mountain Current IFR and Every hr USIFRWX00
Obscuration AIRMETs mountain obscuration
AIRMETs

1202
Graphic Weather
Weather Maps
Table 49-79 Type: Aviation Hazards (U.S.) (continued)

Turbulence AIRMETs & Current turbulence Every hr USTURBC00 (USTB)
Reports AIRMET areas and
reports
Icing AIRMETs & Current icing AIRMET Every hr USICING00 (ICAN)

Reports areas, freezing levels and
reports
SIGMET & Convective Current SIGMET and Every hr USSIGMT00 (USCS)

SIGMET Areas convective SIGMET
areas
Lifted Index Analysis Depicts current lifted Every 6 hrs USLINDX00 (LIAN)
index values
Lifted Index 12 Hour Depicts 12 hour forecast Every 6 hrs USLINDX12 (LI12)
Forecast lifted index values
Lifted Index 24 Hour Depicts 24 hour forecast Every 6 hrs USLINDX24 (LI24)
Forecast lifted index values
Convective Outlook Depicts 12-24 hours of Every 24 hrs USCVOUT12 (AC01)

convective and severe
activity
Hurricane Tracks Depicts current and Every 6 hrs USHURCN00 (NTWT)

tropical systems
U.S. Regional (Alaska)
Table 49-80 Type: Satellite (Alaska)

GOES IR Image GOES 8km infrared Every 30 min AKSATIR00 (G828)
satellite image
GOES Visible Satellite GOES 2km visible Every 30 min (daylight AKSATVS00 (G902)

1203
Graphic Weather
Weather Maps
Table 49-81 Type: Surface & Low-level Significant Weather (Alaska)

Surface Analysis Current surface analysis Every hr AKSFCWX00 (AKSF)
Surface Depiction Depicts current flight Every hr AKWXDEP00 (AKWX)

airports for Southeast
U.S.
Surface Wx 24 Hour Depicts 24 hour surface Every 12 hrs AKSFCWX24 (AK03)
conditions
Table 49-82 Type: High-level Significant Weather (Alaska)

Significant Wx Forecast Depicts 12 hour forecast Every 6 hrs AKHISIG12
between FL240 and
FL600
Table 49-83 Type: Winds and Temps Aloft (Alaska)

FL 050 Wind & Temp AVN wind and Every 6 hrs AKWT05024
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300

1204
Graphic Weather
Weather Maps
Table 49-83 Type: Winds and Temps Aloft (Alaska) (continued)

forecast at FL 340
forecast at FL 390
forecast at FL 450
U.S. Regional (Hawaii)
Table 49-84 Type: Satellite (Hawaii)

GOES IR Image Current GOES 4km Every 30 min HISATIR00 (G847)
GOES Visible Satellite Current GOES 1km Every 30 min (daylight HISATVS00
GOES IR & Single Site GOES 4km infrared Every 30 min HISATRA00
Radar Composite satellite and NEXRAD
2km single site
(Molokai) base
Table 49-85 Type: Surface & Low-level Significant Weather (Hawaii)

Surface Depiction Depicts current flight Every hr HIWXDEP00
airports for Hawaii

1205
Graphic Weather
Weather Maps
Table 49-86 Type: Winds and Temps Aloft (Hawaii)

FL 050 Wind & Temp AVN wind and Every 6 hrs HIWT05024
forecast at FL 050
forecast at FL 100
forecast at FL 180
forecast at FL 240
forecast at FL 300
forecast at FL 340
forecast at FL 390
forecast at FL 450
Table 49-87 Type: Aviation Hazards (Hawaii)

Hurricane Tracks Depicts current and Every 3 hrs HIHURCN00 (EPWT)
tropical systems

1206
Graphic Weather
Weather Maps
U.S. Regional (North Central)
Table 49-88 Type: Satellite (U.S. North Central)

GOES IR Image GOES 4km infrared Every 30 min NCSATIR00 (G854)
satellite image
GOES Visible Satellite GOES 1km visible Every 30 min NCSATVS00 (G984)
Image satellite image
IR & Radar Composite GOES infrared & Every 30 min NCSATRA00

NEXRAD base
reflectivity
Table 49-89 Type: Radar (U.S. North Central)

Base Reflectivity Current NEXRAD 2km Every 5 min NCRADBR00 (R004)
base reflectivity
Composite Current NEXRAD 8km Every 30 min NCRADCP00 (NCRR)

radar composite
Table 49-90 Type: Surface & Low-level Significant Weather (U.S. North Central)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, NCSFCWX00
03, 06, 09, 12, 15, 18, 21
UTC)
Surface Depiction Depicts current flight Every hr NCWXDEP00 (NCWX)

airports for North
Central U.S.

1207
Graphic Weather
Weather Maps
U.S. Regional (Northeast)
Table 49-91 Type: Satellite (U.S. Northeast)

GOES IR Image GOES 4km infrared Every 30 min NESATIR00 (G880)
satellite image
GOES Visible Satellite GOES 1km visible Every 30 min NESATVS00 (G980)
IR & Radar Composite GOES infrared & Every 30 min NESATRA00

NEXRAD base
reflectivity
Table 49-92 Type: Radar (U.S. Northeast)

Base Reflectivity Current NEXRAD 2km Every 5 min NERADBR00 (R006)
base reflectivity
Composite Current NEXRAD 8km Every 30 min NERADCP00 (NERR)

radar composite
Table 49-93 Type: Surface & Low-level Significant Weather (U.S. Northeast)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, NESFCWX00
03, 06, 09, 12, 15, 18, 21
UTC)
Surface Depiction Depicts current flight Every hr NEWXDEP00 (NEWX)

airports for Northeast
U.S.

1208
Graphic Weather
Weather Maps
Table 49-94 Type: Aviation Hazards (U.S. Northeast)

Hurricane Tracks Depicts current and Every 6 hrs NEHURCN00
tropical systems
U.S. Regional (Northwest)
Table 49-95 Type: Satellite (U.S. Northwest)

GOES IR Image GOES 4km infrared Every 30 min NWSATIR00 (G882)
satellite image
GOES Visible Satellite GOES 1km visible Every 30 min NWSATVS00 (G979)
IR & Radar Composite GOES infrared & Every 30 min NWSATRA00

NEXRAD base
reflectivity
Table 49-96 Type: Radar (U.S. Northwest)

Base Reflectivity Current NEXRAD 2km Every 5 min NWRADBR00 (R002)
base reflectivity
Composite Current NEXRAD 8km Every 30 min NWRADCP00 (NWRR)

radar composite
Table 49-97 Type: Surface & Low-level Significant Weather (U.S. Northwest)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, NWSFCWX00
03, 06, 09, 12, 15, 18, 21
UTC)

1209
Graphic Weather
Weather Maps
Table 49-97 Type: Surface & Low-level Significant Weather (U.S. Northwest) (continued)

Surface Depiction Depicts current flight Every hr NWWXDEP00
conditions at selected (NWWX)
airports for Northwest
U.S. Regional (South Central)
Table 49-98 Type: Satellite (U.S. South Central)

GOES IR Image GOES 4km infrared Every 30 min SCSATIR00 (G802)
satellite image
GOES Visible Satellite GOES 1km visible Every 30 min SCSATVS00 (G902)
IR & Radar Composite GOES infrared & Every 30 min SCSATRA00

NEXRAD base
reflectivity
Table 49-99 Type: Radar (U.S. South Central)

Base Reflectivity Current NEXRAD 2km Every 5 min SCRADBR00 (R014)
base reflectivity
Composite Current NEXRAD 8km Every 30 min SCRADCP00 (SCRR)

radar composite
Table 49-100 Type: Surface & Low-level Significant Weather (U.S. South Central)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, SCSFCWX00
03, 06, 09, 12, 15, 18, 21
UTC)
Surface Depiction Depicts current flight Every hr SCWXDEP00 (SCWX)

airports for South
Central U.S.

1210
Graphic Weather
Weather Maps
Table 49-101 Type: Aviation Hazards (U.S. South Central)

Hurricane Tracks Depicts current and Every 6 hrs SCHURCN00
tropical systems
U.S. Regional (Southeast)
Table 49-102 Type: Satellite (U.S. Southeast)

GOES IR Image GOES 4km infrared Every 30 min SESATIR00 (G852)
satellite image
GOES Visible Satellite GOES 1km visible Every 30 min SESATVS00 (G969)
IR & Radar Composite GOES infrared & Every 30 min SESATRA00

NEXRAD base
reflectivity
Table 49-103 Type: Radar (U.S. Southeast)

Base Reflectivity Current NEXRAD 2km Every 5 min SERADBR00 (R015)
base reflectivity
Composite Current NEXRAD 8km Every 30 min SERADCP00 (SERR)

radar composite
Table 49-104 Type: Surface & Low-level Significant Weather (U.S. Southeast)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, SESFCWX00
03, 06, 09, 12, 15, 18, 21
UTC)

1211
Graphic Weather
Weather Maps
Table 49-104 Type: Surface & Low-level Significant Weather (U.S. Southeast) (continued)

Surface Depiction Depicts current flight Every hr SEWXDEP00 (SEWX)
airports for Southeast
U.S.
Table 49-105 Type: Aviation Hazards (U.S. Southeast)

Hurricane Tracks Depicts current and Every 6 hrs SEHURCN00
tropical systems
U.S. Regional (Southwest)
Table 49-106 Type: Satellite (U.S. Southwest)

GOES IR Image GOES 4km infrared Every 30 min SWSATIR00 (G878)
satellite image
GOES Visible Satellite GOES 1km visible Every 30 min SWSATVS00 (G978)
IR & Radar Composite GOES infrared & Every 30 min SWSATRA00

NEXRAD base
reflectivity
Table 49-107 Type: Radar (U.S. Southwest)

Base Reflectivity Current NEXRAD 2km Every 5 min SWRADBR00 (R012)
base reflectivity
Composite Current NEXRAD 8km Every 30 min SWRADCP00 (SWRR)

radar composite

1212
Graphic Weather
Weather Maps
Table 49-108 Type: Surface & Low-level Significant Weather (U.S. Southwest)

Surface Analysis Current surface analysis Every 3 hrs (valid at 00, SWSFCWX00
03, 06, 09, 12, 15, 18, 21
UTC)
Surface Depiction Depicts current flight Every hr SWWXDEP00 (SWWX)

airports for Southwest
U.S.
Table 49-109 Type: Aviation Hazards (U.S. Southwest)

Hurricane Tracks Depicts current and Every 6 hrs SWHURCN00
tropical systems

1213
C HAPTER 50
JEPPFAX Weather Maps

JEPPFAX Weather Maps
Overview
Overview
Jeppesen provides a service in which most weather maps produced or distributed by the
Jeppesen Weather Service can be transmitted to a fax machine. This service, JeppFax®,
allows you to forward text or graphic weather maps to a fax machine.
JeppFax automatically provides a standard cover page with each transmission request. This
cover page contains the latest information about the JeppFax service.
NOTE JetPlan customers can use JeppFax to request weather maps via the Fax-
forwarding option (FX). For more information, see Chapter 18, “Forward Plans and
Messages.”
Consider the following when using the JeppFax system:
• The quality of the maps and images can vary with the different types of fax
machines used.
• Busy fax machines might inhibit the transmission of products. JeppFax
attempts to connect to your fax machine up to 5 times (approximately 3
minutes apart). If the system cannot make a connection to your fax machine
after 5 attempts, the system cancels your order. You are only billed for pages
that are successfully transmitted to your fax machine.
• Partial transmissions can occur due to excessive noise on the phone line, or
when the phone connection is lost. In the event you do not receive a
complete transmission, JeppFax makes 4 more attempts (every 3 minutes) to
transmit the remaining portion of the request. Again, you are only billed for
pages that are successfully transmitted to your fax machine.
NOTE A complete list of JeppFax map codes can be found in the Graphic Weather
chapter of this manual.

1217
C HAPTER 51
Vertical Wind Shear

Vertical Wind Shear
Overview
Overview
JetPlan calculates wind shear based on a formula that samples wind velocity and direction two
thousand feet above and two thousand feet below the current cruise altitude. Presently, JetPlan
does not make use of any ICAO tables to assign a relative intensity to shear.
The formula is as follows:
where:
• WD1= wind direction 2,000 feet below cruise altitude (degrees)

• SP1= wind velocity 2,000 feet below cruise altitude (knots)
• WD2 = wind direction 2,000 feet above cruise altitude (degrees)
• SP2 = wind velocity 2,000 feet above cruise altitude (knots)
• x1= SP1 × COS(WD1)
• y1= SP1 × SIN(WD1)
• x2 = SP2 × COS(WD2)
• y2 = SP2 × SIN(WD2)
• ALT1= altitude at 2,000 feet below cruise altitude.
• ALT2 = altitude at 2,000 feet above cruise altitude.

1221
Vertical Wind Shear
Shear Value Interpretation
Shear Value Interpretation

The following statement was prepared to guide pilots and dispatchers in the interpretation of
shear values as they relate to Clear Air Turbulence (CAT).
Vertical wind shear calculated on JetPlan takes a velocity difference in a 4,000 foot section
centered on the cruise flight level. The numbers derived from this method can sometimes be
misleading when trying to relate wind shear to CAT. For example, an aircraft could be flying
in the center of a 100 knot jet stream and the wind shear could be zero if the wind velocity
2,000 feet above and 2,000 feet below the cruise altitude are the same. In contrast, an aircraft
could be flying through light winds of approximately 20 knots with a direction difference
above and below the cruise flight level that could cause a relatively high shear number, but
little turbulence.
Vertical wind shear is only one of the many factors that cause CAT. Other factors include:
position relative to upper level troughs and ridges, position relative to the tropopause, position
relative to jet streams, temperature gradients, mountain waves and other small scale
phenomenon. Generally, only large scale CAT is forecast for aircraft operations.
In general, the higher the vertical wind shear, the more likely an encounter with CAT and
strong turbulence. There is little aviation criteria for relating wind shear values to a probable
turbulence threshold, except the suggestions that exist in AC 00-6A, p. 143, and AC 00-45D,
pp. 13-1,2. No criteria is defined for relating wind shear values to the occurrence of light,
moderate, or severe.
The only relation is that the likelihood of encountering CAT is increased when there is strong
vertical wind shear. But vertical wind shear values are used for guidance only, not for
determining aircraft operations. High Level Significant Weather Prognostic charts and pilot
reports (PIREPs) are useful tools for determining the areas of CAT over a large region.

1222

Jet Plan User Manual

Uploaded by

Copyright:

Available Formats

Jet Plan User Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jet Plan User Manual

Uploaded by

Copyright:

Available Formats

JetPlan User Manual

JetPlan User Manual

Copyright © 2003-2019 Jeppesen. All rights reserved.

Version Release Date Changes

JetPlan User Manual April 25, 2019

April 25, 2019 JetPlan User Manual

JetPlan User Manual April 25, 2019

April 25, 2019 JetPlan User Manual

Chapter 1: JetPlan Command-Line Interface 9

Chapter 2: Option Commands 21

Flight Plan Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 3: Point of Departure and Point of Arrival Commands 63

JetPlan User Manual April 25, 2019

Adding the Taxi-Out Value to the ETD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Chapter 4: Restricted Area Commands 95

Chapter 5: 4D Avoid and Alert Restrictive Airspaces 109

April 25, 2019 JetPlan User Manual

Using the CCAA, CCAAN, and CCAAF Options . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapter 6: Route Commands 141

JetPlan User Manual April 25, 2019

Nav Optimized Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

April 25, 2019 JetPlan User Manual

City Pair Fleet Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

JetPlan User Manual April 25, 2019

SRS Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

April 25, 2019 JetPlan User Manual

Avoiding Checkpoints and Airways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Chapter 7: Hold-Alternate Commands 273

JetPlan User Manual April 25, 2019

The Automatic AIR OPS ERA Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Chapter 8: Estimated Time of Departure Commands 309

Chapter 9: Profile Commands 327

April 25, 2019 JetPlan User Manual

Altitude Change at Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Chapter 10: Aircraft Type Commands 347

Chapter 11: Cruise Mode Commands 359

JetPlan User Manual April 25, 2019

FPM Secondary Climb Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Chapter 12: Cost Index Commands 387

April 25, 2019 JetPlan User Manual

Chapter 13: Operational Weight Commands 409

Chapter 14: Payload, POD/POA, Weight, and Fuel Commands 413

JetPlan User Manual April 25, 2019

How JetPlan Supports B43 Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Chapter 15: Fuel Off/On and Payload Off Commands 475

April 25, 2019 JetPlan User Manual

Offloading and Onloading Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Chapter 16: Departure and Arrival Bias Commands 479

Chapter 17: Message Commands 491

Chapter 18: Forward Plans and Messages 497

Chapter 19: ATC Filing 511

JetPlan User Manual April 25, 2019

The Filing Program Command Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Chapter 20: Reclear Commands 557

April 25, 2019 JetPlan User Manual

Routing when Using the Auto Select Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Chapter 21: ETOPS 589

Chapter 22: Overwater Driftdown and Terrain Analysis 593

JetPlan User Manual April 25, 2019