IFPS Users Manual - Eurocontrol · 10. MANUAL (MAN) MESSAGE Was previously section 18. 11. REJECT (REJ) MESSAGE Was previously section 19. 12. COPY OPERATIONAL REPLY MESSAGE (ORM)

Edition: 24.0

Edition date: 30-06-2020

Classification: Green

Reference nr:

IFPS Users Manual

Network Manager

EUROCONTROL Network Management Directorate

Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: i

DOCUMENT CONTROL

Document Title IFPS Users Manual

Document Subtitle Network Manager

Document Reference

Edition Number 24.0

Edition Validity Date 30-06-2020

Classification Green

Accessibility Internet

Status Released Issue

Author(s) Benoit HOUOT (NMD/NOM/NOS)

Contact Person(s) Benoit HOUOT (NMD/NOM/NOS) / Andy WOOLLIN (NMD/NOM/NOS)

APPROVAL TABLE

The signature table is optional –a minuted approval meeting may be used instead.

The following table identifies all management authorities who have successively approved the present issue of this document.

This table may be replaced by a format document review and approval meeting, with the meeting details recorded and retained in the edition’s archive folder.

The approval may also be recorded via electronic workflow, where put in place. Where document approval is made via a meeting or electronic workflow, the details shall be indicated here in place of the approval table.

Edition publication approval given on 18/05/2020.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: ii

EDITION HISTORY

Edition No. Validity Date Author(s) Reason

19.2 15/01/2016 HOT New naming for IFPS Staff

20.0 12/04/2016 HOT NM 20.0 Release

20.1 25/10/2016 HOT NM 20.5 Release

21.0 09/05/2017 HOT NM 21.0 Release

21.1 24/10/2017 HOT NM 21.5 Release

22.0 08/05/2018 HOT NM 22.0 Release

22.1 20/11/2018 HOT NM 22.5 Release

23.0 07/05/2019 HOT NM 23.0 Release

23.1 22/10/2019 HOT NM 23.5 Release

24.0 30/06/2020 HOT NM 24.0 Release


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: iii

EDITION CHANGE RECORD

Title Amendment Notes

1. INTRODUCTION Some text removed due to RPL system decommissioned.

2. NM OPERATIONAL CONTACTS Some text removed due to RPL system decommissioned.

3. FLIGHT PLANS AND ASSOCIATED MESSAGES

Some text removed to reflect correctly IFPS possibilities.

Some text removed due to RPL system decommissioned.

REPETITIVE FLIGHT PLAN (RPL) Entire section removed due to RPL system decommissioned.

RPL SUBMISSION Entire section removed due to RPL system decommissioned.

IFPS RPL FORMAT Entire section removed due to RPL system decommissioned.

RPL PROCESSING Entire section removed due to RPL system decommissioned.

RPL AIRAC +1 PREPARATION AND VALIDATION PROCEDURES FOR REPROCESSING AND RAD +2 VALIDATION

Entire section removed due to RPL system decommissioned.

QUALITY CONTROL Entire section removed due to RPL system decommissioned.

RPL SUSPENSION Entire section removed due to RPL system decommissioned.

RPL UNSERVICEABILITIES Entire section removed due to RPL system decommissioned.

04. MESSAGE SUBMISSION TO THE IFPS

Was previously section 12.

12.4 removed due to RPL system decommissioned.

05. MESSAGE DISTRIBUTION BY THE IFPS



Some text removed due to obsolete process.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: iv

Figure 5-1 amended.

Table 5.1: FYROM renamed as North Macedonia.

06. RE-ADDRESSING Was previously section 14.

07. ATS DATA EXCHANGE PRESENTATION (ADEXP)

Was previously section 15. Editorial changes.

08. OPERATIONAL REPLY MESSAGE (ORM)


One row removed in the table due to RPL system decommissioned.

09. ACKNOWLEDGE (ACK) MESSAGE Was previously section 17. Editorial changes.

10. MANUAL (MAN) MESSAGE Was previously section 18.

11. REJECT (REJ) MESSAGE Was previously section 19.

12. COPY OPERATIONAL REPLY MESSAGE (ORM)


13. DETERMINATION OF AIRCRAFT OPERATOR BY IFPS


14. ERROR TYPES


Two paragraphs removed due to RPL system decommissioned.

15. IMPROVEMENT IN QUALITY OF SUBMITTED MESSAGES


One paragraph removed due to RPL system decommissioned.

16. IFPS RE-ROUTE ACCEPTED (IFPSRA) Was previously section 24.

17. IFPS MANUAL PROCESSING PROCEDURES



18. STANDARD CORRECTION PROCEDURE 1 (SCP1)


Some text and table removed due to RPL system decommissioned.

Editorial changes.

19. STANDARD CORRECTION PROCEDURE 2 (SCP2)


20. FLIGHT PLAN REPROCESSING Was previously section 28.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: v

Some text removed and tables 20.1/20.2 amended due to RPL system decommissioned.

21. ATC PRE-DEPARTURE FPL MODIFICATION (AMOD)


22. IFPSTOP/IFPSTART Was previously section 30. Some text removed due to RPL system decommissioned.

TREATMENT OF REPETITIVE FLIGHT PLANS (RPLs) IN IFPS

Entire section removed due to RPL system decommissioned.

23. KEY FIELDS Was previously section 32.

24. MESSAGE ASSOCIATION


(2) Requirements: some text added for completeness.

Some paragraphs removed due to RPL system decommissioned.

25. PROFILE CALCULATION/ROUTE ANALYSIS


26. MILITARY FLIGHTS Was previously section 35.

27. GENERAL AIR TRAFFIC/OPERATIONAL AIR TRAFFIC (GAT/OAT)


28. MILITARY POINTS AND ROUTES Was previously section 37.

29. ADDRESSING Was previously section 38.

30. BLOCKING LEVELS Was previously section 39.

31. RAD FOR MILITARY FLIGHTS Was previously section 40.

32. OPEN SKIES FLIGHTS Was previously section 41.

33. VISUAL FLIGHT RULES (VFR)



34. NORTH ATLANTIC (NAT) TRAFFIC Was previously section 43.

35. FLEXIBLE USE OF AIRSPACE (FUA) CONDITIONAL ROUTES (CDR)


Some paragraphs removed due to RPL system decommissioned and editorial change.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: vi

36. ROUTE AVAILABILITY DOCUMENT (RAD)


(2) Requirements: text added for completeness and editorial changes.

37. REDUCED VERTICAL SEPARATION MINIMA (RVSM)



Some obsolete paragraphs removed in (3) Message Format and (4) System Processing.

38. 8.33 kHz CHANNEL SPACING Was previously section 47.

39. SSR MODE-S Was previously section 48.

40. EN-ROUTE STAY INDICATOR



41. IFPS MONITORING FLIGHT EVOLUTION


42. SPECIAL STATUS FLIGHTS (STS) Was previously section 51.

(2) Requirements: one paragraph updated.

43. STS/SAR INDICATOR Was previously section 52.

44. STS/HEAD INDICATOR Was previously section 53.

45. STS/ATFMX INDICATOR Was previously section 54.

46. STS/HOSP INDICATOR Was previously section 55.

47. STS/HUM INDICATOR Was previously section 56.

48. STS/STATE INDICATOR Was previously section 57.

49. STS/NONRVSM INDICATOR Was previously section 58.

50. STS/FFR INDICATOR Was previously section 59.

51. STS/FLTCK INDICATOR Was previously section 60.

52. STS/HAZMAT INDICATOR Was previously section 61.

53. STS/MARSA INDICATOR Was previously section 62.

54. STS/MEDEVAC INDICATOR Was previously section 63.

55. STS/ALTRV INDICATOR Was previously section 64.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: vii

56. RUNWAY VISUAL RANGE (RVR) Was previously section 65.

57. ORIGINATOR (ORGN) INDICATOR



58. SOURCE (SRC) INDICATOR


(2) Requirements: editorial changes.


59. IFP INDICATORS Was previously section 68.

60. IFPS TEST SYSTEM (IFPUV) Was previously section 69.

61. AIRCRAFT OPERATOR WHAT-IF RE-ROUTE (AOWIR)


62. DIVERSION ARRIVAL MESSAGES Was previously section 71.

63. ITEM 3:MESSAGE TITLE



64. ITEM 7: AIRCRAFT IDENTIFICATION AND SSR MODE/SSR CODE



65. ITEM 8:FLIGHT RULES AND TYPE OF FLIGHT



Numbering 65.1 and 65.2 removed.

66. ITEM 9: NUMBER AND TYPE OF AIRCRAFT AND WAKE TURBULENCE CATEGORY



67. ITEM 10: EQUIPMENT AND CAPABILITIES


OI/19-177 that was previously published on the NOP has been integrated.


Numbering 67.1, 67.2 and 65.3 removed.

68. ITEM 13: AERODROME OF DEPARTURE (ADEP) AND ESTIMATED OFF-BLOCKS TIME (EOBT)




Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: viii

Editorial changes.

69. ITEM 15: ROUTE



70. INITIAL SPEED AND LEVEL Was previously section 79.

Numbering 70.1 and 70.2 removed

71. EN-ROUTE CHANGE OF SPEED / LEVEL


72. SID/STAR



73. POINTS



74. AIRWAYS



75. ITEM 16:

A) DESTINATION AERODROME

B) TOTAL ESTIMATED ELAPSED TIME

C) ALTERNATE AERODROME(s)



76. ITEM 18: OTHER INFORMATION



77. ESTIMATED ELAPSED TIME (EET) Was previously section 86.

78. RE-CLEARANCE IN FLIGHT (RIF) Was previously section 87.

79. AIRCRAFT REGISTRATION (REG)



80. SELCAL (SEL)



81. AIRCRAFT OPERATOR (OPR) Was previously section 90.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: ix

82. STATUS (STS)



93. AIRCRAFT TYPE (TYP)



84. AIRCRAFT PERFORMANCE (PER)



85. COMMUNICATIONS EQUIPMENT (COM)


86. DATA LINK CAPABILITY (DAT) Was previously section 95.

87. NAVIGATION EQUIPMENT (NAV) Was previously section 96.

88. DEPARTURE AERODROME (DEP)



89. DESTINATION AERODROME (DEST)



90. ALTERNATE DESTINATION AERODROME (ALTN)



91. EN-ROUTE ALERNATE AERODROME (RALT)


92. REMARKS (RMK) Was previously section 101.

93. DATE OF FLIGHT (DOF) Was previously section 102.

94. REPLACEMENT FLIGHT PLAN (RFP) Was previously section 103.

95. CODE Was previously section 104.

96. STAYINFO Was previously section 105.

97. EUR PROTECTED Was previously section 106.

98. PBN (PERFORMANCE BASED NAVIGATION)


99. SURVEILLANCE (SUR) Was previously section 108.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: x

100. TAKE-OFF ALTERNATE (TALT) Was previously section109.

101. EN-ROUTE DELAY OR HOLDING (DLE)


102. ADDITIONAL OUTPUT BY THE IFPS Was previously section 111.

Editorial changes.

103. ITEM 19: SUPPLEMENTARY INFORMATION



104. TOTAL FUEL ENDURANCE: E/ Was previously section 113.

105. TOTAL NUMBER OF PERSONS ON BOARD: P/


106. EMERGENCY RADIO: R/ Was previously section 115.

107. SURVIVAL EQUIPMENT: S/ Was previously section 116.

108. LIFE JACKETS: J/ Was previously section 117.

109. DINGHIES: D/ Was previously section 118.

110. AIRCRAFT COLOUR AND SIGNIFICANTMARKINGS: A/


111. OTHER SURVIVAL EQUIPMENT N/ Was previously section 120.

112. PILOT IN COMMAND: C/ Was previously section 121.

113. MESSAGE TYPES



Some text added for completeness.

114. FLIGHT PLAN (FPL)



(2) Requirements: text modified due to system change.

115. MODIFICATION (CHG)



(4) System Processing: note amended due to system change.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xi

116. DELAY (DLA) Was previously section 125.

117. CANCEL (CNL) Was previously section 126.

118. DEPARTURE (DEP) Was previously section 127.

119. ARRIVAL (ARR) Was previously section 128.

120. REQUEST FLIGHT PLAN (RQP) Was previously section 129.

121. REQUEST SUPPLEMENTARY FLIGHT PLAN (RQS)



122. AIRBORNE MESSAGE TYPES Was previously section 131.

123. AIR-FILED FLIGHT PLANS (AFIL) Was previously section 132.

124. ATC FLIGHT PLAN PROPOSAL MESSAGE (AFP)


Entire section reviewed and numerous changes across.

Table 124.2 Compulsory and Optional AFP information removed. 124.2 is now General Procedures.

125. AFP FOR A MISSING FLIGHT PLAN



125.1 General Procedures removed.

126. AFP FOR A CHANGE OF ROUTE



(2) Requirements: new additional requirement. Complete sub-section re-written and graphic examples added.


AFP FOR A CHANGE OF REQUESTED CRUISING LEVEL

Entire section removed.

127. AFP FOR A CHANGE OF AIRCRAFT TYPE



128. AFP FOR A CHANGE OF FLIGHT RULES (IFR/VFR)



Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xii


129. AFP FOR A CHANGE OF FLIGHT TYPE



130. AFP FOR DIVERSION


General Procedures changed to 4) System Processing


131. AFP FOR A CHANGE OF AIRCRAFT EQUIPEMENT



132. FLIGHT NOTIFICATION MESSAGE (FNM)


133. MESSAGE FROM SHANWICK/SANTA MARIA (MFS)


134. ATC FLIGHT PLAN (APL)



135. ATC FLIGHT PLAN CHANGE (ACH)



136. VOICE COMMUNICATIONS SYSTEM (VCS)


137. THE TRANSMIT FUNCTION Was previously section 147.

138. SERVICE AND OTHER NON-STANDARD MESSAGES


139. IFPS UNSERVICEABILITIES



Editorial changes.

140. SYSTEM MAINTENANCE AND INTERVENTIONS


141. ETFMS UNSERVICEABILITIES Was previously section 151.


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xiii

142. MANUAL CREATION OF MESSAGES Was previously section 152.

143. MESSAGE REJECTED BY PARTNER Was previously section 153.

144. DICTIONARY OF ABBREVIATIONS


Three abbreviations removed due to RPL system decommissioned.

145. EUROCONTROL SPECIFICATION FOR THE INITIAL FLIGHT PLAN


All references of RPL removed.

Column “Applicable IFPS User Manual Sections” updated.

146. ERROR MESSAGE DETAILS


All errors: RPL Procedure paragraph removed.

SYN119: example added.

SYN61, SYN63, SYN82, SYN107, SYN113, EFPM208, EFPM218, EFPM233, EFPM240, ROUTE137 removed due to RPL system decommissioned.

EFPM220: Some text removed due to RPL system decommissioned.

EFPM225: Some text removed due to RPL system decommissioned. Some text added for completeness.

EFPM217, EFPM232: IFPS Procedures: cases related to RPL removed. Related Sections: RPL sections removed.

EFPM243, EFPM245, ROUTE150, ROUTE318: Some text removed due to RPL system decommissioned.

EFPM330: OI/19-178 has been integrated: change in IFPS Procedures.

EFPM401: new error introduced by NM release 24.0.

GEN277: Some text removed due to RPL system decommissioned.

WARN313: some text amended and some text added.

147. ABBREVIATIONS Was previously section 157.

Amendment No. 44 to the IFPS USERS MANUAL


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xiv

The main changes are indicated RED with revision bars.

Significant deletions of text are indicated with the symbol


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xv

TABLE OF CONTENT

DOCUMENT CONTROL ................................................................................................... I

APPROVAL TABLE ......................................................................................................... I

EDITION HISTORY ......................................................................................................... II

EDITION CHANGE RECORD ........................................................................................... III

1 INTRODUCTION ............................................................................................ 1

1.1 Scope and Applicability ................................................................................ 1

1.2 Publication ................................................................................................... 2

1.3 Structure ...................................................................................................... 3

1.4 Terminology ................................................................................................. 3

2 NETWORK MANAGER OPERATIONAL CONTACTS......................................... 5

2.1 Operational Problem Reporting ..................................................................... 5

3 FLIGHT PLANS AND ASSOCIATED MESSAGES ............................................. 7

4 MESSAGE SUBMISSION TO THE IFPS ......................................................... 11

4.1 Aerodrome of Departure (ADEP) within IFPZ ............................................... 11

4.2 Aerodrome of Departure (ADEP) outside IFPZ ............................................. 11

4.3 Message Submission via Gateway .............................................................. 13

5 MESSAGE DISTRIBUTION BY THE IFPS....................................................... 15

5.1 Table of IFPS Message Distribution ............................................................ 17

6 RE-ADDRESSING ........................................................................................ 21

7 ATS DATA EXCHANGE PRESENTATION (ADEXP) ........................................ 23

8 OPERATIONAL REPLY MESSAGE (ORM) ..................................................... 29

9 ACKNOWLEDGEMENT (ACK) MESSAGE ...................................................... 31

9.1 General Procedure for Message Originators ................................................ 34

10 MANUAL (MAN) MESSAGE ......................................................................... 35


11 REJECT (REJ) MESSAGE ............................................................................ 37


12 COPY OPERATIONAL REPLY MESSAGE (ORM) ........................................... 41

12.1 General Procedure for Aircraft Operators .................................................... 41

13 DETERMINATION OF AIRCRAFT OPERATOR BY IFPS .................................. 43

14 ERROR TYPES ............................................................................................ 45

14.1 Syntax ........................................................................................................ 45

14.2 Expanded Flight Plan Message (EFPM) ....................................................... 45

14.3 General Route ............................................................................................ 45

14.4 Rerouteing ................................................................................................. 45


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xvi

14.5 Profile ........................................................................................................ 46

14.6 Warning ..................................................................................................... 46

14.7 Routing Assistance .................................................................................... 46

15 IMPROVEMENT IN QUALITY OF SUBMITTED MESSAGES ............................ 47

16 IFPS RE-ROUTE ACCEPTED (IFPSRA) ......................................................... 49

16.1 General Procedures associated to the use of IFPSRA .................................. 50

16.2 ANUs in the NM CACD Receiving ‘NO‘ ACK Messages ................................. 50

17 IFPS MANUAL PROCESSING PROCEDURES ................................................ 53

18 STANDARD CORRECTION PROCEDURE 1 (SCP1) ........................................ 55

18.1 SCP1 General Procedures .......................................................................... 55

18.2 SCP1 Table ................................................................................................ 56

18.3 Flights within the Rostov, Kaliningrad and Belarus FIR Airspaces ................ 58

18.4 Re-routeing Outside the IFPZ ...................................................................... 58

18.5 Flights with Route Coordinated with ATC .................................................... 59

18.6 Procedure for Military RPAS (Remotely Piloted Aircraft System)/UAS ............ (Unmanned Aircraft System) ...................................................................... 60

19 STANDARD CORRECTION PROCEDURE 2 (SCP2) ........................................ 61

19.1 SCP2 General Procedures .......................................................................... 61

19.2 SCP2 Table for Aerodrome of Departure, Destination or Alternate Destination . .................................................................................................................. 61

20 FLIGHT PLAN REPROCESSING ................................................................... 63

20.1 Filing time (or - 12 hours before EOBT) to - 1 hour (included) before EOBT .. 63

20.2 EOBT – 1 hour (excluded) to EOBT .............................................................. 64

20.3 General Procedures for REVAL_SUSPENDED ............................................... 65

20.4 General Procedures for REVAL_ADVISORY ................................................. 66

20.5 Associated Invalid Messages ..................................................................... 66

20.6 General Procedures for Message Originators .............................................. 67

21 ATC PRE-DEPARTURE FPL MODIFICATION (AMOD) ................................... 69

22 IFPSTOP/IFPSTART ................................................................................... 71

23 KEY FIELDS ................................................................................................ 73

24 MESSAGE ASSOCIATION ........................................................................... 75

24.1 Anomalies on Receipt of Duplicate Flight Plans ........................................... 76

25 PROFILE CALCULATION/ROUTE ANALYSIS ................................................ 77

26 MILITARY FLIGHTS .................................................................................... 81

26.1 General Procedures .................................................................................... 81

27 GENERAL AIR TRAFFIC/OPERATIONAL AIR TRAFFIC (GAT/OAT) ................ 83

28 MILITARY POINTS AND ROUTES ................................................................ 85

29 ADDRESSING ............................................................................................. 87

29.1 Processing by the IFPS ............................................................................... 87


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xvii

30 BLOCKING LEVELS ..................................................................................... 89

31 RAD FOR MILITARY FLIGHTS ..................................................................... 91

31.1 AIP/RAD for Military Flights ........................................................................ 91

32 OPEN SKIES FLIGHTS ................................................................................. 93

32.1 General Procedures for Open Skies Flights ................................................. 93

33 VISUAL FLIGHT RULES (VFR) ..................................................................... 95

34 NORTH ATLANTIC (NAT) TRAFFIC ............................................................. 99

35 FLEXIBLE USE OF AIRSPACE (FUA)/CONDITIONAL ROUTES (CDR) ............ 101

36 ROUTE AVAILABILITY DOCUMENT (RAD) ................................................. 103

36.1 General Procedures for Busy Friday and Public Holiday ............................. 105

36.2 General Procedures for RAD Errors due to a NM CACD Deficiency ............. 105

36.3 Preparation of On-line RAD Modifications ................................................. 106

36.4 RAD Errors for Profile ............................................................................... 107

36.5 Verification of RAD Restrictions per AIRAC Cycle ...................................... 109

36.6 RAD Units with Dependant Applicability .................................................... 110

36.7 Incorrectly Suspended Flights................................................................... 110

36.8 Flight Plan Messages on Closed NTFSR .................................................... 111

37 REDUCED VERTICAL SEPARATION MINIMA (RVSM) ................................. 113

38 8.33 KHZ CHANNEL SPACING .................................................................. 115

39 SSR MODE-S ............................................................................................ 119

40 EN-ROUTE STAY INDICATOR .................................................................... 121

41 IFPS MONITORING FLIGHT EVOLUTION ................................................... 123

42 SPECIAL STATUS FLIGHTS (STS) ............................................................. 125

42.1 Dynamic Properties of the STS Sub-field .................................................. 126

43 STS/SAR INDICATOR ............................................................................... 127

44 STS/HEAD INDICATOR ............................................................................. 129

45 STS/ATFMX INDICATOR ........................................................................... 131

46 STS/HOSP INDICATOR ............................................................................. 133

47 STS/HUM INDICATOR .............................................................................. 135

48 STS/STATE INDICATOR ........................................................................... 137

49 STS/NONRVSM INDICATOR ..................................................................... 139

50 STS/FFR INDICATOR ................................................................................ 141

51 STS/FLTCK INDICATOR ............................................................................ 143

52 STS/HAZMAT INDICATOR ........................................................................ 145

53 STS/MARSA INDICATOR .......................................................................... 147

54 STS/MEDEVAC INDICATOR ...................................................................... 149

55 STS/ALTRV INDICATOR ........................................................................... 151


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xviii

56 RUNWAY VISUAL RANGE (RVR) ................................................................ 153

57 ORIGINATOR (ORGN) INDICATOR ............................................................. 155

58 SOURCE (SRC) INDICATOR ....................................................................... 157

59 IFP INDICATORS ...................................................................................... 159

59.1 General Procedures .................................................................................. 161

60 IFPS TEST SYSTEM (IFPUV) ..................................................................... 163

60.1 General Procedures for IFPUV users ......................................................... 166

61 AIRCRAFT OPERATOR WHAT-IF RE-ROUTE (AOWIR) ................................ 169

61.1 OPTION 1a: The flight plan is changed ...................................................... 169

61.2 OPTION 1b: The system cancels the flight plan and a new flight plan is generated ................................................................................................................ 170

61.3 OPTION 2: The flight plan is cancelled and a new slot is booked ................ 170

62 DIVERSION ARRIVAL MESSAGES ............................................................. 173

63 ITEM 3: MESSAGE TITLE .......................................................................... 175

64 ITEM 7: AIRCRAFT IDENTIFICATION AND SSR MODE/SSR CODE .............. 177

65 ITEM 8: FLIGHT RULES AND TYPE OF FLIGHT ........................................... 179

66 ITEM 9: NUMBER AND TYPE OF AIRCRAFT AND WAKE TURBULENCE CATEGORY ................................................................................................................ 181

67 ITEM 10: EQUIPMENT & CAPABILITIES..................................................... 185

68 ITEM 13: AERODROME OF DEPARTURE (ADEP) AND ESTIMATED OFF-BLOCKS TIME (EOBT) ..................................................................................................... 189

69 ITEM 15: ROUTE ....................................................................................... 191

69.1 AIRAC Information incorrect in the NM CACD ........................................... 191

70 INITIAL SPEED AND LEVEL ....................................................................... 193

71 EN-ROUTE CHANGE OF SPEED AND LEVEL ............................................... 195

72 SID/STAR ................................................................................................. 197

72.1 General Procedures for SID/STAR............................................................. 198

72.2 Exceptional Procedures for SID/STAR ....................................................... 199

73 POINTS .................................................................................................... 201

73.1 General Procedure for Non Recognised Points .......................................... 202

74 AIRWAYS ................................................................................................. 203

74.1 General Procedures for Airways................................................................ 204

74.2 Conditional Route Categories ................................................................... 204

74.3 Mandatory DCT Route co-located with a Closed Airway ............................. 205

75 ITEM 16: A) DESTINATION AERODROME B) TOTAL ESTIMATED ELAPSED TIME C) ALTERNATE AERODROME(S) ................................................................... 207

76 ITEM 18: OTHER INFORMATION ............................................................... 211

77 ESTIMATED ELAPSED TIME (EET) ............................................................ 215


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xix

78 RE-CLEARANCE IN FLIGHT (RIF) ............................................................... 217

79 AIRCRAFT REGISTRATION (REG) .............................................................. 219

80 SELCAL (SEL) ........................................................................................... 221

81 AIRCRAFT OPERATOR (OPR) .................................................................... 223

82 STATUS (STS) .......................................................................................... 225

83 AIRCRAFT TYPE (TYP) ............................................................................. 227

84 AIRCRAFT PERFORMANCE (PER) ............................................................. 229

85 COMMUNICATIONS EQUIPMENT (COM) ................................................... 231

86 DATA LINK CAPABILITY (DAT) ................................................................. 233

87 NAVIGATION EQUIPMENT (NAV) .............................................................. 235

88 DEPARTURE AERODROME (DEP) .............................................................. 237

89 DESTINATION AERODROME (DEST).......................................................... 239

90 ALTERNATE DESTINATION AERODROME (ALTN) ..................................... 241

91 EN-ROUTE ALTERNATE AERODROME (RALT) ........................................... 243

92 REMARKS (RMK) ...................................................................................... 245

93 DATE OF FLIGHT (DOF) ............................................................................ 247

94 REPLACEMENT FLIGHT PLAN (RFP) ......................................................... 249

95 CODE ....................................................................................................... 251

96 STAYINFO ................................................................................................ 253

97 EUR/PROTECTED ..................................................................................... 255

98 PBN (PERFORMANCE BASED NAVIGATION) ............................................. 257

99 SURVEILLANCE (SUR) .............................................................................. 259

100 TAKE-OFF ALTERNATE (TALT) ................................................................. 261

101 EN-ROUTE DELAY OR HOLDING (DLE) ....................................................... 263

102 ADDITIONAL OUTPUT BY THE IFPS .......................................................... 265

103 ITEM 19: SUPPLEMENTARY INFORMATION ............................................. 267

103.1 General Procedures for errors in Item 19 .................................................. 268

104 TOTAL FUEL ENDURANCE: E/ ................................................................... 269

105 TOTAL NUMBER OF PERSONS ON BOARD: P/ ........................................... 271

106 EMERGENCY RADIO: R/ ............................................................................ 273

107 SURVIVAL EQUIPMENT: S/ ....................................................................... 275

108 LIFE JACKETS: J/ ..................................................................................... 277

109 DINGHIES: D/ ........................................................................................... 279

110 AIRCRAFT COLOUR AND SIGNIFICANT MARKINGS: A/ ............................. 281

111 OTHER SURVIVAL EQUIPMENT N/ ............................................................ 283



Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xx

112 PILOT IN COMMAND: C/ ........................................................................... 285


113 MESSAGE TYPES ..................................................................................... 287


114 FLIGHT PLAN (FPL) .................................................................................. 289

115 MODIFICATION (CHG) .............................................................................. 291

116 DELAY (DLA) ............................................................................................ 295

116.1 General Procedure for DLA Message Raises Route Availability or RAD Problems ................................................................................................................ 296

116.2 General Procedure for Difficulties in Processing DLA Messages due to AIRAC Switch ................................................................................................................ 296

117 CANCEL (CNL) ......................................................................................... 299

117.1 General Procedure for Multiple Associated Message Window containing a CNL Message .................................................................................................. 300

118 DEPARTURE (DEP) ................................................................................... 301

119 ARRIVAL (ARR) ........................................................................................ 303

119.1 General Procedure for Diversion ARR Message ......................................... 304

119.2 General Procedure for DIVARR Message Treatment .................................. 304

120 REQUEST FLIGHT PLAN (RQP) ................................................................. 305

121 REQUEST SUPPLEMENTARY FLIGHT PLAN (RQS) .................................... 307

122 AIRBORNE MESSAGE TYPES .................................................................... 309


122.2 General Procedure for Errors in the submitted Airborne Message Route .... 311

123 AIR-FILED FLIGHT PLANS (AFIL) .............................................................. 313


124 ATC FLIGHT PLAN PROPOSAL MESSAGE (AFP) ....................................... 315

124.1 AFP Association ....................................................................................... 320


125 AFP FOR A MISSING FLIGHT PLAN ........................................................... 323

126 AFP FOR A CHANGE OF ROUTE ................................................................ 327

127 AFP FOR A CHANGE OF AIRCRAFT TYPE .................................................. 333

128 AFP FOR A CHANGE OF FLIGHT RULES (IFR/VFR) ..................................... 337

129 AFP FOR A CHANGE OF FLIGHT TYPE ...................................................... 339

130 AFP FOR DIVERSION ................................................................................ 341

131 AFP FOR A CHANGE OF AIRCRAFT EQUIPMENT ....................................... 343

132 FLIGHT NOTIFICATION MESSAGE (FNM) .................................................. 347


133 MESSAGE FROM SHANWICK/SANTA MARIA (MFS) .................................. 351


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxi


134 ATC FLIGHT PLAN (APL) .......................................................................... 355

134.1 General Procedures for APL due to no Valid Association ........................... 355

134.2 APL Additional Addressing ....................................................................... 356

135 ATC FLIGHT PLAN CHANGE (ACH) ........................................................... 357

135.1 General Procedure for ACH with source FNM or MFS ................................ 357

135.2 ACH Additional Addressing ...................................................................... 358

136 VOICE COMMUNICATIONS SYSTEM (VCS) ............................................... 359

136.1 General Procedure for Contingency Diversion of Voice Communications System (VCS) ................................................................................................................ 359

137 THE TRANSMIT FUNCTION ...................................................................... 361


138 SERVICE AND OTHER NON-STANDARD MESSAGES.................................. 365

138.1 Rerouteing Requests from Individual States .............................................. 365

138.2 Internal Aircraft Operator Messages ......................................................... 365

138.3 Service Messages Requesting Re-transmission of a Particular Message ... 366

138.4 Service Messages Indicating an Unknown Local Address .......................... 366

138.5 Other Free text Messages and TAF/METAR messages .............................. 366

139 IFPS UNSERVICEABILITIES ....................................................................... 367

139.1 General .................................................................................................... 367

139.2 Responsible (IFPU1) ................................................................................. 367

139.3 Backup (IFPU2) ........................................................................................ 367

139.4 None ........................................................................................................ 367

139.5 General Procedures for IFPS Remote Login............................................... 367

139.6 Contingency Documentation ..................................................................... 368

140 SYSTEM MAINTENANCE AND INTERVENTIONS ....................................... 369

140.1 System Maintenance ................................................................................ 369

140.2 General Procedures for interventions ........................................................ 369

140.3 Planned Interventions ............................................................................... 369

140.4 Additional Interventions ........................................................................... 369

141 ETFMS UNSERVICEABILITIES ................................................................... 371


142 MANUAL CREATION OF MESSAGES ......................................................... 373


143 MESSAGE REJECTED BY PARTNER .......................................................... 375


143.2 Message Rejected by ETFMS .................................................................... 375

143.3 Message Rejected by the ANg1 ................................................................ 376

144 DICTIONARY OF ABBREVIATIONS ............................................................ 379


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxii

145 EUROCONTROL SPECIFICATION FOR THE INITIAL FLIGHT PLAN .............. 387

146 IFPS ERROR MESSAGES ........................................................................... 391

146.1 Error Class/Error Id: SYN32 ...................................................................... 391
























146.25 Error Class/Error Id: SYN87...................................................................... 417












146.37 Error Class/Error Id: SYN100 .................................................................... 429





Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxiii






















146.62 Error Class/Error Id: EFPM31 ................................................................... 458









146.71 Error Class/Error Id: EFPM166 ................................................................. 467














Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxiv























146.106 Error Class/Error Id: EFPM249 .................................................................. 505





146.111 Error Class/Error Id: ROUTE29 .................................................................. 510






146.117 Error Class/Error Id: ROUTE45 ................................................................. 517






146.123 Error Class/Error Id: ROUTE125 ................................................................ 524





Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxv


























146.152 Error Class/Error Id: ROUTE165 ............................................................... 554



















Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxvi











146.180 Error Class/Error Id: PROF50 .................................................................... 584

146.181 Error Class/Error Id: PROF53 .................................................................... 585

146.182 Error Class/Error Id: PROF173 .................................................................. 586



















146.201 Error Class/Error Id: GEN207 .................................................................... 607



146.204 Error Class/Error Id: RA274 ....................................................................... 610

146.205 Error Class/Error Id: RA281 ....................................................................... 611

146.206 Error Class/Error Id: WARN256 ................................................................. 612








Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: xxvii

ABBREVIATIONS ....................................................................................................... 621

TABLE OF FIGURES

Figure 1 - Flight Data Message Flows .............................................................................. 16

Figure 2 - Message Submitted to the IFPS ....................................................................... 54

Figure 3 - SCP1 Table for FPLs and Associated Messages .............................................. 57

Figure 4 - SCP2 Table for Aerodrome of Dep, Dest or Altn Destination ............................. 62

Figure 5 - IFPS Reprocessing Table 1 .............................................................................. 65

Figure 6 - IFPS Reprocessing Table 2 .............................................................................. 66

Figure 7 - Preparation of On-line RAD Modifications ...................................................... 107

Figure 8 - RAD Errors for Profile .................................................................................... 108

Figure 9 - IFPS Reference Graph for 8.33 kHz Flight Planning ........................................ 117


Edition Number: 24.0 Edition Validity Date: 30-06-2020 Classification: Green Page: 1

1 Introduction

A centralised flight plan processing and distribution service has been established under the authority of the EUROCONTROL Network Manager (NM). The service is provided by the Integrated Initial Flight Plan Processing System (IFPS) and covers that part of the ICAO EUR Region [International Civil Aviation Organization] (ICAO) known as the IFPS Zone (IFPZ).

This document provides all users of the IFPS with an easy to access reference manual. The manual is intended to contain all the necessary procedures and information in order for users to be able to construct, transmit or when necessary to correct, flight plan and associated update messages. Procedures for the distribution of such messages after processing by the IFPS are also described.

Correct and accurate application of the procedures contained in this document is essential to the achievement of consistent flight plan data among all relevant actors in the flight planning process.

Flight plans and associated update messages for all Instrument Flight Rules/General Air Traffic (IFR/GAT) flights, including the IFR portions of mixed Instrument Flight Rules/Visual Flight Rules (IFR/VFR) flights, entering, overflying or departing the IFPZ shall be addressed only to the two IFPS addresses for that portion of the flight within the IFPZ.

The IFPS shall check all messages received or changes thereto for:

Compliance with all format and data conventions.

Completeness and accuracy.

The IFPS shall take action to ensure that the flight plan is acceptable to air traffic services.

The IFPS shall indicate acceptance or rejection* of the flight plan or modification to the originator.

The IFPS shall ensure distribution of accepted flight plans and modifications thereto to all relevant Air Traffic Services Units (ATSUs) within its area of responsibility.

The IFPS shall also ensure re-addressing of accepted messages to any additional Aeronautical Fixed Telecommunication Network (AFTN) addresses as requested by the message originator.

The IFPS shall process supplementary messages including request flight plan messages and request supplementary flight plan messages.

Basic rules for the submission of flight plan messages and associated updates have been defined in ICAO Annex 2 and Documents 4444 and 7030. These requirements are applicable to flight plans and associated messages handled by the IFPS.

The IFPS does not process coordination or control messages. However, a number of special messages containing current flight plan information are received and processed by IFPS mainly for Air Traffic Flow and Capacity Management (ATFCM) purposes. These input messages are ATC Flight Plan Proposal (AFP) (message), Message from Shanwick/Santa Maria (MFS) and Flight Notification Message (FNM). Following processing by the IFPS, ATC Flight Plan (APL) (message) or ATC Flight Plan Change (ACH) message is output to all relevant ATSUs.

(*) By default, the originator is set to receive Operational Reply Messages (ORMs) ACK, MAN and REJ from IFPS. The originator has the possibility to configure whether to receive ORMs or not. Nevertheless, for flight plan consistency and safety, it is strongly recommended to keep the standard setting, which is the reception of all ORMs.

1.1 Scope and Applicability

This document applies to the process of flight plan submission, modification and distribution.



The provisions of the document apply to all personnel engaged in these processes, namely:

Network Operations staff engaged in IFPS operations. Aircraft Operators (AOs). ATS Reporting Offices (AROs). Message originators.

Air Traffic Services Units (ATSUs) while processing flight plan data.

For flight plan and associated update messages the provisions of this document apply to the pre-flight phase. The pre-flight phase ends at the earlier of the following events:

Aircraft start-up.

First delivery of airways clearance at Aerodrome of Departure (ADEP) within, or on contact with first ATSU on entering the IFPZ.

Time of first Air Traffic Control (ATC) activation at ADEP within, or on contact with first ATSU on entering the IFPZ.

During the flight phase some special messages regarding current flight plan information are received by the IFPS from ATSUs, processed and distributed.

The procedures in this document apply to the initial flight planning process for all IFR GAT portions of flights intended to be conducted in any part of the IFPZ. The list of States comprising the IFPZ is shown in the section titled Message Distribution by the IFPS.

This document forms part of the Network Operations Handbook as referred to in ICAO document, REGIONAL SUPPLEMENTARY PROCEDURES, EUR REGION (DOC 7030). It is published by the Network Manager. Versions of the manual shall normally be published at least one month prior to the date of applicability and the date of application of the procedures shall be notified in each issue.

Specific temporary procedures may be introduced under the authority of the Network Manager in order to deal with temporary problems that arise from observed data or system deficiencies. Such temporary amendments shall not have a validity exceeding 18 months and shall expire or be incorporated into the manual by the end of the indicated validity period.

This document shall replace previous versions of the Network Operations HANDBOOK – IFPS Users Manual.

1.2 Publication

This document is in the public domain. It is available for consultation and for download on the

EUROCONTROL Internet Site:

http://www.eurocontrol.int/network-operations#library

Part 6 (see below 1.3 Structure) of this manual is also available as web application and can be accessed on the following internet site: https://contentzone.eurocontrol.int/fpl

Any update of this document shall be published as an Operational Instruction and takes precedence over the manual. Updates are available on the NOP Portal under the Network Handbook Portlet>Network Operations Procedure Updates: http://www.nm.eurocontrol.int/STATIC/html/indexProcedureUpdates.html (Flight Planning tab).

All new updates shall be notified in the Network Headline News on the NOP (Network Operations Portal).

Any feedback, remarks or questions about the content this manual or the web application can be communicated by using the following email address: [email protected]

http://www.eurocontrol.int/network-operations#library

https://contentzone.eurocontrol.int/fpl

http://www.nm.eurocontrol.int/STATIC/html/indexProcedureUpdates.html

mailto:[email protected]



1.3 Structure

The document is organised into 7 PARTS as follows:

Introduction (this Part).

Part 1: General procedures and Specifications and for flight plans and associated messages. Part 2: General Procedures and Specifications by flight plan item. Part 3: General Procedures and Specifications for message type. Part 4: General Procedures and Specifications by airborne message types.

Part 5: Miscellaneous procedures and Specifications covering items other than flight plans and associated messages.

Part 6: IFPS errors with Reason, Requirements and corresponding procedures.

Within each part the document is organised by subject (see table of contents). For each subject the following structure is used as appropriate (except for Part 6):

(1) General

A general description of the operational functionality.

(2) Requirements

Requirements for processing the referenced functionality.

(3) Message Format

Specific message format requirements (where relevant).

(4) System Processing

Description of the processing (input, internal processing, output).

1.4 Terminology

The supervisory function in IFPS and AD is performed by:

NOSU: Network Operations Supervisor and SNOS: Senior Network Operations Supervisor

The operator function in IFPS is performed by:

NOO: Network Operations Officer and NOS: Network Operations Specialist

In the present document:

Where IFPS Supervisor(s) is mentioned, it refers to NOSU and SNOS unless specifically specified within the text.

Where IFPS staff is mentioned it refers to NOO, NOS, NOSU, SNOS unless specifically specified within the text.



Where AD Supervisor is mentioned it refers to NOSU and SNOS unless specifically specified within the text.

Where IFPS is used alone it refers to the “System”.



2 NETWORK MANAGER OPERATIONAL CONTACTS

The responsibility for processing invalid flight plan messages in IFPS is shared between two IFPS Units. Each invalid message is manually edited at one of the IFPS Units on a first come, first served basis (with exceptions for messages with special status, which are given a priority in the invalid queue).

Note All messages sent to the IFPS for processing shall be sent to both units.

When telephone contact regarding flight data is necessary, the user should contact one of the IFPS units (IFPU).

The contact details below provide the AFTN and the Société Internationale de Télécommunications Aéronautiques (SITA) addresses to which messages should be submitted to the relevant units and sections, plus the contact telephone numbers to call in the event of specific on-line problems.

IFPS

FP1 - Brussels (Haren) FP2 – Paris (Brétigny)

AFTN EUCHZMFP EUCBZMFP

SITA BRUEP7X PAREP7X

Ops Telephone ++ 32 (0)2 745 1950 ++ 33 (0)1 6988 1750

Ops Fax ++ 32 (0)2 729 9041 ++ 33 (0)1 6988 3822

IFPUV

AFTN EUCHZMFV

SITA BRUEY7X

Note The IFPS Unit for Validation (IFPUV) is a fully automated system and shall normally be used by external message originators independently.

Network Manager Website

http://www.eurocontrol.int/network-manager

2.1 Operational Problem Reporting

Operational problem reporting is covered in detail in the ‘NM Operational Problem Reporting’, which is a part of the Network Operations Handbook, including links to and copies of the relevant reporting forms.

http://www.eurocontrol.int/network-manager



INTENTIONALLY BLANK PAGE



3 FLIGHT PLANS AND ASSOCIATED MESSAGES

1) General

To ensure successful distribution of flight plans to air traffic service units, a flight plan that accurately represents the intentions of the flight must be submitted to, and acknowledged by the IFPS before the flight may operate under IFR as GAT within the IFPZ.

One of the aims of the IFPS is to reduce the number of sources of flight plan data within the IFPZ to a single point, thus maximising the consistency of flight data available operationally. To achieve this, all flight plans and associated messages for IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be submitted to the IFPS for processing. Only upon receipt of an Acknowledgement (ACK) message from the IFPS may the message originator consider that message to be processed. Any exceptions to this rule are detailed in the relevant message type section of this document. In order to further improve the consistency of flight data, the re-addressing function of the IFPS has been developed.

Note The ACK message is a means whereby the IFPS indicates successful processing of a submitted message against the environmental data held by the Network Manager at the time of processing that message.

Such a processing may only take into account the criteria specified by the relevant Member States against which they require flight plan messages to be checked by the IFPS. As such, successful processing by the IFPS cannot guarantee that a processed message is fully in accordance with each Member State’s requirements, where they are not known to the NM CACD, nor does it ensure the correctness of any part of a flight that takes part outside the IFPZ.

The IFPS processing does not take into account criteria such as overflight or diplomatic clearances, ETOPS requirements, SAFA constraints, MNPS requirements, etc., so any message originator in receipt of an IFPS ACK message must also take into consideration such constraints and requirements.

For any valid flight plan, the IFPS will reprocess that flight plan after its initial processing and ACK. The ACK for that initial processing shall not ensure compliance against the relevant criteria coincident with the EOBT of that flight, and a suspension or an IFPS-coordinated modification of that flight plan may occur should the IFPS be notified of any change made to the relevant airspace conditions.

Flight plans and associated messages for all IFR flights, the IFR parts of mixed IFR/VFR flights, and the GAT parts of mixed GAT/OAT flights, operating wholly or in part within the IFPZ, shall be addressed only to the two IFPS addresses for that IFR/GAT part of the flight within the IFPZ.

Those flight plans and associated messages that are both syntactically and semantically correct shall normally be processed automatically by the IFPS. Where inconsistencies in the syntax or semantics of messages submitted for processing are found by the IFPS, those messages shall normally fail automatic processing and may be passed for manual treatment by the IFPS staff or be rejected automatically.

The originator, when not being the operator or the pilot, shall ensure that the conditions of acceptance of a flight plan and any necessary changes to these conditions as notified by IFPS are made available to the operator or the pilot who has submitted the flight plan.

The operator shall ensure that the conditions of acceptance of a flight plan and any necessary changes thereto as notified by IFPS to the originator are incorporated into the planned flight operation and communicated to the pilot.



The IFPS shall build a four dimensional profile for every flight, based on the profile calculated from the flight plan. Where an associated message is processed, the existing profile shall be re-calculated, incorporating the revised data held in that associated message.

When the calculated profile is completed, the IFPS shall then construct a schedule of events planned for that flight. That schedule shall list all those AFTN and SITA addresses to which the message shall be transmitted, and at what time. The transmission time calculated by the IFPS shall take into account those transmission time parameters held in the NM CACD that have been specified by the Air Traffic Control Unit (ATCU) to which the message is being transmitted.

When a message submitted to the IFPS for processing has been acknowledged, the IFPS shall send a copy to the Enhanced Tactical Flow Management System (ETFMS) where the flight shall be analysed for any flow regulations that may be relevant for that flight.

Note The IFPS and ETFMS are separate systems; any message submitted to the IFPS must be acknowledged before it is transmitted to the ETFMS, where any relevant flow regulations may then be applied.

The IFPS shall also calculate at what time the flight plan shall close. Such a closure shall be the time at which the flight plan details become unavailable for any further associated messages, and the flight details are no longer available to external users of the IFPS. The close time of a flight shall either be upon successful processing of an arrival message, 2 hours after the flight is terminated in the ETFMS or 8 hours after the total Estimated Elapsed Time (EET) of that flight; whichever comes first. Until the flight is closed, it shall remain accessible and available for certain associated messages depending on the type and content of those messages as defined in section IFPS Monitoring Flight Evolution. The flight details shall remain available within the IFPS to a maximum of 24 hours after the closure of that flight, after which time the details shall be archived and shall not be directly available to the IFPS operational staff.

The message format used by the IFPS when making manual corrections to those messages that have failed automatic processing shall be the format in which those messages were originally submitted. The format used for the transmission of processed messages shall be determined by the requirements specified by each recipient in the NM CACD.

In order to prevent confusion and the incorrect sequence of processing of submitted messages by the IFPS (and the subsequent distribution of those messages), it is important that message originators do not submit a subsequent associated message until the first message to be submitted has been fully processed by the IFPS. This means that where a message originator has already submitted a message to the IFPS for processing, and subsequently needs to submit another associated message (of any message type), that message originator should wait until they have received an Acknowledgement (ACK) or a Reject (REJ) message from the IFPS for the first message before they submit the second, associated message. It should be noted that receipt of a Manual (MAN) message is not sufficient to act as a trigger for the submission of the subsequent associated message.

Once acknowledged and distributed by the IFPS, a flight plan message is then subject to the requirements of European Commission Regulation (EC) No 1033/2006 on flight plans. This regulation provides a requirement for ATC Units to make available, through the IFPS, any necessary changes affecting the route or flight level key items of a flight plan that could affect the safe conduct of a flight, for flight plans and associated update messages previously received by them from the IFPS.

No other changes to or cancellation of a flight plan shall be made by an ATC Unit in the pre-flight phase without coordination with the operator.

The objective of the regulation is to ensure greater consistency in flight plan data that would contribute to the seamless operation of the network, to support for new concepts of operations, notably in the field of air traffic flow management, and to enhance safety.



A detailed description of each flight plan Item is given in this manual, giving a general comment where necessary, the requirements for each Item, the correct format, and an indication of the associated errors and their required remedial action.

Note 1 The United Kingdom and Ireland’s Standard Route Document (SRD) is produced by NATS to assist AOs in constructing RAD-compliant route portions within UK and Irish airspace. The SRD is not a mandatory document, and the routes contained within should be considered as preferred routeings only. The routes are promulgated to identify optimum routeings for operators with due regard to ATFCM requirements. The IFPS is not obliged to comply with the SRD, and when processing messages, the IFPS staff shall only validate messages in accordance with current and relevant Route Availability Document (RAD) restrictions and route availability requirements.

Note 2 The IFPS staff have a tool available, known as the Transmit function, which shall allow the staff to send plain text messages to AFTN or SITA addresses from the IFPS workstations. This tool may be used for a variety of reasons, but one of the primary purposes is to send information helpful to a message originator for re-submitting a rejected message, when no direct contact is possible with that message originator to coordinate the required corrections and when the POSRTE field present in some REJ messages is not sufficient.

2) Requirements

Flight plans shall be submitted to the IFPS for processing at least three hours before the EOBT where possible. The IFPS shall also accept for processing those messages that are, for operational reasons, filed less than three hours before the EOBT of that flight.

Flight plans may be submitted up to a maximum of 120 hours, or five days, in advance of the EOBT of that flight plan. Those flight plans that are submitted more than 24 hours in advance of the flight shall include the date of flight.

Note The acceptance parameter of 120 hours, or five days, by the IFPS for those flight plans filed in advance is calculated from the EOBT of the flight.

Where messages have failed automatic processing and have been presented for manual treatment, the IFPS staff shall use any necessary current operational instructions and information in the correction of those messages.

It is strongly recommended that the Date Of Flight (DOF) is included in all flight plans and associated messages submitted to the IFPS for processing.

Any changes of more than 15 minutes to the EOBT of a filed flight plan shall be communicated to the IFPS. The IFPS shall not accept negative delays: should the EOBT of a flight need to be changed to an earlier time that flight must be cancelled and re-filed with the earlier EOBT.

Note Although it is not a requirement to update the EOBT of a non-ATFM-regulated flight where the change is not more than 15 minutes, it is recommended to make such an update to the flight plan held by the IFPS.

Flight plan data may be updated with any time, level or route changes, and any other changes except key fields, as necessary.

Flight plans and associated messages shall be distributed to the relevant ATCUs by the IFPS at a pre-determined time prior to the calculated entry time of that flight to that airspace.

When an individual flight plan (FPL) has been filed but it is decided, within 4 hours of EOBT, to use an alternative routeing between the same aerodromes of departure and destination, either a modification message (CHG) may be sent or alternatively:

a) a cancellation message (CNL) shall be sent to IFPS; b) not less than 5 minutes after sending the CNL message, a replacement flight plan (RFP) in

the form of an FPL with identical call sign shall be transmitted;



c) the RFP shall contain, as the first element of Item 18, the indication ’RFP/Qn’, (see section ’Replacement Flight Plan (RFP)’ for details of this procedure); and

d) the last RFP shall be filed at least 30 minutes before EOBT.

Those messages that fail automatic processing and are rejected Reject (REJ) message by the IFPS shall have attached an error message or messages. Each error message shall give an indication of the reason why that message has been rejected, and it shall be the responsibility of the message originator to arrange any necessary corrections to that message before it is re-submitted to the IFPS.

Until a flight plan held by the IFPS is cancelled or closed, it shall remain accessible for certain updates (see section IFPS MONITORING FLIGHT EVOLUTION). Message originators should not file a second flight plan where one already exists in the IFPS for the same flight.

3) Message Format

A detailed description of the format of each message type is given in the appropriate Section.

4) System Processing

A detailed description of the system processing of each message type is given in the appropriate Section.



4 MESSAGE SUBMISSION TO THE IFPS

1) General

The procedures outlined in this SECTION should not be considered as taking precedence over those published in National Aeronautical Information Publications (AIP).

In order to prevent confusion and the incorrect sequence of processing of submitted messages by the IFPS (and the subsequent distribution of those messages), it is important that message originators do not submit a subsequent associated message until the first message to be submitted has been fully processed by the IFPS. This means that where a message originator has already submitted a message to the IFPS for processing, and subsequently needs to submit another associated message (of any message type), that message originator should wait until they have received an ACK or REJ message from the IFPS for the first message before they submit the second, associated message. It should be noted that receipt of a MAN message is not sufficient to act as a trigger for the submission of the subsequent associated message.

The means of submission of flight plans and associated to messages to the IFPS are: AFTN, SITA and B2B.

The method of submission of flight plans and associated messages is dependent upon the location of the aerodrome of departure:

4.1 Aerodrome of Departure (ADEP) within IFPZ

Flight plans and associated messages for IFR/GAT flights departing from an aerodrome within the IFPZ shall, if authorised by the State concerned, be submitted directly to the IFPS and not via the Air Traffic Services Reporting Office (ARO) at the departure aerodrome.

AOs who are unable (e.g. no AFTN or SITA terminal) to submit their flight plan or associated messages directly to the IFPS shall submit the flight plan messages to the ARO of the departure aerodrome.

It shall be the responsibility of the ARO to ensure submission to the IFPS for processing of any flight plans or associated messages relating to IFR/GAT flights or parts thereof intending to operate within the IFPZ submitted to that ARO by the relevant AO or their representative.

AOs shall ensure that the flight plan or associated message is always submitted either directly to the IFPS or to the ARO at the departure aerodrome, but not both.

4.2 Aerodrome of Departure (ADEP) outside IFPZ

Flight plans and associated messages for IFR/GAT flights entering the IFPZ from a departure aerodrome outside the IFPZ shall be submitted in accordance with the procedures applicable within the State concerned.

It shall be the responsibility of the ARO to ensure submission and acceptance by the IFPS for processing of any flight plans or associated messages relating to IFR/GAT flights or parts thereof intending to operate within the IFPZ submitted to that ARO by the relevant AO or their representative.

AOs shall ensure that, once submitted to the ARO, their flight plans and associated messages are acknowledged by IFPS before the operation of the flight and that any changes notified by IFPS are communicated to the pilot.

2) Requirements



All messages submitted to the IFPS for processing (via AFTN or SITA) shall be submitted to both IFPS units.

Submission of “test” flight plans to IFPS is not allowed. Message originators who wish to test flight plans shall use the IFPUV (IFPS test system). Access to IFPUV is possible via AFTN, SITA, NOP (Public & Protected), CHMI and B2B [see section IFPS Test System (IFPUV) for more details].

All flight plans and associated messages for IFR/GAT flights or parts thereof operating within the IFPZ should, as far as possible, be submitted to the IFPS for processing at least 3 hours prior to the EOBT of that flight.

For those IFR/GAT flights departing within the IFPZ and proceeding outside, and for those IFR/GAT flights that depart outside the IFPZ and proceed to enter, it shall remain the responsibility of the message originator to ensure that the relevant ATCUs outside the IFPZ are addressed.

That function shall not be undertaken by the IFPS unless those addresses are added under the re-addressing function to any message submitted to the IFPS for processing.

The IFPS shall not process messages relating to flights operating completely under VFR conditions. However, those flights planning to operate under mixed IFR/VFR conditions within the IFPZ shall submit any flight plan and associated messages to the IFPS in order that the IFPS may process only those parts of that flight operating under IFR conditions. It shall remain the responsibility of the message originator to ensure distribution of the flight plan and any associated messages for those parts of that flight operating under VFR conditions. That function shall not be undertaken by the IFPS unless those addresses are added under the re-addressing function [see section RE-ADDRESSING] to any message submitted to the IFPS for processing.

The IFPS shall not process messages relating to flights operating under completely OAT conditions. However, those operators planning flights under mixed OAT/GAT conditions within the IFPZ shall submit any flight plan and associated messages to the IFPS in order that the IFPS may process only those parts of that flight operating under GAT conditions. It shall remain the responsibility of the message originator to ensure distribution of the flight plan and any associated messages for those parts of that flight operating under OAT conditions.

That function shall not be undertaken by the IFPS unless those addresses are added under the re-addressing function to any message submitted to the IFPS for processing.

The IFPS shall not include any alternate aerodromes in the automatic addressing process. Where the message originator requires a copy of the flight plan or associated message to be sent to the alternate aerodrome, it shall be the responsibility of the message originator to include any relevant addresses in the re-addressing function of that message.

3) Message Format

All flight plans and associated messages for IFR/GAT flights or parts thereof intending to operate within the IFPZ, when filed via AFTN or SITA, shall be addressed only to the two IFPS addresses for that portion of the flight within the IFPZ.

The IFPS addresses for all flight plan and associated message submissions via AFTN or SITA are:

Network FP1 Haren, Belgium FP2 Brétigny, France

AFTN EUCHZMFP EUCBZMFP

SITA BRUEP7X PAREP7X

Note All flight plans and associated messages must be addressed to both IFPS Units either via the AFTN network or the SITA network, but not both networks.




In submitted flight plans, the IFPS shall accept an EOBT of up to 30 minutes in the past when compared to the filing time as being a valid flight for that same day where no Date Of Flight (DOF) is included to indicate otherwise. If the EOBT is more than 30 minutes in the past when compared to the filing time, and no DOF is included in the message, the IFPS shall assume that flight is for the following day, and process it as such, including the addition of the appropriate DOF.

Where a DOF is included in the flight plan, the IFPS shall take that information into account when processing the EOBT.

For practical reasons it shall be possible for the IFPS to process those flight plans that contain an EOBT of more than 30 minutes in the past compared to the filing time (but not more than 12 hours in the past) and a DOF that is not more than 12 hours in the past. The flight plan shall fail automatic processing but may be manually forced through processing by the IFPS staff.

4.3 Message Submission via Gateway

Those message filers intending to use a SITA/AFTN Gateway shall indicate this intention to the NM in advance; failure to do so may result in no response from the IFPS.

When an AFTN Gateway is used, addresses must be inserted correctly to ensure that a message is transmitted to the IFPS only once. To ensure this, the two IFPS unit addresses must appear either on the SITA address line or the AFTN address line, but not both.

Example of a correctly formatted message routed via a Gateway

QU LONYFYX

LHRABCX 020912 / 7R02080C

FF EUCHZMFP EUCBZMFP

020910 EGLLABCX

(FPL- ABC123-IS

…….

The message is addressed via SITA only to the Gateway address of London (LONYFYX). The two IFPS addresses are given only in the AFTN header, thus the IFPS shall only receive the message via AFTN.

Example of an incorrectly formatted message routed via a Gateway

QU LONYFYX BRUEP7X PAREP7X

EGLLABCX AY/021326 MAY04


020910 EGLLABCX

(FPL-ABC123-IS

…….

The message contains the IFPS SITA addresses (BRUEP7X PAREP7X) in the SITA header together with the Gateway address (LONYFYX). In addition, it also contains the IFPS AFTN addresses (EUCHZMFP EUCBZMFP) in the message text, with the result that the message text, including the AFTN header information, is received by the IFPS directly via SITA, and is then received by the IFPS again via AFTN from the Gateway.






5 MESSAGE DISTRIBUTION BY THE IFPS

1) General

All flight plans for IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be submitted to the IFPS for processing. All such flight plan information must originate with the AO, who then has the option of submitting the flight plan directly to the IFPS, or passing the flight plan to an ARO.

Where the flight plan is submitted directly by the AO, or via an ARO, the IFPS shall respond to such submissions with ORMs to indicate the status of each of their submitted messages.

The IFPS shall build a four-dimensional profile for every IFR/GAT flight or part thereof that is planned to operate within the IFPZ, based on the filed route, flight level(s), speed(s), EOBT and aircraft performance.

This profile is constructed for several purposes, one of which is to calculate those airspaces that flight shall penetrate, and therefore to identify which air traffic services units shall require a copy of the flight plan or any associated messages for that flight. In identifying all the relevant ATCUs, the IFPS shall calculate at what time prior to the arrival of that flight in any of those airspaces to send the flight data to that controlling ATCU. The time parameter in this calculated distribution of messages is a time specified by each ATCU, and held in the NM CACD.

The distribution of messages according to the specified times for each airspace shall depend upon how far in advance of the EOBT of the flight plan or associated messages are submitted to the IFPS for processing.

Where a flight plan is filed sufficiently in advance of the EOBT of that flight, the IFPS shall calculate a timed distribution of that message to the ATCUs along the trajectory of that flight, and shall distribute that flight plan at the time specified by each unit.

In the event of a late-filed flight plan or associated message, the IFPS may send that message out to all the relevant ATCUs immediately; as such, messages may arrive in the IFPS within the required receipt time of the relevant ATCUs.

The IFPS shall also send a copy of each processed message to the ETFMS in order that any relevant flow management restrictions may be applied to that flight as appropriate. The time parameter specified by the ETFMS for distribution of messages by the IFPS is set at 48 hours in advance of EOBT.

Should an associated message cause a change in the trajectory of an existing flight that has already been distributed to the relevant ATCUs along the route, to the extent that the flight is re-routed out of some airspaces and into new ones, the IFPS shall send a modification message (CHG) to those airspaces within which the trajectory of the flight has altered, and a flight plan to those previously-unaddressed airspaces that will handle that flight on any part of the revised trajectory.

All associated messages shall also be transmitted by the IFPS to the ETFMS in order to maintain a real picture of that flight and any impact it may have on flow management.



Figure 1 - Flight Data Message Flows

The IFPS shall not process those flight plans that indicate only VFR or OAT conditions, however, where a flight plan is submitted for a flight that is IFR/GAT for any part within the IFPZ, then the IFPS shall process that part or parts of that flight plan. For such mixed IFR/VFR and GAT/OAT flight plans, the IFPS shall only calculate the addressing for the distribution of that flight plan within the part or parts that are planned to operate as IFR/GAT; it shall not calculate any addressing for distribution to those parts of a flight that are planned to operate under VFR or as OAT.

However, where the departure or destination aerodrome is an identifiable ICAO indicator, and the flight is planned to depart or arrive under VFR conditions, the IFPS shall include that departure or destination aerodrome in the message distribution, where that aerodrome has a specified requirement to receive such flight data messages from the IFPS.

After a VFR portion, the current level of the flight is not known at the point where the flight returns to IFR. To ensure that flight plan messages are addressed to all ATC units that may be impacted by the



flight, the IFPS shall address all the AUAs from ground to the current RFL at the point where the flight changes to IFR.

The IFPS shall only automatically distribute messages to those addresses within the IFPZ area for those flights or parts thereof operating under IFR as GAT. Where an IFR/GAT flight exits the IFPZ at any point or points, the IFPS shall not automatically include the addresses of any ATCUs relevant to that flight that are external to the IFPZ unless they have been specified by the message originator in the re-addressing function or have special arrangements for the copy of flight plan messages agreed with Eurocontrol.

It should be noted that IFPS shall not distribute automatically flight plan and associated messages to any specified alternate aerodrome(s). Should a message originator require a flight plan or associated message to be sent to the alternate destination aerodrome(s), then the message originator should use the re-addressing function and insert the relevant AFTN addresses [see section RE-ADDRESSING].

It should be noted that on processing an arrival message, the IFPS shall distribute that message only to the aerodrome control tower, approach and ATS reporting office of the aerodrome of departure and en-route ATCUs, where the units have specified a requirement to receive such messages, and is located within the IFPZ. The IFPS shall also send a copy of the arrival message to any addresses included in the re-addressing function. Diversion arrival messages are distributed to all recipients of the initial FPL, not taking into consideration of the unit’s requirement to receive ARR messages.

Airborne messages; those messages affecting a flight in progress; processed by the IFPS shall only be distributed by the IFPS to those affected ATCUs downstream of the unit submitting the message; the unit submitting the airborne message shall not be sent a copy of the processed message, other than an ORM.

Both the Kaliningrad and Rostov FIRs are not considered to be within the IFPZ, and although messages are sent by the IFPS to the Kaliningrad and Rostov FIRs, they are only copies that are sent to a central address from which domestic distribution is made by the relevant authorities.

The Department of Aviation of the Ministry of Transport and Communications of the Republic of Belarus has an agreement with Eurocontrol to enable the provision of flight plan messages to Minsk ACC in order to improve the completeness and accuracy of flight plan information held by Minsk ACC and the Flight Planning Unit of Minsk ACC.

5.1 Table of IFPS Message Distribution

State Country

Code

IFPZ

(FPM DIST) FIR/UIR ICAO

Albania LA Yes Tirana LAAA

Armenia UD Yes Yerevan UDDD

Austria LO Yes Vienna LOVV

Azerbaijan UB Yes Baku UBBA

Belarus UM Copy only Minsk UMMV

Belgium EB Yes Brussels EBBU/EBUR

Bosnia and Herzegovina LQ Yes Sarajevo LQSB

Bulgaria LB Yes Sofia LBSR

Croatia LD Yes Zagreb LDZO

Cyprus LC Yes Nicosia LCCC

Czech Republic LK Yes Prague LKAA



State Country

Code

IFPZ


Denmark EK Yes Copenhagen EKDK

Estonia EE Yes Tallinn EETT

Finland EF Yes Finland EFIN

France LF Yes

Paris

Reims

Brest

Bordeaux

Marseille

LFFF

LFEE

LFRR

LFBB

LFMM

Georgia UG Yes Tbilisi UGGG

Germany ED Yes

Bremen

Langen

Munich

Rhein

Hanover

EDWW

EDGG

EDMM

EDUU

EDVV

Greece LG Yes Athens LGGG

Hungary LH Yes Budapest LHCC

Ireland EI Yes Shannon

SOTA

EISN

EISN

Israel LL Yes Tel-Aviv LLLL

Italy LI Yes

Rome

Brindisi

Milan

LIRR

LIBB

LIMM

Latvia EV Yes Riga EVRR

Lithuania EY Yes Vilnius EYVL

Luxembourg EL Yes Brussels EBBU/EBUR

North Macedonia LW Yes Skopje LWSS

Malta LM Yes Malta LMMM

Republic of Moldova LU Yes Chisinau LUUU

Monaco (Marseille) LN Yes Marseille LFMM

Morocco GM Yes Casablanca GMMM

The Netherlands EH Yes Amsterdam EHAA

Norway EN Yes Norway

Bodo Oceanic

ENOR

ENOB

Poland EP Yes Warsaw EPWW

Portugal LP Yes Lisbon

Santa Maria

LPPC

LPPO

Romania LR Yes Bucharest LRBB

Rostov FIR (Russian Federation) URR Copy only

Kaliningrad FIR (Russian Federation) UMK Copy only



State Country

Code

IFPZ


Slovak Republic LZ Yes Bratislava LZBB

Slovenia LJ Yes Ljubljana LJLA

Spain LE Yes

Barcelona

Madrid

Canaries

LECB

LECM

GCCC

Sweden ES Yes Sweden ESAA

Switzerland LS Yes Switzerland LSAS

Turkey LT Yes Ankara

Istanbul

LTAA

LTBB

Ukraine UK Yes

L’Viv

Kyiv

Dnipropetrovsk

Odessa

Simferopol

UKLV

UKBV

UKDV

UKOV

UKFV

United Kingdom EG Yes

London

Scottish

Shanwick (OCA)

EGTT

EGPX

EGGX

Serbia and Montenegro LY Yes Belgrade LYBA






6 RE-ADDRESSING

1) General

In order to provide a single source of flight plan data for all ATCU, both inside and outside the IFPZ, the re-addressing function of the IFPS has been developed. This function provides a mechanism by which consistency between the flight plan data distributed inside the IFPZ and that distributed outside the IFPZ is possible.

This function is only available where the addresses specified by the message originator are AFTN addresses; it may not be used for SITA addresses.

Re-addressing may be used in any flight plan or associated message submitted to the IFPS for processing.

The re-addressing function is available for flight plans or associated messages submitted in ICAO and ADEXP format and also for flight plans submitted via the NOP.

2) Requirements

The IFPS shall transmit a copy of a message to any AFTN addresses specified by the message originator in the re-addressing function of that message.

The IFPS shall not accept any SITA addresses specified by the message originator in the re-addressing function of any message.

The IFPS shall not confirm the correctness of any addresses submitted in the re-addressing function, other than that the syntax conforms to that of the AFTN.

The IFPS shall retain any AFTN addresses specified by the message originator in the re-addressing function of any submitted message, and the IFPS shall automatically include those addresses in the distribution of subsequent associated messages submitted to the IFPS for processing.

3) Message Format

ICAO format message:

The extra addresses for re-addressing shall be included in the message text after the originator information line and immediately before the opening bracket of the message. A maximum of 7 AFTN addresses is allowed per line of extra addressing, and each line shall begin with the letters ‘AD’ separated by a space from the first address.

Example

ZCZC BDB01 230845


230830 EGLLABCU

AD EGGXZOZX CZULZQZX CYHQZDZX CZBNZZZX CZQXZQZX CZQMZQZX KZBWZQZX

AD KJFKABCU

(FPL-ABC567-IS

-B744/H-SDWIRYH/S

-EGLL1200

------

------)



ADEXP format message:

The extra addresses for re-addressing shall be included in the message text as –FAC addresses contained within the –EXTADDR field.

Example

-EXTADDR –FAC EGWWZTZX –FAC EBBRZTZX

Should a message text become too long (maximum total number of characters allowed in a message is 2100 including header; 1800 pure text, depending on network type) to include all the extra addresses the message should be transmitted a second time to the IFPS including, in the extra address line, the additional extra addresses.

Flight plan submission via the NOP:

The extra addresses for re-addressing can be added in both the Free text and Structured editor. The editors perform a syntax check each time an address is added. The syntax is 8 characters.


Where the re-addressing function is used for a message submitted to the IFPS for processing, the IFPS shall indicate in the ACK the number of addresses in the re-addressing function that have been successfully processed. In the event that any addresses in the re-addressing function are submitted as incomplete, the IFPS shall invalidate that message.

Example

-EXTADDR-NUM 015 where NUM shall always be a three digit number.

IFPS shall send a copy of the processed flight plan to the extra addresses 12 hours (720 minutes) before EOBT whenever the flight plan is acknowledged earlier than 12 hours before EOBT, or immediately if the flight plan is acknowledged later than 12 hours before EOBT except if the address is known in the NM CACD, in which case it is transmitted according to the time parameter set for this address.

For all messages containing extra addresses, the IFPS shall check only the syntax, not the semantics of the given addresses, thus where an extra address is correct in syntax but incorrect as a valid AFTN address, the IFPS shall send any relevant messages to that incorrect address.

Note 1 In this event, the appropriate AFTN communications centre should return a text message to the IFPS, indicating that the address is not valid.

Note 2 Flight plan filers using the re-addressing function shall note that when the AD line contains an address corresponding to a “flight plan processing platform”, the reply from this platform might be send back to IFPS but IFPS does not provide any treatment for these messages (i.e. no relay service).

Therefore, it advisable not to use the re-addressing function to address “flight plan processing platform(s)”.



7 ATS DATA EXCHANGE PRESENTATION (ADEXP)

1) General

The ATS Data Exchange Presentation (ADEXP) is an agreed standard for the transmission of ATS message data. The ADEXP format has been designed by EUROCONTROL for the exchange of messages between computers either directly or via a network.

The national administrations and the NM have agreed a maximum message length of 10K (approximately 10000 characters) for ADEXP messages.

ADEXP is a format, not a protocol. The format is a textual one, based on characters, and no restrictions are imposed on the transmission media or protocols to be used, other than that of the character set. ADEXP provides a format for use primarily in on-line, computer to computer message exchange.

The ADEXP format has been specified for use within the following areas of message exchange:

Flight planning: exchange of flight plan data and associated messages between the IFPS, ATS and AOs.

ATFCM: exchange of messages between the ETFMS of the NM and AOs and ATS.

Air Traffic Control coordination: exchange of tactical coordination messages between ATCU. Airspace management: exchange of data between National ATSU, the NM and AOs

concerning airspace availability. Civil/military coordination: messages concerning civil/military flight data and airspace

crossing messages.

Although ADEXP is designed primarily for automated treatment, it is provided in a textual format based on characters which allow it to be more open and understandable, and the messages remain readable to a human operator.

Identified and retrievable fields in ADEXP shall be delimited by a special start-of-field character, as this approach improves the robustness of the format, in that if a field is absent or incorrect, it can be skipped and the remainder of the message may still be interpreted.

The ADEXP format is designed as a computer to computer exchange format which may be transmitted on different computer networks or on dedicated computer-computer links. In addition, a requirement exists to be able to exchange some ADEXP messages, typically flight planning and ATFCM related, on the AFTN, although messages which may be required to be transmitted via AFTN shall have their character set restricted.

The IFPS supports both ADEXP format and the ICAO AFTN format and is capable of receiving and outputting flight plan messages which conform with the ADEXP standard, however, the use of the ADEXP format in messages, other than the distribution by the IFPS of ACK, MAN and REJ operational reply messages, will rely on network developments.

3) Message Format

Identified and retrievable fields in ADEXP shall be delimited by a special start-of-field character, the hyphen character (‘-’) and identified by a specific keyword.

The first field shall be the mandatory title field, and the sequence of the subsequent fields shall not be relevant.

Due to their quantity, it is not practical either to list the primary- and sub- fields in ADEXP messages, or to indicate the format of each message type in ADEXP; such information is available upon request to NM.



When transmitting messages in the ADEXP format, all flight data messages distributed by the IFPS shall contain the complete details of that flight, including the flight profile as calculated by the IFPS and the entire list of addresses to which that message is to be distributed.

Exceptions to this are CNL and DEP messages, where only a limited number of elements are included in the message.

Example of a cancel message in the ADEXP format

-TITLE ICNL -BEGIN ADDR

-FAC CFMUTACT -FAC EGTTZGZP -FAC EHAAZQZX -FAC EHAAZRAA -FAC EGLLZEZX -FAC EGZYTTTE -FAC EGZYTTFO -FAC EGLLZTZP -FAC EGLLZPZI -FAC EGLLZTZR -FAC EGZYTTAD -FAC EGZYADEX

-END ADDR -ADEP EGLL -ADES EHAM -ARCID ABC434 -EOBD 050106 -EOBT 1135 -FILTIM 061014 -IFPLID AA47868964 -ORGNID EGLLABCX -ORIGIN –NETWORKTYPE AFTN –FAC EGLLABCX -SRC FPL

Example of a flight plan in the ADEXP format

-TITLE IFPL -BEGIN ADDR


-END ADDR -ADEP EGLL -ADES EHAM -ARCID ABC434



-ARCTYP A319 -CEQPT SRGWY -EOBD 050106 -EOBT 1135 -FILTIM 060126 -IFPLID AA47868964 -ORIGIN –NETWORKTYPE AFTN –FAC EGLLABCX -SEQPT C -WKTRC M -OPR ABC -PBN B2 -REG GAAPO -RMK TCAS -RVR 200 -SEL DSGL -SRC FPL -TTLEET 0034 -RFL F270 -SPEED N0402 -FLTRUL I -FLTTYP S -ROUTE N0402F270 BPK UM185 CLN UL620 REDFA/N0390F230 -ALTRNT1 EHRD -EETFIR EGTT 0008 -EETFIR EHAA 0019 -BEGIN RTEPTS

-PT –PTID EGLL –FL F000 –ETO 050106115100 -PT –PTID BPK –FL F060 –ETO 050106120245 -PT –PTID TOTRI –FL F107 –ETO 050106120605 -PT –PTID MATCH –FL F115 –ETO 050106120630 -PT –PTID BRAIN –FL F164 –ETO 050106120915 -PT –PTID DAGGA –FL F181 –ETO 050106121010 -PT –PTID *6CLN –FL F199 –ETO 050106121105 -PT –PTID CLN –FL F223 –ETO 050106121220 -PT –PTID ARTOV –FL F250 –ETO 050106121400 -PT –PTID REDFA –FL F230 –ETO 050106122010 -PT –PTID EHAM –FL F000 –ETO 050106124950

-END RTEPTS -ATSRT UM185 BPK CLN -ATSRT UL620 CLN REDFA -RFL F230 REDFA -SPEED N0390 REDFA



Example of a modification message in the ADEXP format

-TITLE ICHG -BEGIN ADDR


-END ADDR -ADEP EGLL -ADES EHAM -ARCID ABC434 -ARCTYP A319 -CEQPT SRGWY -EOBD 050106 -EOBT 1135 -FILTIM 060934 -IFPLID AA47868964 -ORIGIN -NETWORKTYPE AFTN -FAC EGLLABCX -SEQPT C -WKTRC M -OPR ABC -PBN B2 -REG GAAPO -RMK TCAS -RVR 200 -SEL DSGL -SRC FPL -TTLEET 0034 -RFL F270 -SPEED N0404 -FLTRUL I -FLTTYP S -ROUTE N0404F270 BPK UM185 CLN UL620 REDFA/N0392F230 -ALTRNT1 EHRD -EETFIR EGTT 0008 -EETFIR EHAA 0019 -BEGIN RTEPTS

-PT -PTID EGLL –FL F000 –ETO 050106115100 -PT –PTID BPK –FL F060 –ETO 050106120240 -PT –PTID TOTRI –FL F107 –ETO 050106120600 -PT –PTID MATCH –FL F115 –ETO 050106120625 -PT –PTID BRAIN –FL F164 –ETO 050106120910 -PT –PTID DAGGA –FL F181 –ETO 050106121005 -PT –PTID CLN –FL F223 –ETO 050106121215 -PT –PTID ARTOV –FL F250 –ETO 050106121355 -PT –PTID REDFA –FL F230 –ETO 050106122000 -PT –PTID EHAM –FL F000 –ETO 050106124935



-END RTEPTS -ATSRT UM185 BPK CLN -ATSRT UL620 CLN REDFA -RFL F230 REDFA -SPEED N0392 REDFA


When distributing messages in ADEXP format, those messages shall necessarily contain the complete calculated profile of that flight in the section ‘RTEPTS’. This section shall contain all those navigation points, including the departure and destination aerodromes, given in the filed route, plus, where the flight is filed on an airway, all those navigation points on that airway between the filed points of joining and leaving that airway.

When calculating the profile of a flight, where a navigation point is identified on more than one occasion in the same calculated flight profile, the ADEXP format has an agreed renaming convention where that navigation point name is re-formatted to include a sequence number.

Example

REN001

REN002

REN003






8 Operational Reply Message (ORM)

1) General

Operational Reply Messages (ORMs) – ACK, MAN, REJ, – shall be used by the IFPS to indicate to a message originator the status of the processing of a submitted message.

The IFPS may, under certain circumstances, send a copy of the ORMs to the aircraft operator.

ORMs shall be sent to message originators according to the following table:

Originator address Operational Replies received from IFPS

All originator addresses except those, which have requested not to receive ORMs.

ACK, MAN, REJ

When the message submission is done via the NOP, message originators shall receive ORMs the same way as if the message had been filed via AFTN or SITA.

If no ORMs are received (see Note), it remains the message originator’s responsibility to check the message status. This can be achieved by consulting the flight’s operational log in the Filing tab in the NOP Flight List.

Note This is the case if, for a message originator, “ACK, MAN, REJ required” are set to NO in NM CACD.

ACK ORMs for messages updating a flight plan (CHG, DLA, CNL) shall also be transmitted to the originator of the initial flight plan and to the address(es) found in the Copy ORMs (see Section 20) whenever an update has been processed from a different originator.

This is applicable when the following conditions are met for the originator of the initial flight plan:

ACK ORM is required for the address. The originator is known and requires ACK ORM for flight plans or the originator is not known. For Copy ORMs, the Aircraft Operating Agency (AOA) requires ACK ORM for flight plans.

ORMs shall have only an ADEXP format; there is no equivalent ICAO/AFTN format.

Where a message originator does not receive an ORM in response to a submitted message after a significant amount of time, the message originator shall consider the original message submission to have failed and contact IFPS to check whether the message was received or not.






9 Acknowledgement (ACK) Message

1) General

The ACK message is a means whereby the IFPS indicates successful processing of a submitted message against the environmental data held by the NM at the time of processing that message.

Such a processing may only take into account the criteria specified by the relevant member states against which they require flight plan messages to be checked by the IFPS. As such, successful processing by the IFPS cannot guarantee that a processed message is fully in accordance with each Member State’s requirements, where they are not known to the NM CACD, nor does it ensure the correctness of any part of a flight that takes part outside the IFPZ.

The IFPS processing does not take into account criteria such as overflight or diplomatic clearances, ETOPS requirements, SAFA constraints, MNPS requirements, etc., so any message originator in receipt of an IFPS ACK message must also take into consideration such constraints and requirements.

For an acknowledged flight plan, the IFPS will reprocess that flight plan after its initial processing and ACK. The ACK for that initial processing shall not ensure compliance against the relevant criteria coincident with the EOBT of that flight, and a suspension or an IFPS notification by mean of a message may occur should the IFPS be notified of any change made to the relevant airspace conditions.

2) Requirements

An ACK message shall be sent to the message originator when the submitted message has been successfully processed either automatically or following manual intervention by the IFPS staff. In the latter case, the ACK message is preceded by a MAN message, unless the message originator has chosen not to receive MAN messages.

When the message submission is done via the NOP, message originators shall receive an ACK message the same way as if the message had been filed via AFTN or SITA.

If no ACK message is received (see Note), it remains the message originator’s responsibility to check the message status. This is especially the case if the Submit results window in the NOP stated: “QUEUED FOR CORRECTION” as the message has been sent for manual processing. The manual processing shall result in the message being acknowledged (ACK) or rejected (REJ). The checking can be achieved by consulting the flight’s operational log in the NOP from the tab “Filing” in “Flight List”.

Note This is the case if, for a message originator, “ACK required” is set to NO in NM CACD.

The originator, when not being the operator or the pilot, shall ensure that the conditions of acceptance of a flight plan and any necessary changes to these conditions as notified by IFPS are made available to the operator or the pilot who has submitted the flight plan.

The operator shall ensure that the conditions of acceptance of a flight plan and any necessary changes thereto as notified by IFPS to the originator are incorporated into the planned flight operation and communicated to the pilot.


An ACK message shall automatically be sent by the IFPS to the message originator when a received message has been successfully processed either automatically or following manual intervention by the IFPS staff unless “ACK required” is set to NO for that message originator.

An ACK message may contain one or several fields “COMMENT”. This is used to inform the message originator of an element in relation with the processing of the message.



Examples of COMMENT field:

—COMMENT THE EOBT UPDATE HAS CAUSED AN OVERLAP WITH A FPL WITH SAME ARCID AND OVERLAPPING FLYING PERIOD (N34DR LFPB1610 EDDT0115 DOF/150317)

—COMMENT THIS FLIGHT MAY REQUIRE SPECIAL HANDLING BY ATC DUE TO 8.33 KHZ CARRIAGE REQUIREMENTS.

In the case of multiple comments, each comment starts on a new line as follows:

-COMMENT ….

-COMMENT …

Automatic processing in the IFPS may not mean that the flight plan has been accepted by the IFPS without modifications. The IFPS shall, for example, automatically insert the name of a suitable route between two points if none has been indicated in the received message. To distinguish between automatic processing without amendment by the IFPS and automatic processing including any amendment (or manual processing by IFPS Staff), two differently formatted ACK messages are available: ‘Short ACK’ when no modification has been made and ‘Long ACK’ for when modifications have been made.

The possibility to always receive Long ACK messages also exists within the IFPS. This option may be implemented for any concerned flight plan originator only after co-ordination with the NM Airspace Data Management Section (AD). A long ACK will always be sent to flight plan originators that are not defined (‘unknown’) in the NM systems.

Note AOs filing directly to the IFPS but not using the re-addressing function of the IFPS are responsible to ensure that all amendments made to a flight plan are communicated to all concerned addresses outside the IFPZ.

Message originators shall take careful note of the message contained within a long ACK message, especially where the IFPS Re-route Accepted feature is included in the original submitted message, to ascertain any amendments made by the IFPS.

Output: Long ACK example

—TITLE ACK Acknowledgement of successful processing. —MSGTYP FPL Title of the original message. —FILTIM 030830 Filing time of the submitted message. —ORIGINDT 9710010200 Date and time of receipt of original message by the IFPS. —BEGIN ADDR —FAC LHRWUAB —FAC EGLLABCX —END ADDR —EXTADDR -NUM 009 Number of additional addresses which have been sent to the IFPS in

the ’AD‘ line. —IFPLID AA00000102 Unique identifier of the flight plan in the IFPS database. —MSGTXT Complete message in ICAO format as accepted by the IFPS —(FPL-ABC567-IS —B744/H-SDGIWIRYH —EGLL1500 —N0487F330 BUZAD T420 WELIN UN57 TNT UL28 RODOL UP6 MIMKU/M083F330 NATB STEAM/N0491F330 N202B TOPPS/N0465F310 DCT ENE/N0410F240 ENE4 —KJFK0721 KEWR KBOS —PBN/B1D1 EET/EGPX0053 EGGX0129 20W0220 CZQX0259 40W0337 50W0440 ADIZ0452 CZQX0504 CZUL0521 CZQM0558 KZBW0626 KZNY0654 REG/GCHGR SEL/EGJL RMK/TCAS EQUIPPED DOF/090503)



Output: Long ACK example with comment

-TITLE ACK -MSGTYP IFPL -FILTIM 190634 -ORIGINDT 1609190634 -BEGIN ADDR -FAC LKPRTVSX -END ADDR -COMMENT MANDATORY 8.33KHZ RADIO EQUIPMENT REQUIRED FROM 01/01/2018. LKAA FIR MAY REQUIRE 8.33KHZ RADIO CARRIAGE BEFORE THIS DATE. CHECK AIP/AIC. -IFPLID AT00123379 -MSGTXT (FPL-ABC123-IN -B739/M-SDFGHILORVWZ/LB1 -LKTB1245 -N0335F150 HLV -LKMT0027 LKTB -PBN/B1D1 COM/TCAS DOF/160919 RVR/200 ORGN/ABCDEFGH)

Output: Short ACK example

—TITLE ACK Acknowledgement of successful processing. —MSGTYP FPL Title of the original message. —FILTIM 030830 Filing time of the submitted message. —ORIGINDT 0405031100 Filing time of the original message expanded to give the year, month,

date and time. —BEGIN ADDR —FAC LHRWUAB —FAC EDDFZPZX —END ADDR —EXTADDR -NUM 009 Number of additional addresses which have been sent to the IFPS in

the ’AD‘ line. —IFPLID AA00000102 Unique identifier of the flight plan in the IFPS database. —BEGIN MSGSUM Summary fields of the message in ADEXP format. —ARCID ABC567 —ADEP EGLL —ADES KJFK —EOBT 1500 —EOBD 040503 —ORGN LHRWUAB —END MSGSUM

Output: Short ACK example with comment

-TITLE ACK -MSGTYP IFPL -FILTIM 190634 -ORIGINDT 1609190634 -BEGIN ADDR -FAC LKPRTVSX -END ADDR -COMMENT MANDATORY 8.33KHZ RADIO EQUIPMENT REQUIRED FROM 01/01/2018. LKAA FIR MAY REQUIRE 8.33KHZ RADIO CARRIAGE BEFORE THIS DATE. CHECK AIP/AIC. -IFPLID AA00123379 -BEGIN MSGSUM -ARCID ABC123 -ADEP LKTB -ADES LKMT0027 -EOBT 1430 -EOBD 160915



-ORGN ABCDEFGH -END MSGSUM

9.1 General Procedure for Message Originators

The message originator shall receive the ACK message unless “ACK required” is set to NO for that message originator. Where a Long ACK is received, the message originator shall check for any amendments made by the IFPS, especially where the submitted message contained the IFPS Re-route Accepted authorisation (RMK/IFPSRA). Where any subsequent action is required of the message originator, then that party shall take that action.



10 Manual (MAN) Message

2) Requirements

A Manual (MAN) message shall be sent to indicate to the message originator that errors have been detected in the submitted message and that it has been referred for manual processing by the IFPS staff.

When the message submission is done via the NOP, message originators shall receive a MAN message the same way as if the message had been filed via AFTN or SITA if the Submit results window in the NOP stated: “QUEUED FOR CORRECTION”.


Where a submitted message fails automatic processing by the IFPS, that message shall, in most cases, be presented for manual treatment, at which time a MAN message shall be sent to the message originator unless “MAN required” is set to NO for that message originator .

After a delay for the necessary manual processing, a MAN message shall be followed either by an ACK message if the submitted message has been successfully corrected by the IFPS staff, or by a REJ message

Note AOs filing directly to the IFPS but not using the re-addressing function of the IFPS are responsible to ensure that all amendments made to a flight plan are communicated to all concerned addresses outside the IFPZ.

Output: MAN example

—TITLE MAN —MSGTYP IFPL —FILTIM 030830 —ORIGINDT 0405031100 —BEGIN ADDR —FAC LHRWUAB —FAC EGLLABCX —END ADDR —BEGIN MSGSUM —ARCID ABC567 —ADEP EGLL —ADES KJFK —EOBT 1500 —EOBD 040503 —ORGN LHRWUAB —END MSGSUM


The message originator shall receive the MAN message unless “MAN required” is set to NO for that message originator. No action is required of the message originator on receipt of a MAN message from the IFPS, and the message originator should not submit any other messages relating to that flight until such time as an ACK or REJ message is received for that invalid message.






11 Reject (REJ) Message

2) Requirements

A Reject (REJ) message shall be sent to the message originator to indicate that the submitted message could not be processed successfully, either automatically or manually, and that the submitted message has not been accepted and processed by the IFPS.

When the message submission is done via the NOP, message originators shall receive a REJ message the same way as if the message had been filed via AFTN or SITA if the Submit results window in the NOP stated: “QUEUED FOR CORRECTION” or “REJECTED”.

If no REJ message is received (see Note), it remains the message originator’s responsibility to check the message status as the manual processing shall result in the message being acknowledged (ACK) or rejected (REJ). The checking can be achieved by consulting the flight’s operational log in the NOP from the tab “Filing” in “Flight List”.

Note This is the case if, for a message originator, “REJ required” is set to NO in NM CACD.

Each REJ message shall contain an error list (to a maximum of 10) giving the nature of the errors in free text followed by the offending field or fields.

If a flight with a flight plan that has been rejected is still to be operated, the Aircraft Operator shall amend and re-submit the corresponding message. A flight plan must be submitted to, and acknowledged by, the IFPS before the flight can operate under IFR as GAT within the IFPZ.


Those submitted messages that fail automatic processing by the IFPS may be automatically rejected by the IFPS. Those that are not are presented to the IFPS staff for manual treatment which, if unsuccessful, shall result in that message being rejected back to the message originator for any necessary correction and re-submission to the IFPS.

When a message originator receives a REJ message because a flight plan for the same flight has already been accepted from another originating source, the error text shall read:

‘The following FPL has already been received from another source’.

A copy of the existing flight plan, not the rejected flight plan, will be attached.

If a flight plan for an IFR/GAT flight or part thereof intending to operate within the IFPZ area receives a REJ message from the IFPS, then no flight plan will exist for that flight within the ATS Units concerned. It shall remain the responsibility of the message originator to take any appropriate action to ensure the successful submission of a flight plan for that flight.

Output: REJ example

—TITLE REJ -MSGTYP IFPL -FILTIM 060830 -ORIGINDT 1105061100 —BEGIN ADDR —FAC LHRWUAB —FAC EGLLABCX —END ADDR —COMMENT THIS MESSAGE HAS BEEN REJECTED AUTOMATICALLY (*) —POSRTE N0120F060 GOLVA GOLVA3C: DIFF LENGTH PLUS (or MINUS) xxNM xxPC (**) —ERROR PROF195: GRZ L604 GOLVA DOES NOT EXIST IN FL RANGE F000..F100 —MSGTXT (FPL-ABC567-IS —PA34/l-S/C —LOWG1500 —N0120F060 GRZ L604 GOLVA —LJMB0020



—EET/GOLVA0010 DOF/110506) —TITLE REJ -MSGTYP IFPL -FILTIM 270730 -ORIGINDT 1902270730 —BEGIN ADDR —FAC LFBOAFMI —END ADDR —COMMENT THIS MESSAGE HAS BEEN REJECTED AUTOMATICALLY (*) —POSRTE N0498F290 BUBLI UG42 LUVAL UN491 DEGES UN871 GAMSA N871 MADEB N606 ELMEM L607 GEDSO DCT DIMLO DCT INVED M747 NEKUL P975 ARTAT/N0493F310 UP975 ERGUN UL124 KONUK/N0482F330 UL124 EVSAS UM688 OTKEP UM688 RATVO/N0488F330 UM688 SIDAD/N0499F330 UP975 SESRA M677 RABAP UM677 PASAK/N0491F350 UM677 OBNET M677 LOVEM L562 SERSA P307 VAXIM L301 RASKI/N0503F330 L301 AAU/N0515F320 J19 QQZ/N0512F310 A347 AMVIG/N0518F300 N895 AAE/M084F290 Q3 UUD/N0507F290 A347 DIPAS DIPAS5F: DIFF LENGTH PLUS (or MINUS) xxNM xxPC (**) -ERROR (R) PROF205: RS: TRAFFIC VIA LDZOCTA:F205..F999 IS ON FORBIDDEN ROUTE REF:[LDLQ1001A] LDZOCTA —ERROR (R) PROF205: RS: TRAFFIC VIA LQSBCTA IS OFF MANDATORY ROUTE REF:[LQ2018B] SOMUN —COMMENT MSGSUM USED TO SHORTEN REPLY —BEGIN MSGSUM —ARCID AFR123 —ADEP LFPG —ADES VIDP —EOBT 0920 —EOBD 190227 —ORGN LFBOAFMI —END MSG SUM (*): Only present when the message has been rejected automatically.

(**): The field POSRTE (possible route) may only be present in REJ messages related to flight plan messages or delay messages for which there is/are error(s) on the route. Depending on the case, the route described in the POSRTE field is either a system generated route or a route found manually by an IFPS staff.

When present in a REJ message and when system generated, the propose route contained in the POSRTE field is valid, at least, with an EOBT in between the filed EOBT minus 10 minutes and the filed EOBT plus 10 minutes.

The field POSRTE includes a difference indicator for the distance in order to help the airspace user to assess the suitability of the proposed route. The difference indicator can be either “PLUS” or “MINUS” with a distance expressed in NM and a percentage (PC).

Examples

POSRTE N0450F400 TOR P601 BAVTA N873 TUSKA UN873 JUIST UP174 EEL UN872 PAM/N0450F410 UN872 DENOX UZ319 MOPIL/N0390F250: DIFF LENGTH PLUS 39NM 4PC the proposed route is 39 NM longer when compared to the distance of the filed route which represents an difference of 4%.

POSRTE N0450F400 TOR P601 BAVTA N873 TUSKA UN873 JUIST UP174 EEL UN872 PAM/N0450F410 UN872 DENOX UZ319 MOPIL/N0390F250: DIFF LENGTH MINUS 39NM 4PC the proposed route is 39 NM shorter when compared to the distance of the filed route which represents a difference of 4%.

It should be noted that the message present within the REJ message (after MSGTXT), in the case of a manual rejection, is the message as it was displayed to the IFPS staff at the moment of rejection. This means that it may be different to the message as filed originally.

Example: a flight plan comes for manual processing due to a syntax error. After correction of that error by the IFPS staff, a profile error is raised (CDR2 route closed). At the end of the processing if the IFPS staff rejects that flight plan, the REJ message will show a copy of the FPL with the syntax error corrected.




The message originator shall receive the REJ message unless “REJ required” is set to NO for that message originator. Then the message originator shall determine the necessary corrections to be made to the rejected flight plan or associated message, if necessary, after co-ordination with the AO. At such time that the corrections are completed, the corrected message shall be re-submitted to the IFPS for processing.

If present in the REJ message, the route contained in the POSRTE field may be used when the flight plan is re-filed. In this case, the message originator is responsible for assessing whether that route is operationally acceptable (length, countries overflown, weather, overflying permits, etc…). The route contained in the POSRTE is “IFPS compliant” but does not guarantee to be avoiding ATFM constraints.






12 Copy Operational Reply Message (ORM)

2) Requirements

The IFPS shall try to determine from the flight plan the identity of the AO. If it is successful in doing so then it is possible that an operational reply message may be sent to the aircraft operator in addition to the message originator.


Where the message originator address is the same as the address stored within the CACD for the AO (direct filing) then only one ORM is transmitted.

The ‘Copy ORMs’ shall only be sent to the central address of the AO as stored within the NM CACD. If the operational reply message is required by the AO at a remote office then the AO must forward the message accordingly, or to add the relevant address to the message using the re-addressing function.

The transmission of a ‘copy’ operational reply message to the AO depends on the following conditions:

a) The IFPS must be able to determine the identity of the AO from the flight plan message. b) The AO must be ‘known’ within the NM CACD together with address information, etc. c) The AO must have made an explicit request to the NM Airspace Data Management Section

(AD) to receive ‘Copy ORMs’ – they shall not be sent automatically to all AOs.

For messages of type AFP, RQP, FNM, MFS, MAN and REJ messages are not copied by the IFPS to the corresponding AOCC (if it has been identified) but only ACK and always in ’long’ format.

12.1 General Procedure for Aircraft Operators

AOs shall ensure that, should they require the ‘Copy ORM’ function to be used by the IFPS, that the relevant details have been submitted to the DT section.






13 Determination of Aircraft Operator by IFPS

2) Requirements

The IFPS shall determine the aircraft operator by analysing the following fields in the order shown:

a) OPR/ information. b) Aircraft identification.


Where the AO may be determined by the IFPS from the sub-field OPR indicator, and the information held therein is the recognised AO’s ICAO code, no further analysis is performed, and the aircraft identification is not checked.

If the OPR indicator is not present, or the AO cannot be determined from the information contained in that sub-field, then the aircraft identification shall be analysed by the IFPS.

Examples

OPR/BAW This is interpreted as British Airways.

RMK/OPR British Airways This is not interpreted.

(FPL-GFABW- This is not interpreted.

(FPL-GFA123- This is interpreted as Gulf Air.

250915 EGLLZPZX This message would result in ORMs being sent

(FPL-BAW123-IS to EGLLZPZX and, if requested, to the address

stored in the NM CACD for BAW operations.

250915 EGLLZPZX This message would result in ORMs being sent

(FPL-GFABW-IS to EGLLZPZX and, if requested, to the address

stored in the NM CACD for BAW operations.

-OPR/BAW)

The aircraft operator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






14 Error Types

2) Requirements

Where a message submitted to the IFPS for processing fails that processing, the failed message shall have attached to it a list of error messages. Each error message shall be grouped into a type of error, and this type of error shall be indicated at the start of each error message.

Each error message contains a number that is unique to the error; this number may be used as search criteria to find the relevant part of this manual.

Example SYN116: MISSING OR INVALID FLIGHT TYPE

An error type indicator shall precede each error message attached to every message that has failed automatic processing by the IFPS; these error types are:

14.1 Syntax

The syntax error type contains all those errors raised when the submitted message does not adhere to the prescribed formats and manner of specifying data as described in ICAO Doc. 4444, Appendices 2 & 3; ICAO Doc. 7030, EUR Region; the IFPS Software Requirements document, and in this document.

Example SYN116: MISSING OR INVALID FLIGHT TYPE

14.2 Expanded Flight Plan Message (EFPM)

The Expanded Flight Plan Message (EFPM) error type contains those errors raised when data in the submitted message is inconsistent either with other Items in that message or with the existing IFPS flight plan database, or there is insufficient data to create a flight plan.

Example EFPM237: MESSAGE MATCHES EXISTING INVALID MESSAGES

14.3 General Route

The Route error type contains all those errors raised where the data format and content in the route portion of the submitted message do not adhere to the prescribed formats and manner of specifying data, or are inconsistent with the NM CACD.

Example ROUTE126: FLIGHT RULES Y WITH NO VFR PART

14.4 Rerouteing

The Rerouteing error type contains all those errors relating to the AOWIR use. These errors are internal IFPS/ETFMS only and are not output to external users.

Example REROUTING182: CANNOT ADD SPEED/RFL AT POINT <pt>. IT IS NOT ON THE NEW CONSTRUCTED ROUTE.



14.5 Profile

The Profile error type contains all those errors raised where data inconsistencies or violations are found during the calculation of the flight profile of the submitted message.

Example PROF188: FLIGHT PLAN DOES NOT COMPLY WITH 8.33 CARRIAGE REQUIREMENTS

14.6 Warning

The Warning error type contains those errors that are generated to provide indications of difficulties in advance of the introduction of specific new checks to be carried out by the IFPS, e.g. RVSM and 8.33 kHz. Under these conditions, the error message is attached to the output message by the IFPS, but no manual processing error is raised.

Example WARNING: FLIGHT PLAN WILL BE REJECTED AFTER [RVSM START DATE]

Warning error types may also be generated during internal IFPS processing of messages to assist in the manual treatment of messages by the IFPS staff.

Example WARNING256: ACH BUILT FROM <msg type>

14.7 Routing Assistance

The Propose Routes tool in the NOP and FCHMI may use all those error message types used in the IFPS, but it may also use one type specific to the Propose Routes tool. A number of errors raised are specific to that system alone; such errors are of a type ‘Routing Assistance Errors’.

Example RA270: UNKNOWN AIRCRAFT TYPE



15 Improvement in Quality of Submitted Messages

1) General

One of the tasks of the IFPS is to provide assistance in finding correct routes where genuinely needed, however, message originators are also required to take responsibility for the quality of any messages they send to the IFPS for processing.

The IFPS shall not be considered responsible for providing regular solutions to repetitive errors or fixing basic errors (e.g. SYNTAX). Where routeing assistance is given by the IFPS, details of that assistance should be noted for future use by the message originator, thus allowing for a concentration of the IFPS efforts where they are most required.

In an effort to increase the quality of messages submitted to the IFPS for processing, regular analyses shall be made by the Network Operations Support staff to identify repetitive or basic errors. In parallel, any repetitive error identified by the IFPS staff shall be notified via the CCMS.

Network Operations Support staff shall contact message originators to inform them of identified errors, and to agree a timescale for solutions.

To improve the effectiveness of flight plan treatment and to deliver flight planning assistance when possible, basic, repetitive and/or avoidable errors shall be set for automatic rejection in the IFPS Error Management Tool.

2) Requirements

Message originators shall be responsible for the submission to the IFPS for processing of flight plans and associated messages for all IFR/GAT flights or parts thereof intending to operate within the IFPZ.

Flight plans and associated messages sent to the IFPS shall take account of all ATM constraints and priorities as published by the NM and any relevant national administration.

Message originators shall ensure that the errors that cause invalid flight plan messages in IFPS are not avoidable, repetitive or basic. Where a message originator has had a submitted message corrected by the IFPS, the details of that correction should be analysed and recorded for future use by that message originator.


The Error Management Tool is implemented within the NM CACD.

It offers the possibility, through restrictions of type Error Management, to set some errors to be rejected automatically or manually. Manually means that it shall be verified and confirmed by an IFPS staff.

Flight plan message item 18 sub-field STS may contain a number of data items indicating emergency or priority situations where systematic rejection is not appropriate. If a STS sub-field contains STS/HOSP, STS/SAR, STS/FFR or STS/MEDEVAC, the message shall not match EM restriction(s) of type reject.

Messages that are to be rejected contain errors that are prefixed with an ‘R’ (Reject) when it has been automatically rejected or prefixed with ‘RC’ (Reject Confirm) when it has been manually rejected/confirmed.






16 IFPS Re-Route Accepted (IFPSRA)

2) Requirements

The IFPS Re-route Accepted feature is subject to those conditions applicable in the Quality of Submitted Messages and should not be considered to take priority over that instruction.

If the IFPSRA indicator is present in the Item 18 sub-field RMK, the route field is empty or contains only the routeing indicator ‘DCT’, and the aerodrome of departure and aerodrome of destination are inside the IFPZ, then it indicates that the message filer requests routeing assistance and IFPS will automatically insert a route if a valid one is found and if none is found the IFPS will automatically reject the message.

For messages which are manually processed by IFPS, the remark ‘IFPSRA’ in the sub-field RMK, of a flight plan shall be considered as written authorisation from the message originator for the IFPS staff to manually correct the message where necessary and possible, without being required to obtain further agreement to those changes from the message originator.

It shall then be the responsibility of the message filer to ensure that any changes made to that message by the IFPS are checked and communicated to any necessary persons prior to the departure of that flight.

It shall remain the responsibility of the message filer to ensure that, where a message that includes this remark is submitted to the IFPS, that message filer shall have the means to receive the updated version of the message after any possible manual processing by the IFPS.

IFPS staff shall not re-route flights without coordination under the following conditions:

The flight plan originator address is associated to an ANU that has ‘ACK Message Required‘ set to ‘No‘;

If the only available re-routeing option includes a change to the IFPZ entry/exit point;

When the re-route enters a previously untouched national airspace.

It shall not be the responsibility of the IFPS to confirm that the AO receives a copy of any updated message containing the ‘IFPS Re-route Accepted’ authorisation.

3) Message Format

Where a message filer wishes to authorise the IFPS staff to make amendments to their submitted messages when necessary and possible, that message filer shall add the comment ‘IFPSRA’ in the RMK sub-field of the submitted message.

Where a message filer wishes to authorise the IFPS staff to assist them in finding a route, the ‘IFPSRA’ indicator shall be inserted in sub-field RMK, and the message submitted with an empty route field, or with only ‘DCT’ in the route field.


The use of the ‘IFPSRA’ authorisation requires that the message originator receive a copy of the corrected/added data in the operational reply message.

The conditions when the IFPS does not send ACK messages and therefore re-routeing/routeing assistance shall not be executed by IFPS staff are when the flight plan originator address (AFTN or SITA) is associated to an ANU that has ‘ACK Message Required‘ set to ‘No‘;

When the route field is empty or contains only the routeing indicator ‘DCT’ and the aerodrome of departure and aerodrome of destination are inside the IFPZ, the IFPS processing is as follows:



The IFPS has automatically found a route, the flight plan is accepted and the long ACK will contain the following comment: THE FILED ROUTE HAS BEEN AUTOMATICALLY OR MANUALLY CHANGED BY THE IFPS OR BY AN OPERATOR or

The IFPS has not found a route, the flight plan is rejected.

16.1 General Procedures associated to the use of IFPSRA

Where a message submitted to the IFPS for processing contains the remark ‘IFPSRA’ in the RMK sub-field of that message, the IFPS shall treat that remark as authorisation to manually treat that message as necessary and where possible, taking into account the requirements laid out in the Quality of Submitted Messages.

Message filers shall not use the remark ‘IFPSRA’ together with the remark ‘RTECOORATC’ as there is a risk that IFPS staff could modify the route (or part of) that has been previously coordinated with ATC.

Message filers shall not use the IFPSRA function for routeing assistance when the flight may be subject to airspace access restrictions, timing restrictions or else such as military flights, air refuelling, non-standard routing coordinated with ATC, round-robin and training flights etc...

When a re-route enters a previously untouched national airspace or the re-route changes the IFPZ entry/exit point, the IFPS staff shall coordinate the necessary changes.

When the flight plan originator will not receive an ACK message, the IFPS staff shall coordinate the necessary changes.

Particular care shall be taken with military flights and flights with special status, as diplomatic clearances could be an issue in the event of any rerouteing by the IFPS staff.

It should be noted that a flight plan accepted by the IFPS does not imply the issue of overflight permission; such requests must be made by the AO directly with the relevant authorities. Message originators who cannot accept a re-route due to diplomatic or overflight clearance constraints should not insert the comment ‘IFPS Re-route Accepted’ or ‘IFPSRA’ in the submitted message.

Where the IFPS staff determine that any necessary changes require coordination with the message originator, but no contact is possible in order to agree the changes, then that message shall be rejected back to the message originator. In these situations and when the workload is not high, the IFPS staff shall normally communicate a possible correction to the message originator via that message originator’s AFTN or SITA address.

Note Messages that contain the remark ‘IFPSRA’ are subject to the rejection of repetitive errors procedure.

When the trajectory (laterally or vertically) between the first and last en-route point is modified as a result of IFPS manual processing, the IFPS staff shall insert the following IFP indicator: IFPSROUTEMOD.

16.2 ANUs in the NM CACD Receiving ‘NO‘ ACK Messages

Error message ref. N/A



Explanation: Where a message is submitted to the IFPS for processing from an address associated to an Air Navigation Unit that is defined in the NM CACD with the requirement for ACK messages set to NO, that address shall not receive ACK messages from the IFPS.

If such an address submits a message containing the comment ‘IFPSRA’, they will not receive any indication of changes made by the IFPS staff that would normally be provided in the ACK message.

Instruction: Where IFPS staff identify that the flight plan originator will not receive an ACK message from the IFPS, then it is not possible to treat that message without coordination. If no contact or no agreement on correction can be made the message shall be rejected.

Flight plan messages with STS/FFR, STS/SAR, STS/MEDEVAC or STS/HOSP shall be manually forced through processing by the IFPS staff using the ‘ignore’ option as appropriate, and adding any relevant IFP indicators as necessary.






17 IFPS Manual Processing Procedures

2) Requirements

The IFPS is responsible for the reception, verification and distribution of flight plan data for all IFR/GAT flights within the IFPZ. AOs have a legal responsibility (ref. National AIPs and ICAO Doc. 7030) to ensure that all flight plans and associated messages for IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be submitted to the IFPS for processing.

The IFPS is not responsible for the reception, verification and distribution of flight plan data for flights outside the IFPZ. However, the NM has agreed to distribute a copy of flight plans it receives that penetrate, Rostov, Kaliningrad or Belarus airspaces. These messages shall be output to the addresses UUUWZDZX (for Rostov and Kaliningrad) and to UMMMZDZX (Belarus), with any necessary further distribution within that airspace being undertaken by the Rostov, Kaliningrad or Belarus authorities. AOs have still the legal responsibility to ensure that all flight plans and associated messages for flights within Rostov, Kaliningrad and Belarus airspaces are being addressed to the appropriate ATC Units responsible for these flights.

Those messages submitted to the IFPS for processing that fail automatic processing may be passed to the IFPS staff for manual treatment.

All messages presented to the IFPS staff for manual treatment shall have attached an indication of the relevant errors causing that message to fail automatic processing. Upon receipt of such messages, the IFPS staff shall confirm the validity of those error messages through the relevant documentation, such as the RAD.

Should an error be found by the IFPS staff to be inaccurate, the details and conditions of that error shall be reported [see NM Operational Problem Reporting in the Network Operations Handbook]. That error indicator, its conditions and any necessary manual treatment actions shall then be promulgated to all the IFPS staff through an operational instruction.

The conditions governing the manual treatment of messages by the IFPS staff are contained in the Standard Correction Procedures.

Under certain conditions, those messages that are passed to the IFPS staff for manual treatment may be forced through processing while still containing some identified errors. Such messages shall have an IFP indicator attached to that message in order to highlight those identified errors that have been accepted by the IFPS.


All messages submitted to the IFPS for processing shall pass through a number of processes that are carried out automatically by the IFPS.

The IFPS is capable of carrying out a number of automatic corrections when processing messages, but where such corrections cannot be made, those messages shall either be automatically rejected or shall be passed for manual treatment by the IFPS staff.

Where manual actions are carried out on an invalid message by the IFPS staff, those actions shall be automatically recorded in the flight plan history, indicating the user identification of the IFPS staff member and the result of the action carried out.

Where any message fails automatic processing by the IFPS and is passed for manual treatment by the IFPS staff, that manual treatment shall be governed by the Standard Correction Procedures (SCP1 and SCP2) unless covered by a specific procedure indicated in this manual.

The following diagram illustrates the processes applied to all messages received by the IFPS:



Figure 2 - Message Submitted to the IFPS

All messages presented for manual treatment must be edited by the IFPS staff. All messages must treated without undue delay upon being called to the flight plan editor function; where the message cannot be treated in a timely manner, the flight plan editor function shall be ended by the IFPS staff member concerned, in order that the message may be treated by another IFPS staff member.

Spurious characters and free text, especially non-alphanumeric characters such as * ! ~ # @ should not be added unnecessarily to any message by the IFPS staff.



18 Standard Correction Procedure 1 (SCP1)

2) Requirements

The Standard Correction Procedure 1 (SCP1) shall be used by the IFPS staff where it is necessary to make decisions about message treatment for flights departing, arriving and overflying the IFPZ.

Detailed procedures for specific errors can be found in section IFPS Error Messages.

18.1 SCP1 General Procedures

During the verification of flight plan data messages, the IFPS may fail the automatic processing of messages and pass them for manual treatment by the IFPS staff. Where this occurs, any amendments to be made by the IFPS staff that require a change to the trajectory of the flight in the submitted message (under certain conditions), changes on key fields such as aircraft identification, Estimated Off-Blocks Time, Estimated Off-Blocks Date and any other error subject to SCP1 shall be coordinated with the message originator before such changes are made to that message.

Aircraft operators who wish to be contacted via a contact point other than indicated by the AFTN/SITA address of the submitting originator shall clearly indicate this in the ORGN sub-field of Item 18, e.g. ORGN/TELEPHONE CONTACT 32 2 729 98 05. Where such an indication is not included and contact with the AFTN/SITA originator is not possible, the message originator wishes to file the proposed correction themselves or agreement cannot be reached on the required correction, the message shall be rejected or suspended.

If no contact can be made with the message originator and the necessary action concerning the required correction is unclear or ambiguous, the message shall be either:

Rejected back to the message originator for them to correct;

Deleted from the invalid message database when a specific procedure dictates this action; In exceptional cases, forced through processing with the appropriate IFP indicators attached.

Note A change of trajectory shall be any change to the track, speed or flight level of the submitted message.

Exception to this procedure is the inclusion of the sub-field RMK, of the comment ‘IFPSRA’. In this case, it may be possible to manually treat that message without coordination except whenever the originator address is displayed in red, as this indicates that no ACK message will be sent to the flight plan originator. The case where this will happen is:

The address is associated to an ANU that has ‘ACK Message Required‘=‘No‘

Note Exceptions to the rule are FNM/MFS messages, which do not generate ACK messages.

In these cases, the route should be amended accordingly as per procedure.

Under particular conditions and for certain message types, some submitted messages shall not be rejected by the IFPS, regardless of errors contained within those messages. Those message types that shall not be rejected are:

FPL with source AFIL. ACH with source FNM & MFS.

FPL with STS/FFR, STS/SAR, STS/HOSP, STS/MEDEVAC: Where any of these STS indicators is indicated and contact with the message originator is not possible, the message shall be



forced using the appropriate IGNORE or other internal procedures and inserting the relevant IFP indicator.

If, as a result of manual processing procedure(s), some error(s) on the ACH (with source FNM or MFS) shall be forced through processing by using the Ignore function, then an indication of that error shall be given through the addition in Item 18 of that message of IFP indicators.

18.2 SCP1 Table

The following flow charts gives an indication of the decision processes governing the manual correction by the IFPS staff of all messages except those containing errors in Aerodrome of Departure, Aerodrome of Arrival or Alternate Aerodrome, or re-addressing. The processes governing the correction of these errors are detailed in the Standard Correction Procedure 2. It should be noted that where a message is rejected by the IFPS staff due to a trajectory error, the corresponding REJ message will in most cases contain a field named POSRTE. POSRTE constitutes an IFPS compliant route which can be used when the message is re-filed to the IFPS. More details can be found in section Reject (REJ) Message.



Figure 3 - SCP1 Table for FPLs and Associated Messages

Green arrow means YES and red arrow means NO.

Note 1 If the message contains the remark ‘IFPSRA’, then it is possible to manually treat that message without co-ordination. However, as stated in section IFPS RE-ROUTE ACCEPTED (IFPSRA) there are 3 exceptions:

The message originator address is associated to an ANU that has “ACK Message Required” set to NO.

The only available re-routeing option includes a change to the IFPZ entry/exit point. When the route enters a previously untouched national airspace.



Note 2 Where a route is changed during the telephone contact with the message originator, the IFPS staff shall ask the message originator to check the new route in the ACK or give a description of the change (either verbally or by means of a transmitted message) where the originator is not receiving an ACK message.

Note 3 Where the flight indicates STS/FFR, STS/SAR, STS/MEDEVAC or STS/HOSP and contact with the message originator is not possible, the message shall be forced using the appropriate IGNORE or other internal procedures and inserting the relevant IFP indicator. Where the error relates to the equipment field (Item 10), and that error is syntactical, it cannot be ignored. In such cases the IFPS staff shall copy the originally-filed equipment and insert it under RMK/ with the following text: ‘Originally filed equipment…’ then the IFPS staff shall correct the syntax and whenever possible send a transmit message to the message originator to inform them of the modification(s) made to the flight plan and suggesting to send a CHG to improve the accuracy of the flight plan data.

Note 4 Where the error can be corrected without any change of trajectory (for example by changing the airway designator to a co-located available airway) then SCP1 is not applicable for this error.

18.3 Flights within the Rostov, Kaliningrad and Belarus FIR Airspaces

The NM CACD includes adjacent additional FIRs mainly in order to ensure accurate profiles in ETFMS (ENV_EXTR area). By inclusion of these FIRs, the IFPS calculates the ATC Unit Airspaces (AUA) to which flight plans would normally be sent; however, the flight plan distribution parameters have been set to ‘No’ for these additional AUAs, thus suppressing flight plan output. Exceptions to this are the Kaliningrad, Rostov and Belarus FIRs.

The NM has agreed to distribute a copy of those flight plans it receives that penetrate URR*, UMK* and UM* airspaces by enabling output to the following addresses:

UUUWZDZX for Kaliningrad and Rostov,

UMMMZDZX for Belarus,

This does not alter the responsibility of aircraft operators to submit flight plans directly to URR*, UMK* and UM* ATC Units.

The NM CACD display shows URRVFIR, UMKKFIR and UMMVFIR within the FPM_COPY Area.

18.4 Re-routeing Outside the IFPZ

Error message ref. N/A

Explanation: The IFPS does not carry out any checking outside the IFPZ, so no changes should be made to that part of the route without coordination/agreement with the flight plan originator or aircraft operator.

Instruction: When re-routeing a flight, the IFPS staff shall ensure that the part of the route outside the IFPZ is not changed. If the only available re-routing option includes a change to the IFPZ entry/exit point, the change shall only be made after coordination/ agreement with the flight plan originator or aircraft operator.

If the change to the IFPZ entry/exit point is the only option and no contact is possible and the flight requires special handling (STS/FFR, HOSP, MEDEVAC or SAR), the original



route shall be forced through processing by the IFPS staff using the appropriate ignore or other internal procedures and inserting the relevant IFP indicator (SCP1)

If the change to the IFPZ entry/exit point is the only option and no contact is possible, the message shall be rejected.

If a re-route proposal containing a change to the IFPZ entry/exit point is sent via the transmit function to the flight plan originator, the message sent shall contain the following ’PLEASE CHECK THE PART OF THE ROUTE OUTSIDE THE IFPS ZONE’.

18.5 Flights with Route Coordinated with ATC

Special flights such as test, military, pollution control, aerial surveillance/photo and others may contain routings which are not compliant with airspaces constraints such as RAD, DCT, CDR, FRA, OAT portions, etc.

Where the entire routing has been coordinated and agreed with all relevant ATC unit(s)/FMP, the message filer shall indicate such prior coordination/agreement in item 18 of the FPL under the RMK field (RMK/) with the following text:

RTECOORATC

Where only (a) specific portion(s) of the routing has/have been coordinated and agreed with the ATC unit(s)/FMP, the message filer shall indicate such prior coordination/agreement in item 18 of the FPL under the RMK field (RMK/) with the following text:

RTECOORATC followed by the name(s)/designator(s) of the ATC unit(s).

Examples: RMK/RTECOORATC ROMA BRINDISI or RMK/RTECOORATC LIRR LIBB.

RTECOORATC shall not be indicated together with IFPSRA as there is a risk that IFPS staff could modify the route (or part of) that has been previously coordinated with ATC.

Only an exact character match of the text string RTECOORATC will guarantee an automatic system recognition (i.e. some automatic rejections may not apply to flight plans that contain RTECOORATC).

Error message ref. Various possibilities of ROUTE and PROFILE errors.

Explanation: Deviation from airspace constraints has been granted by ATC prior the FPL submission.

Instruction: The IFPS staff shall ignore all ROUTE and PROFILE errors (except Profile errors related to 8.33: PROF188, PROF189, PROF190) and shall insert the relevant IFP indicators (see Section 68).

Note: The IFP indicator ERRROUTECOORD shall only be inserted if:

NMOC holds a written confirmation of the agreement or

The flight is covered by an operational instruction or

The agreement has been obtained by a contact initiated by NMOC.



IFPS staff will not check the validity of the text RTECOORATC.

If an ATC unit or an FMP note an abuse in the use of such remark (no coordination/agreement took place, routing submitted was different than routing agreed), then that ATC unit/FMP shall contact directly the aircraft operator.

For civil flights, if there are difficulties to contact or find the aircraft operator, the NM Aircraft Operator Liaison Cell (AOLC) may be contacted at:

[email protected]

For military flights, if there are difficulties to contact or find the aircraft operator, the NM Military Liaison Officer (MILO) may be contacted at:

[email protected]

When the situation of abusing the remark RTECOORATC is evaluated as a significant risk or a potential hazard to aviation safety, contact shall also be achieved through the appropriate NSA/CAA.

18.6 Procedure for Military RPAS (Remotely Piloted Aircraft System)/UAS (Unmanned Aircraft System)

Any queries from ACC/FMP regarding a military flight operated by RPAS/UAS operating in any part of the IFPZ should be directed to the IFPS Supervisor (+3227451950 for FP1 or +33169881750 for FP2) who will, whenever it is available, communicate the relevant phone number. In some cases the flight plan may contain the telephone number of the pilot in item 18 under RMK/.

Error message ref. Various possibilities of ROUTE and PROFILE errors.

Explanation: Due to the particular nature of the RPAS/UAS flights, it is not always possible to have an IFPS compliant routing (RAD, DCTs, etc.) and these flights usually cannot accept any deviation from their routings. Also, these flights often operate at higher level than normal air traffic.

Instruction: The IFPS staff shall ignore all ROUTE and PROFILE errors and shall insert the relevant IFP indicators.





19 Standard Correction Procedure 2 (SCP2)

2) Requirements

The Standard Correction Procedure 2 (SCP2) shall be used by the IFPS staff where it is necessary to make decisions about message treatment when errors are encountered in the re-addressing function.

There are also specific procedures that shall be followed by the IFPS staff where a message contains an error in the Aerodrome of Departure or in the Destination or Alternate Aerodrome.

Detailed procedures for specific errors may be found in the sections relevant to those errors. Where those sections refer to this procedure in the manual correction process by the IFPS staff, the instructions detailed in this section shall be followed.

19.1 SCP2 General Procedures

During the verification of flight plan data messages, the IFPS may fail the automatic processing of messages and pass them for manual treatment by the IFPS staff.

Where an error occurs in the syntax of the re-addressing function of the flight in the submitted message, those errors shall only be corrected or ignored (e.g. 5 days EOBDT errors before a long public holiday weekend) by the IFPS staff in the event that:

The message originator has been successfully contacted

or

The necessary action concerning the required correction is clear and unambiguous

or

Where it is an error in the re-addressing line(s): o If the departure aerodrome is outside the IFPZ, and the message originator and AO

are not contactable, the invalid address shall be deleted and the message originator shall be advised of such via an AFTN or SITA message or

o If the departure aerodrome is inside the IFPZ and it is not possible to contact the message originator to coordinate a correction, the message shall be rejected.

In such cases, it shall be the responsibility of the message originator to confirm the correct address, and to take the appropriate action based on that confirmation.

19.2 SCP2 Table for Aerodrome of Departure, Destination or Alternate Destination

The following flow chart gives an indication of the decision processes governing the manual correction by the IFPS staff of messages containing errors in the aerodrome of departure, destination or alternate destination.



Figure 4 - SCP2 Table for Aerodrome of Dep, Dest or Altn Destination



20 Flight Plan Reprocessing

1) General

Once processed by the IFPS, flight plans are subject to flight plan reprocessing, in which all flight plans held by the IFPS are subject to a reprocessing against any possible environment modifications that may impact them.

Each flight plan held in the IFPS valid flight plan database shall be reprocessed against the NM CACD every 30 minutes until the EOBT of that flight.

This reprocessing is intended to accommodate the on-line input of dynamic environment data such as RAD restrictions and airway closures in the NM CACD at any time. When such on-line inputs are made, any existing valid flight plans held by the IFPS will not have been checked against the new restrictions, thus necessitating the introduction of reprocessing.

This reprocessing feature, in conjunction with the on-line input of new RAD restrictions and closures of airways, is designed to develop greater consistency of flight plan data between the AO, ATS and the NM by reprocessing flight plans against constraints (closures) and opportunities (openings) and/or corrections of RAD restriction in the NM CACD.

2) Requirements

The reprocessing of the IFPS flight plan database shall occur automatically every 30 minutes as from 12 hours (or filing time if less than 12 hours) prior to the EOBT of each flight plan until the EOBT of each flight plan.


Where a flight plan is reprocessed during one of the possible events and is found to be inconsistent with the NM Environment data at that time, the following process shall take place:

20.1 Filing time (or - 12 hours before EOBT) to - 1 hour (included) before EOBT

Any flight plan found to be inconsistent with the NM Environment data at that time shall be given an IFPS status of REVAL_SUSPENDED. The IFPS shall send an internal modification message to the ETFMS; this change does not alter the existing flight plan data in any way, but provides the ETFMS with the necessary information in order that the flight plan shall be suspended via a Flight Suspension (FLS) message.

Flights originating from outside the IFPZ or flights with STS/HOSP, FFR, SAR or MEDEVAC in Item 18 shall not be suspended and shall be given the REVAL_ADVISORY status (see 28.2 EOBT – 1 hour (excluded) to EOBT).

Example of FLS content

—TITLE FLS

—ARCID ABC101

—IFPLID AA12345678

—ADEP EGLL

—ADES LIRF

—EOBD 020423



—EOBT 0945

—NEWRTE N0447F390 MID UN615 XAMAB UL612 MILPA UM730 BEROK UL153 XIBIL

—COMMENT INVALID ROUTE BY REVALIDATION

—ERROR PROF: RS: TRAFFIC VIA MILPA UM135 GVA IS ON FORBIDDEN ROUTE [LS2026A]

—ERROR PROF: RS: TRAFFIC VIA VEROB UM135 TOP IS ON FORBIDDEN ROUTE [LILS1004A]

—ERROR PROF: RS: TRAFFIC VIA UNITA UL50 ELB IS ON FORBIDDEN ROUTE [LI2019A]

—TAXITIME 0020

An ‘early FLS’ shall be sent between -12 to -2 hours before the EOBT to the flight plan originator, to the originator of subsequent associated messages and to the AOCC (when the AOCC is defined as receiving copies of IFPS ORM messages).

An FLS shall be sent between -2 to -1 hours before the EOBT to:

The AOCC (when that AOCC is defined as receiving copies of IFPS ORM messages, IFPS and/or CASA).

The AOCU or Handling Agent or both or none according to ENV setting.

The flight plan originator and to the originator of any subsequent associated messages The ADEP ARO if no AOA is retrieved. The ADEP TWR, or the ADEP FMP if no TWR in the ATFM adjacent area.

The ADEP TMA, EN-ROUTE ACCs and ADES TMA if requested by the ATC.

Note Originators of flight plan messages when being suspended shall not react to the FLS by contacting the Flow Management helpdesk. Only a CHG, CNL or DLA message can appropriately act on the flight suspension. The FLS message contains a proposed route in the NEWRTE field.

In case of early re-opening of routes or deactivation of a RAD restriction, the IFPS supervisor shall identify via the ‘non compliant listing’ function those flights planned to take off in less than an hour in order to de-suspend them via the force compliant function.

20.2 EOBT – 1 hour (excluded) to EOBT

The flight shall be given an IFPS status REVAL_ADVISORY and a message shall be automatically sent to the flight plan originator that contains the aircraft identification, aerodrome of departure, aerodrome of destination, EOBT, EOBD, and in most cases a proposed alternative route preceded by the list of errors generated in the reprocessing.

It is strongly recommended for the flight plan originator to amend the route using the alternative present in the message or any other alternative providing that the new routing is IFPS compliant.

In case the alternative route proposed in the message is used, it remains the flight plan originator’s responsibility to assess if that route is operationally acceptable (length, countries overflown, weather, overflying permits, etc…).

Flights originating from outside the IFPZ or flights with STS/HOSP, FFR, SAR or MEDEVAC in Item 18 shall not be suspended and shall be given the REVAL_ADVISORY status.

The text used in the message to indicate a reprocessing failure shall be:

‘YOUR FPL’ARCID EOBT EOBD ADEP ADES’ HAS FAILED IFPS REVALIDATION’

‘IF NO REROUTE IS FILED EXPECT A SIGNIFICANT OPERATIONAL PENALTY’



Operational penalty indicates that if the route is not amended prior departure to an IFPS compliant route, ATC may have to re-route the flight to avoid an airspace constraint (closed airspace, closed route, etc) with the possible consequence of a route extension.

20.3 General Procedures for REVAL_SUSPENDED

Figure 5 - IFPS Reprocessing Table 1

Note (1) Flights departing from outside the IFPZ and/or flights with STS/HOSP, FFR, SAR or MEDEVAC are not subject to this process and shall fall under Table 2: ‘Revalidation Advisory’ procedure.



Note (2) In the case of a wrong flight suspension of a flight plan message (e.g. incorrect RAD capture) or where the flight suspension is not applicable any more (e.g. end of military exercise and route re-opens), the IFPS staff may use the ‘force compliant’ feature to generate and reprocess a correct flight plan, which is then sent to the ETFMS, thus removing the flight suspension. This action may also be carried out after a telephone call from a flight plan originator and whenever a flight is identified as being genuinely wrongly invalidated.

20.4 General Procedures for REVAL_ADVISORY

The system automatically sends a message to the flight plan originator that contains sufficient information for the flight plan message originator to take action on that message via a submitted CHG, DLA, or CNL and re-file to achieve a compliant flight plan message in the IFPS.

Figure 6 - IFPS Reprocessing Table 2

20.5 Associated Invalid Messages

Error message ref. Non-specific.



Explanation: If an error that caused a revalidation failure is ignored in an associated message, the flight plan will be automatically forced compliant. For this reason, any invalid message that associates to a flight plan that is in a status of REVAL_SUSPENDED or REVAL_ADVISORY, should be processed by the IFPS staff without ignoring the error that caused the revalidation failure, or rejected even if the message is not attempting to change the route (e.g. modification message (CHG) with only a change to RMK/).

It is the responsibility of the flight plan originator to solve the problem that caused the revalidation failure before submitting messages for other updates.

Instruction: When a message associates to a flight plan that is in status REVAL_SUSPENDED or REVAL_ADVISORY and is changing an item of the flight plan that does not concern the route and gives the same error that caused the flight to fail revalidation, the message shall be treated by the IFPS staff in accordance with SCP1, but those errors that caused revalidation failure shall not be ignored.

20.6 General Procedures for Message Originators

Originators of flight plan messages when being suspended due to IFPS revalidation shall not react to the FLS by contacting the Flow Management helpdesk. The FLS contains the following comment: INVALID ROUTE BY IFPS REVALIDATION.

Only a CHG, CNL or DLA message can appropriately act on the flight suspension.

The FLS message may contain an IFPS compliant route, in which case the route can be found in the field “NEWRTE”.

Before re-filing with the route provided within the FLS message (NEWRTE field), the message originator is responsible for assessing whether that route is operationally acceptable (length, countries overflown, weather, overflying permits, etc…). The route contained in the NEWRTE while being “IFPS compliant”, does not guarantee to be avoiding ATFM constraints.






21 ATC Pre-departure FPL modification (AMOD)

1) General

Once processed by the IFPS, flight plans may be subject to the notification of route and level changes by ATC units on receipt of the distributed flight plan data when the filed route could affect the safe conduct of the flight.

This process results from the European Commission Regulation (EC) No 1033/2006, which states ‘ATC Units shall make available, through IFPS, any necessary changes affecting the route or flight level key items of a flight plan that could affect the safe conduct of a flight, for flight plans and associated update messages previously received by them from the IFPS’.

No other changes to or cancellation of a flight plan shall be made by an ATC unit in the pre-flight phase without coordination with the operator.

2) Requirements

ATC units shall notify the IFPS of any solutions introduced for difficulties found with respect to the route or flight level elements of flight plans (and those difficulties could affect the safe conduct of the flight) received by that ATC unit during the pre-flight phase of operations from the IFPS under the following circumstances:

When the exit point from its area of responsibility changes from the exit point indicated in the last route information received from the IFPS.

When the cruising level of the flight is changed when compared with the flight level requested in the last route information received from the IFPS.

Note AMOD shall not be used for flow related issues i.e. to move a flight to a different ATC sector.

The means by which ATC units should notify the IFPS of such changes are either via a telephone call, or via a message with title ‘AMOD’.

ATC units shall not submit pre-departure amendment messages less than 30 minutes before the EOBT of the flight.

The IFPS shall ensure that any difficulties with respect to the route or flight level elements of distributed flight plans, notified by ATC units during the pre-flight phase of operations, are communicated to the originator of the flight plan.

3) Message Format

Message Submission by an ATC Unit to the IFPS:

The format used by ATSUs to submit any necessary changes affecting the route or flight level to the IFPS shall be either in ADEXP or ICAO format, using the message title ‘AMOD’.

The message should be either:

The ICAO flight plan format containing all the necessary fields including the revised and complete Item 15 information:

(AMOD-ABC123-IN

-B732/M-SRWY /C

-EHAM

-N0430F280 CPT UL9 SLANY

-NEW N0430F280 CPT UL983 BIG UL52 SLANY



-EINN

-RMK/ROUTE CLOSED D850 ACTIVE)

OR

The AFP-style in ADEXP format, preferably without estimate information, but containing the revised route as it would normally be produced for an AFP message i.e. containing at least the route within the ATC unit airspace submitting the message:

-TITLE AMOD

-REASON FOR AN ‘AMOD’ BY ACC

-ARCID ABC123

-ARCTYP B732

-CEQPT SRWY

-SEQPT C

-ADEP EHAM

-ROUTE N0430F280 CPT UL9 SLANY

-NEW ROUTE CPT UL983 BIG UL52 SLANY

-ADES EINN

The resulting IFPS message to be sent to the concerned Aircraft Operator or Message Originator shall be:

On behalf of <XXXXX> ATSU, XXXXZQZX, the following FPL <keyfields> contains route inconsistencies for XXXX airspace.

XXXX ATSU, in line with COMMISSION REGULATION (EC) No 1033/2006 has informed IFPS and requests a CHG to be sent in order to correct the route as follows:

(AMOD-ABC123-IN

-B732/M-SRWY /C

-EHAM

-N0430F280 CPT UL9 SLANY

-NEW N0430F280 CPT UL983 BIG UL52 SLANY

-EINN

-RMK/ROUTE CLOSED D850 ACTIVE)

A CHG or CNL+ refile should be sent as soon as possible.

NMOC on behalf of XXXX


The IFPS shall not automatically process any message with title ‘AMOD’; Whenever the message title “AMOD” is recognised in ICAO or ADEXP format, it shall be presented to an IFPS staff with the warning: GEN277: MESSAGE REQUIRES SPECIAL HANDLING and shall be given a priority in the IFPS invalid messages queue.



22 IFPSTOP/IFPSTART

2) Requirements

The designators IFPSTOP and IFPSTART are tools that enable the IFPS staff to stop profile calculation for part or parts of the route given in flight plans or associated messages submitted to the IFPS for processing.

There shall be no limit to the number of IFPSTOP and IFPSTART indicators that may be used in the route description.

The designators IFPSTOP and IFPSTART shall only be used by the IFPS staff during the manual correction of route details in flight plans and associated messages submitted to the IFPS for processing when it is not possible to apply any other manual correction solution.

That part of the route within the designators IFPSTOP and IFPSTART shall be kept as short as is reasonably possible by the IFPS staff, as the data within that part of the route may be amended by the relevant ATS Unit. Should the relevant ATS Unit make such a change, the result could be an inconsistency between the data held by the IFPS and flight crew and that held by the relevant ATS Unit.

The use of IFPSTOP and IFPSTART shall not be offered as a proposed solution to message originators. It shall not be required to coordinate their use as the trajectory of the flight will not be changed in that part of the route following IFPSTOP and prior to IFPSTART.

In that part of the route within the designators IFPSTOP and IFPSTART, no automatic addressing shall take place; any required addressing for that part of the route shall be added manually by the IFPS staff.

That part of the route within the designators IFPSTOP and IFPSTART shall not be ‘visible’ in the flow management systems.

3) Message Format

The designator IFPSTOP shall be inserted in the route after the point at which processing by the IFPS is to stop. The designator shall be separated from that point by a space.

Example BPK IFPSTOP

The designator IFPSTART shall be inserted in the route after the point at which processing by the IFPS is to start. The designator shall be separated from that point by a space.

Example CPT IFPSTART


At the point where IFPSTOP is inserted in a route, the system shall stop the profile calculation of that route from that point.

At the point where IFPSTART is inserted in a route, the system shall start profile calculation of that route from that point.

Within a route after IFPSTOP and before IFPSTART, the system shall continue to take account of certain items of information, should they be present. These items shall be geographical coordinates, OAT/GAT, STAY and VFR/IFR indicators, and any changes of speed and level.

Where IFPSTART is used alone in a route, the system shall calculate the route to be a straight line from the departure aerodrome to the point to which IFPSTART is associated. Where geographical



coordinates, OAT/GAT and VFR/IFR indicators, and any speed and level changes are present within this part of the route, they shall be taken into account in the profile calculation.

Where IFPSTOP is used alone in a route, the system shall calculate the route to be a straight line from the point to which IFPSTOP is associated to the destination aerodrome. Where geographical coordinates, OAT/GAT and VFR/IFR indicators, and any speed and level changes are present within this part of the route, they shall be taken into account in the profile calculation.

Note The use of either IFPSTOP/IFPSTART or VFR/IFR and OAT/GAT has an influence on the profile calculation. IFPSTOP/IFPSTART is a manual processing function that results in many, but not all, errors being ignored by the IFPS. That part of a route within an OAT or VFR designation is considered only as text, except where a STAY designator is found after the first point of a VFR/OAT portion (in such a case, the STAY information is taken into account).



23 Key Fields

1) General

Certain flight plan Items are classified as key fields by the IFPS to allow for message association. These key fields may not be modified by a modification message (CHG).

Those flight plan items that are considered by the IFPS as key fields are:

Aircraft Identification. Aerodrome of Departure. Aerodrome of Destination.

Date of Flight.

Note The date of flight may not be modified as a direct modification of the DOF sub-field, but a change of EOBT via a modification or a delay message may trigger a change of date of flight.

2) Requirements

The IFPS shall not accept messages attempting to change key field data by modifying an existing flight plan. Where such messages are received by the IFPS, they shall be rejected, and the existing flight plan shall remain unchanged.

3) Message Format

No modification message (CHG) attempting to modify the Aircraft Identification, Departure Aerodrome or date of flight may be submitted to the IFPS for processing.


The IFPS cannot accept modification messages (CHG) attempting to change key field data by modifying an existing flight plan. The IFPS shall only accept changes in key fields where the existing flight plan is cancelled, and a new flight plan containing the revised data is submitted to the IFPS for processing.






24 Message Association

2) Requirements

The IFPS shall check all messages submitted for processing to establish if the key field data matches that key field data of any existing message or messages in order that any necessary association may take place.

The message association checks are necessary to ensure that no two flight plans with the same aircraft identification or aircraft registration shall exist within the IFPZ for flights where the calculated profiles overlap in time within given parameters.

For associated messages, the checks are carried out to ensure that those messages are linked to the correct flight plan.

The key fields checked for association purposes, where they exist in the message type, shall be:

Aircraft Identification. Aerodrome of Departure.

Aerodrome of Destination. Date of Flight. Estimated Off-Blocks Time. Total Estimated Elapsed Time.

Aircraft Registration (except for military flights).

Note Where a message is submitted in ADEXP format, the IFPLID may also be used for message association.


The IFPS shall check all messages submitted for processing to ensure any necessary association takes place.

The association process may result in:

Single association

Where the message associates with one flight plan.

Multiple associations

Where the message associates with more than one flight plan. Where more than one flight plan exists in the IFPS database with the same callsign, departure aerodrome and destination aerodrome (e.g. the same flight on consecutive days), it is possible that the IFPS will be unable to automatically associate any subsequent messages with the correct flight plan.

Where such ambiguity exists, the subsequent message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

No association

Where the message does not associate with any flight plan.

Invalid association

Where the message associates with a message that has failed automatic processing by the IFPS and is currently awaiting manual treatment.



Full message association

When processing a new flight plan, full association shall take place provided the three main key fields (aircraft identification, departure aerodrome and destination aerodrome) match with a single existing flight plan, and where the filed total estimated elapsed time of the two flights overlaps.

When a new FPL submission has the same ARCID, ADEP, EOBT, ADES, EOBD, route string and list of errors as a FPL that has already been rejected, then this new submission shall be automatically rejected.

When a submitted FPL associates with a stored flight, the reaction of the IFPS in this situation shall depend on the originator of the new flight plan:

Where the originator address of the new flight plan is different to that of the original flight plan, the IFPS shall reject that new flight plan with an error:

‘EFPM: FLIGHT PLAN ALREADY RECEIVED FROM ADDRESS <AFTN or SITA address>’

Where the originator address of the new flight plan is the same as that of the original flight plan, the IFPS shall update the existing flight plan with any information in the new flight plan, except the EOBT, that differs from the original.

Partial message association

Partial message association shall occur where the aircraft identification and either departure aerodrome or destination aerodrome matches with any existing flight plans and where the filed total estimated elapsed time of the two flights overlaps. Partial association shall normally result in an automatic rejection for messages other than RQP, RQS and AFP. The error message sent with the reject message shall indicate with which flight plan the message associated with.

Duplicates

Where a submitted message is an exact character match with a previously received message, has the same or an unknown message originator, and has a filing time within 5 minutes of the previously received message, then that submitted message shall be automatically discarded as a duplicate. The flight plan history shall show these messages as Duplicate.

Note Where a message is discarded as a duplicate, no operational reply message is sent to the message originator, and the message is not processed in any way by the IFPS.

24.1 Anomalies on Receipt of Duplicate Flight Plans

Error message ref. None.

Explanation: If multiple associated messages are submitted to the IFPS in such a sequence that one of the subsequent messages is an exact duplicate of a previously submitted message, that subsequent message shall be automatically discarded if the submission is within 5 minutes of the original.

Such a scenario is achieved when the messages are submitted in the sequence FPL-CNL-FPL, where the second FPL is an exact character match of the original; or FPL-CNL-FPL-CNL, where the second CNL is an exact match of the first.

Instruction: The message originator must make a modification to the re-submitted message.



25 Profile Calculation/Route Analysis

1) General

The flight profile is a representation of the four dimensional path that a flight is expected to follow between departure and arrival aerodrome. The profile calculation is required to validate the route of that flight, to determine the address list for the distribution of messages and to facilitate air traffic forecasting.

2) Requirements

All flight plans and associated messages for IFR/GAT flights or parts thereof operating within the IFPZ shall be submitted to the IFPS for processing.

The profile for any given flight must provide the means to determine the flight levels and times at which it is expected to enter/overfly/exit any significant point that may be used as a potential parameter for validation, distribution and forecast.

The IFPS shall check all those messages submitted for processing. As far as possible, those messages shall be processed automatically, but some messages may require manual treatment by the IFPS staff. During the process of checking against the CACD and any resulting necessary automatic correction, the IFPS shall extract the data in each message, including the route description, and shall calculate a four-dimensional profile for that flight based on that extracted information.

Note The profile calculation does not take into account weather data or individual flight characteristics such as load sheets for individual aircraft (except if specified in item 18 under RMK/), as it is the case with profiles calculated by aircraft operators.

For profile calculation and route analysis the IFPS shall use the following items/elements from the flight plan or associated message:

Flight rules and flight type. Aircraft type and the corresponding performance data from the NM CACD. Aerodrome of departure and estimated off-block time.

Initial speed and requested flight level. Route elements including change of speed/level. Aerodrome of destination, total estimated elapsed time.

Item 18: PBN, EET, DOF, DLE, RMK.

In order to improve the IFPS profiles accuracy compared with the profiles as calculated by aircraft operators it is possible for message originators to include profile data in the sub-field RMK/ of the ICAO format message, or in specific ADEXP field in ADEXP message or via B2B.

This profile data that may be provided is:

Taxi (taxi time). For IFPS profile calculation, a standard taxi time dependant on the aerodrome of departure is used. If the airline operator considers holding a more accurate taxi time, then it may be inserted.

Take-off weight (TOW). For each aircraft type, the NM CACD has 3 performance tables: low, nominal and high. By default, the nominal data is used. The provision of the take-off weight may result in IFPS using another table when calculating a profile.

Distance at location (DAL).

Top of climb (TOC): position for every transition from a climb phase to a cruise phase. Top of descent (TOD): for every transition from a cruise phase to a descent phase. Bottom of climb (BOC): position for every transition from a cruise phase to a climb phase. Bottom of descent (BOD): for every transition from a descent phase to a cruise phase



Normally profile data shall be automatically generated by the Computerised Flight Plan Service Provider (CFSP) used by the operator. Profile data should not be created manually except for TAXI and TOW.

Although it may not be required by a National Authority through AIP publication, the message originator may indicate the SID and STAR designators (for aerodromes inside the IFPZ) in the flight plan route submitted to IFPS. Whenever present, such designators shall be used by the IFPS for the profile calculation. The IFPS will ensure that in messages distributed to ATC, the SID and STAR designators will not be present whenever they are not required.

Whenever present in a message, TAXI, DAL, TOW, TOC, TOD, BOC BOD shall be used by the IFPS for the profile calculation, providing that they do not contain errors in format or discrepancies in content. The IFPS shall not raise any error for syntactically incorrect elements with the RMK/ sub-field or in the specific ADEXP fields. Such syntactically incorrect elements shall be ignored by the IFPS.

An address list shall be automatically generated by the IFPS, based on the calculation of ATC units that are planned to handle that flight.

After processing, the IFPS shall distribute messages to ETFMS for ATFM purposes and to all those ATC Units within the IFPZ through whose airspace that flight is calculated to pass while operating under IFR/GAT conditions.

Note Different message types may contain different address lists; for example, an Arrival Message shall only be distributed to the ATS reporting office, approach and aerodrome control tower of the aerodrome of departure, if they have specified a requirement of arrival notification.

3) Message Format

The format of each flight plan or associated message item is described in the corresponding sections.

For the profile data provided within the sub-field RMK/ of an ICAO format message the following format shall be used:

TAXI: Estimated TAXI time at the aerodrome of departure. Format: TAXI: <hhmm>. Example: RMK/TAXI: 0012. Maximum value accepted is 1 hour and 30 minutes.

TOW: Actual Take-Off Weight. Format: TOW:<weight> weight to be expressed in kilograms. Example: RMK/TOW:137500

Note DAL is only supported for the aerodrome of destination and when the route does not contain any OAT, VFR or STAY portions.


The four-dimensional profile calculated by the IFPS for each IFR/GAT flight or part thereof within the IFPZ shall be based on the route and speed/level information where given in Item15: Route, on the aircraft performance, the Estimated Off-Blocks Time (EOBT) and the Estimated Off-Blocks Date (EOBD) of that flight and/or based on the airline operator profile data if provided in the message. If the profile data provided is found to be inconsistent when compared to the profile as calculated by the IFPS, then the data is disregarded.

For those flights that are flying across two AIRAC (EOBDT in one AIRAC and landing in the following AIRAC), IFPS checks the profile against the constraints of both AIRAC. However the IFPS cross AIRAC check applies only to the flight plan initial validation and subsequent associated messages (DLA, CHG) and does not apply to IFPS revalidation (see section FLIGHT PLAN REPROCESSING).

In addition, whenever present in a message, the estimated elapsed time(s) (EET) shall be used by the IFPS for profile calculation, together with the total elapsed time (Item 16B). Prior to using the EET information, the IFPS shall validate it against its own calculated EETs allowing for the provided EETs to be within a pre-defined window around the EETs as calculated by the IFPS. In the case the



provided EET information is found to be outside this window, the message shall not be invalidated. In this case the IFPS shall retain its own calculated EETs.

It should be noted that IFPS will use EET given at significant points (providing that those points are on the route) as well as EET given at FIR boundaries.

Note Whenever a flight plan route is modified, the message originator shall ensure that the estimated elapsed times (EET) are also modified in order to be consistent with the new route and also any profile data if provided in the original message.

Whenever present in messages submitted to the IFPS, TAXI, DAL, TOW, TOC, TOD, BOC and BOD elements shall be removed from messages transmitted to external addresses.

The profile shall be a calculated point profile, where the level and time of that flight for each specific point along the route shall be calculated by the IFPS. The profile shall consist of a departure phase, an en-route phase and an arrival phase.

Although it may not be required by a National Authority through AIP publication, the message originator may indicate the full SID and STAR designators in the flight plan route submitted to IFPS. Whenever present, such designators shall be used by the IFPS for the profile calculation. The IFPS will ensure that in messages distributed to ATC, the SID and STAR designators will not be present when they are not required.

A taxi time shall be included in the profile calculation as and where that taxi time is held in the NM CACD.

When the profile has been calculated, the IFPS shall compare the calculated total EET to the total EET indicated in the message. A percentage may be used to adjust all estimate times at points along the path of the calculated profile of the flight to arrive exactly within the total EET indicated in the message.

The calculated point profile shall be the basis for further checking of the route and shall be used to determine the point of entry to or exit from the IFPZ where applicable.

The profile shall be used to check the flight path against airway requirements and against airspace requirements.

Where the IFPS calculates a flight to violate airway availability or RAD conditions, or where a flight is not compliant with 8.33 kHz or RVSM requirements, that message shall fail automatic processing and be passed for manual processing by the IFPS staff.

The IFPS shall identify a list of those ATC addresses to which that message shall be sent, based on the calculated profile. The profile calculation shall produce a list containing all airspaces crossed by the flight path. It shall contain only those airspaces calculated to be entered by any part of an IFR/GAT flight within the IFPZ.







26 Military Flights

1) General

All flight plans and associated messages for IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be submitted to the IFPS for processing.

This shall include those flights where the type of flight is indicated as military (M) in the flight plan, where all or part of the flight is operating within the IFPZ under IFR/GAT conditions.

As the terms ‘GAT’ and ‘OAT’ have been developed within the European region as tools to assist in European flight planning, for the purpose of clarity, the following meanings shall be attached to those terms:

General Air Traffic (GAT): Flights or parts thereof that are operating subject to civil ATC rules and procedures.

Operational Air Traffic (OAT): Flights or parts thereof that are operating subject to military ATC rules and procedures.

The IFPS shall only process those military flights or parts thereof that are operating within the IFPZ under IFR/GAT conditions; the IFPS shall not process those military flights or parts thereof operating within the IFPZ under OAT conditions.

26.1 General Procedures

Due to the necessary complexity of the routes of some military flights, the IFPS may be required to process routes that cannot conform to all those requirements given for a GAT flight. Such routes shall mean that the submitted message shall fail automatic processing and shall require non-standard treatment by the IFPS staff.

Although it remains the responsibility of the message originator to submit a correct route as far as possible, it may be necessary for the IFPS staff to undertake any of a number of possible actions to assist in the acceptance of some of these military routes, depending on the information available for that flight.

On receipt of a military flight plan or associated message giving a non-standard route, the IFPS staff should check the sub-field RMK, for any comments therein that might be of assistance. Such comments could give an indication that the flight is following an in-flight refuelling route, or may not enter certain national airspaces, or is taking part in a military exercise, or similar.

Due to such comments, and the fact that many military flights are strictly governed as to which national airspaces they may overfly, great care should be exercised by the IFPS staff when dealing with such flights. It may not be possible to have a fully-correct route when taking into account all these factors, and when such is the case, the IFPS staff should:

Check for compliance with the military RAD routes.

Check for any indication in the message that gives a reason for a non-standard route (where none is given, it is advisable to call the message originator, where possible, to confirm any reason for a non-standard route).

Check for any fax received by the IFPS giving authorisation for a non-standard route.

Where possible, coordinate any necessary route changes with the message originator, regardless of the presence of the IFPSRA indicator in Item 18.

o Where it is clear that the flight may not follow a standard route, the IFPS staff should contact all those FMPs within whose airspace the non-standard route is planned, in order to obtain explicit approval for that route, or to co-ordinate any modifications to it that are required by ATC.

Apply SCP1.






27 General Air Traffic/Operational Air Traffic (GAT/OAT)

2) Requirements

The IFPS shall only process those military flights or parts thereof that are operating within the IFPZ under IFR/GAT conditions; the IFPS shall not process those military flights or parts thereof operating within the IFPZ under OAT conditions.

Military flights intending to operate within the IFPZ under civil rules and procedures (GAT) shall submit a flight plan to the IFPS for processing, indicating clearly in that flight plan where the flight intends to operate under those conditions.

The point at which a military flight intends to change to or from GAT shall be a published waypoint from the relevant National AIP, or a set of geographical coordinates (unless not allowed by the relevant National AIP).

3) Message Format

The method of indicating where a flight intends to change to/from civil/military control is the insertion of the terms ‘OAT’ and/or ‘GAT’ in the route immediately after the point at which the change is intended to take place.

Example 1

N0400F330 ………….. LAMSO DCT NOLRU OAT T911 ……………

The flight intends to change from GAT to OAT at the point NOLRU so the IFPS shall stop route extraction from NOLRU onwards.

Example 2

N0400F330 MC1…………..TB6 NTM GAT UR110 ……………

The flight intends to change from OAT to GAT at the point NTM. In this situation, the IFPS shall assume that the entire route prior to NTM was OAT and therefore shall only begin route extraction from NTM onwards.

Where appropriate, it is possible to include an indication of a change to the speed and level of the flight at the point at which the change in condition takes place.

Example 3

N0400F330 ………….. NOLRU/N0375F270 OAT T911 ……………

The flight intends to change from FL330 to FL270 at the point NTM and to change from GAT to OAT at that point so the IFPS shall stop route extraction from NTM onwards.

Note The IFPS shall accept the terms OAT or GAT when separated from the point at which the change is to take place by a ‘/’, but the IFPS shall automatically replace the ’/’ with a space in the output version of the message.



Example 4

Submitted to the IFPS for processing N0400F330 ………….. NOLRU/OAT T911……………

Output by the IFPS after processing N0400F330 ………….. NOLRU OAT T911 ……………


The IFPS shall check the route of a submitted flight plan or associated message for the indicators ‘OAT’ and ‘GAT’, and where these indicators are associated with a published navigation beacon, that change of condition shall be processed automatically.




28 Military Points and Routes

2) Requirements

Those flights operating under OAT conditions shall file named military points and routes only in that portion of the flight that is indicated as OAT.

3) Message Format

Where military points are used in GAT portions of a flight, the point shall be filed as the geographical co-ordinates for the relevant point(s), not as the name.


The IFPS shall check all routes or parts thereof that are filed under GAT conditions. As the IFPS is only required to check GAT designators, any message failing to correctly identify an OAT portion of a route may fail automatic processing in the event that military points and/or routes are indicated in that portion of the route.






29 Addressing

2) Requirements

Military flights intending to operate within the IFPZ under civil rules and procedures shall submit a flight plan to the IFPS for processing, indicating in that flight plan where the flight intends to operate under those conditions.

For those flights operating under OAT conditions within the IFPZ, either wholly or in part, it shall remain the responsibility of the message originator to ensure that the relevant ATC units for those OAT part or parts are addressed. That function shall not be undertaken by the IFPS unless those addresses AFTN addresses are added to the message submitted to the IFPS for processing under the re-addressing function.

3) Message Format

[see section MESSAGE SUBMISSION TO THE IFPS] and

[see section RE-ADDRESSING].


The IFPS shall check the route of a submitted flight plan for the indicators ‘OAT’ and ‘GAT’, and where these indicators are identified, the IFPS shall calculate distribution of that flight plan and associated messages only for that part(s) of the flight operating under GAT conditions. Where any part of the flight operates under OAT conditions within the IFPZ, the addressing for that part of the flight plan and any associated messages shall not be undertaken by the IFPS, instead it shall be carried out by the message originator.

29.1 Processing by the IFPS

[see section MESSAGE SUBMISSION TO THE IFPS] and

[see section RE-ADDRESSING].






30 Blocking Levels

2) Requirements

The IFPS shall accept flight plans and associated messages for military flights operating within the IFPZ under civil rules and procedures where that flight indicates the intention to block more than one flight level.

3) Message Format

The method to indicate level blocking is to indicate at the point at which the level blocking is to start a speed and level immediately followed by ‘B’ and the level to which the level blocking is required.

Example 1

N0400F250 ………………. MUT/ N0400F250B280 R55 AYT……………

The flight intends to block FL250 through to FL280 from the point MUT.

Example 2

N0400F250 ………………. MUT/ N0400F250B280 OAT DCT AYT……………

The flight intends to block FL250 through to FL280 from the point MUT and to change from GAT to OAT at that point so the IFPS will stop route extraction from MUT onwards.






31 RAD for Military Flights

(2) Requirements

The IFPS shall check all military flights (flight type ‘M’) operating within the IFPZ for compliance with all RAD restrictions for that part(s) of the flight that operates under GAT conditions within the IFPZ.

In the event that the flight follows any route listed in the RAD document, the IFPS shall also check those flights for compliance with the routes therein.


Where a military flight is subject to routing restrictions as described in the RAD document, the same processing rules as those used for civil flights shall be applied by the IFPS.

31.1 AIP/RAD for Military Flights

Explanation: Military IFR/GAT flights are subject to RAD and AIP restrictions, but some flights should be excluded.

Instruction: After coordination with the message originator, where possible, where military flights are unable to comply with RAD/AIP restrictions for operational or diplomatic reasons, the IFPS staff should contact the concerned FMP(s) to request non-standard routings. Whenever such routing is provided by the FMP or ATC, the IFPS staff shall insert the IFP indicator ERRRTECOORD.






32 Open Skies Flights

(1) General

The treaty on Open Skies, signed in Helsinki on 24th March 1992, represents a multinational effort to enhance military transparency through mutual aerial observation flights.

The purpose of the treaty is to facilitate the monitoring of compliance with existing or future arms control treaties. Virtually the entire territory of each signatory state is open to such overflights, and the information gathered by the joint teams on each flight is made available for all involved parties.

(2) Requirements

All Open Skies treaty flights shall operate with the callsign ‘OSY’, and three types of flight are allowed, with the last letter of the callsign indicating the type of flight:

F An observation mission. Such flights may contain, the indicator STS/ATFMX, and a remark indicating that the route has been approved and co-ordinated with the relevant National Authorities.

D A demonstration flight. These flights may contain the indicator STS/ATFMX, and a remark indicating that the route has been approved and co-ordinated with the relevant National Authorities.

T A transport flight. These flights shall receive no special status or priority, and shall be subject to the normal IFPS processing.

(3) Message Format

All flight plans to be accepted under the Open Skies exemption agreement shall have a callsign that starts with the letters ‘OSY’, and a last letter in the callsign that shall be either ‘F’ or ‘D’. These flights may also contain, the indicator STS/ATFMX, and in the sub-field RMK, a comment indicating that the route has been co-ordinated with and approved by the relevant National Authorities.

Those flights having a callsign that starts with the letters ‘OSY’, and a last letter in the callsign that is ‘T’ shall not be accepted under the Open Skies exemption agreement.


A number of observation flights with specific routes will be performed in the countries that signed the treaty. Due to the unusual characteristics of these routes (often a series of geographical coordinates), the flight plans are likely to fail automatic processing and be presented in the manual queue for treatment.

Where the correct format is followed, such flights shall be accepted with no route correction, and any route errors being manually ignored by the IFPS staff.

32.1 General Procedures for Open Skies Flights

Error message ref. n/a



Explanation: Those Open Skies flights, with a callsign starting with the letters ‘OSY’ and ending with the letters ‘F’ or ‘D’ may raise various route-related errors and violations.

Instruction: All flights operating with a callsign starting with the letters ‘OSY’ and ending with the letters ‘F’ or ‘D’ shall be accepted by the IFPS staff without modification to the route, regardless of what route-related errors may be raised.

Note Those flights, with a callsign starting with the letters ‘OSY’ and ending with the letter ‘T’ shall be treated by the IFPS staff in accordance with SCP1.



33 Visual Flight Rules (VFR)

(2) Requirements

All flight plans and associated messages for IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be submitted to the IFPS for processing. This shall include those flights where the flight rules are indicated as mixed IFR and VFR, shown as Y (IFR then VFR) or Z (VFR then IFR) in the Flight Rules of the flight plan and where all or part of the flight is operating within the IFPZ under IFR/GAT conditions.

Any intended change of flight rules shall be associated with a significant point. The point at which the change of flight rules is intended to take place shall be a specified ICAO-named designator, a set of geographical co-ordinates, or a bearing and range from a named navigation beacon.

The IFPS shall fully process only the IFR/GAT parts of the flight and distribute the message to those ATC Units handling the IFR/GAT part or parts of the flight.

The IFPS shall undertake only minimal processing of any VFR part of a flight. The IFPS shall not distribute the message to those parts of the flight indicated as VFR unless the message originator makes use of the re-addressing function. It shall remain the responsibility of the message originator to ensure distribution of the message to all those addresses requiring the message for any VFR part(s) of the flight.

It shall remain the responsibility of the message originator to ensure that any VFR part of a flight is filed in accordance with any requirements outlined by the relevant National Authorities.

It is not allowed to fly VFR above FL195.

(3) Message Format

Where a flight intends to change to/from IFR/VFR control, this shall be indicated in the Flight Rules and in the route.

Note Y in the Flight Rules indicates that the flight shall commence under IFR conditions and shall change to VFR.

Z in the Flight Rules indicates that the flight shall commence under VFR conditions and shall change to IFR.

The point at which the flight plans to change from VFR to IFR shall be followed by an oblique stroke or a space and the identification group ‘IFR’. The point may also have the speed and level indicators attached to it but separated by an oblique stroke.

Example

N0487VFR WELIN/N0487F330 IFR UN57 TNT UL28 RODOL…

The flight intends to change from VFR to IFR at the point. In this situation, the IFPS shall assume that the entire route prior to WELIN shall be under VFR flight rules and therefore shall only begin route extraction from WELIN onwards.

The point at which the flight plans to change from IFR to VFR may be followed by an oblique stroke or a space then the identification group ‘VFR’.

Examples

N0487F330 BUZAD T420 WELIN/N0430F190 N57 TNT/VFR … (while not being ICAO compliant, this format is accepted by IFPS and the output will be as follows: …N57 TNT VFR…)

N0487F330 BUZAD T420 WELIN/N0430F190 N57 TNT VFR …



The flight intends to change from IFR to VFR at the point TNT, so the IFPS shall stop route extraction from the point TNT onwards.

Where required by national authorities, the message originator may include an indication of the speed and level of the flight at the point at which the change in flight rules takes place.

Examples

N0487F330 BUZAD T420 WELIN/N0430F190 N57 TNT/N0245A050VFR ……………

N0487F330 BUZAD T420 WELIN/N0430F190 N57 TNT/N0245VFR VFR……………

N0487F330 BUZAD T420 WELIN/N0430F190 N57 TNT/N0245VFR …………… (while not being ICAO compliant, this format is accepted by IFPS and the output will be as follows : …N57 TNT/N0245VFR VFR…The first VFR indicates the flight level and the second VFR indicates the change of flight rules).


The IFPS shall check the route of a submitted flight plan for the indicators ‘IFR’ and ‘VFR’.

The IFPS shall confirm that the filed flight rules and any change of flight rules indicated in the route correspond. Where they do not, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Any change of flight rules shall be processed automatically by the IFPS where these indicators are associated with a significant point.

When a flight transitions from VFR to IFR and the RFL for the VFR portion is ‘VFR’ and the RFL for the IFR portion is above F195, the IFPS shall calculate the flight to be at maximum F195 at the transition point (depending on the distance from the aerodrome of departure and the transition point).

Example

N0330VFR DCT POL/N0330F230 IFR N601 GRICE P600 GLESK

IFPS shall calculate the profile to be at POL at maximum F195 and no error is raised.

Whenever the RFL for a VFR portion is above F195, then the message shall fail automatic processing and shall be passed for manual processing by the IFPS staff.

Examples

Y flight: N0330F230 BCN N864 NITON P17 POL/N0310F175 VFR …

Y flight: N0330F230 BCN N864 NITON P17 POL/N0310VFR …

Y flight: N0330F230 BCN N864 NITON P17 POL VFR …

Are not valid because the previous RFL before the VFR portion (upstream of POL) is higher than F195 (F230).

Solution: indicate a change of RFL below F195 at a point upstream of the point at which the transition to VFR is planned:

N0330F230 BCN N864 NITON P17 BARTN/N0330F190 P17 POL VFR …

Z flight: N0330F225 BCN/N0330F240 IFR N864 NITON P17 POL GRICE P600 GLESK

Is not valid because the RFL for the VFR portion is higher than F195.

Solution: indicate an RFL at or below F195 for the VFR portion:

N0330F195 BCN/N0330F240 IFR N864 NITON P17 POL GRICE P600 GLESK

The full route extraction shall only be carried out for IFR/GAT flights or parts thereof intending to operate within the IFPZ. However, a profile calculation is carried out by the IFPS where data within the VFR portion of the route is syntactically correct. These data items are used in the calculation of



the total estimated elapsed time and any speed/level changes at these data items shall also be taken into account.

The IFPS shall calculate distribution of that flight plan and associated messages only for that part or parts of the flight operating under IFR/GAT conditions. Where any part of the flight operates under VFR conditions within the IFPZ, the addressing for that part of the flight plan and any associated messages is not undertaken by the IFPS. Any necessary addressing for those VFR parts of that flight shall be carried out by the message originator or the aircraft operator, and such addressing may be included in the re-addressing function.

Note The trigger events for the transmission of an AFP message now include a change in flight rules.

The use of either IFPSTOP/IFPSTART or VFR/IFR and OAT/GAT has an influence on the profile calculation. IFPSTOP/IFPSTART is a manual processing function that results in many, but not all, errors being ignored by the IFPS. That part of a route within an OAT or VFR designation is considered only as text, except where a STAY designator is found after the first point of a VFR/OAT portion (in such a case, the STAY information is taken into account).






34 North Atlantic (NAT) Traffic

(1) General

North Atlantic (NAT) Tracks

Where the route in a message submitted to the IFPS for processing contains a North Atlantic Track (NAT), the IFPS shall verify its availability and correctness according to that information provided by Gander and Shanwick in the NAT Eastbound Oceanic Track Structure signal.

(2) Requirements

All flight plans and associated messages for IFR/GAT flights or parts thereof operating within the IFPZ shall be submitted to the IFPS for processing.

Where the route of a message submitted to the IFPS for processing contains a North Atlantic track, the IFPS shall verify its availability and correctness according to that information provided by Gander and Shanwick.


Where a route in Item 15 of a flight plan or associated message submitted to the IFPS for processing contains a North Atlantic Track, the IFPS shall confirm that the requested track is correct and available for that flight.

Those messages that fail automatic processing by the IFPS due to the specified track being incorrect or incompatible with the rest of the route within the IFPZ in the message shall be passed for manual treatment by the IFPS staff.

Those messages that indicate the use of a track outside the published hours of operation of that track shall fail automatic processing by the IFPS and be passed for manual treatment by the IFPS staff.

For Eastbound tracks the airway linking the Oceanic Exit point to the landfall point shall be automatically inserted by IFPS for later transmission in output messages.

Where a flight plan or associated message submitted to the IFPS for processing relates to a flight entering the OCA Oceanic Airspace, the IFPS shall check for the required speed and level conditions at that Oceanic Entry point.

Where for westbound traffic the speed at the Oceanic Entry point is not given as a Mach number, the IFPS shall automatically convert any given value to a Mach number, and output such.

Where for westbound traffic no speed and level indication at the Oceanic Entry point is given, the IFPS shall automatically insert such, basing the values on the last given speed and level indications in the route field of that flight.






35 Flexible Use of Airspace (FUA)/Conditional Routes (CDR)

(1) General

The Flexible Use of Airspace (FUA) Concept has been adopted by the International Civil Aviation Organization (ICAO) with the intention of increasing airspace capacity and improving the efficiency and flexibility of aircraft operations.

The concept is intended to allow the maximum shared use of airspace through civil/military co-ordination. The application of the FUA concept ensures that any airspace segregation shall be temporary and based on real use for a specified time period. Flexible airspace structures have been established that are suited to temporary use, one of these are the so-called Conditional Routes (CDR).

Conditional Routes (CDR) are ATS routes that are only available for use under specified conditions. A Conditional Route may have more than one category, and those categories may change at specified times. Special care shall be taken in the use of Conditional Routes that have been established for the implementation of FUA.

CDR routes are grouped into three categories and are published by national authorities:

Category 1 Conditional Route (CDR1)

This CDR route may be available for flight planning during times published in the relevant National AIP. The EAUP/EUUP shall notify closures of CDR1 routes.


This CDR route may not be available for flight planning. Flights may only be planned on a CDR2 in accordance with conditions published daily in the EAUP/EUUP.


This CDR route shall not be available for flight planning at all. Flights shall not be planned on these routes but ATC may issue tactical clearances on such route segments.

Explanations on other route categories can be found in [see section ITEM 15: Route].

The National Airspace Use Plans (AUPs) contain information on availability of CDR1, CDR2 routes, RSA allocations and FUA Restrictions for a 24-hour period. The AUPs are published by EUROCONTROL as consolidated EAUP (European AUP) (section: - NOM - AD OPS – CADF) daily at the latest at 16:00 UTC (15:00UTC summer) and disseminated to operators for flight planning purposes. The EAUP covers the 24 ’hours‘ time period between 0600 UTC the next day and 0600 UTC the following day and may be accessed via the NOP in the EAUP/EUUP portlet. This information is also made available as a B2B web service via the e-AMI (electronic Airspace Management Information Message).

AUPs can be updated several times by using an UUP (Updated airspace Use Plan). The UUPs are published by EUROCONTROL as the consolidated EUUP (European UUP).

DRAFT AUPs may be published from D-6, when information is available, until the current AUP at D-1 which remains the last publication time to provide a consolidated set of airspace information at network level (EAUP).

DRAFT AUPs, although not valid for flight planning purposes, provide information that can be used by airspace users to improve their planning operations.

An EUUP valid for the period between 0600 UTC the next day and 0600 UTC the following day is possible each hour from 17:00 UTC (16:00 UTC summer) till 20:00 UTC (19:00 UTC summer).

An EUUP valid with immediate effect and until the next day 06:00 UTC is possible every hour from 07:00 UTC (06:00 UTC summer) till 20:00 UTC (19:00 UTC summer).



(2) Requirements

All flight plans and associated messages for IFR/GAT flights or parts thereof operating within the IFPZ shall be submitted to IFPS for processing and shall contain a route, which shall be available at the time and level calculated by the IFPS profile calculation.

Special care shall be taken in the use of Conditional Routes (CDR), which have been established for the implementation of FUA.

The availability of CDR1 and CDR2 routes shall be published on a daily basis in the EAUP/EUUP.

It is the responsibility of the flight plan filer to check the condition of the CDR availability in the EAUP and subsequent EAUP/EUUP and subsequent EAUP(s) if applicable, prior to submitting any messages to the IFPS for processing.

In accordance with arrangements agreed under the Flexible Use of Airspace (FUA) Concept, some Fridays shall be designated as Busy Fridays in the airspace of a number of European states where harmonised early access to weekend/conditional route structure is permitted from 10h00 instead of 15h00 on those designated Busy Fridays. Such additional route availability is normally published by AIP or AIC and is defined in the NM CACD.


The AUP and UUP(s) shall be transmitted to the NM Environment system where it is automatically processed and the CDR conditions of routes are dynamically updated. This information is automatically transmitted to the IFPS and the route conditions updated accordingly.

The route availability conditions used by the IFPS when processing flight plans and associated messages shall be updated automatically when the EAUP/EUUP is transmitted.

The IFPS shall automatically check the availability of Conditional Routes and invalidate those messages where the IFPS calculates the profile of any IFR/GAT part of the route to enter a CDR segment that is not available at that time and level.

Those messages that fail automatic processing by the IFPS for reasons of route availability shall be passed for manual treatment by the IFPS staff.



36 Route Availability Document (RAD)

(1) General

The Route Availability Document (RAD) is a sole-source-planning document that combines AIP Route Flow Restrictions with Air Traffic Flow and Capacity Management (ATFCM) routing requirements designed to make the most effective use of ATC capacity. The RAD is finalised during the ATFCM strategic planning process organised by the NM.

The RAD consists of 7 appendices:

Appendix 1: RAD General Description

Appendix 2: Area Definitions (TMA, FIR etc.). Appendix 3: City-Pair Level Capping.

Appendix 4: Enroute DCTs/General Limits and DCTs MAP. Appendix 5: Airport Connectivity.

Appendix 6: Flight Profile Restrictions. It contains the vertical profile elements of the Letters of Agreement between adjacent ACCs.

Appendix 7: FUA Restrictions. It defines the RSAs and their corresponding restrictions. A Network wide Pan-European Annex.

And if necessary a separate Annex for special events, containing restrictions of temporary nature (i.e. European/World sport events, Olympic Games, large scale military exercises, economic forums …).

The implementation of RAD restrictions is based on the AIRAC calendar as far as possible.

Since the introduction of the RAD, the NM has subsequently developed a process whereby RAD restrictions may be introduced into the NM CACD on-line, rather than only in accordance with the AIRAC calendar. This has been made practical with the introduction of the reprocessing of the IFPS valid flight plan database.

The on-line input and modification of RAD restrictions is designed to allow consistency of flight plan data between the AO, ATS and the NM by reprocessing flight plans against constraints (closures), opportunities (openings) and/or corrections of RAD restriction in the NM CACD.

(2) Requirements


The RAD (Route Availability Document) provides a single fully integrated and co-ordinated list of routing restrictions and requirements for the NM area.

Exceptions to these schemes are not envisaged under normal conditions, however, FMPs and ATSUs occasionally authorise the use of non-compliant routes, on their initiative, for very specific flights (aircraft delivery, equipment test, etc). These one-off authorised exceptions shall be noted in the IFPS operational log book and briefed to the IFPS staff by the IFPS Supervisor. Any additional information or list of authorised flights shall be held at the IFPS Supervisor position. A remark in Item 18, indicating the prior authorisation, will facilitate the identification of these cases during the treatment of the message by the IFPS (see sub-section Flights with Route Coordinated with ATC).

Where such approval is given for specific cases over a period of time, a relevant operational instruction containing the list of those cases having received prior authorisation shall be provided for the IFPS staff and updated as necessary.

For those messages containing route details, the IFPS shall determine the availability of that route or each part thereof, at the time and level calculated for that flight during the profile calculation carried out by the IFPS.



The IFPS shall check all IFR/GAT flights or parts thereof operating within the IFPZ for compliance with any relevant RAD restrictions, including those military flights operating under GAT conditions.

The RAD document shall be updated each AIRAC cycle to reflect periodical changes in the airspace of the IFPZ and shall be available via the NM Website at www.nm.eurocontrol.int/RAD/

An intermediate incremental file is produced and valid until 6 days before the AIRAC switch, to allow modifications to the coming AIRAC. Via this file, the RAD restriction details may be modified after a specified change from an ANSP.

Temporary changes to the RAD restrictions during the currently-applicable AIRAC due to exceptional circumstances shall be published via the ‘What is New’ Web page, giving details of the new restrictions.

Where a RAD restriction is required to be modified or cancelled on-line after an operational incident report, or on request for a new RAD restriction, it shall be entered into the NM CACD on-line only after having been approved by the RAD Management Team and validated by the NMOC.


Where a route listed in the RAD document is filed in the route of Item 15: Route in a message, the IFPS shall check that route for RAD compliance.

Route is RAD compliant

Those messages containing route details that are RAD compliant may be processed automatically by the IFPS and distributed to the relevant ATC Units and ETFMS. An ACK message shall be returned to the message originator/AO.

Route is not RAD compliant

Those messages containing route details that are not RAD compliant may fail automatic processing and be presented to the IFPS staff for manual treatment. A Manual (MAN) message shall be returned to the flight plan originator /AO.

Depending on manual processing procedures, the IFPS staff may accept a message containing a non-RAD compliant route and shall indicate this with the inclusion of the IFP/ERROUTRAD indicator. The message shall be distributed to the relevant ATC Units and ETFMS, with the warning indicator ‘IFP/ERROUTRAD’, and an ACK message including the warning indicator shall be returned to the message originator /AO.

Note With regards to the rules pertaining to the ICAO flight plan form, where a change of speed or level is indicated, the correct interpretation of this provision is that a change in level is to be initiated at the point indicated in the route of the filed flight plan.

The NM systems (IFPS and ETFMS) are designed to calculate aircraft trajectories in line with the ICAO interpretation. But at the same time it is recognised that a number of aircraft operator flight planning systems do not interpret speed level change information in accordance with the ICAO interpretation. This may give rise to flight plans and associated messages being referred for manual processing in IFPS (or rejected by IFPUV) where a submitted message indicates a change of level at a point from which a RAD level restriction applies. In order to ensure that the restriction is fully respected (and thus ensure automatic processing by IFPS) flight plan originators need to submit messages that adhere to the ICAO interpretation of a speed and level change.

Where a RAD restriction is modified or introduced on-line, the impact on those affected flight plans held in the IFPS valid flight plan database shall be indicated to the IFPS staff when the IFPS reprocessing event takes place up to the EOBT of that flight.

Problems in RAD implementation for the AIRAC cycle

Due to the complexity of the RAD, errors may not be detected in time to be corrected in the NM CACD component for an AIRAC cycle. This may then lead to one of the following situations:

http://www.nm.eurocontrol.int/RAD/



Route is RAD compliant but generates incorrectly a RAD error:

Where a route complies with the restrictions detailed in the RAD, a message may fail automatic processing and may be presented to the IFPS staff for manual treatment. This may happen where a specific restriction incorrectly generates an error, causing the IFPS staff to manually force the acceptance of the message. A Manual (MAN) message shall be returned to the message originator / aircraft operator, followed by an ACK message.

Route is not RAD compliant but is automatically accepted by the IFPS:

Where a route does not comply with the restrictions detailed in the RAD document, a message may be automatically processed by the IFPS and distributed to the relevant ATC Units and ETFMS without a warning indicator. This may happen where the Airspace Data Section has disabled a specific restriction, or has wrongly implemented a restriction. Where and if required, the ETFMS may create a ‘zero-rate regulation’ in order to make the originator aware, of the RAD non-compliance. An ACK message shall be returned to the message originator /AO. This ‘zero-rate regulation’ may result in the application of a substantial delay to that flight by the ETFMS [see the Network Operations Handbook - ATFCM Users Manual].

Where a route does not comply with the restrictions detailed in the RAD document, a message may be automatically processed by the IFPS and distributed to the relevant ATC Units and ETFMS, with the warning indicator ‘IFP/ERROUTRAD’. This may happen where a specific restriction has been implemented incorrectly and where the Airspace Data Section has qualified the restriction to be ‘soft’. An ACK message including the warning indicator shall be returned to the message originator /AO.

36.1 General Procedures for Busy Friday and Public Holiday

The weekend route structure is normally made available from 15h00 on the day preceding a Public Holiday until 07h00 on the day after. This availability is entered in the NM CACD either following publication in AIPs and AICs or via the EAUP.

In accordance with arrangements agreed under the FUA Concept, some Fridays shall be designated as Busy Fridays in the airspace of a number of European states where Harmonised Early Access to weekend/conditional route structure is permitted from 10h00 instead of the standard 15h00. Such additional route availability is normally published by AIP or AIC and shall be reflected in the NM CACD.

36.2 General Procedures for RAD Errors due to a NM CACD Deficiency

Restrictions shall be described in one of three different modes in the NM CACD system:

HARD Processing will raise an IFPS error to be corrected in accordance with Manual Processing Procedure.

SOFT Processing will not raise an IFPS error. An IFP/ERROUTRAD indicator shall be automatically inserted into the message. Data on the restriction is present in IFPS (search RAD restriction).

DISABLED Processing will not raise an IFPS error. Data on the restriction is46 not available in the IFPS, but contained in the ‘List of Anomalies Report’ from DT. Traffic might be caught via a zero-rate restriction in ETFMS.

Note The IFPS Software Requirements Document states that only flights that are IFR/GAT at the entry in the reference location are subject to the unit; flights are not subject where they are in OAT, VFR or IFPSTOP.

The IFPS staff shall always check for the correctness of the raised error:



If the error has been raised incorrectly due to a known CACD deficiency, the IFPS staff shall apply the correction procedure as detailed in the operational instructions.

If the error has been raised incorrectly due to a CACD deficiency, the IFPS staff shall raise the corresponding Ops Incident in Remedy CCMS and shall ignore the error.

36.3 Preparation of On-line RAD Modifications

The following procedure describes the steps which will lead from the reception of the claim to the transmission of the data to DT section for input and validation.

1. Reception of Request from: OPS incident report asking to correct a wrongly implemented restriction. The OPS section is

getting the result of the investigation about a wrongly implemented RAD restriction. A decision of disabling the restriction, ignoring the error in IFPS, or correcting the restriction is taken.

A National RAD Coordinator asking to implement a new restriction based on a NOTAM.

2. Assessment of the request considering:

Operational goal. Impact on traffic.

Potential Impact on Flight planning reprocessing.

3. Decision to reject or accept. In case of rejection, possible tactical solutions could be provided.

4. DMR sent to AD supervisor for ENV implementation and validation. This DMR should contain the operational goal and the restriction description.

5. Once the restriction is implemented, a validation process should take place in NMC in coordination between DT and OPS section in order to evaluate the impact of the new/corrected restriction.

6. The decision to enable the restriction in OPS section is taken or not depending on the evaluation result of point 5.



Figure 7 - Preparation of On-line RAD Modifications

36.4 RAD Errors for Profile

To ensure consistency in manual processing for messages with RAD errors due to profile, the following table shall be applied by the IFPS staff:



Figure 8 - RAD Errors for Profile

Green arrows mean YES

Red arrows mean NO

Note The RFL requirement is either:

A general statement on the first page of a RAD annex stating that where the RFL is mentioned, it applies to the complete airspace (e.g. EG and LI annexes).

A specific airspace, in which case it is indicated in the textual description of the RAD unit.

For the point or the segment, in which case nothing specific is stated in the textual description of the RAD unit.



36.5 Verification of RAD Restrictions per AIRAC Cycle

The RAD integrates both structural and ATFCM requirements, both geographically and vertically.

The RAD is updated each AIRAC cycle, following a structured standard process of requirement, validation and publication by the NM in cooperation/coordination with the States and AOs. To enable a thorough verification of the RAD when applied in the IFPS, the following methodology has been developed:

The NM RAD team produces a document containing all the RAD restrictions with every AIRAC release. A draft version of this document is produced at AIRAC -49 (i.e. two AIRAC cycles in advance) in order to allow validation of the RAD, while the final version takes into account the results of that validation prior to final publication at AIRAC -34.

The document is written using an MS Word template, and is named RADnnnn.doc, (where nnnn refers to the AIRAC release number). The document is also converted to PDF format. This document is transmitted by e-mail to, amongst others, the global IFPS supervisor e-mail address, and should be stored in the dedicated directories.

In addition, the Airspace Data section produces two sets of results of currently valid flight plans (extracted from the AN1 output logs), one extracted from a week-end day and another extracted from a week day (invariably a Saturday and Tuesday, respectively). The results are achieved by injecting the sets of flight plans against the new NM CACD in a massive run. In most instances, the errors generated represent a modification in the IFPS (by invalidating certain flight plans) due to new restrictions. However, there are instances when the simple realignment of ATS routes or the removal of a mandatory / forbidden point from an ATS route can invalidate flight plans.

The results have to be carefully analysed by reading the text of the restriction, analysing the contents of the flight profile, and reaching the conclusion of whether the IFPS is behaving in accordance with the published restriction, or not.

In the eventuality of a discrepancy, reference to the national RAD Coordinator is required, via an incident report, to ensure that the document produced internally by the NM RAD team is compliant with that of the national administration. If it is not, an increment file is available to cover the changes from D-34 to D-6 where changes to the RAD restrictions are modified in the NM CACD.

During the validation of the NM CACD test tape, it is of paramount importance to carry out any problem analysis before AIRAC –10, as all the DMRs must be translated into NM Environment data by this date. All DMRs received by AD after this date shall be part of the dynamic implementation of RAD data concept.

This procedure does not permit the detection of flight plans violating RAD restrictions due to an ‘under-definition’ of a particular restriction. These can only be captured by the production of test cases. The following table describes the sequence of events in this procedure:

Date Task

AIRAC –20

Reprocessing of FPLs against new NM CACD (test tape).

AIRAC –10

Deadline for closure of modifications to NM CACD.

AIRAC–7 Reprocessing of FPLs against new NM CACD (final tape).

AIRAC –6 Implementation of Disabled restrictions (following EDTCB meeting) or live update and ‘What is New’ page entry.

AIRAC –4 Production of operational instructions



36.6 RAD Units with Dependant Applicability

The RAD allows for the checking of one constraint, depending on the status of a non-associated entity. For example, the IFPS will raise an error if a flight is planned via airspace ABC (constraint) if route XYZ (entity) is open. Because of the non-associated entities, the IFPS will not always have the exact entry time of the dependant entity. For example, the IFPS will know the entry time into airspace ABC, but will not know the entry time into the dependant route XYZ if the flight route was to be changed. The IFPS uses the time over the reference location of the RAD unit for checking the availability of the dependant entity.

Error message ref. General RAD and Route Availability

Explanation: When flight plan message profiles are arriving around the beginning or end of the route closure, the difference in estimated time over the route segment and estimated time over the reference location of the restriction can lead to a route availability error on one route and a RAD error on the alternative route. It can also lead to a RAD error on the filed route and another RAD error on the alternative route.

Instruction: If a RAD error is raised indicating that:

an alternative route is mandated during its opening times, or

the filed route is forbidden during the opening times of an alternative route

Then the IFPS staff shall apply the following procedure:

If the required re-route puts the profile onto the alternative route during its closure time at any stage, do not use this route. Ignore the RAD error in these cases.

If the required re-route causes another RAD error, determine the calculated entry time into the dependant constraint and ignore the RAD error that is outside the calculated time.

36.7 Incorrectly Suspended Flights

Explanation: When EAUP/EUUP(s) have been processed, the IFPS might incorrectly suspend some flights via the IFPS reprocessing mechanism.



Instruction: The duty Supervisor shall monitor the list of non-compliant flights. Where flights have been identified as being suspended incorrectly, the flight shall be forced compliant as per the following procedure:

If the required re-route puts the profile onto the alternative route during its closure time at any stage, do not use this route. Ignore the RAD error in these cases.

If the required re-route causes another RAD error, determine the calculated entry time into the dependant constraint and ignore the RAD error that is outside the calculated time.

An entry into the Flight Planning logbook via the OPSD Console shall be made accordingly.

36.8 Flight Plan Messages on Closed NTFSR

A non-published RAD unit has been created in order to raise an error in the IFPS when a flight is filed on a closed EI/EG NTFSR and the ETO at the EI/EG boundary is within 20 minutes of the closing time. This RAD unit will display an ‘INSIDE NTFSR BUFFER’ error to signify that the ETO falls within the specified buffer and that ACH/APL derived from an FNM or MFS can have the forbidden NTFSR error ignored.

Error message ref. EURO6000A, 6001A, 6002A or 6003A, ‘INSIDE NTFSR BUFFER’

Explanation: Agreed buffer for acceptance of messages arriving late on NTFSR.

Instruction: FNM/MFS Processing - When an ACH/APL derived from an FNM or MFS message gives a RAD error for flying on a closed NTFSR, the error shall be ignored if the ETO at the EI/EG boundary is less that 20 minutes after the closing time of the route. The special ‘buffer’ error shall also be ignored.

If the ETO is more than 20 minutes after the closing time of the route, the route shall be corrected to follow the published fixed route network.

FPL/CHG/DLA processing - when a FPL, CHG or DLA message gives a RAD error for flying on a closed NTFSR, the IFPS staff shall apply SCP1. If the message is to be rejected, the special ‘buffer’ error shall be ignored before the rejection: this is to ensure that the ‘buffer’ error is not sent in the REJ operational reply message.






37 Reduced Vertical Separation Minima (RVSM)

(2) Requirements

All flights operating in the EUR RVSM area between FL290 and FL410 shall be suitably equipped to do so.

Those flights that are suitably equipped to operate in the EUR RVSM airspace shall indicate such with the letter W in the equipment of a flight plan, regardless of the filed flight level.

RVSM approved aircraft shall indicate their registration in item 18 of the ICAO flight plan under REG/ (or the equivalent field in ADEXP or B2B).

Note The above requirement is only satisfied with the presence of the REG/ field in item 18 of the flight plan and therefore it is not satisfied if the registration of the aircraft is used in Item 7 Aircraft Identification and not specified under REG/.

Only RVSM approved aircraft and non-RVSM approved State aircraft shall operate between FL290 – FL410 inclusive within the lateral limits of the EUR RVSM airspace.

Non-RVSM approved aircraft shall operate below FL290 or above FL410 inside the lateral limits of the EUR RVSM airspace.

Flights operating under VFR shall not be authorised within the lateral limits of the EUR RVSM airspace between FL290-FL410 inclusive.

Civil formation flights shall not be authorised within the lateral limits of the EUR RVSM airspace between FL290-FL410 inclusive.

(3) Message Format

RVSM approved aircraft shall include the following in the flight plan and any associated messages:

Item 10a W

Item 18 REG/

Non-RVSM approved State aircraft or formation flight of State aircraft shall include the following in the flight plan and any associated messages:

Item 8 Type of Flight M

Other information STS/NONRVSM


The IFPS shall check that any flight planning to enter the EUR RVSM airspace is suitably equipped and approved to do so by checking Items 8: Type of Flight, Item 10: Equipment, Item 15: Route and Item18: Other Information in any submitted message.

The IFPS shall check that any RVSM approved aircraft planning to enter the IFPZ has indicated its registration in the flight plan in item 18 under REG/ (or its equivalent field in ADEXP format).



Those messages that fail automatic processing for reasons related to RVSM shall be presented for manual treatment by the IFPS staff, who under certain circumstances may force certain RVSM errors through processing, using the IFPSTOP-IFSTART procedure. This shall result in the automatic inclusion of an IFP indicator in the message.

Where an AFP/AFIL is the source of the flight plan, the system shall automatically insert IFP/RVSMUNKNOWN in Item 18 of that message.



38 8.33 kHz Channel Spacing

(1) General

Due to a congested VHF radio frequency band, the switch from 25 kHz to 8.33 kHz channel frequency spacing in VHF voice communications was designed to increase the number of available frequencies.

The carriage of 8.33 kHz channel spacing capable radio equipment has been made mandatory from the 15th March 2007, for aircraft operating in the IFPZ above FL195, on the understanding that an individual State may grant exemptions within its area of responsibility.

The carriage of 8.33 kHz channel spacing capable radio equipment has been made mandatory from the 1st of January 2018, for aircraft operating in the airspace of the EU Member States plus Norway and Switzerland below FL195 (See note below).

Note: Local exemptions from the carriage of 8.33 kHz capable radios may be applicable in parts of the airspace. Operators are required to check State AIP for applicable exemptions.

(2) Requirements

All IFR/GAT flights or parts thereof operating in 8.33 kHz airspace above FL195 within the IFPZ or below FL195 in the airspaces of the EU member states (plus Switzerland and Norway), are required to carry the 8.33 kHz radio equipment, except where local measures granting exemptions apply (see below: Exemptions) and as specified by the terms of those exemptions.

Whenever an aircraft is equipped with the 8.33 kHz radios, the letter Y shall be inserted in Item 10: Equipment, of the filed flight plan.

Exemptions:

General Air Traffic (GAT) o Above FL195, in the IFPZ, not equipped aircraft may be exempted from the carriage

of the 8.33 kHz radios (refer to the national AIP of the state concerned to see if the flight is eligible) in which case the letter Y shall not be inserted in Item 10a Equipment, but the letter Z shall be inserted in Item 10a as well as COM/EXM833 in the Item 18 of the filed flight plan.

o Below FL195, in the airspace of the EU member states (plus Switzerland and Norway) some airspaces may be exempted from the carriage of the 8.33 kHz radios (refer to the national AIP of the state concerned) in which case the airspace is not inserted in the area where the mandatory carriage check takes place. Such exemption will permit a non-equipped aircraft to fly but only if the flight trajectory remains exclusively in airspaces where 8.33 kHz is not mandatory.

State aircraft operated as GAT (see Note below) o In the IFPZ, State aircraft that are not equipped with 8.33 kHz capable radios but are

equipped with UHF and 25 kHz capable radios shall be permitted to fly in 8.33 kHz airspace where UHF coverage is provided or special procedures are implemented (see the national AIP of the State concerned). To indicate such, the letters U and Z shall be inserted in Item 10a Equipment and ‘COM/EXM833’ shall be inserted in Item 18 of the filed flight plan. The ACK message for such an exempted flight plan shall contain the following comment:

‘THIS FLIGHT MAY REQUIRE SPECIAL HANDLING BY ATC DUE TO 8.33 kHz CARRIAGE REQUIREMENTS’

o If operated exclusively, in the airspaces of the EU member states (plus Switzerland and Norway), below FL195, state aircraft non-UHF and non-833 are exempted. The



letters Y and U shall not be inserted in Item 10 Equipment, but STS/STATE shall be inserted in the Item 18 of the filed flight plan.

Medical flights specifically declared by the medical authorities and aircraft engaged in search and rescue missions, are automatically exempted from the 8.33 kHz mandatory carriage requirements. To indicate such, the letter Y shall not be inserted in Item 10a Equipment and STS/SAR or STS/HOSP or STS/MEDEVAC or STS/FFR shall be inserted in Item 18 of the filed flight plan.

The ACK message for such an exempted flight plan shall contain the following comment:

‘COMMENT FLIGHT PLAN IS NOT COMPLIANT WITH 8.33KHZ RADIO EQUIPMENTS; EXPECT SIGNIFICANT OPERATIONAL PENALTY’

Where the status of the 8.33 kHz radio capability changes prior departure, such a change shall be notified to the IFPS by means of a modification message (CHG) or by filing a new flight plan.

Note Only those flights that are other than Head of State, and that are specifically required by the State Authorities, e.g. military or civil registered aircraft used in military, customs and police services, shall use the sub-field STS/STATE indicator.



(3) Message Format

Figure 9 - IFPS Reference Graph for 8.33 kHz Flight Planning




Two 8.33 kHz regions are defined in the NM CACD which the IFPS uses to perform the 8.33 kHz flight plan checks. The regions for the 8.33 kHz checking mechanism are:

8.33 Region Indicator

Description

833_EUR_IFPS Composed of all those airspaces inside the IFPZ within which 8.33 kHz equipped flights, State aircraft with UHF and non-equipped exempted flights are allowed.

833_VHF_UHF Composed of all those airspaces inside the IFPZ within which only 8.33 kHz equipped flights and State aircraft with UHF are allowed.

The IFPS shall make a crosscheck between the concerned airspaces crossed by the flight profile and the radio communication equipment indicated in Item 10: Equipment and/or type of flight in Item 8: Type of Flight and/or Item 18: other information, provided in the submitted message.

If Item 10: Equipment of the submitted message contains Y, then that flight is considered to be compliant.

If Item 10: Equipment of the submitted message does not contain Y, but contains ‘Z’ and “U” and the exemption indicator COM/EXM833 is present in Item 18: Other Information, and the flight is a STATE aircraft , then that flight shall be considered compliant.

If Item 10: Equipment of the submitted message does not contain Y but contains the exemption indicator COM/EXM833 and the flight is not penetrating the 833_UHF_VHF region and is entirely within the 833_EUR_IFPS, then that flight shall be considered compliant.

If Item 10: Equipment, of the submitted message does not contain Y, neither U and Item 18 contains STS/STATE and the flight is exclusively in the airspace of the EU members states (plus Switzerland and Norway) below FL195 then that flight shall be considered compliant.

In all the other cases, the flight shall be considered not compliant and shall fail automatic processing.

When a flight is deemed to be non-compliant by the IFPS, the following is applied in order of priority:

Whenever the flight is indicated as a STS/SAR or STS/HOSP or STS/MEDEVAC or STS/FFR flight then it is accepted and the following comment is added in the operational reply message from IFPS: ‘FLIGHT PLAN IS NOT COMPLIANT WITH 8.33KHZ RADIO EQUIPMENTS; EXPECT SIGNIFICANT OPERATIONAL PENALTY’.

In case the flight plan is sent for manual processing by the IFPS staff and the 8.33kHz error is manually ignored then the following comment is added in the operational reply message from IFPS: ’THIS FLIGHT DOES NOT COMPLY WITH 8.33 RADIO EQUIPMENT’.

IACH and IDLA messages shall not be checked for 8.33 kHz compliance.

IFP Indicators

IFP/NON833

IFP/833UNKNOWN



39 SSR Mode-S

(1) General

The SSR Mode-S enhanced surveillance programme is designed to provide more and better quality information on aircraft in flight for air traffic control. Mode-S aircraft equipment shall only be mandatory in those airspaces participating in the Mode-S programme. Mode-S airspace is defined as those airspaces from ground up to unlimited for which the Mode-S rules are applicable.

Further details are available at 20Hhttp://www.eurocontrol.int/communications-navigation-and-surveillance or the relevant National AIPs.

The principle of Mode-S dictates that each aircraft is assigned an individual and unique identification number known as an ICAO 24-bit Aircraft Address (AA), which is pre-set and cannot be changed from the cockpit.

Two types of Mode-S shall be available:

a) Elementary surveillance: position + altitude + downlinked aircraft identification. b) Enhanced surveillance: as in Elementary surveillance + heading + speed + selected vertical

intention.

The carriage and operation of Mode-S enhanced surveillance functionality shall be mandatory for all aircraft with:

either a maximum take-off mass in excess of 5700 kg;

or a maximum cruising true airspeed in excess of 250kts;

or both a maximum take-off mass in excess of 5700 kg and a maximum cruising true airspeed in excess of 250kts.

These criteria shall apply to those aircraft conducting IFR flights as General Air Traffic (GAT) in designated airspace.

Note Although the IFPS shall not process VFR flights or those parts of flights conducted under VFR, such flights may be subject to Mode-S requirements. For further details it is advised to check the relevant national AIPs.

(2) Requirements

Those flights that are suitably equipped to operate within the Mode-S airspace shall indicate such in Item 10b: Equipment of the flight plan by inserting one or more of the following letters:

Note When ‘I’ is present it excludes S, E, H, L (as well as P and X).

I (Transponder-Mode-S, including aircraft identification transmission, but no pressure-altitude transmission).

S (Transponder-Mode-S, including both pressure-altitude and aircraft identification transmission).

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.

L Transponder-Mode S, including aircraft identification, pressure-altitude, extended squitter (ADS-B) and enhanced surveillance capability.

(3) Message Format

http://www.eurocontrol.int/communications-navigation-and-surveillance

http://www.eurocontrol.int/communications-navigation-and-surveillance



In addition to those standard equipment designators, I, or one or more of the following designators: S, E, H L, as appropriate for the equipment for that aircraft, shall be inserted in Item 10b: Equipment.


The IFPS shall check compliance with Mode-S requirements, and shall insert the IFP indicator IFP/MODESASP in the flight plan distributed to ATC where that compliance is met. Such compliance shall comprise:

I, S, E, H or L, in Item 10b: Equipment and: The flight enters the designated Mode-S airspace and remains entirely within the Mode-S

airspace for the rest of that flight and arrives at an aerodrome flagged as Mode S or The flight takes place entirely within the Mode-S designated airspace between aerodromes

flagged as Mode S.

Where compliance is not met, the IFPS shall not fail the processing of that message, and shall not pass such messages for manual treatment by the IFPS staff.

It shall be possible to indicate the unique Mode-S airframe code by inserting the sub-field CODE followed by a ‘/’, then 6 hexadecimal characters e.g. CODE/A1234D.

When the sub-field CODE is not followed by 6 hexadecimal characters and there was no CODE value from a previously processed message for that flight, the IFPS shall attach the following warning message to the ORM:

WARN: INVALID AIRCRAFT ADDRESS (CODE) HAS NOT BEEN STORED

and the IFPS shall automatically remove the CODE from that message.

Where the CODE sub-field is not followed by 6 hexadecimal characters and the IFPS holds a CODE value from a previously processed message for that flight, the IFPS shall attach the following warning messages to the ORM:

WARN: INVALID AIRCRAFT ADDRESS (CODE) HAS NOT BEEN STORED PREVIOUS AIRCRAFT ADDRESS HAS BEEN REMOVED

and the IFPS shall remove the CODE from that message and the CODE from the previously processed message.

When a submitted message (AFP, CHG or FPL) changes the status of the IFP/MODESASP indicator, then:

if the existing valid flight plan held by the IFPS contains the IFP/MODESASP indicator, then the distributed message resulting from the new message shall contain the full new Item 18 where such is present.

if the existing valid flight plan held by the IFPS does not contain the IFP/MODESASP indicator, then the distributed message resulting from the new message shall contain the IFP/MODESASP indicator.

IFP Indicators

IFP/MODESASP



40 En-Route Stay Indicator

(1) General

The STAY indicator has been introduced by the IFPS to enable time delays associated with certain special en-route activities such as training flights, air-to-air refuelling, and photographic missions etc. to be entered into the route of a flight plan. This feature shall enable the IFPS to make a more accurate profile calculation.

The STAY indicator may be used in association with any significant point in the route, including the first and last points, but it may not be associated with a SID/STAR designator.

It is also possible to indicate an en-route delay or holding with the use of DLE/ in item 18 of the flight plan (see section EN-ROUTE DELAY OR HOLDING).

The rationale for using the STAY as opposed to the DLE is the following:

The STAY is implemented within Item 15 where routeing/trajectory related information is extracted.

The use of Item 15 and STAY provides the ability to indicate a vertical deviation during the course of the activity.

The use of Item 15 and STAY provides the ability to indicate an area (between two points) where the activity will take place as opposed to a single point.

The use of Item 15 and STAY provides the possibility to indicate training activity taking place at an aerodrome where a training flight may wish to make some practise approaches.

The use of Item 15 and STAY provides the ability to make a correct indication(s) for circular flights i.e. a flight which may pass overhead the ‘DLE/’ point more than once.

(2) Requirements

Where a flight plans to carry out special activities in an area or over an aerodrome, the STAY indicator may be used in the route between the point of entry of the STAY activity and the point of exit of the STAY activity.

The STAY indicator shall only be used for en-route special activities.

The STAY indicator shall only be used for those flights that are completely within the IFPZ.

The time given in the STAY indicator shall be less than the total estimated elapsed time of the flight.

The STAY indicator shall only be available for use in messages with title FPL, CHG or AFP.

The STAY reason shall be indicated in item 18 of the flight plan under STAYINFOn/ (see section STAYINFO).

(3) Message Format

The STAY indicator shall follow the point at which the STAY is to start, separated from that point by a space. The STAY indicator shall consist of the letters ‘STAY’, a sequence number followed by a ‘/’, then four numbers giving the time in hours and minutes for which that flight shall be operating under the STAY condition.

Example …. WAL STAY1/0100 DCS….

The entry point to the STAY area and the exit point from the STAY area may be the same or different points.

Example …. WAL STAY1/0100 WAL….

…. WAL STAY1/0100 DCS….



More than one STAY indicator may be used if so required. Where more than one STAY indicator shall be used, then a sequence number shall be attached to each STAY indicator, using the format of the sequence number up to a maximum value of 9, followed by a ‘/’, then the time indicator.

Example …. WAL STAY1/0100 DCS DCT TLA STAY2/0045 FOYLE….

It shall be possible to indicate changes to the speed and flight level at the entry point to the STAY area or the exit point from the STAY area.

Example …. WAL/N0427F240 STAY1/0100 DCS/N0442F340 DCT TLA STAY2/0045

It shall be possible to indicate changes to the flight rules (IFR/VFR) or type of flight (GAT/OAT) at the entry point to the STAY area or the exit point from the STAY area.

Example …. WAL VFR STAY1/0100 DCS/N0442F280 IFR DCT TLA STAY2/0045 ….

…. WAL OAT STAY1/0100 DCS GAT DCT TLA STAY2/0045 ….

It shall be possible to indicate the reason for the STAY in the flight plan; for this purpose the sub-field heading ‘STAYINFO’ shall be used, immediately followed by a ‘/’, then free alpha-numeric text.

Example 1:

Item 15: Route ….WAL STAY1/0100 WAL….

Item 18: Other Information STAYINFO1/CALIBRATION OF WAL

Example 2:

Item 15: Route ….WAL STAY1/0100 WAL….

Item 18: Other Information STAYINFO1/MULTIPLE IFR APPROACHES AT…

It shall not be possible to have more than one consecutive STAY indicator associated with the same point.


The IFPS shall check in the route of all IFR/GAT flight plans and associated messages for those flights operating entirely or partly within the IFPZ for the STAY indicator. If a STAY indicator is found that does not follow the correct format, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Where a correctly formatted STAY indicator is identified in a flight entering or leaving the IFPZ at any point, that message shall fail automatic processing and shall be passed for manual treatment by the IFPS staff.

Where a correctly-formatted STAY indicator is identified in a flight entirely within the IFPZ, the time given with the STAY indicator shall be taken into account when calculating the total estimated elapsed time of that flight.

Where the calculated total elapsed time of the flight plus the STAY time indicator are greater than the total estimated elapsed time of the flight given in the flight plan or associated message, then that message shall fail automatic processing and be passed for manual processing by the IFPS staff.

Note Those route parts after the start point and before the end point of a STAY indicator shall not be automatically addressed by the IFPS. Should any extra addressing for such be required, it shall be the responsibility of the message originator to ensure any such addresses receive a copy of the message. The Re-addressing function may be used for this purpose.



41 IFPS Monitoring Flight Evolution

(1) General

The IFPS shall monitor the evolution of a flight, as a Flight Status, from the moment a flight plan for the flight has been filed with IFPS until the flight is closed. The passage of a flight from one stage to another shall be determined by either the passage of time or information received via flight plan and associated messages by the IFPS and flight updated messages (FSA, CPR etc.) by ETFMS. It shall be possible for a flight to skip stages and go directly to a later stage without going through all the previous stages.

Linked to the knowledge of the evolution of a flight, the IFPS will invalidate messages depending on the message title and the current status of the flight.

(2) Requirements

Information received by the NM regarding the progression of a flight is used by the IFPS for the processing of flight plan messages.

The IFPS shall reject cancellation (CNL) messages, EOBT and route updates (CHG and DLA) that are received for a flight after the moment the flight was activated in the NM systems. Depending on the type of information received by the NM for a flight, the activation of a flight in the NM systems occurs:

When the flight is reported to be airborne through an FDI, FSA, CPR, AFP, FNM, MFS or APR message.

When the flight is reported to be off-blocks through an ATC DPI (concerns CDM airports and Advanced Tower airports).

At the departure time received in a DEP message.

Linked to the knowledge of the evolution of a flight, the IFPS shall invalidate:

DLA and CNL messages that are associated to a flight that is Off_Blocks, ATC_Activated, Terminated or Deleted.

Modification messages (CHG) that contain EOBT or route changes and that are associated to a flight that is Off_Blocks or ATC_Activated.

Modification messages (CHG) that are associated to a flight that is Terminated or Deleted. DEP, RQP, FNM, MFS and AFP messages that are associated to a flight that is Terminated or

Deleted. ARR messages that are associated to a flight that is Deleted.

The flight status information is sent to the IFPS by the ETFMS in a ‘Flight Update Message’ (FUM). The FUM message shall be recorded in the flight plan history of the flight for which it associated.


It shall be possible to switch the behaviour of the IFPS into one of the following operating states:

Disable

The system shall function as previously implemented with no processing associated with the status of the flight.

Manual

The system shall detect and place in the invalid queue any message associated to a status that is not allowed as specified above.

Automatic



The system shall detect and automatically reject any message associated to a status that is not allowed as specified above.

IFP Indicators

IFP/ERREOBT



42 Special Status Flights (STS)

(1) General

Those IFR/GAT flights or parts thereof operating within the IFPZ that require special handling may use the sub-field STS indicator to indicate those needs.

(2) Requirements

The STS indicators listed below shall be given an automatic exemption from flow regulations.

STS/SAR

STS/HEAD

STS/ATFMX

STS/FFR

STS/MEDEVAC

Note These exemption designators shall only be used with the proper authority. Any wrongful use of these designators to avoid flow regulations shall be regarded by the relevant States as a serious breach of procedure and shall be dealt with accordingly.

The presence in a flight plan or associated message of any one single STS descriptor listed above ensures that the flight will be exempted from flow regulations. For example for a Search and Rescue flight, STS/SAR shall be filed. It is not required to file: STS/SAR ATFMX

EUROCONTROL shall make available to the accountable entity (e.g Member State, ATS Unit) data related to ATFM exemptions resulting from the usage of the above designators (sensitive flights shall be excluded from this data).

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, then one or more of the standardised STS descriptors. Any other reasons for special handling by ATS shall be denoted under the designator RMK/.

Where more than one STS indicator is applicable for a flight, each descriptor shall be separated from each other by a space.

Examples STS/HEAD

STS/STATE ATFMX

Where more than one STS indicator is found in a message, theirs contents shall be concatenated by IFPS within a single occurrence of the indicator but with a space between the two data streams.

Examples Input to IFPS: STS/STATE STS/ATFMX

Output from IFPS: STS/STATE ATFMX


The following table contains those standardised abbreviations as well as the specific meaning attached to each designator:

STS TYPE Description

STS/ALTRV For a flight operated in accordance with an altitude reservation.

STS/SAR For a flight engaged in Search and Rescue missions.



STS/HEAD For a flight with ‘Head of State’ status.

STS/ATFMX For a flight specially authorised by the National Body established for the purpose to be exempted from flow regulations, regardless of any other STS/indicator used (if any).

STS/HOSP For a medical flight specifically declared by the medical authorities.

STS/HUM For flights operating for humanitarian reasons.

STS/STATE For military registered aircraft or civil registered aircraft used in military and/or customs and/or police services.

STS/FFR For a flight engaged in fire-fighting.

STS/NONRVSM For a non-RVSM flight intending to operate in RVSM airspace.

STS/MEDEVAC For a life critical medical emergency evacuation.

STS/MARSA For a flight for which military entity assumes responsibility for separation of military aircraft.

STS/FLTCK For a flight performing calibration of navaids.

STS/HAZMAT For a flight carrying hazardous material.

The following sub-field STS descriptor shall be cross referenced by the IFPS to other Items in the flight plan message:

STS/NONRVSM with the type of flight, number of aircraft, equipment and the route.

To remove STS descriptor(s) from the flight plan currently held by the IFPS, a modification message (CHG) may be submitted to the IFPS for processing that contains the complete Item 18 without the STS descriptor(s) which is intended to be removed.

Any designator possible within STS/ can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.

42.1 Dynamic Properties of the STS Sub-field

STS values may be modified by the subsequent arrival of any of FPL or modification message (CHG):

If an associated FPL is received, any STS values it contains completely replace those that were previously held. If none are contained in the second FPL, it will remove any STS values that were present.

If an AFP is received, the STS values it contains are added to those that were previously held. If a CHG is received, any STS values it contains completely replace those that were previously

held. If none are contained in the modification message (CHG), it will remove any STS values that were present.



43 STS/SAR Indicator

(2) Requirements

Only those flights that are engaged in Search and Rescue missions shall use the sub-field STS/SAR indicator.

By using this STS/SAR indicator the flight shall automatically be exempted from any relevant flow regulations.

This exemption designator shall only be used with the proper authority. Any wrongful use of this designator to avoid flow regulations shall be regarded by the relevant States as a serious breach of procedure and shall be dealt with accordingly.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by SAR.


Those messages containing the Item 18 sub-field STS/SAR that are syntactically and semantically correct, shall be processed by the IFPS and transmitted to the ETFMS system, where the flight shall be exempted from any relevant flow regulations.

It shall be possible for a message originator to remove the STS/SAR indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if SAR is the only STS descriptor or ‘SAR’ if SAR is not the only STS descriptor present in the stored FPL.

The STS/SAR designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






44 STS/HEAD Indicator

(2) Requirements

Only those flights that are with Head of State status shall use the sub-field STS/HEAD indicator.

By using this STS/HEAD indicator the flight shall automatically be exempted from any relevant flow regulations.


(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by HEAD.


Those messages containing the Item 18 sub-field STS/HEAD that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system where the flight shall be exempted from any relevant flow regulations.

It shall be possible for a message originator to remove the STS/HEAD indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if HEAD is the only STS descriptor or

‘HEAD’ if HEAD is not the only STS descriptor present in the stored FPL.

The STS/HEAD designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






45 STS/ATFMX Indicator

(2) Requirements

Those flights that do not require special handling but which are specifically authorised by the relevant national authority to be exempted from flow regulations may use the sub-field STS/ATFMX indicator.


Note The rules for acquiring the necessary permissions to use STS/ATFMX may be found in the appropriate section of the national Aeronautical Information Publication (AIP) of the country in which the aerodrome of departure is located.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by ATFMX.


Those messages containing the sub-field STS/ATFMX that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS where the flight shall be exempted from any relevant flow regulations.

It shall be possible for a message originator to remove the STS/ATFMX indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if ATFMX is the only STS descriptor or

‘ATFMX’ if ATFMX is not the only STS descriptor present in the stored FPL.

The STS/ATFMX designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






46 STS/HOSP Indicator

(2) Requirements

The sub-field STS/HOSP may be used for those flights categorised as a medical flight specifically declared by the relevant medical authorities.

Routine positioning flights e.g. returning empty after an evacuation or positioning for fuel or positioning to an airport to collect a patient sometime after arrival (i.e. not time critical) shall not qualify for use of the sub-field STS/HOSP.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by HOSP.


Those messages containing the sub-field STS/HOSP indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system.

It shall be possible for a message originator to remove the STS/HOSP indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if HOSP is the only STS descriptor or ‘HOSP’ if HOSP is not the only STS descriptor present in the stored FPL.

The STS/HOSP designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






47 STS/HUM Indicator

(2) Requirements

Only those flights that are undertaken for humanitarian reasons shall use the sub-field STS/HUM indicator.

Those flights using STS/HUM shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by HUM.


Those messages containing the sub-field STS/HUM indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system but will not automatically qualify for exemption from any relevant flow regulation(s).

It shall be possible for a message originator to remove the STS/HUM indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if HUM is the only STS descriptor or ‘HUM’ if HUM is not the only STS descriptor present in the stored FPL.

The STS/HUM designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






48 STS/STATE Indicator

(2) Requirements

Only those flights that are other than Head of State, and that are specifically required by the State Authorities, e.g. military or civil registered aircraft used in military, customs and police services, shall use the sub-field STS/STATE indicator.

Flights using STS/STATE shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by STATE.


Those messages that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system, but shall not automatically qualify for exemption from any relevant flows regulation(s).

It shall be possible for a message originator to remove the STS/STATE indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if STATE is the only STS descriptor or ‘STATE’ if STATE is not the only STS descriptor present in the stored FPL.

The STS/STATE designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






49 STS/NONRVSM Indicator

(2) Requirements

Only those State flights (e.g. military, police or customs) which do not indicate RVSM equipment in the message shall use the STS/NONRVSM indicator.

Those flights using STS/NONRVSM shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by NONRVSM.


Those messages containing the sub-field STS/NONRVSM indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system but shall not automatically qualify for exemption from any relevant flow regulations.

It shall be possible for a message originator to remove the STS/NONRVSM indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if NONRVSM is the only STS descriptor or ‘NONRVSM’ if NONRVSM is not the only STS descriptor present in the stored FPL.

The STS/NONRVSM designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






50 STS/FFR Indicator

(2) Requirements

Flights engaged in firefighting shall indicate such by inserting the indicator STS/FFR.

By using this Item 18 sub-field STS/FFR indicator the flight shall automatically be exempted from any relevant flow regulations.


(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by FFR. Where more than one STS descriptor applies to a flight, the descriptors shall be inserted under one STS sub-field and separated by a space.


Those messages containing the Item 18 sub-field STS/FFR that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system where the flight shall be exempted from any relevant flow regulations.

Where more than one sub-field STS entry is found in a message, the content of the multiple entries shall be concatenated by IFPS into a single sub-field with a space in between the original data streams.

It shall be possible for a message originator to remove the STS/FFR indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information, minus:

The STS indicator if FFR is the only STS descriptor or ‘FFR’ if FFR is not the only STS descriptor present in the stored FPL.

The STS/FFR designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






51 STS/FLTCK Indicator

(2) Requirements

The Item 18 sub-field STS/FLTCK shall be used for those flights performing flight check for calibration of navaids where special handling by ATC may be required

Those flights using STS/FLTCK shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by FLTCK. Where more than one STS descriptor applies to a flight, the descriptors shall be inserted under one STS sub-field and separated by a space.


Those messages containing the sub-field STS/FLTCK indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system.

It shall be possible for a message originator to remove the STS/FLTCK indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if FLTCK is the only STS descriptor or ‘FLTCK’ if FLTCK is not the only STS descriptor present in the stored FPL.

The STS/FLTCK designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






52 STS/HAZMAT Indicator

(2) Requirements

The sub-field STS/HAZMAT shall be used for those flights carrying hazardous material. Those flights using STS/HAZMAT shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by HAZMAT. Where more than one STS descriptor applies to a flight, the descriptors shall be inserted under one STS sub-field and separated by a space.


Those messages containing the sub-field STS/HAZMAT indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system.

It shall be possible for a message originator to remove the STS/HAZMAT indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if HAZMAT is the only STS descriptor or

‘HAZMAT’ if HAZMAT is not the only STS descriptor present in the stored FPL.

The STS/HAZMAT designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






53 STS/MARSA Indicator

(2) Requirements

The sub-field STS/MARSA shall be used for those flights for which a military entity assumes responsibility for separation of military aircraft.

Those flights using STS/MARSA shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by MARSA. Where more than one STS descriptor applies to a flight, the descriptors shall be inserted under one STS sub-field and separated by a space.


Those messages containing the sub-field STS/MARSA indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system.

It shall be possible for a message originator to remove the STS/MARSA indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if MARSA is the only STS descriptor or ‘MARSA’ if MARSA is not the only STS descriptor present in the stored FPL.

The STS/MARSA designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






54 STS/MEDEVAC Indicator

(2) Requirements

Flights operating a life critical medical emergency evacuation shall indicate such by inserting the indicator STS/MEDEVAC.

By using this STS/MEDEVAC indicator the flight shall automatically be exempted from any relevant flow regulations.


(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by MEDEVAC. Where more than one STS descriptor applies to a flight, the descriptors shall be inserted under one STS sub-field and separated by a space.


Those messages containing the Item 18 sub-field STS/MEDEVAC that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system where the flight shall be exempted from any relevant flow regulations.

Where more than one sub-field STS entry is found in a message, the content of the multiple entries shall be concatenated by IFPS into a single sub-field with a space in between the original data streams.

It shall be possible for a message originator to remove the STS/FFR indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information, minus:

The STS indicator if MEDEVAC is the only STS descriptor or ‘MEDEVAC’ if MEDEVAC is not the only STS descriptor present in the stored FPL.

The STS/MEDEVAC designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






55 STS/ALTRV Indicator

(2) Requirements

The sub-field STS/ALTRV shall be used for those flights operated in accordance with an altitude reservation.

Those flights using STS/ALTRV shall not automatically qualify for exemption from any relevant flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters STS followed by a ‘/’, followed by ALTRV. Where more than one STS descriptor applies to a flight, the descriptors shall be inserted under one STS sub-field and separated by a space.


Those messages containing the sub-field STS/ALTRV indicator that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system.

It shall be possible for a message originator to remove the STS/ALTRV indicator by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS indicator if ALTRV is the only STS descriptor or ‘ALTRV’ if ALTRV is not the only STS descriptor present in the stored FPL.

The STS/ALTRV designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






56 Runway Visual Range (RVR)

(2) Requirements

All IFR/GAT flights or parts thereof intending to operate within the IFPZ are recommended to include in the flight plan the landing Runway Visual Range (RVR) capabilities of that flight. Landing RVR information may be used for flow management during low visibility conditions (full details are available in the ATFCM Users Manual).

Where low visibility conditions apply within a part or parts of the IFPZ that influence the arrival capacity at one or more aerodromes, the ETFMS may use the RVR value given in the current flight plan to regulate the traffic flow to those aerodromes.

The ETFMS may issue an AIM requesting the confirmation of the RVR by the aircraft operators by means of a Flight Confirmation Message (FCM).

(3) Message Format

The sub-field shall be denoted with the letters RVR followed by a ‘/’, then not more than three digits to indicate the runway visual range in metres for that flight.

Example RVR/250


The IFPS shall check any sub-field RVR, entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed and also because duplicates are not allowed for this sub-field.

On acknowledgement of the message, the RVR information shall be distributed to the relevant ATCUs and to the ETFMS where it may be used for ATFCM measures under low visibility conditions.

It shall be possible for a message originator to remove the RVR details by sending a modification message (CHG).The modification message (CHG) shall contain all the previous Item 18 sub-fields except the RVR sub-field.






57 Originator (ORGN) Indicator

(1) General

A message filer has the possibility to specify the message originator (if for example the filer acts as a relay service for an operator). The originator information may be inserted in item 18 of the message in the sub-field ORGN. When not present in a message submitted to the IFPS, the IFPS uses the SITA or AFTN originator address and inserts it in the messages distributed to ATC centres. As the originator information is always available, recipients of those messages may, if required, contact the message originator directly rather than request messages to be forwarded on their behalf.

(2) Requirements

In case the sub-field is submitted in a message for processing by IFPS, it shall be the 8 letter AFTN address or other appropriate contact details in case the originator of the flight plan may not be readily identified.

The following message types shall have the sub-field ORGN indicator automatically inserted by the IFPS during processing of that message:

FPL (Flight Plan).

FPL (Flight Plan, submitted by ATC for an aircraft in flight with source AFIL).

APL (ATC Plan as a result of an AFP, FNM or MFS). ACH (ATC Flight Plan Change for an aircraft in flight).

(3) Message Format

Whenever the ORGN sub-field is present in Item 18 of a message submitted to the IFPS for processing it shall be denoted by the letters ORGN followed by a ‘/’, then free text to a maximum of 30 characters. Special characters such as ‘!’ or ‘@’ are not allowed.


If received in a message, the IFPS shall retain the value and provide it in the output of those messages listed in Requirements. If not received in a message and upon successful processing of those message types listed in Requirements, the IFPS shall automatically insert the sub-field title ORGN followed by a ‘/’, then the AFTN or SITA address of the message originator

Example

Input to IFPS: originator address EGLLZPZX and Item 18: ORGN/EGLLBAWO

Output from IFPS: ORGN/EGLLBAWO

Input to IFPS: originator address EGLLZPZX and Item 18 contains no ORGN/

Output from IFPS: ORGN/EGLLZPZX

Whenever more than one ORGN indicator is present in a message, that message shall fail automatic processing as duplicates are not permitted for this indicator.






58 Source (SRC) Indicator

(1) General

In order to indicate the source of a message processed by the IFPS, the NM has developed a sub-field titled SRC that shall be inserted automatically by the IFPS into certain message types during processing. The source refers to the original message from which the message distributed by the IFPS was constructed.

(2) Requirements

The following message types shall have the sub-field SRC indicator and the relevant source details automatically inserted into all ADEXP format messages, and certain ICAO format messages, by the IFPS during processing of that message. The source information inserted by the IFPS shall be an indication of the type of message received by the IFPS from which the processed message was constructed.

FPL (Flight Plan). AFIL (Flight Plan, submitted by ATC for an aircraft in flight with source AFIL).

AFP (ATC Flight Plan Proposal). FNM (Flight Notification Message).

MFS (Message From Shanwick). RQP (Request Flight Plan).


Upon successful processing of those message types listed in Requirements, the IFPS shall automatically insert the sub-field title SRC followed by a ‘/’, then the source details of that message as relevant for that message format or type of message.

Only where a FPL, ACH message or APL is distributed in ICAO format, the sub-field title SRC/FNM, SRC/MFS, SRC/AFP and SRC/RQP shall be automatically inserted by the IFPS as appropriate.

Example SRC/FNM

The SRC/ designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






59 IFP Indicators

(1) General


The following message types shall not be rejected by IFPS, but the output resulting from the receipt of these messages shall, where appropriate, have IFP indicators inserted corresponding to the errors raised:

FPL with source AFIL.

FNM & MFS. FPL with STS/FFR, STS/SAR, STS/MEDEVAC or STS/HOSP.

The IFP indicators are intended for information purposes only. ATC Units are not obliged to react to the reception of a flight plan or associated message containing IFP indicators; however certain errors indicated through the use of IFP indicators are operationally more significant than others.

The following IFP indicators have been created by the NM:

IFP indicators Explanation

ERROUTRAD The route does not conform to the RAD rules.

ERROUTWE The route does not conform to the weekend routings.

ERROUTE An error that cannot be corrected has been found in the route.

ERRTYPE An error that cannot be corrected has been found in the aircraft type.

ERRLEVEL An error that cannot be corrected has been found in the requested flight level.

ERREOBT An earlier EOBT exists.

NON833 Flight does not comply with 8.33 kHz requirements.

833UNKNOWN Flight compliance with 8.33 kHz requirements is unknown.

NONRVSM Flight is not RVSM approved.

RVSMUNKNOWN RVSM approval status of this flight is unknown.

RVSMVIOLATION Violates RVSM rules, originator of the flight plan cannot be contacted.

MODESASP Flight compliance with mode S Surveillance.

ERREQPT An error in the aircraft equipment has been corrected by adding or deleting data in the message.

ERRRTECOORD The filed route has been coordinated with ATC and either it was coordinated by NMOC or NMOC holds a written confirmation of the coordination.

IFPSROUTEMOD The trajectory, between the first and last en-route point, has been manually modified (laterally or vertically) by an IFPS staff.

Note MODESASP is another indicator that is a part of a fully automated process within the IFPS, and the IFPS staff have no influence over its use.



The IFPS shall automatically insert the IFP indicators relating to errors ignored for RVSM and 8.33 kHz.

Once applied to a message, IFP indicators cannot be removed. Should a message originator wish to file another route in order to correct those routing errors identified by IFP indicators, for example for STS/FFR, STS/SAR, STS/MEDEVAC or STS/HOSP, that originator must cancel the existing flight plan and submit a replacement flight plan.

(2) Requirements

Those messages relating to flights departing, arriving or overflying the IFPZ that fail automatic processing may be passed for manual treatment by the IFPS staff in accordance with SCP1.

Where an error is ignored by the IFPS staff, that error shall be indicated by the insertion of the appropriate IFP Indicator.

As many IFP indicators as appropriate shall be used.

IFP indicators shall be added either manually or automatically by the IFPS in the output of flight plans and modification messages (CHG) distributed to ATC and in ACK messages.

These IFP indicators shall not be present in messages submitted to the IFPS.

(3) Message Format

The indicator shall be denoted in the message with the letters IFP followed by a ‘/’, then the text as appropriate for the error.


The following IFP indicators may be inserted manually by the IFPS staff:

ERROUTRAD

ERROUTWE ERRROUTE ERRTYPE

ERRLEVEL

ERREOBT ERREQPT ERRRTECOORD IFPSROUTEMOD

The following IFP indicators shall be inserted automatically by the IFPS whenever the indicated errors or conditions have been ignored in order to force a message into the IFPS.

Note IFP/ERROUTRAD may also be inserted either automatically or manually by the IFPS staff as necessary.

NON833

Whenever the flight is not 8.33 kHz compliant and where the following errors have been ignored during manual processing by an IFPS staff:

PROF188: FLIGHT PLAN DOES NOT COMPLY WITH 8.33 CARRIAGE REQUIREMENTS

PROF190: NON 8.33 AND NON UHF EQUIPPED AIRCRAFT IN 8.33 AIRSPACE



833UNKNOWN

Whenever the source of a flight plan is an APL or AFIL and the flight plan does not contain COM/EXM833 or the equipment of those message types does not contain Y.

RVSMVIOLATION

Shall be automatically inserted where the following error messages have been ignored during manual processing by an IFPS staff:

EFPM212: FIELDS 10 AND/OR 18 INCORRECT FOR STATE FORMATION FLIGHT IN

EUR RVSM AIRSPACE

EFPM231: CIVIL FORMATION FLIGHT NOT PERMITTED IN EUR RVSM AIRSPACE

EFPM209: STS/NONRVSM IS NOT EXPECTED FOR AN RVSM APPROVED FLIGHT

WITHIN EUR RVSM AIRSPACE

NONRVSM

Shall be automatically inserted where the following error messages have been ignored during manual processing by an IFPS staff:

EFPM219: NON RVSM APPROVED FLIGHT WITHIN EUR RVSM AIRSPACE

EFPM210: NON RVSM APPROVED FLIGHT WITHIN EUR RVSM AIRSPACE AND

STS/NONRVSM IS NOT EXPECTED FOR A CIVIL AIRCRAFT

EFPM211: STS/NONRVSM IS REQUIRED FOR NON RVSM APPROVED STATE FLIGHT

ERROUTRAD

Shall be automatically inserted where a RAD restriction has been set to SOFT, and may be added manually by the IFPS staff where a RAD violation in a submitted message cannot be corrected.

Where more than one IFP Indicator has been inserted, the IFPS shall merge them into a single IFP field, containing one space between each item.

Example During IFPS processing, the IFP Indicators ERROUTRAD and NONRVSM have been inserted by the IFPS, but the IFPS shall output after processing: IFP/ERROUTRAD NONRVSM.

Whenever an IFP indicator is found in a message submitted to the IFPS, the IFPS shall ignore it and the indicator shall be removed from any message output.

Once applied to a message, IFP indicators cannot be removed. Should a message originator wish to file another route in order to correct those routing errors identified by IFP indicators, they must cancel the existing flight plan and submit a replacement flight plan.


The IFPS shall automatically insert the IFP indicators relating to errors ignored for RVSM and 8.33 kHz.

For those IFP indicators that are not inserted automatically by the IFPS, the IFPS staff shall insert as many IFP indicators as deemed necessary for that message.






60 IFPS Test System (IFPUV)

(1) General

An IFPS validation system (IFPUV) has been made available to enable message originators, who so wish, to submit their flight plan to a dedicated test platform for flight plan validation against the IFPS validation criteria, prior to their submission to the operational IFPS.

The IFPUV offers also the possibility to validate flight plans against ETFMS data in order to assess whether the flight plan will be subject to an ATFM regulation, and if so, the delay that is likely to be allocated to that flight in the event of a submission to the operational IFPS.

Upon successful validation, message originators with access to NOP Protected have the possibility to submit flight plan messages from IFPUV to the operational IFPS.

The aim of this system is to provide the means with which message originators may improve the automatic processing rate of flight plans submitted to the operational IFPS and the means to assess the ATFM situation of flight plans that will be submitted to the operational IFPS. It should be noted that the IFPUV only indicates compliance with the IFPS processing requirements; it does not indicate ICAO compliance.

Message originators wishing to test flight plans through the IFPUV prior to their submission to the IFPS shall submit those flight plans using one of the following options (some options offer additional features, see below):

To the AFTN address EUCHZMFV

To the SITA address BRUEY7X

Via the B2B web service

Via the NOP Portal (Public and Protected application)

Via the CHMI IFPUV Application

The test flight plans may be submitted with a Date Of Flight (DOF) up to 120 hours (5 days) in advance of EOBT by inserting the DOF/<YYMMDD> where YY indicates the year MM indicates the month and DD indicates the day in that flight plan.

The access to IFPUV via the NOP Protected application offers the following additional features:

Flight plan Submission

Generation of IFPS compliant routes with user preference options (via/avoid point/airspaces, freeze portion, etc.)

Avoid (ATFM) measure option Route Last Validity OBT (Off-Block Time) displayed Query of ETFMS for expected slot

Early access to AIRAC data (from 14 days prior the AIRAC)

Access to AIRAC data for pre-validation exercises (Example: major airspace changes, Free Route Implementation)

There are several access to IFPUV via the NOP Protected with differences in the features that are offered. This is summarized below:



Features 1 2 3 4

FPL Validation (“Validate”)

FPL Submission (“Submit”)

Generation of IFPS compliant routes with user preference options (“Propose Routes”)

Avoid (ATFM) measures option (“Avoid Measure”)

Route Last Validity Off-Block-time displayed for route Proposals (“LV” “Last Validity OBT”)

Query of ETFMS for expected slot (“Validate & Try / Generate & Evaluate”)

Early Access to AIRAC data (from 14 days prior the AIRAC)

Access to AIRAC data for pre-validation exercise

The access to IFPUV via the CHMI IFPUV application offers the following additional features:

Generation of IFPS compliant routes with user preference options (via/avoid point/airspaces, freeze portion, etc.)

Avoid (ATFM) measure option

Route Last Validity OBT (Off-Block Time) displayed Query of ETFMS for expected slot

Early access to AIRAC data (from 14 days prior the AIRAC). This requires a separate login to CHMI ENVPREVAL (Next AIRAC).

Access to AIRAC data for pre-validation exercises (Example: major airspace changes, Free Route Implementation). This requires a separate login to CHMI ENVPREVAL (ADHOC AIRAC).

It should be noted that the IFPUV facility shall undergo normal NM system maintenance and for that reason may not be available for a short period of time. Such periods of outage shall normally be a maximum of 1 hour during Tuesday / Wednesday night, once per month.

Note Message originators wishing to test flight plans shall not submit those test messages to the operational IFPS.



(2) Requirements

The IFPUV is a fully automated system and shall normally be used by external message originators independently.


The IFPUV contains the current IFPS software and receives the updates from the operational CACD fed by live updates in the same way as the operational IFPS, and is therefore an accurate reflection of the operational IFPS.

However:

Early access to AIRAC data (NOP Protected NEXT AIRAC and CHMI ENVPREVAL): the data accessed is provisional and might still be subject to modifications. The system is set to the first day of the AIRAC (i.e. Thursday), therefore DOF in the flight plan is not required unless the validation is for a “week-end routing” in which case the DOF for the corresponding day shall be stated.

Access to AIRAC data for pre-validation exercise (NOP Protected ADHOC AIRAC and CHMI PREVAL): the data accessed is provisional and might still be subject to modifications. The system is set to the first day of the AIRAC (i.e. Thursday), therefore DOF in the flight plan is not required.

The IFPUV system undertakes the same checking mechanisms as the IFPS in the following order:

Syntax. Semantics.

Route analysis.

Then the system builds a profile and continues with the following checks:

Profile analysis: RAD restrictions, 8.33 kHz, RVSM compliance, etc.

It is important that a flight plan submitted to the IFPUV is syntactically and semantically correct as the IFPUV shall fail any flight plan on those errors it finds in the order described.

Messages which have undergone IFPUV validation are neither distributed by nor stored in the IFPUV. Since flight plans are not stored in the IFPUV, flight plan associated messages (CHG, DLA, CNL, RQP, etc.) shall be rejected by the IFPUV with the message:

EFPM: NO EXISTING FILED FLIGHT PLAN MATCHES THIS MESSAGE (when submitted through AFTN, SITA or CHMI) or the following message shall be displayed:

Validation is only possible for FPL/IFPL messages.

Flight plan validation reply via the AFTN or SITA

The system will respond to flight plan submissions by means of a reply message in the form of either an ACK which indicates that the flight plan should pass automatic processing, or a REJ (rejection) which indicates that the flight plan would fail automatic processing in the IFPS. In the case of REJ the reply message shall contain a system generated indication of the reason for failure.

The IFPUV shall not generate MAN (Manual) messages.

Every reply message from the IFPUV contains the phrase:

’THIS MESSAGE HAS BEEN SENT BY A TEST SYSTEM AND MUST NOT BE USED OPERATIONALLY’.

This message is added to ensure that there is no confusion between submissions to the IFPUV and those to the operational IFPS.



Flight Plan validation reply via NOP (Internet)

The system shall respond to the validation to the IFPUV by means of a reply message that shall appear at the bottom of the web page. The reply consists of a copy of the ICAO format message as it has been submitted, followed by the list of errors. In case the flight plan is valid, the text: ’NO ERRORS’ shall be displayed.

Note It should be noted that occasionally a flight plan may fail the processing due to an error which is not inherent in the received message but which may be due to environment inconsistencies or even a processing error. If in doubt concerning a specific error, the IFPS supervisor should be contacted.

Flight Plan submission reply via NOP (Internet)

The system shall respond to the submission to the IFPS through the IFPUV by means of a reply message that shall appear at the bottom of the web page in the Submit Results window. The reply consists of:

The text “Submission status VALID NO ERRORS” followed by “Comment” and an ACK message when the submission is successful or

The text “Submission status REJECTED”, or The text “Submission status QUEUED FOR CORRECTION”.

Message originators shall receive ORMs the same way as if the message had been filed via AFTN or SITA (i.e an ACK or a REJ or a MAN, with MAN later on followed by an ACK or a REJ).

If no ORMs are received (see Note), it remains the message originator’s responsibility to check the message status. This can be achieved by consulting the flight’s operational log in the Filing tab in the NOP Flight List.

Note This is the case if, for a message originator, “ACK, MAN, REJ required” are set to NO in NM CACD.

60.1 General Procedures for IFPUV users

Should difficulties while accessing the IFPUV be experienced, your contact will depend on how the IFPUV was accessed:

AFTN/SITA/B2B web service, NOP Public, NOP Protected (access via 1 and 2, see above), then the IFPS staff should be contacted by phone at +32 (0)2 745 19 50 (FP1) or +33 (0)1 69 88 17 50 (FP2). In order to avoid confusion, it should be clearly indicated that the call refers to the IFPUV. It should also be stated whether the message was filed via a secure connection (with an NM token) or not, as the secure and non-secure IFPUV applications are maintained on separate servers, and are thus accessed by the IFPS staff differently.

Note Message originators validating messages with the IFPUV via AFTN or SITA or NOP Protected are directed to the secure server.

NOP Protected (access via 3, see above) and CHMI ENVPREVAL Next AIRAC: early access to AIRAC data (from day -14). Should anomalies or questions be experienced when accessing NEXT AIRAC data, then the IFPS Supervisor should be contacted via email at [email protected]. The email subject shall be AIRAC Validation followed by the AIRAC number (i.e. 1903) followed by TEST and the email body should contain the FPL(s) concerned, the corresponding error(s) and a textual description of the issue. The email shall be treated by FP2 supervisors who shall take the appropriate action(s), including acknowledging reception of the email.




NOP Protected (access via 4, see above) and CHMI ENVPREVAL ADHOC AIRAC: ADHOC AIRAC (pre-validation exercise). Should anomalies or questions be experienced when accessing ADHOC AIRAC data, then NM CACD shall be contacted via email at [email protected]. The email subject shall state the name of the Preval and the email body should contain the FPL(s) concerned, the corresponding error(s) and a textual description of the issue. Please note that such pre-validation exercise will be announced via the NOP Headline news.







61 Aircraft Operator What-if Re-Route (AOWIR)

(1) General

The Aircraft Operator What-If Re-route (AOWIR) function shall allow an Aircraft Operator to request a modification to a filed flight plan routing within the NM system using the NOP or external CHMI.

The procedures described in the following sections shall only relate to the flight planning aspects; any ETFMS actions are detailed in the ATFCM Users Manual.

(2) Requirements

The user of the AOWIR function shall be able to make a series of consultations in order to assess different scenarios. Although it is possible to make unlimited consultations for a suitable re-routing it

shall only be possible to apply three re-routes per flight maximum.

Whenever a suitable re-route has been chosen, the user shall use one of three possible flight plan re-filing options:

OPTION 1a: Shall be used for a flight plan modification (CHG)

OPTION 1b: Shall be used for a cancellation of the existing flight plan and the generation of a new flight plan.

OPTION 2: Shall be used whenever the NM shall simultaneously initiate a flight plan cancellation (CNL) and a slot booking, where the user shall re-file the flight plan via AFTN or SITA.

(3) Message Format

For the format, see the relevant pages of the ATFCM Users Manual.


61.1 OPTION 1a: The flight plan is changed

The IFPS proceeds as if a modification message (CHG) had been submitted by the user. As a consequence the following actions shall be initiated by the NM:

The original flight plan shall be updated and all IFPS messages indicating this change (FPL, CHG) shall be flagged with ’AWR/Rn‘ and shall be distributed to the appropriate ATC addresses.

A (long) ACK message (see § ORM), with ’—MSGTYP IFPL’, shall be sent to the address associated to the NM terminal having made the re-routeing acceptance and to the originator of the initial flight plan, if identifiable, and to the originator of the latest flight plan message received prior to the AOWIR, if any. The ACK shall contain all the flight plan details of the re-routed flight as accepted by the NM and ’AWR/Rn’ shall also be automatically inserted into the message.

In addition, the ACK shall contain a message:

—COMMENT FLIGHT PLAN CHANGED AS A RESULT OF AOWIR

In order to be consistent with the existing ICAO Replacement Flight Plan procedure, the IFPS shall additionally insert or increment an ’RFP/Q’ indicator in the FPL in accordance with the following rules:

If no ’RFP/Q’ indicator is given in the FPL which is being treated for re-routeing, the IFPS shall insert both the ’RFP/Q1’ and ’AWR/R1’ in the message.



If an ’RFP/Q’ indicator is given in the FPL which is being treated for re-routeing, the IFPS shall increment the ’RFP/Q’ indicator and shall insert ’AWR/R1’ in the message.

e.g. received FPL gives RFP/Q3

output FPL will give RFP/Q4 + AWR/R1

61.2 OPTION 1b: The system cancels the flight plan and a new flight plan is generated

In certain circumstances there could be a mismatch between the last known EOBT stored in IFPS and the latest known EOBT stored in ETFMS. If such a case occurs then the IFPS shall NOT proceed as if a modification message (CHG) had been submitted by the user but shall:

Distribute an FPL Cancellation (CNL) to the appropriate ATC addresses.

Sent a (short) ACK message, with ’—MSGTYP ICNL’ including the flag ’AWR/Rn’ to the address associated to the NM terminal having made the re-routeing acceptance and to the originator of the initial Flight Plan if identifiable and to the originator of the latest Flight Plan message received prior to the AOWIR, if any.


— COMMENT FLIGHT PLAN CANCELLED AS A RESULT OF AOWIR

A Slot Cancellation (SLC) message is distributed in accordance with the existing addressing rules for this message.

The message shall include the comments:

—COMMENT FLIGHT REROUTED BY AO FPL CANCELLED and

—REASON RRTE

Wait for an appropriate period (to allow adequate time for the transmission of the cancellation message).

Sent a new FPL to the appropriate ATC addresses using the latest known EOBT from ETFMS and insert ’AWR/Rn’ in the message.

Sent a (long) ACK message with ’—MSGTYP IFPL’ to the address associated to the NM terminal having made the rerouteing acceptance.

The ACK contains all the flight plan details of the re-routed flight as accepted by the NM and sub-fields ’RFP/Qn’ and ‘AWR/Rn’ shall also be inserted therein.

In order to be consistent with the existing ICAO Replacement Flight Plan procedure, the IFPS shall additionally insert or increment an ’RFP/Q’ indicator in the FPL.

Appropriate ATFM messages (SAM, FLS) shall be sending according to the existing rules for these messages.

61.3 OPTION 2: The flight plan is cancelled and a new slot is booked

The IFPS proceeds as if a flight plan cancellation (CNL) message had been submitted by the user, i.e.:



A flight plan cancellation (CNL) message shall be distributed to the appropriate ATC addresses.

As a consequence of the flight plan cancellation (CNL) an ACK message with ’—MSGTYP ICNL’, including the flag ’AWR/Rn’, shall be sent to the address associated to the NM terminal having made the rerouteing acceptance and to the originator of the initial flight plan message, if identifiable and to the originator of the latest flight plan message received prior to the AOWIR, if any.


—COMMENT FLIGHT PLAN CANCELLED AS A RESULT OF AOWIR

A slot cancellation (SLC) message shall be distributed in accordance with the existing addressing rules for this message.

The message shall include the comments:

—COMMENT FLIGHT REROUTED BY AO FPL CANCELLED and

—REASON RRTE

A rerouteing notification (RRN) message shall be generated by the ETFMS to the address associated to the NM terminal having made the re-routeing acceptance and to the same addresses as for re-routeing proposal (RRP)/slot improvement proposal (SIP) messages. This message shall include the new route description and the new slot calculation result e.g.:

—NEWCTOT 1130 or

—REASON OUTREG when the new route is not submitted to ATFCM regulation.

Aircraft Operator/Air Traffic Services response Requirements

After the reception of an ACK for the CNL message, the user shall file a new flight plan to the IFPS Units in accordance with the normal rules and where appropriate to all relevant units outside the IFPS distribution area. The flight plan shall include the flags ’RFP/Qn’ and ’AWR/Rn’ in the message.

Note The route in the new flight plan shall be fully consistent with the one provided within the RRN message.

The booked slot shall be used only if the profile of the flight plan matches with the profile of the booked flight representing the accepted rerouteing.

The matching is using the following rules:

Only the aerodromes and en-route points of the point profile are used in the matching process; those points in the departure or arrival procedure shall be ignored.

There can be more points in the route of the replacement flight plan than in new route description of the provisional flight plan reserved in the ETFMS. All additional points found in the flight plan are ignored.

The sequence of the en-route points must be identical. The levels and the timing on the points must be similar (a very small tolerance is accepted). The criteria indicated above are intended to give a reasonable flexibility (i.e. additional points

for level/speed, SID/STAR free choice) without being too permissive.

Processing of the New Flight plan by the Network Manager

When the new flight plan is received and has been processed successfully by the IFPS then:



An ACK message shall be sent to the address(es) associated to the originator of the flight plan. The ACK shall give the complete flight plan concerning the re-routed flight and shall include the flags ’RFP/Qn’ and ’AWR/Rn’, as provided by the aircraft operator, in the message.

The flight plan (including the flags ’RFP/Qn’ and ’AWR/Rn’ as provided by the aircraft operator) shall be distributed to the appropriate ATS Units.

In the exceptional case that the new flight plan fails automatic processing in the IFPS, the user upon receipt of the Manual (MAN) message shall call IFPS.

In the case of a flight plan being rejected by the IFPS a Rejection (REJ) message shall be sent back to the originator in accordance with to normal rules. The user must resubmit a correct flight plan.



62 Diversion Arrival Messages

(2) Requirements

The IFPS shall not accept messages with title ‘DIVARR’. Where a flight shall divert to an aerodrome other than the filed destination, an Arrival (ARR) message in the format described in [see SECTION

ARRIVAL (ARR)] shall be submitted to the IFPS for processing.






63 ITEM 3: Message Title

(2) Requirements

All messages submitted to the IFPS for processing shall contain Item 3: Message title information.

The message titles recognised by the IFPS in submitted messages shall be:

FPL, CHG, DLA, CNL, DEP, ARR, RQP, RQS, AFP, FNM, MFS and AMOD.

ACH and APL messages submitted to the IFPS shall be rejected.

(3) Message Format

It is required that those flight data messages submitted to the IFPS for processing shall have one of the recognised message titles. The title shall immediately follow the opening bracket of the message.


The IFPS shall check the message title in all messages submitted to the IFPS for processing for compliance with the recognised message titles. Where a message title is not identified, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Where a message submitted to the IFPS for processing contains a recognised message title, the IFPS shall process that message according to the requirements of that recognised message type.






64 ITEM 7: Aircraft Identification and SSR Mode/SSR Code

(2) Requirements

All messages submitted to the IFPS for processing shall contain the aircraft identification information to indicate the radio call sign of that flight.

The aircraft identification shall contain either the aircraft registration markings or the ICAO telephony designator of the aircraft operating agency followed by the flight identification.

It shall be possible for the message originator to include the SSR mode after the aircraft identification by inserting the A and the SSR code of that flight, where it is known.

Note The IFPS shall only automatically accept an SSR code when it is prefixed by the letter A.

(3) Message Format

The aircraft identification in a message submitted to the IFPS for processing shall contain a minimum of 2 and a maximum of 7 alphanumeric characters without hyphens or symbols. The SSR mode and code may be included for those aircrafts that wish to do so, it shall consist of the letter A and it shall be followed four numerics between the values of 0 and 7 and shall be separated from the aircraft identification by a slash ‘/’.

The maximum number of characters accepted by the IFPS in the aircraft identification and SSR mode and code, including the ‘/’ shall be 13.

Examples ABC567C

ABC567C/A3356


The IFPS shall check aircraft identification in all messages submitted to the IFPS for processing for compliance with the required format. Where the required format is not complied with, those messages shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Where SSR mode and code is included in a message submitted to the IFPS for processing, the IFPS shall check for compliance with the required format. Where the Item does not comply with the required format, those messages shall fail automatic processing and be passed for manual treatment by the IFPS staff.






65 ITEM 8: Flight Rules and Type of Flight

(1) General

The IFPS shall only process those flight plans and associated messages that contain the flight rules & type of flight information as relevant for an IFR/GAT flight or part thereof intending operating within the IFPZ.

(2) Requirements

Flight Rules

The following indications of flight rules may be used when submitting a flight plan or associated message to the IFPS for processing:

I for those flights that are to be conducted entirely under IFR conditions.

V for those flights that are to be conducted entirely under VFR conditions.

Y for those flights that shall commence under IFR conditions and shall change to VFR conditions.

Z for those flights that shall commence under VFR conditions and shall change to IFR conditions.

Of these possible flight rule indicators, the IFPS shall only process those messages that relate to flights conducted fully or partially under IFR conditions within the IFPZ.

Type of Flight

The following types of flight may be used when submitting a flight plan or associated message to the IFPS for processing:

S if the flight is a scheduled air transport flight.

N if the flight is a non-scheduled air transport flight.

G if the flight is a general aviation flight.

M if the flight is a military flight.

X for all other type of flights.

(3) Message Format

The flight plan or associated message shall contain one of the flight rules indicators followed by one of the type of flight indicators.

Examples VG represents a VFR general aviation flight.

IS represents an IFR scheduled flight.




Only those flight plans and associated messages that indicate in flight rules that the flight shall be conducted wholly or partially under IFR conditions within the IFPZ shall be processed by the IFPS. Those flight plans that indicate an intention to operate under VFR conditions only within the IFPZ shall fail automatic processing by the IFPS and shall be rejected.

Where a flight plan or associated message submitted to the IFPS for processing contains the flight rules I, Z or Y, the IFPS shall crosscheck that information against the route data.

Should a change of flight rules be given that is not supported by an identifiable indication of that change in the route of that message, then that message shall fail automatic processing and shall be presented for manual processing by the IFPS staff.

The IFPS shall crosscheck the type of flight information against the restriction modules used in the CACD for those flights entering RAD restrictions and or routes for military flights only. Where the type of flight is not allowed for that route, that message shall fail automatic processing and be passed to the IFPS staff for manual treatment.

Note The IFPS shall react differently in message association whenever the type of flight is given as X.



66 ITEM 9: Number and Type of Aircraft and Wake Turbulence Category

(1) General

When processing flight plans and associated messages, the IFPS shall take into account the performance of identifiable individual aircraft types.

In order to calculate more accurate flight profiles, the NM has built a table of aircraft performance figures, with all recognised ICAO aircraft type designators having a specific series of performance data (Ref ICAO DOC 8643 – Aircraft Type Designators).

(2) Requirements

Where required, the number of aircraft shall be indicated. The number of aircraft may be included if that flight consists of only one aircraft, but it shall be included if more than one aircraft is involved in that flight.

The flight plan or associated message submitted to the IFPS for processing shall indicate the ICAO aircraft type designator where it is known.

Where the aircraft type does not have an approved ICAO designator, that aircraft type shall be filed as ZZZZ, with the details of that aircraft type given in the sub-field TYP.

The message shall indicate the wake turbulence category of that aircraft type. The IFPS shall accept only the following 4 wake turbulence categories:

L (light), M (medium), H (heavy) or J (super).

L Shall be inserted for an aircraft with a maximum certified take off mass of 7000 kg or less.

M Shall be inserted for an aircraft with a maximum certified take off mass of less than 136000 kg but more than 7000 kg.

H Shall be inserted for an aircraft with a maximum certified take off mass of less than 560000kg but more than 136000 kg.

J Shall be inserted for an aircraft with a maximum certified take off mass of 560000kg or more.

(3) Message Format

The number of aircraft may be included if that flight consists of only one aircraft, but it shall be included if more than one aircraft is involved in that flight. The number of aircraft indicated shall be given as not more than two numeric.

The type of aircraft shall be given as the ICAO designator for that type, or where the type is not known or not an ICAO designator, ZZZZ shall be inserted. Where ZZZZ is used, the details of the aircraft type shall be given in the sub-field TYP.

The aircraft type shall be followed by a ‘/’ then the letter L, M, H or J to indicate the wake turbulence category of the aircraft type indicated.




The IFPS shall check any aircraft type given in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format and pass those messages for manual processing by the IFPS staff where the required format is not followed.

The IFPS shall check all filed aircraft types for compliance with the known ICAO aircraft type designators. Where an unknown designator is found, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Where the aircraft type is filed as ZZZZ, the IFPS shall check the sub-field TYP for the details of that aircraft type.

Example One unknown type of aircraft

Item 9: ZZZZ/M Item 18: TYP/D9FF

Where the aircraft type is filed as ZZZZ, the IFPS shall allocate for that flight one of the four generic aircraft performance.

These generic aircraft performances are:

SEEE (SINGLE ENGINE) MEEE (MULTI-ENGINE)

TPPP (TURBO-PROP) TJJJ (TURBO-JET)

The allocation is based on the speed and RFL specified in the route field.

If more than one aircraft type intends to fly in formation, the total number of aircraft shall be given. The aircraft type shall be given as ZZZZ in Items 9 and 18, the (numbers and) type(s) of aircraft preceded by TYP/.

Example1 Two aircraft types

Item 9: 2ZZZZ/M Item18: TYP/1AN26 1LJ39 or TYP/AN26 LJ39

Example 2 Three aircraft types

Item 9: 3ZZZZ/M Item18: TYP/2AN26 1LJ39 or TYP/2AN26 LF39

In the two examples above, the output of the IFPS shall be the same as the input.

Where no WTC is given by the originator of the message and the aircraft type is known in the NM database, the IFPS shall automatically insert the wake turbulence category of that aircraft type. If the aircraft type is unknown and no wake turbulence category is given by the originator of the message, the IFPS shall automatically insert an internal value for profile calculation but shall not output this internal value.

The IFPS shall not accept a known aircraft type in the flight plan in combination with the sub-field TYP.

Where ZZZZ is used in the flight plan, and a sub-field TYP entry has been made that indicates a known ICAO aircraft type designator, the IFPS shall automatically update the aircraft type to that known aircraft type and remove the sub-field TYP.

When calculating the profile of a flight, the IFPS shall apply performance data specific to each aircraft type given.

The IFPS shall confirm the wake turbulence category given with the aircraft type to the ICAO wake turbulence category assigned to that aircraft type.

The following table shall show the processing of the wake turbulence category by the IFPS:



No wake turbulence category in flight plan

Valid wake turbulence category in flight plan

Unknown wake turbulence category in flight plan

Valid wake turbulence category in IFPS Database for this type of aircraft

Automatic inclusion of the Wake Turbulence Category as held in the IFPS

Wake Turbulence Category from IFPS Database inserted

Wake Turbulence Category from IFPS Database inserted

No wake turbulence category in IFPS database for this type of aircraft

Wake Turbulence category shall be empty

Wake Turbulence Category as filed shall be maintained in the output

Wake Turbulence Category shall be removed from flight plan

Aircraft type is ZZZZ Wake Turbulence category shall be empty

Wake Turbulence Category as filed shall be maintained in the output

Flight plan not accepted Flight plan shall come up for manual treatment by IFPS Staff

Note Where an aircraft type is filed as ZZZZ, that message shall always fail automatic processing in order that the IFPS staff may apply an appropriate aircraft performance to that flight.

The aircraft type or the aircraft type classification (single engine, multi-engine, turbo-prop, turbo-jet) can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






67 ITEM 10: Equipment & Capabilities

(1) General

The IFPS is only required to check certain equipment, regardless of other requirements specified in the relevant national AIPs. The checks carried out by the IFPS are for compliance with UHF, 8.33 kHz, RVSM, Datalink, and where Other Equipment (Z or R in Equipment) is specified in the flight plan message, that the corresponding details are given in Item 18 of the flight plan.

The term ‘capabilities’ comprises the following elements:

Presence of relevant serviceable equipment on board the aircraft;

Equipment and capabilities commensurate with flight crew qualifications, and Where applicable, authorization from the appropriate authority.

(2) Requirements

The flight plan shall indicate the equipment/capabilities regarding radio communication, navigation and approach aid, carried by that aircraft.

The flight plan shall also indicate the equipment/capabilities regarding surveillance, carried by that aircraft.

The equipment/capabilities of the aircraft shall require certain conditions to be applied to that flight.

Where the aircraft type specified in an existing flight plan processed by the IFPS has to be changed by the aircraft operator, the equipment of the replacement aircraft shall, where different from that of the original aircraft, be specified in the modification message (CHG).

(3) Message Format

The flight plan shall indicate the equipment/capabilities regarding radio communication, navigation & approach aid by inserting the appropriate designator letter or letter/number combination (with a maximum of 64 characters and without repetition) for the relevant equipment, followed by a ‘/’. The flight plan shall also indicate the equipment/capabilities regarding surveillance by inserting the appropriate designator(s), (with a maximum of 20 characters and without repetition) used to indicate such.

Only those messages that contain the following approved designators shall be accepted by the IFPS.

Item 10a: Radio Communication, Navigation and Approach Aid Equipment

There are three options available to indicate the status of the radio communication, navigation and approach aid equipment:

The letter N to indicate that no radio communication, navigation or approach aid equipment for the route to be flown is carried or the equipment is unserviceable or

The letter S to indicate that the standard radio communication, navigation and approach aid equipment for the route to be flown is carried and serviceable. If the letter S is used, standard equipment is considered to be VHF RTF, VOR and ILS unless another combination is prescribed by the appropriate ATS Authority or

One or more of the following letters (S can be present) to indicate the serviceable radio communication, navigation and approach aid equipment and capabilities available:

A GBAS landing system

B LPV (APV with SBAS)



C LORAN C

D DME

E1 FMC WPR ACARS

E2 D-FIS ACARS

E3 PDC ACARS

F ADF

G GNSS. If the letter G issued, the types of GNSS external augmentation, if any may be specified in Item 18 following the indicator NAV/ and separated by a space.

H HF RTF

I Inertial Navigation

J1 CPDLC ATN VDL Mode 2

J2 CPDLC FANS 1/A HFDL

J3 CPDLC FANS 1/A Mode 4

J4 CPDLC FANS 1/A Mode 2

J5 CPDLC FANS 1/A SATCOM (INMARSAT)

J6 CPDLC FANS 1/A SATCOM (MTSAT)

J7 CPDLC FANS 1/A SATCOM (Iridium)

K MLS

L ILS

M1 ATC SATVOICE (INMARSAT)

M2 ATC SATVOICE (MTSAT)

M3 ATC SATVOICE (Iridium)

O VOR

P1 CPDLC RCP 400 (see Note)

P2 CPDLC RCP 240 (see Note)

P2 SATVOICE RCP 400 (see Note)

P4-P9 Reserved for RCP

Q (Not allocated)

R PBN approved. If the letter R is used, the performance based navigation levels that can be met shall be specified in Item 18 under PBN/.

T TACAN

U UHF RTF

V VHF RTF

W RVSM approved

X MNPS approved

Y VHF with 8.33 kHz channel spacing capability

Z Other equipment carried (whenever Z is being used in the equipment indicator of that flight plan, a specification shall be made by inserting the sub-field COM/ and/or NAV/ and/or DAT/ of the flight plan to indicate the type of COM/ and/or NAV/ and/or DAT/ used for this flight).



Note P1, P2, P3: Guidance material on the application of performance-based communication, which prescribes RCP to an air traffic service in a specific area, is contained in the Performance Based Communication and Surveillance (PBCS) Manual (Doc 9869).

Area Navigation (RNAV) Specifications

Operators of aircraft approved for basic area navigation (B-RNAV / RNAV5) operations shall insert the designator ’R’ in Item 10a of the flight plan and PBN/ in Item 18 followed by the appropriate capability of that flight. The PBN descriptors for B-RNAV are: B1, B2, B3, B4, B5.

Operators of aircraft approved for precision area navigation (P-RNAV / RNAV1) operations shall, in addition to the designator ’R’ in Item 10a , also insert PBN/ in Item 18 followed by the appropriate capability of that flight. The PBN descriptors for P-RNAV are: D1, D2, D3, D4, depending upon the sensors used, as appropriate. Unlike RNAV1 it is also possible to achieve P-RNAV capability using only VOR/DME in which case ‘Z’ should be inserted in item 10a and NAV/EURPRNAV in item 18.

Operators of State aircraft not approved for B-RNAV or P-RNAV operations shall not insert any of the designators B1, B2, B3, B4, B5, D1, D2, D3, D4 within the PBN/ indicator of Item 18 of the flight plan. Instead, the letter ‘Z’ shall be inserted in Item 10a and NAV/RNAVX shall be inserted in Item 18 of the flight plan.

Where a failure or degradation results in the aircraft being unable to meet the B-RNAV functionality and accuracy requirements before departure, the operator of the aircraft shall not insert any of the designators B1, B2, B3, B4, B5 within the PBN/ indicator of Item 18 of the flight plan. Since such flights require special handling by ATC, the letter ‘Z’ shall be inserted in Item 10a and Item 18 shall contain NAV/RNAVINOP.

Item 10b: Surveillance Equipment

A minimum of one and a maximum of 20 characters shall be used to indicate the serviceable surveillance equipment in the equipment field of that flight plan.

To indicate the surveillance equipment, insert:

N If no surveillance equipment for the route to be flown is carried, or the equipment is unserviceable.

Or, one or more of the following descriptors:

I Transponder-Mode S, including aircraft identification transmission, but no pressure-altitude capability.

P Transponder-Mode S, including pressure altitude, but no aircraft identification capability.

X Transponder-Mode S, with neither aircraft identification nor pressure altitude capability.

A Transponder-Mode A (4digits-4096 codes)

C Transponder-Mode A (4digits-4096 codes) and Mode C

Note I, P, X are mutually exclusive, i.e. only one of the 3 indicators may be present.

Or one or more of the descriptors:

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.

L Transponder-Mode S, including aircraft identification, pressure-altitude, extended squitter (ADS-B) and enhanced surveillance capability.

S Transponder-Mode S, including both pressure-altitude and aircraft identification capability.



Plus optionally one or more of the descriptors (ADS-B and ADS-C descriptors are optional and cannot be present without any transponder descriptor(s)):

B1 ADS-B with dedicated 1090 MHz ADS-B ‘out’ capability

B2 ADS-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


The IFPS shall check any equipment indicators entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed.

All messages submitted to the IFPS that require a profile calculation to be made shall have the equipment indicators checked for specific equipment levels. Where such equipment is found, it shall be cross-referenced against the relevant conditions elsewhere in the message. Where the submitted message associates with an existing flight plan held by the IFPS, the conditions and/or equipment of that submitted message shall be cross-referenced against those of the existing flight plan.

The specific equipment cross-checks carried out by the IFPS shall be:

W (RVSM) – The flight may enter RVSM airspace (FL290 – FL410). Y (8.33kHz) – The flight may enter 8.33kHz-only airspace (FL195 and above). U (UHF) – The flight may enter UHF-minimum airspaces.

Z – The sub-field NAV and/or COM and/or DAT is/are present with explanatory information in Item 18.

R – The sub-field PBN/ is present with minumum one and maximum 8 valid descriptors in Item 18.

Submitted messages that associate with an existing flight plan shall be checked by the IFPS to be in compliance with the relevant equipment specified in that flight plan, and where compliance is not met, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

The IFPS shall output any equipment details in a specific sequence. That sequence shall be the letter S, where present, then any other equipment designators in alphabetic sequence.

Any designator possible within field 10a and 10b can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.



68 ITEM 13: Aerodrome of Departure (ADEP) and Estimated Off-Blocks Time (EOBT)

(1) General

The IFPS shall calculate a four-dimensional profile for every flight that is submitted for processing, and shall check that profile against the NM CACD. The profile calculation shall start at the aerodrome of departure, or where that is unknown, at the first point given in the route. In order to achieve this, the ICAO four letter aerodrome codes and their geographical locations have been included in the CACD.

The IFPS profile calculation shall commence at the given Estimated Off-Blocks Time (EOBT).

(2) Requirements

The IFPS shall process those IFR/GAT flight plans and associated messages or parts thereof that intend to operate wholly or in part within the IFPZ.

Where no ICAO designator exists for the aerodrome or point of departure, that aerodrome or point shall be given as ZZZZ, with corresponding details in the sub-field DEP.

Note Where the departure aerodrome is given as ZZZZ, a known ICAO location designator should not be filed in the sub-field DEP.

Where a flight plan is filed for an aircraft in flight, the departure point shall be given as AFIL. The EOBT at the aerodrome or point of departure shall be given. In the case of a flight plan filed for an aircraft in flight, the time given represents the estimated time over the first point indicated in the route.

(3) Message Format

Any flight plan or associated message shall indicate the aerodrome of departure using the ICAO four-letter designator, where that designator is known. Where the aerodrome of departure does not have an ICAO four-letter designator or the flight is departing from a specified location or the ICAO four-letter designator for that aerodrome is not known, ZZZZ shall be used.

For those flights filing a flight plan when already airborne, the text AFIL shall be used.

Where ZZZZ is used to indicate the departure aerodrome or point, the corresponding details of that aerodrome or point shall be indicated in the sub-field DEP.

The IFPS shall check all four-letter codes given as the departure aerodrome of all flight plans and associated messages submitted to the IFPS for processing against the NM CACD. Where an unknown code is submitted, that message shall fail automatic processing and shall be passed for manual treatment by the IFPS staff. For this purpose, ZZZZ and AFIL shall be considered as known codes with a specific IFPS processing meaning.

Where the departure aerodrome or point of a flight plan or associated message is filed as a known ICAO designator or as ZZZZ, then the associated time shall indicate the Estimated Off-Blocks Time of that flight. That EOBT shall be given as UTC expressed as four digits.

For those flights with the departure point given as AFIL, the associated time shall indicate the Estimated or Actual Time Over the first point given in the route. That ETO/ATO shall be given as UTC expressed as four digits.

Examples EGLL1500

ZZZZ1200 (with corresponding sub-field DEP/ details)

AFIL0537




The IFPS shall check the departure aerodrome in all submitted messages. The system shall first

check to identify the ICAO aerodrome code, ZZZZ or AFIL. Those flight plans containing ZZZZ with no sub-field DEP information shall fail automatic processing and be passed for manual processing.

When the sub-field DEP is a unique geographical coordinate, that information will be inserted at the beginning of the route field.

In the event that flight plans containing ZZZZ and a known ICAO aerodrome designator in the sub-field DEP are submitted for processing, the IFPS shall automatically replace the ZZZZ indicator with that known ICAO designator give in the sub-field DEP.

When the departure aerodrome has been identified, the EOBT is checked against the current time in the IFPS and against any DOF given in that message.

The IFPS shall accept flight plans that do not contain a DOF. In such cases, the IFPS shall automatically assume that the flight is to take place in the 24 hour period starting 30 minutes in the past when compared to the current time, and shall add the appropriate DOF to that message.

Where a DOF is included in the flight plan, the IFPS shall take that information into account when processing the EOBT.

For practical reasons it shall be possible for the IFPS to process those flight plans that contain an EOBT of more than 30 minutes in the past compared to the current IFPS time. This shall only be possible where the EOBDT (i.e. the combination of the EOBT and DOF) is not more than 12 hours in the past when compared to the current IFPS date/time. The flight plan shall fail automatic processing but may be manually forced through processing by the IFPS staff.

It shall not be possible to alter the departure aerodrome by means of a message.



69 ITEM 15: Route

(2) Requirements

The IFPS shall process flight plans and associated messages that may contain information in the route as relevant for an IFR/GAT flight or part thereof operating within the IFPZ.

Where present in a flight plan or associated message submitted to the IFPS for processing, the route shall describe the intended route of the flight and shall be completed in accordance with ICAO requirements. That route shall consist of a sequence of SID (or last point thereof) or point route point or STAR (or first point thereof), where SID and STAR are available. That route may contain the designator DCT if the routeing will be outside a designated route. That route may also contain changes of speed, level, flight rules, flight conditions and the indicator STAY.

Some states have implemented the Free Route Airspace (FRA) concept. This concept means a specific airspace (usually an ATC Unit Airspace (AUA)) within which users may plan their routes between an entry and exit point for that airspace without reference to an Air Traffic Services (ATS) route network. In this airspace, flights will remain subject to air traffic control.

Depending on the country, the implementation may differ as the concept offers several options such as:

Free Route Airspace during a specific time period only (i.e. night time).

During the time the FRA is active; the ATS route network may remain or may be suspended.

Dependent upon the published requirements of the specific FRA, between the entry and the exit points the airspace may be traversed in the following ways:

on a direct (DCT) routeing between the entry and exit points

on DCT routeings between the entry and exit points and via those specifically-allowed intermediate points that have been designated for FRA in that airspace

on a DCT routeing between the entry and exit points via the whatever intermediate points are most suitable for that flight.

Full details concerning Free Route Airspace where it is implemented may be found in the AIP of the country concerned.

The IFPS shall calculate the profile of all flights for which a flight plan and any associated messages are submitted to the IFPS for processing, using the information given in the route of that message. The IFPS shall check the availability of the requested route in respect to time, level restrictions and any other restriction detailed in the RAD document or required due to 8.33kHz and RVSM checking.

Changes to speed/level shall be specified at each point at which either a change of speed and/or level is planned to commence.

When a transition is planned between a lower and upper ATS route and the routes are oriented in the same direction, the point of transition shall be inserted.

The detailed requirements for the composition of the route field may be found in the following sections of this manual.

69.1 AIRAC Information incorrect in the NM CACD

Error message ref. Various error messages might refer.

Explanation: In exceptional cases information for an AIRAC has been issued too late to be implemented in the NM CACD, or has been implemented incorrectly.



Instruction: Errors are raised incorrectly by the system and shall be corrected manually. The IFPS staff shall refer to the operational instructions in force.



70 Initial Speed and Level

(2) Requirements

The IFPS shall accept speed and level indications in the route of a flight plan or associated messages that are submitted to the IFPS for processing. These speed and level indications shall be taken into account by the IFPS when calculating the profile of that flight.

(3) Message Format

It is required that an accurate indication of the speed and level of that flight be given at the start of the route.

Initial Speed

Speed may be indicated in three ways:

Knots, denoted by an ‘N’, immediately followed by four numerics. Mach number, denoted by an ‘M’, immediately followed by three numerics.

Kilometres per hour, denoted by a ’K’, immediately followed by four numerics.

Examples N0485

M087

K0835

Flight Level

Flight level may be indicated in four ways:

Flight level, denoted by an ‘F’, immediately followed by three numerics. Altitude in hundreds of feet, denoted by an ‘A’, immediately followed by three numerics. Standard metric level in tens of meters, denoted by an ‘S’, immediately followed by four

numerics. Altitude in tens of metres, denoted by an ‘M’, immediately followed by four numerics.

Examples F330

A030

S1190

M0850


For each flight plan or associated message submitted to the IFPS for processing, the IFPS shall verify that all speed and level indicators in the route correspond to the aircraft performance of the aircraft type given in the message.

Where the required format is not followed, or the indicator is beyond the performance of that aircraft type, the message shall fail automatic processing and shall be passed for manual processing by the IFPS staff.

Where a requested flight level (RFL) for a visible portion (GAT, IFR, IFPSTART) does not end with a zero, the message shall fail automatic processing and shall be passed for manual processing by the IFPS staff.

Where a level in a flight plan or associated message submitted to the IFPS for processing is given in metric units, the IFPS shall convert that information into the corresponding flight level for the



purpose of profile calculation. The IFPS shall not output that converted value; that value shall be output in the original format.

Where a speed indicator is not present in a flight plan or associated message submitted to the IFPS for processing, the IFPS shall automatically insert a given average speed, in knots, for that aircraft type at the indicated level.

The IFPS shall use the indicated speed and level given in any flight plan or associated message submitted to the IFPS for processing to calculate the profile of that flight, and to verify the availability of the route as filed. An appropriate error shall be raised when any part or parts of that route are calculated as being not available for that flight. The profile shall be adapted with a performance factor, which expresses the difference between the requested speed and the optimal speed (taken from the performance table) at RFL. This factor is applied to the climb and descent speed.

All flight plans and associated messages for IFR/GAT flights or parts thereof operating within the IFPZ submitted to the IFPS for processing shall have any indicated levels checked for compliance with RVSM and 8.33 kHz.



71 En-Route Change of Speed and Level

(2) Requirements

Changes to the speed and/or level may be indicated in the route field of a flight plan or associated message submitted to the IFPS for processing; any such change of speed and/or level shall be associated with a specified point in the route of that flight. Changes to speed/level shall be specified at each point at which either a change of speed and/or level is planned to commence.

The IFPS shall take into account any change in speed and/or level when calculating the profile of that flight.

In respect to cruise climb, the IFPS shall not check conformity with requirements or restrictions published by National Authorities.

(3) Message Format

Where a message originator requires indicating a change of speed and/or level in the route field of a flight plan or associated message submitted to the IFPS for processing, the point at which that change of speed and/or level is made shall be followed by a ‘/’, then the revised speed and level.

Any change of speed shall be accompanied by an associated indication of level, and any change of level shall be accompanied by an associated indication of speed.

The point at which the change is indicated may be a known significant point, a set of geographical co-ordinates, or a bearing and range from a named navigation aid.

Examples LN/N0450F330

MAY/N0250A030

HADDY/M083F310

46N078W/K0410S1190

DUB180040/K0200M0150

The point at which a change to cruise climb is indicated may be a known named navigation beacon, a set of geographical co-ordinates, or a bearing and range from a named navigation beacon.

The IFPS shall not check conformance with any cruise climb requirements or restrictions published by National Authorities.

Examples C/48N050W/M082F290F350

C/48N050W/M082F290PLUS


The IFPS shall verify that the speed and level in the route corresponds to the aircraft performance of the indicated aircraft type of the flight plan or associated message. Where the required format is not followed, or the indicator is beyond the performance of that aircraft type, or the RFL in a visible portion (GAT, IFR, IFPSTART) does not end with a zero, the message shall fail automatic processing and shall be passed for manual processing by the IFPS staff.

The IFPS shall use the indicated speed and level given in any flight plan or associated message submitted to the IFPS for processing to calculate the profile of that flight, and to verify the availability of the route as filed. An appropriate error shall be raised when any part or parts of that route are calculated as being not available for that flight. The profile shall be adapted with a performance factor, which expresses the difference between the requested speed and the optimal speed (taken from the performance table) at RFL. This factor is applied to the climb and descent speed.



The IFPS shall take the point at which a change in speed/level is indicated to be the point at which the change in speed and/or level is to commence, and the profile shall be calculated accordingly.

Note It is recognised that a number of aircraft operator flight planning systems do not interpret speed level change information in accordance with the ICAO interpretation. This may give rise to flight plans being referred for manual processing by the IFPS staff where a flight plan indicates a change of level at a point from which a RAD level restriction or unavailable route applies. In order to ensure that the constraint is fully respected (and thus ensure automatic processing by IFPS) flight plan originators should submit flight plans that adhere to the ICAO interpretation of a speed and level change.

Where a flight plan or associated message submitted to the IFPS for processing relates to a flight entering the OCA Oceanic Airspace, the IFPS shall check for the required speed and level conditions at that Oceanic entry point.

Where for westbound traffic the speed at the Oceanic entry point is not given as a Mach number, the IFPS shall automatically convert any given value to a Mach number, and output such.

Where for westbound traffic no speed and level indication at the Oceanic entry point is given, the IFPS shall automatically insert such, basing the values on the last given speed and level indications in the route field of that flight.



72 SID/STAR

(2) Requirements

Within the IFPZ, the IFPS is required to provide a route that starts and finishes with points that allow the relevant ATS units to insert the appropriate terminal procedure with no other modification to that route.

Message originators shall file terminal procedures in the filed route of a flight plan or associated message submitted to the IFPS for processing according to the published requirement of those aerodromes.

Where no SIDs or STARs are published for an aerodrome within the IFPZ, it shall remain the responsibility of the message originator to confirm whether that aerodrome requires only VFR arrivals or departures.

Certain aerodromes within the IFPZ have no terminal procedures, but do not require solely VFR arrivals or departures. When planning to depart from or arrive at these aerodromes, the message originator should, where possible, connect the aerodrome to the nearest airway within the DCT limit of that aerodrome.

(3) Message Format

The IFPS shall accept published ICAO terminal procedures. The format for these procedures shall be the procedure name, in letters to a maximum of five, immediately followed by the sequence number, then the runway designator, given as a letter. The IFPS also accepts P-RNAV (Precision RNAV) terminal procedures: the format of these procedures is the same as ICAO terminal procedures but finishes by 2 letters.

Examples DUB1A

KODAP2B

BAKRU1AS (P-RNAV)


Where the aerodrome requires a Terminal Procedure (TP) to be included in the flight plan distributed by the IFPS:

i. When a TP is specified in the filed route of a flight plan or associated message received, the IFPS shall check the validity of that TP.

Where the TP is valid, the IFPS shall accept and transmit that TP in the distributed message. Where the TP is not valid, the IFPS shall propose a valid TP where existing that shall be

included in the distributed flight plan after validation by the IFPS staff.

Where no valid TP can be proposed, the message will be presented with the error message: ‘TP not valid, DCT is assumed, other possibilities are NONE’ to the IFPS staff for manual correction. Connecting points should be found, to allow valid TP to be included by the IFPS in the distributed messages.

ii. When a TP is not specified in the filed route of a flight plan or associated message received, the IFPS shall:

Check that the first/last point extracted from the filed route is a connecting point (CP) from a valid TP for that aerodrome and if so, insert in the distributed message a valid TP.

Where the first/last point extracted from the filed route is not a CP from a valid TP for that aerodrome, raise a SID/STAR DCT limit for that aerodrome and present the message for



manual correction in order for the IFPS staff to find a CP that connects the route to a valid TP.

Where the aerodrome does not require a TP to be included in the flight plan distributed by IFPS:

i. When a TP is specified in the filed route of a flight plan or associated message received, the IFPS shall check the validity of the TP:

Where the TP is valid, the IFPS shall use it for its internal profile, but shall not transmit it in the distributed message.

Where the TP is not valid, the IFPS shall use a valid TP where existing for its internal profile but shall not transmit it in the distributed message.

Where no valid TP can be used, the message shall be presented to the IFPS staff for manual correction, with the error message ’TP not valid, DCT is assumed, other possibilities are NONE’.

Where a TP exists for that aerodrome, the route field should be corrected to connect that aerodrome with a CP of that valid TP.

Where no TP exists, but CPs from a DCT route segment is defined for the aerodrome, one of those CPs should be inserted.

Where no CPs are defined for that aerodrome, a point that is within the SID/STAR DCT limit should be inserted.

ii. When a TP is not specified in the filed route of a flight plan or associated message received, the IFPS shall accept the flight plan where the first/last point extracted from the route field is within the maximum SID/STAR DCT limit for that aerodrome providing that it is compliant with the DCT cross-border restriction and::

Where the first/last point of the route field exceeds the maximum SID/STAR DCT limit, check that the first/last point specified in the filed route is a CP from a valid TP. If so, the TP will be used in its internal profile but not transmitted in the distributed message.

When the first/last point specified in the filed route is not a CP from a valid TP, raise a SID/STAR DCT limit for that aerodrome and present the message for manual correction by the IFPS staff.

Where a CP exists for that aerodrome, it should be inserted.

Where no CP exists for that aerodrome, a point that is within the SID/STAR DCT limit should be inserted.

Note To be considered valid, a terminal procedure must:

a) Not have any active TP restrictions (type of flight, aircraft type and equipment) and

b) Be available in time and level (the minimum level on the first/last route segment is ≤ to the requested flight level) and

c) Connect to the route and d) Belong to the aerodrome.

72.1 General Procedures for SID/STAR

Where a message submitted to the IFPS for processing contains errors in the arrival or departure phase, the message shall fail automatic processing and pass for manual treatment by the IFPS staff.

Where a message containing errors in the arrival or departure phase is presented to the IFPS staff for manual treatment, the IFPS staff shall always verify that the aerodrome of departure and/or aerodrome of destination are correct and do not contain a semantics error.



Example The departure aerodrome is submitted as LFBP instead of LFPB.

Should published terminal procedures exist for the concerned aerodrome, the Standard Correction Procedure, SCP1, shall be applied. Either the last point of the SID/first point of the STAR or a connecting point shall be proposed as a solution.

In the event that the only error contained in the terminal procedure is the sequence number, the IFPS staff shall change that number to the sequence number held by the NM. No coordination with the message originator shall be made for this action.

72.2 Exceptional Procedures for SID/STAR

The Airspace Data Management Section (AD) may have created artificial SID/STAR designators for some aerodromes; these contain values for SID between 50-89 and for STAR between 10-49. The IFPS shall not output these designators.

Where no published terminal procedures exist for the concerned aerodrome, and the departure aerodrome and the first point/last point and destination aerodrome may be connected by an airway without changing the trajectory and within the direct (DCT) limit for that aerodrome, the IFPS staff may make the correction without the need of coordination with the message originator or aircraft operator.

Where no published terminal procedures exist for the concerned aerodrome and the necessary correction requires a change of trajectory, the Standard Correction Procedure SCP1shall be applied.






73 Points

(2) Requirements

The IFPS requires that all flight plans or associated messages submitted to the IFPS for processing shall contain details of the route intended to be flown by that flight.

Where a route is made up of more than a direct (DCT) route between the departure and destination aerodromes, that route shall give details of any relevant significant geographical points.

Where a flight intends to fly on an airway, the route given in the flight plan shall indicate the point at which the flight intends to join that airway and the point at which the flight intends to leave that airway.

Any flight intending to enter or leave the European RVSM airspace from or to non-RVSM airspace within the vertical limits of the RVSM airspace is required to indicate in the route of the flight plan or any associated messages the RVSM entry/exit point plus the planned speed and level at that point.

(3) Message Format

The IFPS shall accept an indication of location as a named navigation beacon, a set of geographical coordinates, or as a bearing and range from a named navigation beacon.

Those navigation beacons in the route field of flight plans or associated messages submitted to the IFPS for processing that have a published ICAO designator shall be accepted by the IFPS.

Significant points (waypoints and navigation aids) shall be given as named points with a minimum of 2 and a maximum of 5 letters or alphanumeric of which at least 1 is a letter, indicating the name of that point.

Examples LN

MAY

HADDY

LS103 (helicopter point)

A position may be expressed as a bearing and range from a significant point, where 3 digits for the bearing and 3 digits for the distance shall immediately follow the significant point name from the navigation aid. The correct number of digits shall be made up, where necessary, by the insertion of zeros.

Examples

LN180040 indicates a point 180° magnetic at a distance of 40 nautical miles from ‘LN’

DUB090050 indicates a point 90° magnetic at a distance of 50 nautical miles from ‘DUB’

Geographical co-ordinates shall consist of either 2 degrees latitude followed by 3 degrees longitude, or 2 degrees and 2 minutes latitude followed by 3 degrees and 2 minutes longitude or by 2 degrees, 2 minutes and 2 seconds latitude followed by 3 degrees, 2 minutes and 2 seconds longitude.

Examples 46N078W

4620N05805W

462013N0580503W

Note The IFPS will automatically accept those coordinates where one digit is missing, and will add a 0 (zero) to the front of the incomplete coordinate, provided that the first digit present is not a 0 (zero).



Examples

4N40W and 04N40W accepted as 04N040W

4N04W and 04N04W rejected

400N40000W and 0400N4000W accepted as 0400N04000W

400N0400W and 0400N0400W rejected


Where a navigation aid name is given in the route of a message submitted to the IFPS for processing, the IFPS shall confirm that the name given is correct and unambiguous. In the event that the IFPS cannot clearly identify a navigation aid, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Where a navigation aid is indicated as being a part of an airway or a terminal procedure in a message submitted to the IFPS for processing, the IFPS shall verify that the navigation aid is a part of that airway or terminal procedure. Where a navigation aid inside the IFPZ cannot be identified by the IFPS, the IFPS shall fail the automatic processing of that message and pass it for manual treatment by the IFPS staff.

Note Where geographical coordinates are given in a route, the IFPS shall check those coordinates against the coordinates of the known navigation aids held in the NM CACD, and subsequently carry out the processing described above.

Given the large number of named navigation aids, occasionally there may be several points in different states with the same name. When this situation is identified, the NM Environment creates homonyms in order that the IFPS is able to unambiguously identify those points when they are given in the routes of messages submitted to the IFPS for processing.

Where a navigation aid is preceded or followed by another navigation aid without the indication of either DCT or an airway, the IFPS shall check if an available airway exists between those two points. The IFPS shall use an algorithm to determine if the airway shall be inserted automatically between those two points.

Where the IFPS cannot determine an airway between two navigation aids, the message shall fail automatic processing and be passed for manual correction by the IFPS staff.

73.1 General Procedure for Non Recognised Points

Where a message containing errors in the navigation aid names is presented to the IFPS staff for manual treatment, the IFPS staff shall only amend those names without prior co-ordination with the message originator where a correction may be positively and unambiguously identified.



74 Airways

(2) Requirements

The IFPS requires that all flight plans or associated messages submitted to the IFPS for processing shall contain details of the route intended to be flown by that flight.

The minimum possible for the route is a direct (DCT) route between the departure and destination aerodromes; the availability of that direct route, and any other routes mentioned shall be verified by the IFPS.

Where a flight intends to fly on a route, whether a named airway, or a direct routeing, the route given in the flight plan or any associated messages shall indicate the points at which the flight intends to join and leave that route.

Note Where a flight intends to fly only on a DCT route between the departure and the destination aerodrome, the IFPS may accept this route as the only route entry. The IFPS shall verify the DCT against any cross border or maximum DCT limit requirements (both en-route and aerodrome) issued by the relevant National Authorities.

The relevant National Authorities may decide a maximum DCT length, in nautical miles, that shall be allowed within a specified airspace. Additionally a state may declare specific DCT portions as forbidden or allowed, regardless of the DCT limit of the airspace. Details for DCT limits can be found in Appendix 4 of the RAD document. The allowed maximum DCT length may be defined per airspace slice and type of flight.

The relevant National Authorities may declare the crossing of an international boundary on a DCT routeing to be forbidden or allowed.

The designator T for truncated route shall not be accepted by the IFPS.

The route information shall be used in the profile calculation for that flight. The IFPS shall not check the cruising levels against the flight level series defined for the flown segment except for the entry and exit requirements of the EUR RVSM airspace.

A check shall be executed for the use of DCT between two points, therefore it is recommended to use DCT only where a connection to a point is not possible via an ATS route or a SID/STAR.

(3) Message Format

The route designator in the route shall be preceded by a point followed by a space, and shall consist of a combination of between two and seven characters indicating the coded designator assigned to that route, or DCT, followed by a space and the next point.

Example ELB UA1 SPR UA24 NIK


The IFPS shall check the route details in any message submitted to the IFPS for processing, and where a route designator is found, the IFPS shall confirm that the given designator matches that one given in the NM CACD as being the correct route between the given points. Where no such match is found, the IFPS shall pass those messages for manual processing by the IFPS staff.

Should the route start with a route rather than a point, the IFPS shall use an algorithm to determine which point to extract as the first point of the route for the profile calculation. This point shall then be used for terminal procedure checking.

Should the route end with a route rather than a point, the IFPS shall use an algorithm to determine which point to extract as the last point of the route for the profile calculation. This point shall then be used for terminal procedure checking.



The IFPS shall verify that the given point preceding the ATS route and the given point following the ATS route are part of that ATS route.

Where an airway is preceded or followed by another airway without the indication of a point at the intersection of those airways, the IFPS shall check if an available point exists between those two airways. The IFPS shall use an algorithm to determine if the point shall be inserted automatically between those two airways.

Where the IFPS cannot determine a unique intersection between two airways, the message shall fail automatic processing and be passed for manual correction by the IFPS staff.

Where a DCT route is filed between two points, the IFPS shall confirm whether there is an available airway between those two points. Where such is found, the IFPS shall automatically replace the DCT with the available airway.

Where the airway between the two points is not available, the message shall fail automatic processing and be passed for manual correction by the IFPS staff.

Where no unavailable route is found between those two points, the availability of the filed DCT route shall be confirmed against the unavailable DCT routes provided by the national authorities and against the maximum allowed DCT length for that airspace. Should the DCT route fail either of these checks, the message shall fail automatic processing and be passed for manual correction by the IFPS staff.

Where a DCT route is filed across an international boundary, the IFPS shall confirm whether or not the relevant states permit the use of cross-border DCT routes. Should the DCT route fail this check, the message shall fail automatic processing and be passed for manual correction by the IFPS staff.

The IFPS shall calculate the profile of the flight and check the availability of the requested route in respect to time, level and any other restriction detailed in the RAD document.

The IFPS shall drop any repetitive ATS routes and output the route in a simplified form.

Example

Submitted to the IFPS: LATEK UN871 OBUTO UN871 GONUP UN871 TOU UN871 GIPNO

Output by the IFPS: LATEK UN871 GIPNO.

74.1 General Procedures for Airways

In all cases, Standard Correction Procedure (SCP1) shall be applied for errors in relation to routes. Only where a correction can be positively identified that shall not change the trajectory of the flight shall that correction be made without prior co-ordination with the message originator.

Exceptions are not envisaged under normal conditions, however, FMPs and ATSUs occasionally authorise the use of non-standard routes. These one-off authorised exceptions shall be noted in the log book and briefed to the staff by the IFPS Supervisor. Any additional information or list of authorised flights shall be held at the IFPS Supervisor position. A RMK/ in Item 18 indicating the prior authorisation will facilitate the identification of these cases during the treatment of the flight plan.

Where the approval is given for specific cases over a period of time, the relevant operational instruction containing the list of those cases having received prior authorisation shall be updated.

74.2 Conditional Route Categories

In the NM CACD all routes are defined in categories. The following categories have been created: CDR0, CDR1, CDR2, CDR3, and CDRN.



Category 0 Route (CDR0)

An internal NM route category-naming convention indicating a normal ATS route, always available.

The route can be visualised through the representation of a graph, wherein the flight level series are indicated with a yellow line. The correct flight level series shall be taken into consideration whenever the IFPS staff is making a manual correction.


This CDR route may be available for flight planning during times published in the relevant National AIP. The AUP/UUP(s) shall notify closures of CDR1 routes.


This CDR route may not be available for flight planning. Flights may only be planned on a CDR2 in accordance with conditions published daily in the AUP/UUP(s).


This CDR route shall not be available for flight planning at all. Flights shall not be planned on these routes but ATC may issue tactical clearances on such route segments.

Category N (CDRN)

An internal NM route category naming convention indicating that no flight levels are available in a defined direction within a defined level band.

The CHMI Map Legend contains two further categories:

Category MIXED CDR

This indicates a route for which, inside its vertical limits, there is more than one CDR availability. On the map these are displayed as a magenta interrupted line.

Category UNDEFINED

This indicates a route which is not defined H24 7/7. When the route is undefined it means that it does not exist. CHMI offers the possibility to display a route at a time it is undefined. This CHMI feature has to be enabled (Preferences>MAP application>General>Show CDR U). On the map these are displayed as a violet line.

74.3 Mandatory DCT Route co-located with a Closed Airway

Where a flight plan message contains a DCT which is on the same trajectory as an airway (Point A DCT Point B and there is an airway between A and B), then the IFPS shall automatically replace the DCT with the airway designator and include that designator in the flight plan message output.

However, if that airway is closed, then the IFPS will raise an error indicating the closure.

If the route segment is restricted by a mandatory DCT RAD unit, then the IFPS shall raise RAD errors. For this reason, mandatory DCTs should not normally be implemented in the RAD on the same trajectory as an existing airway portion.

Explanation: Mandatory DCT implemented in the RAD on the same trajectory as an existing airway portion.



Instruction: The IFPS staff shall check the RAD document (open complete document to ensure that the search incorporates all annexes).

If the DCT is published as available in RAD document but is on the same trajectory as a closed airway, the IFPS staff shall not ignore the error but shall apply SCP1. If contact is possible with the message originator via telephone or via the transmit function, the IFPS staff shall explain that the route cannot be accepted on the same trajectory as a closed airway and the problem will be reported via internal operational incident report.

If the DCT is published as available in the RAD document but is raising another RAD error, the IFPS staff shall ignore the RAD error. The flight plan message will contain the route designator rather than the DCT in the output.

The IFPS staff shall then raise an Ops Incident in Remedy CCMS.



75 ITEM 16: A) Destination Aerodrome B) Total Estimated Elapsed Time C) Alternate Aerodrome(s)

(1) General

The IFPS shall calculate a four-dimensional profile for every flight that is submitted for processing, and shall check that profile against the NM CACD. The profile calculation shall end at the destination aerodrome, or where that is unknown, at the last point given in the route. In order to achieve this, the ICAO four-letter aerodrome codes and their geographical locations have been included in the NM CACD.

(2) Requirements

The IFPS shall process those IFR/GAT flight plans and associated messages or parts thereof intending to operate wholly or in part within the IFPZ.

In order to help determine whether a flight operates wholly or in part within the IFPZ, the IFPS shall identify the geographical location of the destination aerodrome, where that aerodrome of destination is given as a known ICAO code.

Where no ICAO designator exists for the aerodrome or point of destination, that aerodrome or point shall be given as ZZZZ with corresponding details, where known, in the sub-field DEST.

The total Estimated Elapsed Time (EET) given shall be considered by the IFPS to be the total time calculated for that flight from departure to the point at which that flight lands at the aerodrome or point of destination.

Where an alternate destination aerodrome is given, that aerodrome shall be given as a known ICAO code, otherwise ZZZZ shall be used.

Where ZZZZ is used, the corresponding details shall be given in the sub-field ALTN.

It shall be possible to indicate more than one sub-field ALTN.

(3) Message Format

A flight plan or associated message shall indicate the destination aerodrome using the ICAO four-letter designator, where that designator is known. Where the destination aerodrome does not have an ICAO four-letter designator, or the destination of that flight is a specified location, or the ICAO four-letter designator for that aerodrome is not known, ZZZZ shall be used.

Where ZZZZ is used for the destination or alternate aerodrome, the corresponding details of that aerodrome or point shall be indicated in the sub-field DEST and or ALTN.

Those messages submitted to the IFPS for processing that contain ZZZZ for the destination aerodrome without the corresponding details in the sub-field DEST shall fail automatic processing and be passed for manual treatment by the IFPS staff.

The total EET given in the message shall be expressed in hours and minutes (HHMM).

Examples KJFK0721 KEWR

ZZZZ0214 (with corresponding details in the sub-field DEST)

EKCH0233 ZZZZ EKBI (with corresponding details in the sub-field ALTN)



After the total EET, the IFPS shall accept from zero to a maximum of two alternate aerodrome(s). It shall not be possible to remove an alternate aerodrome by sending a modification message (CHG) or a new flight plan. It shall be possible to update the alternate aerodrome(s) by sending a modification message (CHG) or a new flight plan.

In order to remove an alternate aerodrome, the message originator shall cancel and refile the flight plan.

Examples of filed item 16: -EDDM0100

-EDDM0100 EDDF EDDT

-EDDM0230 EDDF

Neither EDDT nor EDDF can be removed. Any subsequent modification message (CHG) for a change of Item 16 in order to update the stored flight plan will overwrite the previous alternate aerodrome(s).


The IFPS shall check Item 16 in all submitted messages. The system shall first check to identify any known ICAO aerodrome codes or ZZZZ that shall be present; where such identification cannot be made, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

Where ZZZZ is found for the destination aerodrome, the IFPS shall check for the sub-field DEST giving the name of the destination. Should no sub-field DEST information be given when ZZZZ is used for the destination aerodrome, the message shall fail automatic processing and shall be presented for manual treatment by the IFPS staff.

Where ZZZZ is used for the destination aerodrome and a known aerodrome of destination is used in the sub-field DEST the IFPS shall replace ZZZZ by the known DEST.

Where the sub-field DEST is a unique geographical co-ordinate, that information will be inserted at the end of the route field.

Where ZZZZ is found for the alternate aerodrome, the IFPS shall check for the sub-field ALTN giving the name of the alternate destination aerodrome. Should no sub-field ALTN information be given when ZZZZ is used for the alternate aerodrome, the message shall fail automatic processing and shall be presented for manual treatment by the IFPS staff.

Where ZZZZ is used for the alternate aerodrome and a known alternate aerodrome is used in the sub-field ALTN the IFPS shall replace ZZZZ by the known ALTN.

Note The IFPS shall not distribute any flight plans or associated messages to the alternate or en-route alternate aerodromes given in the flight plan. It shall remain the responsibility of the message originator to ensure the distribution of the flight plan and all subsequent associated messages to the alternate or en-route alternate aerodromes.

It is possible for the message originator to use the Re-addressing function to ensure message distribution to any alternate aerodromes.

Following the destination and alternate aerodrome checks, the IFPS shall check the time given for the total EET, against the profile calculation made by the IFPS. Should there be a discrepancy of more than 40%, 120% or 200% (depending on the length of that flight) between the given and calculated total EETs, that message shall fail automatic processing and be passed for manual treatment by the IFPS staff. This check is not performed for those flights with a flight type given as ‘X’.



Note Where the Ignore function is used against a total EET error to manually force a message through processing, the total EET of that message calculated by the IFPS shall be used to calculate the flight profile.






76 ITEM 18: Other Information

(2) Requirements

The IFPS shall process flight plans and associated messages that may contain information as relevant for an IFR/GAT flight or part thereof operating within the IFPZ.

The IFPS shall check all those sub-field indicators detailed in System Processing. Designators not listed below shall not be checked and shall be output by IFPS as filed, at the end of Item 18.

(3) Message Format

The total number of characters that may be used is restricted by the maximum number of 2100 characters allowed for the total flight plan message, including the header, or 1800 characters of pure text. Certain sub-fields are restricted in the number of characters in that sub-field. The relative details are given in the relevant section of this document.


The following elements shall be recognised by the IFPS as sub-field indicators and shall be processed by the IFPS:

-0

-STS/

-PBN/

-EUR/

-NAV/

-COM/

-DAT/

-SUR/

-DEP/

-DEST/

-DOF/

-REG/

-EET/

-SEL/

-TYP/

-CODE/

-RVR/

-DLE/

-OPR/

-ORGN/

-PER/

-ALTN/

-RALT/



-TALT/

-RIF/

-RMK/

-STAYINFOn/

-RFP/

If duplicates are found in the sub-fields indicators STS/, NAV/, COM, DAT/, SUR/, EET/, TYP/, DLE/, ALTN/, RALT/, TALT/, RMK/,RIF/, their contents shall be concatentated within a unique occurance of the sub-field indicator but with a space inserted between the two data streams.

Example

Input to IFPS: -18/STS/STATE STS/ATFMX

Output from IFPS: -18/STS/STATE ATFMX

However if duplicates of the following sub-field indicators are found, the message shall fail automatic processing and be presented to an IFPS staff for manual treatment.

DEP/, DEST, DOF/, OPR/, RVR/, SEL, REG/, PBN/, CODE/, ORGN/, PER/, RFP/.

The following recognised ICAO indicators shall be cross-referenced by the system to other Items in the flight plan message:

STS/ (to Number of Aircraft)

STS/ (to Equipment)

STS/ (to Route)

TYP/ (to Aircraft Type)

COM/ (to Equipment

DAT/ (to Equipment)

NAV/ (to Equipment)

DEP/ (to Departure Aerodrome)

DEST/ (to Destination Aerodrome)

ALTN/ (to Alternate Aerodrome)

PBN/ (to Equipment)

DLE/ (to Route)

For messages distributed by the IFPS the following sub-field indicators may be inserted by the IFPS after processing of the message:

-ORGN/

-IFP/

-AWR/

-SRC/

-DOF/

The IFPS shall output the Item 18 sub-fields indicators in the following order:

0, STS, PBN, NAV, COM, DAT SUR, DEP, DEST, DOF, REG, SEL, TYP, CODE, RVR, IFP, DLE OPR, ORGN, PER, ALTN, RALT, TALT, SRC, RIF, RMK, STAYINFO, RFP, AWR



It shall be possible to remove any Item 18 sub-field indicator (except EUR/PROTECTED) by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the sub-field which is intented to be removed.






77 Estimated Elapsed Time (EET)

(2) Requirements

The IFPS shall check the syntax and semantics of any Estimated Elapsed Time (EET) given in a flight plan or associated message.

The IFPS shall not check conformance with any published EET requirements of National Authorities. This information shall be found in the relevant National AIP, ENR section.

The IFPS shall accept an EET value from 0000 to a maximum of 2359.

The IFPS shall accept multiple EETs with the same FIR/POINT identifier and/or same time.

The IFPS shall store and output duplicate EETs.

The IFPS shall output EETs in chronological order, and shall respect the input order for the sequences of multiple EETs with identical estimate times.

(3) Message Format

The EETs given in the sub-field EET, shall indicate the significant point, FIR boundary designators or geographical co-ordinates, immediately followed by the EET over those points.

Example EET/NTM0120 LOVV0210 56N010E0306 011E0309 57N0321

Where the EET point is a geographical co-ordinate, the IFPS shall accept several formats. The geographical co-ordinate shall be expressed in 2 digits latitude and 3 digits longitude, or 4 digits latitude and 5 digits longitude. The EET point however, may also be expressed as only 2 digits latitude, or only 3 digits longitude.


The IFPS shall check any sub-field EET entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed.

The IFPS shall use the values given in EET entries for calculating the flight profile when such are found to be within an acceptable window compared with the EET calculated by IFPS.

It shall be possible for a message originator to remove the EET indicators from the sub-field EET by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the EET sub-field.






78 Re-Clearance in Flight (RIF)

(2) Requirements

The sub-field RIF shall be used to indicate the route details to the revised destination aerodrome followed by the ICAO four-letter code for that revised destination aerodrome. The revised route shall be subject to re-clearance in flight.

(3) Message Format

The sub-field shall be denoted with the letters RIF followed by a ‘/’, then the route details, in free text, to the revised destination aerodrome, followed by the ICAO four-letter location indicator of that aerodrome.

Example RIF/DTA KLAX

RIF/LEMD


The IFPS shall check any sub-field RIF, entries in messages submitted to the IFPS for processing.

Where multiple entries are found, the content of the multiple entries shall be concatenated by IFPS into a single sub-field with a space in between the original data streams.

It shall be possible for a message originator to remove the RIF details from the sub-field RIF, by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the RIF sub-field.






79 Aircraft Registration (REG)

(2) Requirements

The IFPS shall accept the sub-field REG to indicate the registration markings of the aircraft, whenever necessary and if different from the aircraft identification.

Where possible, the aircraft registration should be submitted to the IFPS, and where an aircraft change is made for that flight, the registration should be updated accordingly.

For operators of RVSM-approved aircraft, it is mandatory to insert the aircraft registration in Item 18 of the ICAO flight plan form.

(3) Message Format

The sub-field shall be denoted with the letters REG followed by a ‘/’, then the registration details of the aircraft(s), if different from the aircraft identification, with a maximum of 50 characters. Where the message concerns a formation flight, the registrations of the aircraft may be specified under one unique REG/ sub-field and separated by a space


The IFPS shall check any sub-field REG entries in messages submitted to the IFPS for processing.

Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing where the required format is not followed.

Where multiple entries are found, the IFPS shall fail that message from automatic processing as duplicates are not permitted in this sub-field.

It shall be possible for a message originator to remove the aircraft registration details from the sub-field REG by sending a modification message (CHG).The modification message (CHG) shall contain all the previous Item 18 sub-fields except the REG sub-field.

RVSM approved aircraft shall indicate their registration in item 18 of the ICAO flight plan under REG/ (or the equivalent field in ADEXP or B2B).

Note The above requirement is only satisfied with the presence of the REG/ field in item 18 of the flight plan and therefore it is not satisfied if the registration of the aircraft is used in Item 7 Aircraft Identification and not specified under REG/.






80 SELCAL (SEL)

(2) Requirements

The sub-field SEL shall be used to indicate the SELCAL code of the aircraft to which the flight plan relates.

A maximum of one SELCAL code for each flight plan shall be accepted by the IFPS.

(3) Message Format

The sub-field shall be denoted with the letters SEL followed by a ‘/’, then the SELCAL code details of the aircraft, in 4 letters; the IFPS shall not accept numeric.

Example SEL/ADBF


The IFPS shall check any sub-field SEL entries in messages submitted to the IFPS for processing.

Where one entry is found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed.

Where mutiple entries are found the IFPS shall fail that message from automatic processing as duplicates are not permitted in this sub-field.

It shall be possible for a message originator to remove the SEL details from the sub-field SEL by sending a modification message (CHG).The modification message (CHG) shall contain all the previous Item 18 sub-fields except the SEL sub-field.






81 Aircraft Operator (OPR)

(2) Requirements

The sub-field OPR shall be used to indicate the aircraft operator of the aircraft to which that flight plan relates if different from the aircraft identification in Item 7.

A maximum of one OPR code for each flight plan shall be accepted by the IFPS.

(3) Message Format

The sub-field shall be denoted with the letters OPR followed by a ‘/’, then the details of the aircraft operator in free alphanumeric text.

Example OPR/BRITISH AIRWAYS

OPR/BAW


The IFPS shall check any sub-field OPR entries in messages submitted to the IFPS for processing.

Where mutiple entries are found, the IFPS shall fail that message from automatic processing as duplicates are not permitted in this sub-field.

Where such an entry is found, the IFPS shall check for recognised aircraft operators and, where such is found, the IFPS shall then check for any specified requirements of that aircraft operator to receive copies of ORMs.

It shall be possible for a message originator to remove the OPR details from the sub-field OPR by sending a modification message (CHG).The modification message (CHG) shall contain all the previous Item 18 sub-fields except the RMK sub-field.






82 STATUS (STS)

(2) Requirements

The sub-field status STS may be used in a flight plan or associated message by those aircraft operators requiring special handling by ATS for that flight.

The following STS shall be accepted by IFPS:

STS/ALTRV For a flight operated in accordance with an altitude reservation.

STS/ATFMX For a flight approved for exemption from ATFM slot allocation.

STS/FFR For a Fire-fighting flight.

STS/FLTCK For a Flight check for calibration of navaids.

STS/HAZMAT For a flight carrying hazardous material.

STS/HEAD For a flight with HEAD of STATE status.

STS/HOSP For a medical flight declared by medical authorities.

STS/HUM For a flight operating on a humanitarian mission.

STS/MARSA For a flight for which a military entity assumes responsibility for separation of military aircraft.

STS/MEDEVAC For a life critical medical emergency evacuation.

STS/NONRVSM For a non-RVSM capable flight intending to operate in RVSM airspace.

STS/SAR For a flight engaged in a search and rescue mission.

STS/STATE For a flight engaged in military, customs or police services.

Other reasons for special handling by ATS shall be denoted under the designator RMK/.

(3) Message Format

The sub-field shall be indicated with the letters STS followed by a ‘/’, followed by one the above status.

The IFPS shall accept multiple STS indicators. Where multiple STS indicators are necessary it shall be specified under one STS/ header and separated by a space.

Example STS/STATE ATFMX


The IFPS shall check any STS indicator in a flight plan or associated message submitted to the IFPS for processing.

Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed.

Where multiple entries are found, the content of the entries shall concatenate by IFPS into a single sub-field with a space in between the original data streams.

In the event that the indicator is a prescribed designator, the IFPS shall confirm that the associated conditions, where appropriate are correct.

Example STS/NONRVSM must be a State flight.



The NM system may use some STS indicators for granting exemption from flow regulations (see section Special Status Flights (STS)).

It shall be possible for a message originator to remove the STS details from the sub-field STS by sending a modification message (CHG). The modification message (CHG) shall contain the complete Item 18 information minus:

The STS descriptor(s) that is intended to be removed or The STS indicator in case the intention is to remove all STS descriptors from the stored FPL.



83 Aircraft Type (TYP)

(2) Requirements

The IFPS shall accept the approved ICAO designators for aircraft types in a flight plan or associated message. Where an aircraft does not have such a designator, or the aircraft type is not known, the message originator shall insert ‘ZZZZ’ in the flight plan or associated message. The message originator shall also then include the sub-field TYP that shall contain details of the aircraft type, preceded by the number of aircraft, as necessary.

(3) Message Format

The sub-field shall be denoted by the letters TYP followed by a ‘/’, then free text detailing the aircraft type(s) and number of aircraft if necessary with a maximum of 60 characters. Special characters such as ! or @ are not permitted.

Note The IFPS shall accept an indicator of the number of aircraft where the aircraft type is indicated as unknown. The IFPS shall also accept an indicator of the number of aircraft, sub-field TYP where the aircraft type is indicated as unknown.


Where ZZZZ is indicated as the aircraft type and the details are included in the sub-field TYP in a flight plan or associated message submitted to the IFPS for processing, the IFPS shall accept that information.

Where a flight plan or associated message is submitted to the IFPS for processing containing a ZZZZ indicator and a known aircraft type indicator in the sub-field TYP, the IFPS shall accept that information. However, under these conditions, the IFPS shall automatically replace the ZZZZ with the known aircraft type designator indicated in the sub-field TYP.

For those flight plans or associated messages submitted to the IFPS for processing that require indicating a formation flight where there is more than one type or there is an unknown aircraft type designator, the aircraft type shall be given as ZZZZ, with the aircraft type details indicated in the sub-field TYP.

Example

Item 9: 02ZZZZ/M item 18: TYP/UNKNOWN or TYP/02 UNKNOWN

Item 9: 03ZZZZ/M item 18: TYP/2F16 1C135

Where multiple entries are found, the content of the entries shall be concatenated by IFPS into a single sub-field with a space between the original data streams.

Where an aircraft type is indicated, the IFPS shall not accept a sub-field TYP to be included for that flight.

Where an aircraft type is indicated as ZZZZ in a flight plan or associated message, the IFPS shall not accept that message without the sub-field TYP details for that flight.

It shall be possible for a message originator to remove the sub-field TYP indicator by sending a modification message (CHG); however the message must also contain the new details of the aircraft type (Item 9) and shall also contain all the previous Item 18 sub-fields except the TYP sub-field.






84 Aircraft Performance (PER)

(2) Requirements

The sub-field PER shall be used to indicate one aircraft performance data whenever that information is necessary (if required by an ATS authority).The specifications can be found in the Procedures for Air Navigation Services – Aircraft Operations (PANS-OPS, Doc 8168), Volume I – Flight Procedures.

(3) Message Format

The sub-field shall be denoted with the letters PER followed by a ‘/’, then one letter. The letter may be: A, B, C, D, E or H.


The IFPS shall check any sub-field PER, entries in messages submitted to the IFPS for processing.

Where one entry is found, the IFPS shall check for compliance with the required format, and pass those messages for manual treatment where the required format is not followed.

Where multiple entries are found, the IFPS shall fail that message from automatic processing as duplicates are not permitted in this sub-field.

It shall be possible for a message originator to remove the aircraft performance information from the sub-field PER by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the PER sub-field.






85 Communications Equipment (COM)

(2) Requirements

The sub-field COM shall be used to indicate communications applications or capabilities not specified in Item 10a data. Where the sub-field COM is used in a message submitted to the IFPS for processing, the associated Item 10a should include a ‘Z’ to indicate that other applications or capabilities are carried.

Example Item 18: Other Information: COM/INOPERABLE

Item 10: Equipment: Z

Only those flights where an aircraft is not equipped with 8.33 kHz capable radios but that are EXEMPTED from the carriage requirements shall use the sub-field COM/EXM833 indicator.

Note The rules for acquiring the necessary permissions to use COM/EXM833 may be found in the appropriate section of the national Aeronautical Information Publication (AIP).

(3) Message Format

The sub-field shall be denoted with the letters COM followed by a ‘/’, and free text to a maximum of 50 alphanumeric characters


The IFPS shall check any sub-field COM entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed.

Where multiple entries are found, the content of the entries shall be concatenated by IFPS into a single sub-field with a space in between the original data streams.

Example

Input to IFPS: COM/EXM833 COM/INOPERABLE

Output by IFPS: COM/EXM833 INOPERABLE

It shall be possible for a message originator to remove the sub-field COM details by sending a modification message (CHG), however, the modification message (CHG) must also remove the Z from the Equipment indicators unless DAT and/or NAV is present in Item 18 and that modification shall also contain all the previous Item 18 sub-fields except the COM sub-field.

Should the equipment indicators contain Z but the sub-field COM be missing, the IFPS shall invalidate that message and pass it for manual processing by the IFPS staff unless NAV and/or DAT is present in Item 18.






86 Data Link Capability (DAT)

(2) Requirements

The sub-field DAT shall be used to indicate data applications or capabilities, not specified in Item 10a. Where the sub-field DAT is used in a message submitted to the IFPS for processing, the associated Item 10a should include a ‘Z’ to indicate that other applications or capabilities are carried.

One of the applications of that field is to indicate Controller Pilot Data Link Communications (CPDLC) exemption for flights conducted wholly or partly in the EUR CPDLC airspace and not equipped with CPDLC capabilities.

Example Item 18: Other Information: DAT/CPDLCX

Item 10: Equipment: Z

(3) Message Format

The sub-field shall be denoted with the letters DAT followed by a ‘/’, and free text to a maximum of 50 characters.


The IFPS shall check any sub-field DAT entries in messages submitted to the IFPS for processing.


It shall be possible for a message originator to remove the sub-field DAT indicator by sending a modification message (CHG), however, the message must also remove the Z from the Equipment indicators unless COM and/or NAV is present in Item 18.

Should the Equipment indicators contain Z but the sub-field DAT be missing, the IFPS shall invalidate that message and pass it for manual processing by the IFPS staff unless NAV and/or COM is present in item 18 and that modification shall also contain all the previous Item 18 sub-fields except the DAT sub-field.






87 Navigation Equipment (NAV)

(2) Requirements

The sub-field NAV shall be used to indicate significant data related to the navigation equipment of that aircraft, other than specified in PBN/. It shall also be used to indicate the GNSS augmentation, with a space between two or more methods of augmentation, e.g. NAV/GBAS SBAS. Where the sub-field NAV is used in a message submitted to the IFPS for processing, the associated Item 10a should include a ‘Z’ to indicate that other equipment/capability is carried.

(3) Message Format

The sub-field shall be denoted with the letters NAV followed by a ‘/’, and free text up to a maximum of 50 alphanumeric characters.

Example Item 18: NAV/RNAV NAV/INOPERABLE

Item 10: Z


The IFPS shall check any sub-field NAV entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing by the IFPS staff where the required format is not followed.


Example

Input to IFPS: NAV/GBAS NAV/SBAS

Output by IFPS: NAV/GBAS SBAS

It shall be possible for a message originator to remove the sub-field NAV details by sending a modification message (CHG), however, the message must also remove the Z from the Equipment indicators unless DAT and/or COM is present in item 18.

Should the Equipment indicators contain Z but the sub-field NAV be missing, the IFPS shall invalidate that message and pass it for manual processing by the IFPS staff unless COM and/or DAT is present in Item 18 and that modification shall also contain all the previous Item 18 sub-fields except the DAT sub-field.






88 Departure Aerodrome (DEP)

(2) Requirements

The IFPS shall accept approved ICAO aerodrome designators in Item 13: Departure Aerodrome of a flight plan or associated message. Where an aerodrome does not have such a designator, or the designator is not known, the message originator shall insert ‘ZZZZ’ in Item 13 and include the sub-field DEP in Item 18. The sub-field DEP shall indicate the name and location of the departure aerodrome. The location can be indicated either as bearing and distance from a significant point or as latitude and longitude.

Example Item 13: ZZZZ

Item 18: DEP/MALAHIDE DUB110015 or

DEP/MALAHIDE 5327N00608W or

DEP/BAGSO or

DEP/5327N00608W

(3) Message Format

The sub-field shall be denoted by the letters DEP followed by a ‘/’, then free text to a maximum of 50 alphanumeric characters detailing the name and location of the departure aerodrome.


Where ZZZZ is indicated as the departure aerodrome and details are included in the sub-field DEP in a flight plan or associated message submitted to the IFPS for processing, the IFPS shall accept that information.

Where a flight plan or associated message is submitted to the IFPS for processing containing a ZZZZ indicator as the departure aerodrome and a known ICAO aerodrome designator in the sub-field DEP, the IFPS shall accept that information. However, under these conditions, the IFPS shall automatically replace the ZZZZ with the known ICAO aerodrome designator indicated in the sub-field DEP.

Where a flight plan or associated message is submitted to the IFPS for processing contains a ZZZZ indicator as the departure aerodrome and an aerodrome location is provided in a correct and readable format, that information shall be used for the profile calculation.


Where a departure aerodrome is indicated as ZZZZ in a flight plan or associated message, the IFPS shall not accept that message without the sub-field DEP details for that flight.

Where a known aerodrome designator is indicated as the departure aerodrome, and the sub-filed DEP is present in Item 18, the IFPS shall disregard the information given in the sub-field.

It shall be possible for a message originator to remove the sub-field DEP details by sending a modification message (CHG), however that message must also add a valid departure aerodrome in Item 13 and shall also contain all the previous Item 18 sub-fields except the DEP sub-field.






89 Destination Aerodrome (DEST)

(2) Requirements

The IFPS shall accept approved ICAO aerodrome designators in Item 16: Destination Aerodrome of a flight plan or associated message. Where an aerodrome does not have such a designator, or the designator is not known, the message originator shall insert ‘ZZZZ’ in Item 16 and include the sub-field DEST in Item 18. The sub-field DEST shall indicate the name and location of the destination aerodrome.

The location can be indicated either as bearing and distance from a significant point or as latitude and longitude.

Example Item 13: ZZZZ

Item 18: DEST/MALAHIDE DUB110015 or

DEST/MALAHIDE 5327N00608W or

DEST/BAGSO or

DEST/5327N00608W

(3) Message Format

The sub-field shall be denoted by the letters DEST followed by a ‘/’, and then free text to a maximum of 50 characters detailing the name and location of the destination aerodrome.


Where ZZZZ is indicated as the destination aerodrome and details are included in the sub-field DEST in a flight plan or associated message submitted to the IFPS for processing, the IFPS shall accept that information.

Where a flight plan or associated message is submitted to the IFPS for processing containing a ZZZZ indicator as the destination aerodrome and a known ICAO aerodrome designator in the sub-field DEST, the IFPS shall accept that information. However, under these conditions, the IFPS shall automatically replace the ZZZZ with the known ICAO aerodrome designator indicated in the sub-field DEST.


Where a destination aerodrome is indicated as ZZZZ in a flight plan or associated message, the IFPS shall not accept that message without the sub-field DEST, giving details for that flight.

Where a known aerodrome designator is indicated as the destination aerodrome, and the sub-filed DEST is present in Item 18, the IFPS shall disregard the information given in the sub-field.

It shall be possible for a message originator to remove the sub-field DEST details by sending a modification message (CHG), however that message must also add a valid destination aerodrome in Item 16 and shall also contain all the previous Item 18 sub-fields except the DEST sub-field.






90 Alternate Destination Aerodrome (ALTN)

(2) Requirements

The IFPS shall accept approved ICAO aerodrome designators in Item 16: Alternate Aerodrome, of a flight plan or associated message. Where an aerodrome does not have such a designator, or the designator is not known, the message originator shall insert ‘ZZZZ’ in Item 16c and include the sub-field ALTN in Item 18. The sub-field ALTN shall indicate the name(s) and location(s) of the alternate aerodrome(s) of that flight.

Examples Item 16: EDDT0135 ZZZZ

Item 18: ALTN/TGL200008 or

ALTN/5233N01318E or

ALTN/BEELITZ 5240N1157E

(3) Message Format

The sub-field shall be denoted by the letters ALTN followed by a ‘/’ and then free text to a maximum of 100 alphanumeric characters detailing the name(s) and location(s) of the alternate aerodrome(s).


Where ZZZZ is indicated as an alternate aerodrome and the alternate aerodrome details are included in the sub-field ALTN in a flight plan or associated message submitted to the IFPS for processing, the IFPS shall accept that information.

Where a flight plan or associated message is submitted to the IFPS for processing containing a ZZZZ indicator as the alternate aerodrome and a known ICAO aerodrome designator in the sub-field ALTN, the IFPS shall accept that information. However, under these conditions, the IFPS shall automatically replace the ZZZZ with the known ICAO aerodrome designator indicated in the sub-field ALTN.


Where an alternate aerodrome is indicated as ZZZZ in a flight plan or associated message, the IFPS shall not accept that message without the sub-field ALTN details for that flight.

It shall be possible for a message originator to remove the ALTN sub-field by sending a modification message (CHG), however, the message shall also remove (see Note) any ‘ZZZZ’ from Item 16c and shall also contain all the previous Item 18 sub-fields except the ALTN sub-field.

Note

To remove the ZZZZ indication, the modification message shall contain an alternate aerodrome different than ZZZZ. See section 85 and example below:

Example:

(FPL-ABC123-IS

-RJ1H/M-SDE3FIRWY/H

-EBBR1320



-N0401F310 CIV UN872 KOVIN UM728 RESMI UN857 DIRMO UZ365 GUERE UN860 VEGOB UN859 NARAK

-LFBO0131 ZZZZ

-PBN/B3B4B5 DOF/130909 REG/OODWJ EET/LFFF0011 RVR/150 IFP/MODESASP OPR/BEL ORGN/EBBRSABU ALTN/5611N01000E RMK/AGCS EQUIPPED TCAS EQUIPPED ID SN3669 RTE 01 SEQ10003)

(CHG-ABC123-EBBR1320-LFBO-0-16/LFBO0131 LFBD-18/PBN/B3B4B5 DOF/130909 REG/OODWJ EET/LFFF0011 RVR/150 IFP/MODESASP OPR/BEL ORGN/EBBRSABU RMK/AGCS EQUIPPED TCAS EQUIPPED ID SN3669 RTE 01 SEQ10003)

Flight Plan amended:

(FPL-ABC123-IS

-RJ1H/M-SDE3FIRWY/H

-EBBR1320

-N0401F310 CIV UN872 KOVIN UM728 RESMI UN857 DIRMO UZ365 GUERE UN860 VEGOB UN859 NARAK

-LFBO0131 LFBD

-PBN/B3B4B5 DOF/130909 REG/OODWJ EET/LFFF0011 RVR/150 IFP/MODESASP OPR/BEL ORGN/EBBRSABU RMK/AGCS EQUIPPED TCAS EQUIPPED ID SN3669 RTE 01 SEQ10003)



91 En-Route Alternate Aerodrome (RALT)

(2) Requirements

Where a flight is required to indicate en-route alternate(s), that information shall be indicated in the sub-field RALT. It can be indicated either by the ICAO four letter location indicator(s) of the aerodrome(s) when it exits, or by the name(s) if no indicator is allocated. For aerodromes not listed in the relevant Aeronautical Information Publication (AIP), the location shall also be indicated (whenever possible) in latitude and longitude or in bearing and distance from the nearest significant point.

(3) Message Format

The sub-field shall be denoted by the letters RALT followed by a ‘/’, then free text to a maximum of 100 alphanumeric characters detailing the en-route alternate aerodrome(s).

Examples RALT/EBAW EBLG

RALT/EBBR

RALT/TGL200008

RALT//BEELITZ 5240N1157E

RALT/5240N1157E


The IFPS shall accept the sub-field RALT indicator when it is present in a message submitted to the IFPS for processing.


Example

Input to IFPS: RALT/BIKF RALT/LFPG

Output by IFPS: RALT/BIKF LFPG

It shall be possible for a message originator to remove the RALT indicator from a message by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the RALT sub-field.






92 Remarks (RMK)

(2) Requirements

The sub-field RMK shall be used to indicate any plain language remarks required by the appropriate ATS authority or deemed necessary by the pilot-in-command for the provision of air traffic services.

The character ‘/’ shall not be used in the RMK sub-field other than following the RMK. Also the character ’-’ shall not be used in the free text of the sub-field RMK as it may happen that the IFPS disregards all information after the ‘/’ and/or ‘–‘ and valid information for that flight might get lost or that the IFPS reads that information as Item 19 elements.

(3) Message Format

The sub-field shall be denoted with the three letters RMK followed by a ‘/’ and then free text. The RMK sub-field shall have no limit to the number of characters other than the maximum number of characters possible for the entire message (2100).

Example RMK/DIP CLEARANCE 410 23 5486


The IFPS shall check any sub-field RMK entries in messages submitted to the IFPS for processing.

Where such entries are found, the IFPS shall not check the contents of that sub-field, other than:

Special characters such as: ‘ ( ) ^ % $ # / - @ which are not allowed.

IFPSRA which triggers a specific processing by the IFPS (see relevant section).


Example

Input to IFPS: RMK/DIP CLEARANCE NUMBER 410 23 5486 RMK/NO OVERFLIGHT CLEARANCE FOR SWITZERLAND

Output by IFPS: RMK/DIP CLEARANCE NUMBER 41023 5486 NO OVERFLIGHT CLEARANCE FOR SWITZERLAND

It shall be possible to remove a sub-field RMK indicator by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the RMK sub-field.






93 Date of Flight (DOF)

(2) Requirements

The sub-field DOF shall be used to indicate the date of flight of that flight. The IFPS shall accept a date of flight for any flight; it is recommended to include the date of flight in all flight plans and associated messages submitted to the IFPS for processing.

A date of flight shall be included in all messages where the estimated off-blocks time is more than 24 hours in advance, but not more than 120 hours (5 days) in advance the time at that message is processed by the IFPS.

The IFPS shall not accept any flight plan filed more than 120 hours (5 days) in advance the time at the time that message is processed by the IFPS.

The IFPS shall not accept a message submitted for processing that has a date of flight for a time in the future that does not yet have AIRAC data available via the NM CACD.

(3) Message Format

The sub-field shall be denoted with the letters DOF followed by a ‘/’, then six numbers in the format YYMMDD, where YY indicates the year, MM indicates the month, and DD indicates the day.

Example DOF/130503 = 13 Year 2013, 05 Month (May), 03 Day 3 of the month.


The IFPS shall check any sub-field DOF entries in all messages submitted to the IFPS for processing.


Where no sub-field DOF is included in a message submitted to the IFPS for processing, then the IFPS shall assume that the message is for a flight to take place within the next 24 hours.

The IFPS shall accept a flight plan with no DOF indication in Item 18 and an EOBT up to a maximum of 30 minutes in the past (when compared to current system time at the time of processing) as being a flight for that same day.

The IFPS shall check Item 18: Other Information of a flight plan or associated message for a sequence of the letters D, O and F, regardless of other characters between those letters. Where those letters are found, then the IFPS shall fail the automatic processing of that message and pass that message for manual processing by the IFPS staff. Where such a message is presented for manual processing, the IFPS staff shall confirm the correct date of flight for that message, if necessary, through coordination with the message originator.

The IFPS shall accept the sub-field DOF in associated messages (CHG, DLA, ARR, CNL, and DEP) and shall use it for association purposes.

The IFPS shall invalidate a message submitted for processing with a date of flight outside of the validity period of available AIRAC data in the NM CACD.

The IFPS shall invalidate a message submitted for processing with a date of flight for which no AIRAC data is available via the NM CACD. This will avoid processing a message for the next AIRAC when the relevant data is not yet loaded.

The IFPS shall add a comment ’AIRAC DATA NOT AVAILABLE. MESSAGE QUEUED FOR LATER PROCESSING’ in the associated manual message if the new error ‘AIRAC_NOT_AVAILABLE’ is generated and the error ‘EOBDT_OUT_OF_RANGE’ is not reported.






94 Replacement Flight Plan (RFP)

(2) Requirements

The sub-field RFP shall be used to indicate where an alternative routeing is filed in a new flight plan during the pre-flight stage (within four hours of estimated off-blocks time).

(3) Message Format

The sub-field shall be denoted with the letters RFP followed by a ‘/’, followed by Q and a number from 1 to 9 to indicate the sequence of that route.

The message originator shall follow the following procedure to ensure correct processing:

a) The original flight plan is cancelled by submitting a cancellation using the DD priority indicator when filing via the AFTN.

b) The replacement flight plan shall be filed upon receipt of an ACK message for that cancellation message. The replacement flight plan shall contain the aircraft identification; the departure aerodrome; the destination aerodrome; the date of flight (recommended), and the complete new route in Item 15, and in Item 18, the indication RFP/Q <number.

Note Where more than one replacement flight plan is submitted, the procedure as explained in a) and b) shall be followed again.

Example 1st replacement flight plan - Item 18: Other Information – RFP/Q1

2nd replacement flight plan - Item 18: Other Information - RFP/Q2


The IFPS shall check any sub-field RFP entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and shall fail those messages from automatic processing where the required format is not followed and also because duplicates are not permitted in this sub-field.

It shall only be possible to use the numbers 1 up to and including 9 to indicate the latest RFP, if a number is entered that exceeds one character or the number 0, the message shall fail automatic processing and shall be invalidated and sent for manual processing by the IFPS staff.






95 CODE

(2) Requirements

The sub-field CODE shall be used to indicate the unique 24-bit aircraft address of the airframe for this aircraft.

Flights planning to use CPDLC over the aeronautical telecommunication network (ATN) shall include in Item 18 of the flight plan the indicator CODE/ followed by the 24-bit aircraft address (expressed in the form of alphanumerical code of six hexadecimal characters).

(3) Message Format

The sub-field shall be denoted with the letters CODE followed by a ‘/’, followed by 6 alphanumeric ranging from 0 to 9 and/or from A to F.


The IFPS shall check that the sub-field CODE contains 6 alphanumeric ranging from 0 to 9 and/or from A to F where A=10 ,….,F=15.

The IFPS shall check any sub-field CODE entries in messages submitted to the IFPS for processing. Where multiple entries are found, the IFPS shall fail that message from automatic processing as duplicates are not permitted in this sub-field.

When the sub-field CODE is present in a message submitted to the IFPS for processing which does not contain 6 alphanumeric in the correct format, and the IFPS does not hold a CODE value from a previously-processed associated message, then the sub-field CODE shall automatically be deleted from that message.

The warning message:

COMMENT: INVALID AIRCRAFT ADDRESS (CODE) HAS NOT BEEN STORED

shall be included in the ACK message.

Whenever the sub-field CODE is present in a message submitted to the IFPS for processing that does not contain 6 alphanumeric in the correct format, and the IFPS does hold a CODE value from a previously-processed associated message, then the sub-field CODE and its contents shall be automatically removed from that message and from the previously-processed associated message.

The following warning message:

COMMENT: INVALID AIRCRAFT ADDRESS (CODE) HAS NOT BEEN STORED PREVIOUS AIRCRAFT ADDRESS HAS BEEN REMOVED

shall be included in the ACK message.

The IFPS shall accept and process, for AFP messages, the CODE field (ICAO format) or the –ARCADDR field (ADEXP format) in order to enable ATC to:

Add the 24-bit aircraft address of the airframe when it is missing or

Amend the 24-bit aircraft address of the airframe when it is incorrect.

The presence of the CODE/ designator can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.






96 STAYINFO

(2) Requirements

The sub-field STAYINFO, followed by the appropriate sequence number (i.e. STAYINFOn) shall be inserted in the flight plan to provide information on those STAY indicators detailed in the route. The information provided is essential for ATC.

The sequence number of the sub-field STAYINFO shall correspond to the sequence number of the STAY indicator detailed in the route.

(3) Message Format

The sub-field shall be denoted with the letters STAYINFO followed by a sequence number ranging from 1 to 9 as appropriate, then ‘/’, followed by free text.

Example in ICAO format (Item 18)

…

-DOF/190513 PBN/B1D1 REG/FGFVO STAYINFO1/PHOTOGRAPHIC MISSION OVER LAKE EET/…)

Example in ADEXP format

-STAYINFO -STAYIDENT STAY1 -REMARK PHOTOGRAHIC MISSION OVER LAKE


The IFPS shall not perform a crosscheck between any sub-field STAYINFO indicators and any STAY indicators in the route.

The IFPS shall check that the sub-field STAYINFO has a sequence number ranging from 1 to 9 attached to it. Where such a sequence number is not found, that message fail automatic processing and be passed for manual treatment by the IFPS staff.






97 EUR/PROTECTED

(2) Requirements

Only those flights for which the details should only be available to a restricted audience (e.g. a security sensitive flight) shall use the EUR/PROTECTED indicator.

Those flights using EUR/PROTECTED shall not automatically qualify for exemption from flow regulations.

(3) Message Format

The sub-field shall be denoted with the letters EUR followed by a ‘/’, followed by PROTECTED.


Those messages that are syntactically and semantically correct shall be processed by the IFPS and transmitted to the ETFMS system, but shall not automatically qualify for exemption from relevant flow regulations unless one or more of the following STS indicators is present:

FFR, MEDEVAC, ATFMX, SAR, HEAD.

The EUR/PROTECTED indicator shall not appear in either the Operational Reply Messages or the distributed flight plan. It shall however be retained by the IFPS internal systems, in order to ensure protection of the archiving and log files.

It shall not be possible to remove the EUR/PROTECTED from the flight plan held by the IFPS by sending a modification message (CHG). To remove the EUR/PROTECTED it will be necessary to cancel the flight plan and re-file that flight plan without the EUR/PROTECTED indicator.

Request Flight Plan (RQP) messages relating to flight plans held by the IFPS that contain EUR/PROTECTED shall be presented for manual processing. The IFPS staff may only transmit a copy of that flight plan to the originator of the RQP when the flight plan originator has given authorisation, or where the requesting address is determined to be affected by the trajectory of that flight.

Note Normally only those ATS Unit(s) directly affected by the trajectory of the flight shall be authorised to receive the required information.






98 PBN (Performance Based Navigation)

(2) Requirements

Whenever a flight plan contains the equipment ‘R’ (PBN approved) in the Item 10a, the Performance Based Navigation (PBN) and/or the Required Navigation Performance (RNP) levels than can be met shall be specified in the Item 18 following the indicator PBN.

As the navigation levels that can be met are dependent on the aircraft equipment, the IFPS shall cross-check the content of the PBN sub-field with the navigation and approach aid equipment present in Item 10 as follows:

If any of the indicators B1, B2, C1, C2, D1, D2, O1 or O2 are filed, then a ‘G’ must be present in Field 10a.

If any of the indicators B1, B3, C1, C3, D1, D3, O1 or O3 are filed, then a ‘D’ must be present in Field 10a.

If either of the indicators B1 or B4 is filed, then either an ‘O’ or ‘S’ must be present and a ‘D’ must also be present in Field 10a.

If any of the indicators B1, B5, C1, C4, D1, D4, O1 or O4 are filed, then an ‘I’ must be present in Field 10a.

If any of the indicators C1, C4, D1, D4, O1 or O4 are filed, then a ‘D’ must be present in Field 10a.

(3) Message Format

The sub-field shall be denoted by the letters PBN followed by a ‘/’, then from one to eight of the following descriptors:

RNAV specifications:

A1 RNAV 10 (RNP 10)

B1 RNAV 5 all permitted sensors

B2 RNAV 5 GNSS

B3 RNAV 5 DME/DME

B4 RNAV 5 VOR/DME

B5 RNAV 5 INS or IRS

B6 RANV 5 LORANC

C1 RNAV 2 all permitted sensors

C2 RNAV 2 GNSS

C3 RNAV 2 DME/DME

C4 RNAV2 DME/DME/IRU

D1 RNAV 1 all permitted sensors

D2 RNAV 1 GNSS

D3 RNAV 1 DME/DME

D4 RNAV 1 DME/DME/IRU

RNP specifications:



L1 RNP4

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

T2 RNP AR APCH without RF


The IFPS shall accept the sub-field PBN indicator when it is present in a message submitted to the IFPS for processing.

Where multiple entries are found, and/or the content does not comply syntactically or semantically with the prescribed format, the IFPS shall fail that message from automatic processing.

Where a PBN descriptor is found, and the corresponding required equipment is not present in the Item 10a, the IFPS shall fail that message from automatic processing.

It shall be possible for a message originator to remove the sub-field PBN by sending a modification message (CHG). However the modification message (CHG) shall also remove the letter R from Item 10a. The modification message (CHG) shall contain all the previous Item 18 sub-fields except the PBN sub-field.

Any designator possible within PBN/ can be used as a condition in a RAD restriction. The condition, when satisfied or not sastified, may validate or invalidate the message.



99 Surveillance (SUR)

(2) Requirements

The sub-field SUR shall be used to indicate surveillance applications or capabilities not specified in the Item 10b.

(3) Message Format

The sub-field shall be denoted by the letters SUR followed by a ‘/’ and then free text to a maximum of 50 alphanumeric characters.


The IFPS shall check any sub-field SUR entries when it is present in a message submitted to the IFPS for processing. Whenever the message format does not comply with the prescribed format, that message shall fail automatic processing and be presented to an IFPS staff for manual treatment.


It shall be possible for a message originator to remove the SUR indicator by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the SUR sub-field.






100 Take-off Alternate (TALT)

(2) Requirements

It shall be possible to indicate for a flight take-off alternate aerodrome(s). That information shall be indicated in the sub-field TALT. It can be indicated either by the ICAO four letter location indicator(s) of the aerodrome(s) when it exits, or by the name(s) if no indicator is allocated. For aerodromes not listed in the relevant Aeronautical Information Publication (AIP), the location shall also be indicated (whenever possible) in latitude and longitude or in bearing and distance from the nearest significant point.

(3) Message Format

The sub-field shall be denoted by the letters TALT followed by a ‘/’, and then free text to a maximum of 100 characters detailing the take-off alternate aerodrome(s).

Examples TALT/EBAW EBLG

TALT/EBBR

TALT/TGL200008

TALT//BEELITZ 5240N1157E

TALT/5240N1157E


The IFPS shall accept the sub-field TALT indicator when it is present in a message submitted to the IFPS for processing.


Example

Input to IFPS: TALT/BIKF TALT/LFPG

Output by IFPS: TALT/BIKF LFPG

It shall be possible for a message originator to remove the TALT indicator from a message by sending a modification message (CHG). The modification message (CHG) shall contain all the previous Item 18 sub-fields except the TALT sub-field.






101 En-Route Delay or Holding (DLE)

(1) General

The en-route delay or holding enables a message originator to indicate for a flight, a planned en-route delay. As that information can be processed by ATS systems, the flight data in those systems becomes more accurate.

The IFPS provides also a similar feature, the en-route stay indicator (see section EN-ROUTE STAY INDICATOR). The en-route stay indicator may be used for submission concerning flights whose flight path remains entirely within IFPZ. The rationale for using the STAY as opposed to the DLE is the following:

The STAY is implemented within Item 15 where routeing/trajectory related information is extracted.

The use of Item 15 and STAY provides the ability to indicate a vertical deviation during the course of the activity.

The use of Item 15 and STAY provides the ability to indicate an area (between two points) where the activity will take place as opposed to a single point.

The use of Item 15 and STAY provides the possibility to indicate training activity taking place at an aerodrome (by associating the STAY indicator to the IAF), where a training flight may wish to make some practise approaches.

The use of Item 15 and STAY provides the ability to make a correct indication(s) for circular flights i.e. a flight which may pass overhead the ‘DLE/’ point more than once.

(2) Requirements

It shall be possible for a flight to indicate an en-route delay or a holding. Whenever along the flight path a delay is planned to occur at significant point the indication of that delay shall be present.

(3) Message Format

The sub-field shall be denoted by the letters DLE followed by a ‘/’, then a significant point or a significant point with bearing and distance or geographical coordinates, followed by an indication of a time period in hours and minutes. If the en-route delay or holding takes place at more than one location, each location shall be separated by a space (see 4th example below).

Examples: DLE/DUB0040

DLE/DUB1800400030

DLE/5340N00326E0120

DLE/5340N00326E0120 5440N00326E0030


The IFPS shall accept the sub-field DLE indicator when it is present in a message submitted to the IFPS for processing.


A DLE on a point found within Item 15 shall be used by IFPS in the elaboration of the calculated profile by adding the delay to the elapsed time for the route segment immediately following the DLE point.

If the point given in the DLE is found within Item 15 and that point is overflown more than once, then the delay shall be applied to the last occurrence.



If the point given in the DLE cannot be found within Item 15 and the Item 15 route contains one and only one ‘unknown’ portions (a portion outside the IFPZ, a VFR portion or an OAT portion) then the delay shall be applied to this unknown portion.

A DLE on a significant point shall only be accepted if that point is either explicitly indicated in Item 15 or is implicitly within a route portion identified in Item 15. An error shall be reported when all the following conditions are met:

The point is not present on the route (including SID/STAR) The route is entirely inside IFPZ or the point is a geographical coordinates. The route contains no OAT or VFR portions

It shall be possible to remove or modify the sub-field DLE by sending a modification message (CHG).



102 Additional Output by the IFPS

For messages distributed by the IFPS the following Item 18 indicators may be automatically inserted by the IFPS:

ORGN [see SECTION Originator (ORGN) Indicator] IFP [see SECTION IFP Indicators]

AWR [see SECTION Aircraft Operator What-if Re-Route (AOWIR)] SRC [see SECTION Source (SRC) Indicator]

DOF [see SECTION Date of Flight (DOF)]

A detailed description of these indicators is given in the relevant SECTION.






103 ITEM 19: Supplementary Information

(2) Requirements

It is required that accurate supplementary flight plan information for a flight shall be available in the event that an ATS Unit should require it. It shall be the responsibility of the aircraft operator to ensure that the supplementary flight plan information is available at all times according to the requirements of the relevant States.

Where supplementary flight plan information for any IFR/GAT flights, or parts thereof, operating within the IFPZ, is submitted to the IFPS in a flight plan or associated message, the IFPS shall accept that information and shall store the information in the IFPS database. Where the IFPS has received supplementary flight plan information, the IFPS shall transmit that information in the form of a SPL message upon receipt of an RQS message.

(3) Message Format

The supplementary information indicators that are to be used in the flight plan or associated message shall be organised into a string of elements separated by spaces and shall contain some or all parts of the supplementary information indicators. The supplementary information must always be filed after Item 18 elements.

Certain sub-fields are restricted in the number of characters in that sub-field; where this is the case, the details are given in the section relevant to that subject.

Example

E/0430 P/89 R/UV S/PDM J/LFU D/4 160 C ORANGE A/WHITE WITH GREEN TAIL N/EXTRA POLAR SURVIVAL EQUIPMENT CARRIED C/WILKINSON


Where supplementary information sub-field information is submitted to the IFPS in a flight plan or associated message, that information shall be stored within the IFPS database without transmitting the data in the flight plan output message. The sub-field information held by the IFPS shall be made available upon receipt of an RQS message.

The following elements shall be recognised by the IFPS as supplementary information sub-field indicators and shall be processed by the IFPS:

E/ total fuel Endurance expressed in hours and minutes.

P/ total number of Persons on board.

R/ emergency Radio

S/ Survival equipment.

J/ life Jackets.

D/ Dinghies.

A/ colour of the Aircraft and significant markings (this may include the registration).

N/ other survival equipment.

C/ pilot in Command.



103.1 General Procedures for errors in Item 19

Should a message submitted to the IFPS for processing fail automatic processing and be passed for manual treatment by the IFPS staff due to errors in any part of Item 19: Supplementary Information; the Standard Correction Procedure (SCP) 1 shall not be applied to that message, nor shall that message be subject to the Requirements laid out in the Quality of Submitted Messages. Where the departure aerodrome is outside the IFPZ, and no contact is possible with the message originator, the message shall not be rejected, so the following modifications to those sub-fields causing the errors may be necessary to ensure processing of that message:

Those sub-fields that contain the letters ‘TBN’ where such is not accepted shall have those letters removed.

Example E/TBN is corrected to E/

Those sub-fields containing non-standard characters shall have those characters removed.

Example R/VHF is corrected to R/V



104 Total Fuel Endurance: E/

(2) Requirements

The sub-field E shall be used to indicate the total fuel endurance of that flight.

The IFPS shall not check conformance with any fuel endurance requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter E followed by a ‘/’ then the time given for the fuel endurance in hours and minutes (HHMM).

Example E/0246


The IFPS shall check any sub-field E entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing where the required format is not followed.

Where the total number of characters in the sub-field exceeds the maximum allowed for the sub-field, the sub-field shall be automatically truncated by the IFPS to the allowed maximum length of 4.

It shall be possible for a message originator to remove the endurance details from a message by sending a modification message (CHG). The message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, is this case a deletion.






105 Total Number of Persons on Board: P/

(2) Requirements

The sub-field P shall be used to indicate the total number of persons on board that flight.

The IFPS shall not check conformance with any persons on board indication requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter P followed by a ‘/’ and then the number of persons on board that flight expressed in digits to a maximum of three.

Example P/23


The IFPS shall check any sub-field P entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing where the required format is not followed.

Where the total number of characters in the sub-field exceeds the maximum allowed for the sub-field, the sub-field shall be automatically truncated by the IFPS to the allowed maximum length of 3 characters.

It shall be possible for a message originator to remove the persons on board details from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, is this case a deletion.






106 Emergency Radio: R/

(2) Requirements

The sub-field R shall be used to indicate the emergency radio capabilities of that flight.

The IFPS shall not check conformance with any indication of emergency radio capability requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter R followed by a ‘/’ then the prescribed indicator or indicators, to a maximum of three, for the emergency radio capabilities of that flight.

The prescribed indicators for the emergency radio capabilities that shall be listed consecutively when more than one, of a flight are:

U if frequency 243.0 (UHF) is available.

V if frequency 121.5 (VHF) is available.

E if emergency location beacon-aircraft ELBA is available.

Example R/UVE


The IFPS shall check any sub-field R entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing where the required format is not followed.

It shall be possible for a message originator to remove the emergency radio capability details from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, is this case a deletion.






107 Survival Equipment: S/

(2) Requirements

The sub-field S shall be used to indicate the survival equipment capabilities of that flight.

The IFPS shall not check conformance with any indication of survival equipment capability requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter S followed by a ‘/’ then the prescribed indicator or indicators, to a maximum of four, for the survival equipment capabilities of that flight.

The prescribed indicators for the emergency radio capabilities that shall be listed consecutively when more than one, of a flight are:

P if polar survival equipment is carried.

D if desert survival equipment is carried.

M if maritime survival equipment is carried.

J if Jungle survival equipment is carried.

Example S/PM


The IFPS shall check any sub-field S entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing where the required format is not followed.

It shall be possible for a message originator to remove the survival equipment capability details from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, in this case a deletion.






108 Life Jackets: J/

(2) Requirements

The sub-field J shall be used to indicate the life jacket capabilities of that flight.

The IFPS shall not check conformance with any indication of life jacket capability requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter J followed by a ‘/’ then by one or more of the following indicators without spaces, to a maximum of four, for the life jacket capabilities of that flight.

The prescribed indicators for the life jacket capabilities that shall be listed consecutively when more than one, of a flight are:

L if the life jackets are equipped with lights.

F if the life jackets are equipped with fluorescent.

U if any life jacket radio is equipped with UHF on frequency 243.0 mHz.

V if any life jacket radio is equipped with VHF on frequency 121.5 mHz.

Example J/LFV


The IFPS shall check any sub-field J entries in messages submitted to the IFPS for processing. Where such entries are found, the IFPS shall check for compliance with the required format, and pass those messages for manual processing where the required format is not followed.

It shall be possible for a message originator to remove the life jacket capability details from a message by sending a modification message (CHG). That modification message (CHG) shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, in this case a deletion.






109 Dinghies: D/

(2) Requirements

The sub-field D shall be used to indicate the dinghy capabilities of that flight.

The IFPS shall not check conformance with any indication of life dinghy requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter D followed by a ‘/’, then one or more of the following, separated by single spaces:

2 Numerics giving the number of dinghies carried.

3 Numerics giving the total capacity, in persons carried, of all the dinghies.

C If dinghies are covered.

The colour of the dinghies.

Example D/3 60 C YELLOW


The IFPS shall check any sub-field D entries in messages submitted to the IFPS for processing.

Where the total number of characters in the sub-field exceeds the maximum allowed for the sub-field, the sub-field shall be automatically truncated by the IFPS to the allowed maximum length of 50 characters. Each sub-field of D/ shall be truncated to the number of allowed characters (e.g. 2 characters for the number of dinghies carried).

It shall be possible for a message originator to remove the dinghy capability details from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, in this case a deletion.






110 Aircraft Colour and Significant Markings: A/

(2) Requirements

The sub-field A shall be used to indicate the colour and significant markings of the aircraft making that flight.

The IFPS shall not check conformance with any indication of colour and significant markings of the aircraft requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter A followed by a ‘/’, then plain text indicating the colour and any significant markings of the aircraft.

Example A/WHITE WITH BLUE AND RED STRIPE AND GREEN TAIL


The IFPS shall check any sub-field A entries in messages submitted to the IFPS for processing.


It shall be possible for a message originator to remove the details of the colour and any significant markings of the aircraft from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, in this case a deletion.






111 Other Survival Equipment N/

(2) Requirements

The sub-field N shall be used to indicate any other survival equipment carried and any other useful remarks for that flight.

The IFPS shall not check conformance with any other survival equipment carried and any other useful remarks requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter N followed by a ‘/’, then plain text indicating any other survival equipment carried and any other useful remarks.

Example N/EXTRA POLAR SURVIVAL EQPT


The IFPS shall check any sub-field N entries in messages submitted to the IFPS for processing.


It shall be possible for a message originator to remove the details of any other survival equipment carried and any other useful remarks from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, in this case a deletion.


Where flight plans and associated messages submitted to the IFPS for processing contain errors in the sub-field N, those messages shall not be rejected by the IFPS.






112 Pilot in Command: C/

(2) Requirements

The sub-field C shall be used to indicate the name of the pilot in command of that flight.

The IFPS shall not check conformance with any other pilot in command requirements published by National Authorities.

(3) Message Format

The sub-field shall be denoted with the letter C followed by a ‘/’, then plain text indicating the name of the pilot in command.

Example C/WILKINSON


The IFPS shall check any sub-field C entries in messages submitted to the IFPS for processing.


It shall be possible for a message originator to remove the details of the pilot in command from a message by sending a modification message (CHG). That message shall contain the complete Item 19 as it was stored in IFPS, including the intended modification, in this case a deletion.


Where flight plans and associated messages submitted to the IFPS for processing contain errors in the sub-field C, those messages shall not be rejected by the IFPS.






113 Message Types

(2) Requirements

The IFPS shall accept and process the following message types relating to IFR/GAT flights or parts thereof intending to operate within the IFPZ:

FPL, CHG, DLA, CNL, DEP, ARR, RQP, RQS, FNM, MFS, AFP and AMOD.

After processing these messages, the IFPS shall distribute the following message types:

FPL, CHG, DLA, CNL, DEP, ARR, ACK, MAN, REJ, SPL, ACH, APL.

Note SPL messages are only manually created by the IFPS staff, and are not automatically generated by the IFPS.

It is strongly recommended that the Date of Flight (DOF) is included in all flight plans and associated messages submitted to the IFPS for processing.


Message matches multiple flight plans.

Where more than one flight plan exists in the IFPS database with the same callsign, departure aerodrome and destination aerodrome (e.g. the same flight on consecutive days), it is possible that the IFPS will be unable to automatically associate any subsequent messages with the correct flight plan.

Where such ambiguity exists, the subsequent message shall fail automatic processing and be passed for manual treatment by the IFPS staff.

In order to minimise the possibility of subsequent messages associating with multiple existing flight plans, message originators are strongly recommended to include the EOBT and date of flight in all associated messages submitted to the IFPS for processing.






114 Flight Plan (FPL)

(1) General

This section summarises the requirements for flight plan messages (FPL). More details as well as the possible errors raised during IFPS processing and the corresponding procedures may be found in the relevant sections of this manual.

(2) Requirements

All flight plans for IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be submitted to the IFPS for processing. Submissions should, as far as possible, be made at least 3 hours prior to the EOBT of that flight.

The IFPS shall not accept flight plans filed more than 120 hours (5 days) prior to the estimated off-block date and time compared to the IFPS processing time.

If a flight plan is filed more than 24 hours in advance of the estimated off-block time of the flight to which it refers, the date of the flight departure shall be inserted in Item 18 of the flight plan.

It shall not be possible to modify certain key fields within a flight plan, as these fields are used for message association purposes.

These non-modifiable key fields are:


Aerodrome of Destination. Estimated Off-Block Date (as a direct modification to the DOF sub-field).

To change any of these items, it shall be necessary to cancel the original flight plan and re-file a new flight plan containing the corrected data. The RFP procedure shall not be used for such changes.

Apart from the above key fields, flight plans may be modified by sending a modification message (CHG) or a delay message (DLA). The IFPS also accepts the modification of a flight plan by submitting another flight plan (with a different route for example) providing that the message originator is the same and that the key fields and the EOBT are identical. It is not permitted by IFPS to update the EOBT by means of a FPL. Modification of the EOBT shall only be possible by sending a DLA or CHG message.

All flights intended to operate or operating as general air traffic in accordance with instrument flight rules within the airspace defined by the ICAO EUR region shall comply with the Commission Regulation (EC) No 1033/2006 of 4 July 2006 laying down the requirements on procedures for flight plans in the pre-flight phase for the single European sky.

This Regulation lays down the requirements on procedures for flight plans in the pre-flight phase in order to ensure the consistency of flight plans and associated update messages between operators, pilots and air traffic services units through the Integrated Initial Flight Plan Processing System, either in the period preceding the first delivery of air traffic control clearance for flights taking off from within the airspace covered by this Regulation or in the period preceding entry into that airspace for other flights.

This Regulation shall apply to each of the following parties involved in the submission, modification, acceptance and distribution of flight plans:

Operators and agents acting on their behalf; Pilots and agents acting on their behalf; Air traffic services units providing services to general air traffic flying in accordance with

instrument flight rules.



The means of compliance to this regulation can be found in the Eurocontrol Specification for the Initial Flight Plan.

Operators of IFR/GAT flights or parts thereof intending to operate within the IFPZ shall be aware and

comply with the requirements laid down in the following documents, including this manual:

ICAO 4444 Air Traffic Management ICAO 7030 Regional Supplementary Procedures, EUR region Commission Regulation (EC) No 1033/2006 Eurocontrol Specification for the Initial Flight Plan

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32006R1033:EN:NOT



115 Modification (CHG)

(2) Requirements

Within the parameters specified in ICAO Annex 2, any changes to a previously submitted flight plan for an IFR/GAT flight or part thereof operating within the IFPZ shall be submitted to the IFPS for processing.

It shall not be possible to modify certain key fields within a flight plan, as these fields are used for message association purposes.

These non-modifiable key fields are:


Aerodrome of Destination.

Estimated Off-Block Date (as a direct modification to the DOF sub-field).

To change any of these items, it shall be necessary to cancel the original flight plan and re-file a flight plan containing the corrected data. The RFP procedure shall not be used for such changes.

(3) Message Format

All modification messages (CHG) submitted to the IFPS for processing shall contain an opening bracket, the message title, aircraft identification, departure aerodrome and estimated off-block time, arrival aerodrome, a correctly formatted Item 18, Item 22 containing the content of the change and a close bracket.

For the IFPS the preferred option for the Item 18 is the insertion of the DOF as it can be used for association purposes.

Each item submitted in a modification message to update existing data shall be prefixed by a hyphen and the item number for that item. Any number of items may be updated in a single modification message.

In case of update of any Item 18 sub-field via Item 22, the whole Item 18 shall be inserted in the modification message including the intended change as the IFPS completely overwrites the previous Item 18 content.

Example

Original flight plan held by the IFPS:

(FPL-ABC345-IG

-MD90/M-SRGWY/S

-EGLL1200

-N0430F330 BPK M185 CLN UL620 ARTOV UP44 SOMVA UP155 ANDIK UN873 JUIST UP729 DOSUR P729 TUDLO

-EKCH0130

- PBN/B2 DOF/121126 REG/GBAWC RMK/FERRY FLIGHT )

Messages submitted to the IFPS for processing for a change of aircraft type and registration and equipment:

(CHG-ABC345-EGLL1200-EKCH-DOF/121126-9/A321/M-10/ SRDGIWY/S-18/ PBN/B1 DOF/121126 REG/GBHTC RMK/FERRY FLIGHT)



Note ‘DOF/121126’ represents the correctly formatted Item 18 and the Item 18 from the stored flight plan is completely repeated inside the item 22 and contains the change of aircraft registration and change of PBN.

Note When updating certain items of a flight plan, it is necessary to consider any impact on other Items in that flight plan. For example, where an aircraft type and the requested cruising flight level are updated, the equipment and PBN of that new aircraft should also be replaced, as should the registration (where filed), and any route amendments resulting from the revised cruising flight level should also be included in a new route description.


The IFPS shall automatically process those modification messages (CHG) that are syntactically and semantically correct and associate with a single valid flight plan in the IFPS database.

The Estimated Off-Blocks Time (EOBT) of an existing flight plan may be updated using a modification message; however, the same constraints that apply to delay messages also apply to those modification messages that intend to modify the EOBT. Those constraints are that the IFPS shall not accept:

A ‘negative delay’, i.e. a new EOBT that is earlier than the existing EOBT in the flight plan.

A new EOBT, which is more than 20 hours in the future compared to the existing EOBT in the flight plan.

A new EOBT, which is in the past compared to the current IFPS time at the time the message is processed.

Note The existing EOBT in the flight plan is the original EOBT given in the flight plan plus any subsequent updates that have been processed by the IFPS.

Example

(CHG-ABC567-EGLL1500-KJFK-DOF/090503-13/EGLL1545)

This shall have the same effect as submitting a delay message:

(DLA-ABC567-EGLL1545-KJFK-DOF/090503)

An ACK message for a CHG containing an EOBT update may hold the following comment:

-COMMENT THE EOBT UPDATE HAS CAUSED AN OVERLAP WITH A FPL WITH SAME

ARCID AND OVERLAPPING FLYING PERIOD

The comment is present when the following conditions are met:

Before the CHG submission, IFPS holds two valid flight plans with the same ARCID and no overlapping flying period between the 2 flight plans.

A CHG updating the EOBT is sent for the earlier flight.

The new EOBT contained in the CHG triggers an overlapping flying period with the later flight.

The comment aims at informing the message originator/aircraft operator of the situation resulting from the treatment of the CHG message.

Where a flight plan submitted to the IFPS for processing associates with an existing flight plan, any differences (except for the EOBT, see note below) in the second flight plan shall be considered and treated by the IFPS as changes. The IFPS shall accept that second flight plan and after processing, output any changes to the existing processed flight plan as a modification message (CHG).

Note Where a second flight plan is submitted to update an existing flight plan, it is not possible to update the existing EOBT. Such submission will be rejected with the error EFPM401: NOT ALLOWED TO USE A FPL TO UPDATE THE EOBT. DLA OR CHG IS REQUIRED.



The submission of a second flight plan should not be considered a legitimate means of updating an existing flight plan; the correct procedure to update an existing flight plan held by the IFPS should be through the use of a modification or delay message.

As both CHG and DLA can be used to modify the EOBT, and both messages shall contain a correctly formatted Item 18, for which IFPS preferred option is that it contains the DOF, the following processing is recommended when the EOBT of the flight plan is delayed across (00:00) midnight UTC:

Example

The stored FPL has an EOBT at 2300 with a DOF/120615. A delay occurs to the flight plan and the new planned EOBT is 01:00, therefore on the following day (16th): the modification message shall read (including a change of Item 18 to notify the change of DOF):

(CHG-ABC123-LFPG2300-LFBO-DOF/120615-13/LFPG0100-18/PBN/B2C2S1 DOF/120616 REG/FBPCG)

or the DLA:

(DLA-ABC123-LFPG0100-LFBO-DOF/120615)

If a further delay is needed, the DOF to be inserted in the CHG or DLA message shall be the one of the last EOBT (where the DOF/ represents the correctly formatted Item 18):

(CHG-ABC123-LFPG0100-LFBO-DOF/120616-13/LFPG0130)


If a modification message submitted to the IFPS for processing does not contain the estimated off-block time (EOBT) after the aerodrome of departure, the IFPS shall not raise an error, but the EOBT will be automatically inserted in the output by IFPS.

The IFPS shall output field 18 containing only the DOF/ upon successful processing of a modification message (CHG) regardless of the content of Item 18 in the incoming message.






116 Delay (DLA)

(2) Requirements

The IFPS shall accept those delay messages that are not more than 20 hours in advance of the current EOBT held for the flight plan and not less than the current system time at the time the message is processed.

Any delay of more than 15 minutes and less than 20 hours for an IFR/GAT flight or part thereof operating within the IFPZ shall be submitted to the IFPS for processing.

The IFPS shall not accept a delay of more than 20 hours in advance of the current EOBT held for the flight.

The IFPS shall not accept any delay that is a negative time compared to the current system time at the time of processing that delay message by the IFPS.

Submission for Flights Issued with ATFCM Slot

For those flights that have been issued with an ATFM Slot, a detailed description of the procedures for submitting a delay message is available in the ATFCM Users Manual.

(3) Message Format

The delay message shall contain an opening bracket, the message title, departure aerodrome, requested new estimated off-blocks time, destination aerodrome, and a correctly formatted Item 18 and close bracket.


Example

(DLA-ABC567-EGLL1545-KJFK-DOF/090305)

An existing EOBT may also be delayed using a modification message.

When a delay to a flight modifies the EOBT and that new EOBT passes across midnight UTC (00:00), it is recommended to use a modification message (CHG) over a DLA.

Example

The stored FPL has an EOBT at 2300 with a DOF/120615.

A delay occurs to the flight plan and the new planned EOBT is 01:00, therefore on the following day (16th): the modification message (CHG) shall read (including a change of Item 18 to notify the change of DOF):

(CHG-ABC123-LFPG2300-LFBO-DOF/120615-13/LFPG0100-18/PBN/B2C2S1 DOF/120616 REG/FBPCG)

or a DLA:


If a further delay is needed, the DOF to be inserted in the CHG or DLA message (where the DOF/ represents the correctly formatted Item 18), shall be the one of the last EOBT:

(CHG-ABC123-LFPG0100-LFBO-DOF/120616-13/LFPG0130)





The IFPS shall automatically process those delay messages that are syntactically and semantically correct and associate with a single valid flight plan in the IFPS database.

On receipt of a delay message that is not earlier than system time at the time that message is processed by the IFPS, and not more than 20 hours in advance of the current EOBT of the flight, the IFPS shall re-calculate the profile of that flight based on the revised EOBT. The IFPS shall automatically reject any delay message that does not respect these time parameters.

When re-calculating the flight profile using the revised EOBT, the IFPS shall apply the route and airspace availability checks relevant to that flight. Where any unavailable items are found, that message shall fail automatic processing and be passed for manual processing by the IFPS staff. This may also be a result of delay messages that take the flight into a new AIRAC or a new conditional route availability period.

Where the EOBT of a flight is to be changed to an earlier time, the existing flight plan shall be cancelled, and a new flight plan containing the revised EOBT shall be submitted to the IFPS for processing (see ATFCM Users Manual).

Where the processing of a delay message must be forced by the IFPS staff, appropriate IFP indicators shall be attached to that message.

The IFPS shall output Item 18 containing only the DOF/ upon successful processing of a DLA message regardless of the content of Item 18 in the incoming message.

An ACK message for a DLA may contain the following comment:

-COMMENT THE EOBT UPDATE HAS CAUSED AN OVERLAP WITH A FPL WITH SAME

ARCID AND OVERLAPPING FLYING PERIOD

The comment is present when the following conditions are met:

Before the DLA submission, IFPS holds two valid flight plans with the same ARCID and no overlapping flying period between the 2 flight plans.

A DLA is sent to update the EOBT of the earlier flight. The new EOBT contained in the delay triggers an overlapping flying period with the later flight.

The comment aims at informing the message originator/aircraft operator of the situation resulting from the treatment of the DLA message.

116.1 General Procedure for DLA Message Raises Route Availability or RAD Problems

Error message ref. Various possible errors

Explanation: A delay message may push a previously correct flight plan into periods of route unavailability, or raise RAD errors caused by a switch between week and weekend RAD routes, that take place within the time difference between the original EOBT and the revised EOBT in the delay message.

Instruction: The IFPS staff shall apply SCP1.

116.2 General Procedure for Difficulties in Processing DLA Messages due to AIRAC Switch

Error message ref. Various possible errors



Explanation: It is possible for a flight with a date of flight of AIRAC – 1 to be delayed through into the new AIRAC, and this may create route problems where data from the first DOF is no longer valid for the new delayed DOF. Where this happens, the DLA message will go for manual processing, giving an error indicating route problems.

Instruction: The IFPS staff may convert the original DLA message into a modification message (CHG) containing information to update the new EOBT, plus route information to correct the route to the new AIRAC data. The IFPS staff shall apply SCP1 to any necessary route updates.






117 Cancel (CNL)

(2) Requirements

A flight plan Cancellation (CNL) message shall be submitted to the IFPS for processing for any flight plan that has been submitted to and processed by the IFPS and is subsequently to be cancelled.

Where key field data is required to be changed, the existing processed flight plan shall be cancelled and a new flight plan containing the revised data shall be submitted to the IFPS for processing. An exception to this rule is where an EOBT is to be delayed to a later time, in which case the flight plan may be updated with a delay or a modification message, rather than the flight plan be cancelled and re-filed with the later EOBT.

(3) Message Format

All cancel messages submitted to the IFPS for processing shall contain an opening bracket, the message title, aircraft identification, departure aerodrome and estimated off-block time, arrival aerodrome, a correctly formatted Item 18 and a close bracket.

For the IFPS, the preferred option for the Item 18 is the insertion of the DOF as it can be used for association purposes.

Example

(CNL-ABC567-EGLL1500-KJFK-DOF/130503)


The IFPS shall automatically process those cancellation messages that are syntactically and semantically correct and associate with a single valid flight plan in the IFPS database.

Where more than one flight plan exists with which the cancel message may associate, the IFPS shall invalidate that cancel message and raise an error indicating that the cancel message may associate with more than one existing valid flight plan.

Where the IFPS holds no valid flight plan with which the submitted cancel may associate, the IFPS shall reject that cancel message with an error indicating such.

If a CNL message submitted to the IFPS for processing does not contain the estimated off-block time (EOBT) after the aerodrome of departure, the IFPS shall not raise an error, but the EOBT will be automatically inserted in the output by IFPS.

The IFPS shall output Item 18 containing only the DOF/ upon successful processing of a CNL message regardless of the content of Item 18 in the incoming message.



117.1 General Procedure for Multiple Associated Message Window containing a CNL Message


Explanation: It is possible for the IFPS staff to be presented with a multiple associated message window containing a cancellation message following a flight plan. This is due to the cancellation message being submitted to the IFPS before the associated flight plan has been processed, and is more commonly found in times of heavy traffic. To successfully process and distribute a flight plan, closely followed by an associated cancellation is time consuming for the IFPS staff and potentially confusing for those in receipt of both messages.

Instruction: Two main scenarios may be encountered:

FPL – CNL – FPL are presented in the same window for manual processing. The IFPS staff shall reject the first FPL and the CNL, then process the second FPL.

FPL – CNL are presented in the same window for manual processing. The IFPS staff shall first check for any existing associated flight plans held by the IFPS; if one is found, then an attempt shall be made to contact the message originator to clarify which flight plan they wish cancelled.

Where no contact is possible, or where no existing associated flight plan is found, both invalid messages shall be rejected.



118 Departure (DEP)

(2) Requirements

A Departure (DEP) message should be submitted to the IFPS for processing for any IFR/GAT flight or part thereof operating within the IFPZ when it is required by the National Authority under whose authority the departure aerodrome lies.

(3) Message Format

The departure message submitted to the IFPS for processing shall contain an opening bracket, the message title, aircraft identification, departure aerodrome and actual time of departure, arrival aerodrome, a correctly formatted Item 18 and a close bracket.


The actual time of departure shall be expressed in 4 numbers, in the format HHMM.

Example (DEP-ABC567-EGLL1507-KJFK-DOF/130503)


The IFPS shall accept a departure message for any existing flight plan provided the departure time indicated in the message is not in the future when compared to the system time at the time of processing. Where the departure time is indicated to be in the future, such messages shall be automatically rejected by the IFPS.

The IFPS shall output Item 18 containing only the DOF/ upon successful processing of a DEP message regardless of the content of Item 18 in the incoming message.






119 Arrival (ARR)

(2) Requirements

Where an Arrival message (ARR) is required for an IFR/GAT flight or part thereof operating within the IFPZ, the appropriate air traffic services unit shall submit such to the IFPS for processing.

Where an IFR/GAT flight or part thereof operating within the IFPZ diverts to an aerodrome other than that indicated as the arrival aerodrome in the processed flight plan, that flight shall have an arrival message submitted by the appropriate air traffic services unit to the IFPS for processing.

(3) Message Format

Message Format – ARR

The arrival message submitted to the IFPS for processing shall contain an opening bracket, the message title, aircraft identification, departure aerodrome and estimated off-block time, arrival aerodrome and actual time of arrival and a close bracket.

It is strongly advised that the message also contains the date of flight, separated from the destination aerodrome by a hyphen, in order to make more accurate message association.

Examples (ARR-ABC567-EGLL1400-KJFK2207)

(ARR-ABC567-EGLL1400-KJFK2207-DOF/090503)

Message Format – Diversion Arrival

The diversion arrival message submitted to the IFPS for processing shall contain the message title that shall be ARR, aircraft identification, departure aerodrome and estimated off-block time, original planned destination aerodrome, and actual destination aerodrome and actual time of arrival.

Note The use of the term ‘DIVARR’ as a message title shall not be accepted by the IFPS, as this is not a recognised ICAO message title.

It is strongly advised that the message also contains the date of flight, separated from the destination aerodrome by a hyphen, in order to make more accurate message association.

Examples (ARR-ABC567-EGLL-KJFK-BIKF1807)

(ARR-ABC567-EGLL-KJFK-BIKF1807-DOF/090503)


On processing an arrival message, the IFPS shall distribute that message to the aerodrome control tower, approach and ATS reporting office of the aerodrome of departure where that aerodrome has specified a requirement to receive such messages, and is located within the IFPZ. The IFPS shall also send a copy of that arrival message to any extra addresses included in the re-addressing function.

On processing a diversion arrival message, the IFPS shall distribute that message to all ATC units that have been calculated in the processing of the associated flight plan, also to any extra addresses included in the re-addressing function.

In addition, the IFPS shall also close the associated flight plan, at which point the flight plan data shall become inaccessible outside the IFPS.

If an ARR message or diversion arrival message submitted to the IFPS for processing does not contain the estimated off-block time (EOBT) after the aerodrome of departure, the IFPS shall not raise an error, but the EOBT will be automatically inserted in the output by IFPS.



119.1 General Procedure for Diversion ARR Message


Explanation: Diversion messages titled ‘ARR’ may be received for those flights that have diverted to another aerodrome than that given as their flight-planned destination.

If any scheduled Transmit events exist in the future for the associated flight plan, that diversion ARR message shall not automatically close the flight plan in the IFPS.

Instruction: Where a diversion arrival message is received in the IFPS with the message title ‘ARR’, the IFPS staff shall check for any scheduled Transmit events in the future for the associated flight plan.

Where such an event is identified, after processing the diversion ARR message, the IFPS staff shall delete the associated flight plan, and contact the ATFCM staff to deactivate the original flight plan held in the ETFMS.

119.2 General Procedure for DIVARR Message Treatment


Explanation: Messages titled ‘DIVARR’ may be received for those flights that have diverted to another aerodrome than that given as their flight-planned destination.

Instruction: Where a diversion arrival message is received in the IFPS with the message title ‘DIVARR’, the IFPS staff shall correct the title to ‘ARR’.

If any subsequent errors are raised, the IFPS staff shall apply SCP1.

On processing the message, the IFPS staff shall contact the ATFCM staff and request them to delete that flight plan from the ETFMS.



120 Request Flight Plan (RQP)

(2) Requirements

A Request Flight Plan (RQP) message shall be submitted to the IFPS when an external user wishes to obtain flight plan data for an IFR/GAT flight or part thereof operating within the IFPZ. Where the IFPS holds (a) processed flight plan(s) matching the request, the IFPS shall return a copy of that/these flight plan(s) to the originator of the RQP except where the flight plan(s) is/are in a protected status.

(3) Message Format

The request flight plan message submitted to the IFPS for processing shall contain an opening bracket, the message title, aircraft identification, departure aerodrome (and optionally the estimated off-block time if known precisely, as it can be used for association purposes), arrival aerodrome, a correctly formatted Item 18 and a close bracket.

For the IFPS the preferred option for the Item 18 is the insertion of the DOF (as it can be used for association purposes).

The RQP message shall be sent to both IFPS units, regardless of the aerodrome of departure.

Example: (RQP-ABC567-EGLL-KJFK-DOF/130503)

(RQP-ABC567-EGLL1500-KJFK-DOF/130503)


The IFPS shall automatically process those RQP messages that are syntactically and semantically correct and that associate with (a) valid flight plan(s) in the IFPS database except those RQP messages that relate to flights using the EUR/PROTECTED function.

Where the IFPS receives an RQP message for (an) identifiable flight(s), it shall send a copy of that/these flight plans to the originating address of that RQP message. Identifiable flight(s) is/are determined by looking at the following fields:

ARCID, ADEP, EOBT (if present), ADES, DOF (if present).

If the RQP matches a single flight plan in the IFPS valid flight plan database, then the RQP originator shall receive a single flight plan.

If the RQP matches more than one flight plan in the IFPS valid flight plan database, then the following logic shall be used:

The RQP shall only associate to those valid flight plans that have an EOBT up to 6 hours in the future when compared to the IFPS system time at the time of processing of the RQP.

If all matching flight plans have and EOBT later than 6 yours when compared to the IFPS system time at the time of processing of the RQP, then the RQP shall associate to all of them.

Therefore, when an RQP matches more than one flight plan, the RQP originator may receive one or several flight plan(s).

The IFPS shall indicate that the transmission of that/these flight plan(s) is a result of a request flight plan in the SRC sub-field of that transmitted flight plan by the insertion of ‘RQP’ therein.

Note Where an RQP associates with an identifiable flight that has been modified at any stage by an ATC-generated message (AFP, FNM or MFS), then the IFPS shall output a message type APL, and that message shall contain a comment in the Item 18 sub-field RMK ‘APL IS AN FPL UPDATED BY ATC’



Where the IFPS receives an RQP message for an identifiable flight that is using the EUR/PROTECTED function, that message shall be passed to the IFPS staff for evaluation.

Transmission of flight plans containing EUR/PROTECTED shall only be made in accordance with internal procedures to verify the relevance of the flight to the authority requesting the flight plan.

If an RQP message submitted to the IFPS for processing does not contain the estimated off-block time (EOBT) after the aerodrome of departure, the IFPS shall not raise an error, but the EOBT will be automatically inserted in the output by IFPS. The IFPS shall automatically reject those RQP messages that are not syntactically correct as well as those RQP where no matching flight plan(s) are found in the IFPS database.

In some cases, where the IFPS finds a matching flight plan (based on the aircraft identification (ARCID) only and ADEP and ADES from the RQP do not match), the RQP is automatically rejected with the following comment:

-COMMENT THIS MESSAGE HAS BEEN REJECTED AUTOMATICALLY

-COMMENT FPL does exist for ABC123 EBBR1710 LIMF0125 DOF/121015



121 Request Supplementary Flight Plan (RQS)

(2) Requirements

A request supplementary flight plan message shall be submitted to the IFPS when an ATS unit wishes to obtain supplementary flight plan data for an IFR/GAT flight or part thereof operating within the IFPZ.

(3) Message Format

The request supplementary flight plan message submitted to the IFPS for processing shall contain an opening bracket, the message title, aircraft identification, departure aerodrome and estimated off-block time, arrival aerodrome, a correctly formatted Item 18 and a close bracket.


Example: (RQS-ABC567-EGLL1500-KJFK-DOF/130503)


Where the IFPS receives a message titled RQS, that message shall be invalidated and shall be presented to an IFPS staff with a warning: GEN277: MESSAGE REQUIRES SPECIAL HANDLING.

RQS messages have the highest priority in the IFPS invalid messages queue.






122 Airborne Message Types

(1) General

The IFPS shall accept and process the following message types from ATC sources relating to IFR/GAT flights or parts thereof operating within the IFPZ:

FPL with source AFIL, AFP, FNM and MFS.

After processing these messages, the IFPS shall distribute the following message types:

APL, ACH, and FPL with source AFIL.

Invalid airborne flight messages may be rejected according to IFPS procedures.

Wherever possible, the IFPS shall process those messages relating to flights already airborne. The purpose of processing these types of message is to allow the IFPS to provide the ETFMS and those ATC Units downstream of the reported change with updated information on the predicted trajectory of the flight.

The types of flights concerned with airborne update messages are:

Flights with a significant change of trajectory, whether track, level, time or destination. Flights with a significant change whether aircraft being different from the filed FPL, flight

type/flight rules, or aircraft equipment.

Flights for which the relevant ATC Units do not have any details.

When processing messages containing clearance limits and/or estimate points, the IFPS shall not change those points in any way.

Where no route details are given between two points in a cleared route submitted to the IFPS for processing, the IFPS shall assume the route to be direct (DCT), and shall insert either DCT, regardless of any maximum DCT limit errors, or the appropriate airway designator where both points are on the same airway.

From the clearance limit onwards, the IFPS staff shall, if necessary, construct a logical route to connect that cleared route either with the existing route as previously filed or with the destination or with the point at which that flight leaves the IFPZ, taking into account in all the cases any restrictions such as RAD and route availability. Where no associated filed flight plan exists, the IFPS staff shall construct a logical route to connect that cleared route either with the destination or with the point at which that flight exits the IFPZ also taking into account any restrictions such as RAD and route availability.

Requests are sometimes received from message originators or aircraft operators to make modifications to the route of flight plans that are airborne. On receipt of such a request, IFPS staff should advise the originator that flight plan modifications can only be made by ATC once a flight is airborne, using the AFP procedure.

(3) Message Format

The message format for each type of airborne message is described in detail in the relevant section for that message type.


The IFPS shall check to ensure airborne messages update or create flight plans with time and date information representative of the current system time. This ensures:

Flight plans are not updated with time data causing immediate closure. Airborne message ETO data are realistic with respect to the current real world time.



Airborne messages are rejected when filed well outside the possible time the flight could have been flying.

The comparisons are based upon the EOBT value (for flight plans with source AFIL) and the ETO over an ‘entry’ point for the remaining airborne messages.

FNM, MFS and AFP Message

FNM, MFS and AFP messages can be filed containing any time value as an ETO, (i.e. 0000 to 23:59). From the given ETO the system creates two time values, one 12 hours in the future the other 12 hours in the past. A check is then made to determine which of the time values lies closest to the current system time. The date for the ETO becomes today minus 1 hour if the closest time lies in the past and today or today plus 1 hour if the time lies in the future.

Flight Plans with source AFIL

The EOBT is used to determine if a flight plan with source AFIL violates timing constraints. Flight plans with source AFIL may be filed with an EOBT up to 23 hours and 55 minutes in the past and 24 hours and 05 minutes in the future. Exceeding these limits generates an error that cannot be ignored by the IFPS staff. Such wide tolerances can lead to peculiar filing situations, e.g.

The flight plan with source AFIL may be filed outside the EET of the flight; conceptually this implies the flight plan was filed before the calculated time at the first point on the route, hence the pilot could not have been airborne when the message was filed.

Filing in the past can lead to the calculated arrival time lying in the past; again implying the pilot has landed his aircraft before filing the message.

Note The EOBT field in the context of a flight plan with source AFIL is not the EOBT but the ETO at the first point given in the route. Throughout the IFPS Users Manual, where reference is made to the EOBT within the context of a flight plan with source AFIL, that EOBT shall refer to the ETO at the first route point.


When processing messages containing clearance limits and/or estimate points, the IFPS shall not change those points in any way.

Where no route details are given between two points in a cleared route submitted to the IFPS for processing, the IFPS shall assume the route to be direct (DCT), and shall insert such, regardless of any maximum DCT limit errors.

Where the route given in the submitted message is incomplete or incorrect, a logical and correct route shall be built by the IFPS using the propose route function to connect the last point given in the message route to the destination aerodrome or to the original route or to the point at which that route leaves the IFPZ.

The route given in the message before the AFPEND indicator shall not be modified in any way, regardless of any contained errors, but any route built to connect the last point in the message to the destination aerodrome or to the original route or to the point at which that route leaves the IFPZ must, wherever possible, ensure compliance with all relevant RAD and route availability restrictions or DCT limitations.

The applicable mode for airborne message processing may be set from manual to automatic and vice versa. In the manual mode, the IFPS shall build a route as described above but shall systematically present the message for manual review by the IFPS staff. In this case, the IFPS staff shall check the relevance of the proposed route before applying the message.



When in the automatic mode, the IFPS shall build a route as described above but whenever the message is compliant with processing parameters it shall be automatically processed.

In the event that the IFPS propose route function is unable to build a correct route, the message shall be presented for manual processing. In such cases, from the clearance limit onwards, the IFPS staff shall, if necessary, construct a logical route to connect that cleared route either with the existing route as previously filed or with the destination. Where no associated filed flight plan exists, the IFPS staff shall construct a logical route to connect that cleared route either with the destination or with the point at which that flight exits the IFPZ.

Where the message relates to a military flight, regardless of whether the automatic route-building by the IFPS is successful or not, to allow for any necessary confirmation of diplomatic clearances, that message shall be passed to the IFPS staff with a warning message.

Those AFP messages submitted to the IFPS for processing that relate to valid flight plans held by the IFPS, or that provide information on a previously unknown IFR/GAT flight or part thereof operating within the IFPZ may be rejected according to general or specific IFPS procedures.

Under normal circumstances, the IFPS staff shall not contact ANSPs to ask for information to resolve AFP message issues unless there is no valid FPL data held in the IFPS for that flight.

122.2 General Procedure for Errors in the submitted Airborne Message Route


Explanation: Where an airborne message is submitted to the IFPS as a result of a missing flight plan or revised trajectory, the route given in the submitted message may contain errors in RAD, 8.33kHz, route availability or RVSM.

Instruction: Any errors that are raised for that part of the route given in the AFP (before the AFPEND indicator) shall be automatically ignored by the IFPS.

The automatic placing of the AFPEND indicator shall not be modified or removed by IFPS staff.






123 Air-Filed Flight Plans (AFIL)

(1) General

Air Filed Flight plans (AFIL) represent flight plans submitted by an ATS unit to the IFPS for processing on behalf of an aircraft already in flight.

(2) Requirements

The IFPS shall accept those flight plans submitted for aircraft already in flight. The route details given in such messages shall be considered an ATC clearance, and the IFPS staff shall make no manual modifications to the given route, regardless of any indicated errors.

Where the route details given in the message submitted to the IFPS for processing do not connect to the destination aerodrome, the IFPS staff shall construct a logical route to that destination from the last point in the given route.

(3) Message Format

An air-filed flight plan submitted in ICAO format shall use the same format as a standard flight plan except the departure aerodrome shall contain the letters ‘AFIL’, and the message should contain the sub-field DEP/ followed by the ICAO four-letter location indicator of the location of the ATS unit from which supplementary flight plan data can be obtained

The time given in the message that would normally be the EOBT of that flight shall instead indicate the ATO/ETO of the estimate point given in the route of that flight plan.

Example

ICAO format (FPL-ABC789-IG

-BE9L/L-SRGWY/S

-AFIL1207

-N0285F230 CPT L9 MALBY

-EGFF0025

-DEP/EGTT PBN/B2)

An AFIL may also me submitted in ADEXP format:

ADEXP format -TITLE IFPL

-ADEP AFIL

-ADES LEMG

-ARCID ABC987

-ARCTYP C560

-CEQPT RWYUSDGH

-AFILDATA –PTID HIJ –FL F190 –ETO 130106130400

-EOBD 130106

-EOBT 1245

-TTLEET 0119

-EETPT MOLIN 0119



-SEQPT C

-SSRCODE A6034

-STS STATE

-PBN B2

-WKTRC M

-FLTRUL I

-FLTTYP G

-ALTRNT1 LEGT

-ROUTE N0350F200 HIJ A857 SVL


The IFPS shall accept those flight plan messages with source AFIL and apply the same system processing as used for standard flight plan messages.


The route given in a flight plan with source AFIL is an ATC clearance and shall not be amended in any way by the IFPS staff without coordination with the message originator, regardless of any errors in that route.

Those flight plans with source AFIL that are submitted to the IFPS for processing may contain errors in route availability, RAD, DCT limits, RVSM, 8.33 kHz, or other such violations within the route given in the ATC clearance. If no contact with the message originator is possible, then those errors shall be ignored, and the appropriate IFP indicators shall be added to the message.

Where the route given in the message is incomplete, the IFPS staff shall construct a logical route from the last point of the given route to the destination or the point at which that flight leaves the IFPZ, taking into account any restrictions such as RAD and route availability.



124 ATC Flight Plan Proposal Message (AFP)

(1) General

The ATC Flight Plan Proposal Message (AFP) message shall be submitted to the IFPS by an ATC unit where that unit has new or revised information concerning an aircraft operating as IFR/GAT within the IFPZ that is already in flight.

Normally AFP messages shall be automatically generated by the respective ATC Unit system, based upon an ATC input. AFP messages should not be created manually except where it is a standard operating procedure in that unit.

The information received by the IFPS in an AFP shall be distributed in the form of an ATC Flight Plan (APL) or an ATC Change (ACH) to those affected ATCUs downstream of the reporting unit, with source given as AFP.

The objectives of AFP messages are to:

Enable the NMOC to provide ATC Units downstream with more accurate flight plan information, improving their traffic situation awareness and reducing the workload and disruption caused by last minute updates or missing flight plans;

Update the ETFMS with flight plan information in order to reflect as accurately as possible the current and future trajectory of the flight, providing accurate sector load calculations thus improving the ATFCM performance.

Update CCAMS with flight plan data for missing flight plans such that directional codes can be assigned instead of omni-directional codes.

(2) Requirements

An AFP shall only be sent for airborne flights.

An AFP shall be sent by an ATC unit to IFPS in ADEXP format (see Note), including the IFPLID, when one of the following events occurs:

For a missing flight plan. For a change of route. For a change of aircraft type.

For a change of flight rules (IFR/VFR). For a change of flight type (OAT/GAT). For diversion.

For a change of aircraft equipment.

Note 1 Only an AFP for missing flight plan can be sent to IFPS in ICAO or ADEXP format.

The implementation of the AFP message in ADEXP format is covered by the following ESSIP/SLOa:

FCM03-ASP10 – Provide AFP messages in ADEXP format.

Note 2 A “time-shift” only, indicated in the Estimate field (ESTDATA) shall not be an event for sending an AFP.

An AFP shall be sent only for flights for which the message originator ATS unit has assumed control of the flight except for AFP messages for a missing flight plan which may be transmitted before assuming control of the flight, under the following conditions:

A flight plan for a flight is considered to be missing when all the following conditions are met:

An estimate for the flight is received by the ATC Unit. No flight plan information was received by the ATC Unit from IFPS.



IFPS does not have a flight plan for the flight.

An ATC unit shall stop transmitting AFP messages from the moment it has transferred control of the flight.

The IFPS shall accept AFPs that communicate more than one event. This is achieved by complying with all the requirements applicable to each event.

Examples

AFP for a change of aircraft type and for change of aircraft equipment. AFP for a change of aircraft type, change of aircraft equipment and a change of route.

Check under 3) Message Format, for detailed examples.

The IFPS shall accept and process updates via AFP messages for the following Items:

Item 8a: Flight Rules.

Item 9b: Type of Aircraft. Item 9c: Wake Turbulence Category. Item 10: Aircraft equipment.

Item 14: Estimate Data. Item 15: Route. Item 16: Aerodrome of destination. Item 18: Other Information (limited to the following fields: PBN, COM, DAT, NAV, SUR,

ORGN, PER).

AFPs submitted to the IFPS in ADEXP format shall contain only the minimum required fields (see Note below). The minimum required fields are listed in each section under 2) Requirements and examples of AFPs with these minimum required fields can be found in each section under 3) Message format.

The field IFPLID shall be included in AFPs submitted to IFPS (for association purposes), except for AFP for a missing flight plan.

Note Except for the field –ARCADDR than may be inserted under certain conditions. See 4) System Processing.

Flight rules requirements

The flight rules should be included in an AFP message for a missing flight plan. If not provided, IFPS shall assume the following value: I

The flight rules shall be included in an AFP for a change of flight rules and shall reflect the new flight rules of the flight.

In case the flight rules do not change, this field shall be omitted in an AFP message.

Type of aircraft requirements

The type of aircraft shall be included in an AFP message for a missing flight plan.

The type of aircraft shall be included in an AFP for a change of aircraft type and shall reflect the new aircraft type that the flight is operated with.

In case the aircraft type does not change, this field shall be omitted in an AFP message.

Equipment requirements

All available equipment information shall be included in an AFP message for a missing flight plan sent in ICAO format.

All available equipment information should be included in an AFP message for a missing flight plan sent in ADEXP format within the CEQPT and/or SEQPT fields as well as within the PBN, NAV, COM, SUR and DAT fields if applicable.



All available equipment information shall be included in an AFP for a change of equipment, within the primary field EQCST and/or, where necessary, within the PBN, NAV, COM, SUR and DAT fields.

In the case of an AFP other than for a missing flight plan or change of aircraft equipment, the equipment shall be omitted.

Estimate data requirements

The estimate data field shall be included in all types of AFP messages.

The estimate data field shall contain the estimated or the actual time and level over the estimate point.

The estimate point shall be explicitly or implicitly included in the AFP route field (see Note below).

However, for AFPs for a change of aircraft type and for AFPs for a change of aircraft equipment, there is no AFP route field. For these occurrences, the flight plan route field is considered instead.

In large cross-border Free Route Airspace, it may happen that the flight plan route for that part of the trajectory is described only with a FRA entry point followed by DCT followed by a FRA exit point. In this scenario, the FRA exit point should be used as the Estimate Point (which may be located in one of the downstream ATS units).

Note The AFP estimate point is implicitly included in the route field when it is a point on one of the route segments that are included in the route description but the point name is not mentioned in the route field.

The estimate point shall be any point along the AFP route (or flight plan route, see above) with the following exceptions:

a) It shall not be a point located on a SID or STAR procedure included in the AFP route apart from the point where the SID or STAR is connected to the en-route part of the route;

b) It shall not be a point described with geographical coordinates or as bearing and distance from a navigation aid that is considered to be implicitly included in the AFP route as being located along one of the airways in the AFP route.

c) It shall not be a point located in a VFR or OAT portion of the flight.

d) It shall not be a published ICAO aerodrome code.

The estimate point shall be a published ICAO navigation beacon designator or a set of geographical coordinates or a range and bearing from a published ICAO navigation beacon designator.

Route requirements

The ROUTE field shall be included in all types of AFP messages except for:

AFP for a change of aircraft type only. AFP for a change of aircraft equipment only.

AFP for a change of aircraft type and aircraft equipment.

The route field of an AFP message shall only contain the route part on which the flight has been cleared or is about to be cleared by the AFP originator ATS unit.

The AFP route shall not contain the upstream part of the route compared to the area of responsibility of the AFP originator ATC unit.

The AFP route shall implicitly or explicitly contain the AFP estimate point.

Note The AFP estimate point is implicitly included in the AFP route when it is a point on one of the route segments that are included in the route description but the point name is not mentioned in the route field.



The AFP route description shall comply with the ICAO Doc 4444 specifications regarding the content of the Field Type 15 of a flight plan message.

Note If not provided in the AFP route, IFPS shall automatically insert between two consecutive significant points either an airway that is available at the requested cruising level or in case it does not find an airway, a DCT route. This automatic processing is not applied in case the significant points are described using geographical coordinates or as bearing and distance from a navigation aid.

The AFP route shall be considered as an update to the flight plan, as such the AFP route should be “flight plannable” and compliant with the constraints relevant for the airspaces it crosses.

Requested cruising levels, flight rules changes (IFR/VFR) and flight type changes (GAT/OAT) shall be inserted in the route field at the point(s) from which they become applicable.

The route field shall contain the original requested cruising level(s) within the airspace of the AFP originator ATC Unit as included in the filed flight plan before departure.

The first and last elements of an AFP route shall be:

a) A significant point or

b) A DCT route, in case of a flight that is cleared directly from its aerodrome of departure to the first point of the route / to the aerodrome of destination or from the last point of the route to the aerodrome of destination.

The first and last elements of an AFP route shall not be an airway designator.

An AFP route shall not contain internal, unpublished and non-ICAO point/route designators.

Where route information is required to be included in an AFP message in ADEXP format, the ADEXP primary field ROUTE shall always be included in the message.

IFPS shall consider the AFP route as valid and flown as indicated in the AFP message.

Note IFPS will therefore accept a flight that will penetrate closed airspaces, fly along closed routes and against RAD restrictions on the AFP route.

Note It should be noted that incorrect use of this facility may lead to invalid routes within the airspace of downstream ATC units being accepted and distributed by IFPS having a potential significant impact on the downstream ATC units.

Aerodrome of destination requirements:

The aerodrome of destination field shall be included in all types of AFP messages.

In case of an AFP message for diversion, the aerodrome of destination field shall contain the new destination of the flight.

For all other AFP trigger events, the aerodrome of destination field shall contain the aerodrome of destination included in the filed flight plan.

Old aerodrome of destination requirements:

The old aerodrome of destination field (ADEXP primary field ADESOLD) shall be used to indicate that a flight has diverted from the original aerodrome of destination included in the filed flight plan.

The old aerodrome of destination (ADESOLD) field shall contain the original aerodrome of destination as included in the filed flight plan (even in case of multiple diversions. This is for association purposes of the AFP to the correct flight plan).

(3) Message Format



AFP messages shall be submitted in ADEXP format. Only the AFP message for a missing flight plan may be submitted in ICAO format if it cannot be submitted in ADEXP format.

Note It is recommended to use ADEXP format for submission of AFP messages for a missing flight plan as it provides more flexibility and facilities. The format chosen for the submission of messages to the IFPS shall not be dependent upon the format specified for receipt of messages from the IFPS. A unit requesting to receive all output from the IFPS in ICAO format may still submit AFP messages in ADEXP, should it so wish.

Example of an AFP for a change of route. Each vertical red bar “ “ represents a “one space character” and is only shown in this section

-TITLE IAFP -IFPLID AA00228589 -ARCID ABC123 -ADEP LFPG -ESTDATA –PTID OKEKO –ETO 200415122528 –FL F270 -ROUTE N0430F290 OKEKO UL612 MOU UL178 LESPI -ADES LFBO

Example of an AFP having the estimate point expressed by geographical coordinates

-TITLE IAFP -IFPLID AA00228589 -ARCID ABC123 -ADEP LFPG -ESTDATA -PTID GEO01 -ETO 200415122528 -FL F270 -ROUTE N0430F290 DCT 471918N0030812E MOU UL178 LESPI -ADES LFBO

Example of an AFP for a change of aircraft type/aircraft equipment and change of route

-TITLE IAFP -IFPLID AA00228589 -ARCID ABC123 -ARCTYP A35K -BEGIN EQCST -EQPT E3/NO -END EQCST -ADEP LFPG -ESTDATA –PTID OKEKO –ETO 200415122528 –FL F270 -ROUTE N0430F290 OKEKO UL612 MOU UL178 LESPI -ADES LFBO More examples can be found in the corresponding sections.


The result of a successful AFP message processing by the IFPS shall be an APL or an ACH.

The IFPS shall distribute an APL or ACH to all ATC Units concerned with the flight that are situated downstream of the estimate point in the AFP, but not to the originator of the AFP message.

An APL message shall be distributed by the IFPS to those ATC Units to whom the IFPS did not send flight plan data for the flight (the new concerned units).

An ACH shall be distributed by the IFPS to those ATC Units to whom the IFPS has already sent flight plan data for the flight (the old concerned units).



The ACH/APL format (ADEXP or ICAO) that is distributed to the ATS units is not dependent on the input format. It is based on the setting defined in NM CACD.

Example An AFP sent in ADEXP format (which is the case for most AFPs since only AFPs for a missing flight plan may be sent in ICAO format) can trigger ACH/APL output in ICAO format to some ATC units an in ADEXP format to some other ATC units.

Where the IFPS receives an RQP message for a flight that has been modified by an AFP, the IFPS shall transmit an APL message to the originator of the RQP. In such cases, the IFPS shall add in the sub-field RMK the text APL IS AN FPL UPDATED BY ATC in the output message.

Note RQP messages that relate to flight plans using the EUR/PROTECTED function shall pass for manual processing by the IFPS staff.

Where an AFP associates with an existing flight plan, the IFPS shall check any route details given in the AFP against those of the existing flight plan. Should a difference be identified that cannot be automatically processed, the AFP shall fail automatic processing and be passed for manual treatment by the IFPS staff with the following warning message:

WARN: ACH BUILT FROM AN IAFP

Plus any error messages that may be appropriate.

Where an AFP does not associate with an existing flight plan, the IFPS shall automatically build a route to connect to the destination. Where the route generation is successful, that message shall be processed automatically for distribution as an APL; where the route generation fails, that message shall be passed for manual treatment by the IFPS.

When processing AFP messages where that AFP associates with a single flight plan, the IFPS shall take a number of actions:

The IFPS shall make an automatic association between the routes of the flight plan and AFP wherever possible. The level of this association shall depend upon the information given in the AFP message, and where necessary, the IFPS staff shall build a logical route to connect the AFP route as required.

Note Where that part of a route copied from an existing flight plan contains designators such as IFR, VFR, GAT, OAT or any change of speed and level, those designators shall also be copied to the AFP route.

In cases where an AFP is displayed for manual processing by the IFPS staff, it shall contain the text ‘AFPEND’ in the route description immediately following the point that was the last given point in the submitted AFP route. All errors associated with the route prior to the indicator ‘AFPEND’ shall be automatically ignored by the system. The text ‘AFPEND’ shall not be included in the version of the message distributed to external users.

The IFPS shall accept and process, for AFP messages, the –ARCADDR field (ADEXP format) in order to enable ATC to:

Add the 24-bit aircraft address of the airframe when it is missing or

Amend the 24-bit aircraft address of the airframe when it is incorrect. The change shall be transmitted in ACH/APL messages.

124.1 AFP Association

Where an AFP is submitted to the IFPS in ADEXP format, it is possible to include the IFPLID, and where this is present, the IFPS shall use it to make any necessary message association.



As a safety precaution, the IFPS shall also check that both the AFP and the associated flight in the database have the same aircraft identification (ARCID) and departure aerodrome (ADEP). If the aircraft identification and departure aerodrome are the same then the association is confirmed.

If the aircraft identification and departure aerodrome are not the same, then the IFPLID shall be dropped for message association purposes and AFP association shall be carried out as if the IFPLID is not present.

Those AFP messages submitted to the IFPS that have no IFPLID, or have an IFPLID but do not fulfil the additional association criteria, shall be associated with all flights that have an EOBT in the past or up to 30 minutes in the future compared to the AFP estimate time, and the same aircraft identification (ARCID), departure aerodrome (ADEP) and destination aerodrome (ADES).


Whenever an ACH or an APL with source AFP is presented for manual processing, the following warning and error are displayed to the IFPS staff:

WARN256: ACH BUILT FROM AN IAFP (or APL BUILT FROM AN IAFP)

ROUTE 303: NO VALID ROUTE FOUND TO CONNECT TO FLIGHT ROUTE.

And optionally: ROUTE41: PLEASE CHECK NAS OF GENERATED PORTION: <List of NAS>.

The IFPS staff shall build an IFPS compliant correct route to connect the last point given in the AFP route to the original route or to the destination aerodrome (whatever is the most logical/possible) or to where that flight exits the IFPZ (if applicable).

If an IFPS compliant route is not possible, the IFPS staff shall force the message by ignoring the relevant error(s) and the corresponding IFP indicator(s) shall be inserted.

The route given in the AFP shall not be modified in any way (i.e. the route before the AFPEND in the ACH message).

Where the message relates to a military flight, regardless of whether the automatic route-building by the IFPS is successful or not, to allow for any necessary confirmation of diplomatic clearances, that message shall be passed to the IFPS staff with the a warning message attached:

ROUTE305: FLIGHT TYPE IS MILITARY. PLEASE CHECK NAS OF GENERATED PORTION: <List of NAS>.

The IFPS staff should check the flight plan history for any previously submitted flight plan related to that flight, as historical flight plan data may be used as a guideline to build the ACH/APL route.






125 AFP For a Missing Flight Plan

(1) General

The implementation of the AFP message for a missing flight plan is covered by the following ESSIP/SLOa:

FCM03-ASP05 – Automatically provide AFP for missing flight plans.

(2) Requirements

An AFP message shall be sent to the IFPS automatically in ADEXP format (exceptionally, it may be in ICAO format if sent manually) by an ATC Unit where a flight plan is found to be missing.

A flight plan for a flight shall be considered to be missing when all the following conditions are met:

An estimate for the flight is received by the ATC Unit.

No flight plan information was received by that Unit from the IFPS.

The IFPS does not hold a flight plan for that flight.

Note If the flight plan is available in IFPS, then IFPS has full flight plan information on the flight. It is very unlikely that an ATC Unit, unless it has received the flight plan information from IFPS, will have full information on the flight. Differences between the flight plan information stored in IFPS and the flight plan information sent by the ATC Unit in an AFP message will be treated by IFPS as updates to the flight plan information and processed as such. This may cause for example a possibly incorrect alteration of the flight plan equipment information.

In order to check if a flight plan for the flight is available within the IFPS, an RQP message should be sent by the ATC Unit to the IFPS where possible. Where a flight plan for that flight is held by the IFPS, the flight plan shall be returned to the originator of the RQP message.

If the IFPS does not hold a valid flight plan matching the details given in the submitted RQP, then a reject message shall be returned to the originator of that RQP. This indicates that an AFP for a missing flight plan is required.

Note RQP messages that relate to flight plans using the EUR/PROTECTED function shall pass for manual processing by the IFPS staff.

(3) Message Format

AFP messages for a missing flight plan may be submitted in ADEXP or ICAO format.

However, it is recommended to use the ADEXP format for AFP messages for a missing flight plan as well as it provides more flexibility in what concerns the content of the message. In addition, transmission of AFP messages in ADEXP format to IFPS is linked to processing of flight plan data in ADEXP format received from IFPS (FCM-ASP03). Moreover the final aim, set in the ESSIP objectives, is to have all AFP messages transmitted to IFPS in ADEXP format.

An AFP message for a missing flight plan that is submitted to the IFPS for processing shall contain all flight plan information available for that flight with the originator ATC Centre.

The minimum information for such messages shall be:

Message title. Aircraft identification.

Type of aircraft. Equipment (compulsory only in ICAO format).

Departure aerodrome. Estimate data.

Route.



Destination aerodrome.

PBN (if R is present in the Equipment Information).

Please refer to section ATC Flight Plan Proposal Message (AFP), (2) Requirements for the specific requirements of each AFP field.

Note Although it is possible for the IFPS to process an AFP message in ADEXP format without the optional equipment information in that format, it is strongly recommended that all available equipment information is included in the AFP message. In particular, RVSM capabilities, 8.33 kHz and UHF equipage status should be confirmed by ATC with the pilot and included in the message.

Although the type of aircraft is normally an optional field of an AFP in ADEXP format, it is compulsory information in an AFP for a missing flight plan. Without the type of aircraft, the profile of a flight cannot be calculated by IFPS.

If not provided in the AFP message, IFPS shall assume the following information:

Flight Rules = I Flight Type = G Communication Equipment = S Surveillance Equipment = S

Examples of AFP for a missing flight plan

ADEXP format:

-TITLE IAFP -ARCID ABC123 -ARCTYP A359 -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200417094000 –FL F270 -ROUTE N0430F290 ERIXU UN860 ETAMO -ADES LFBO ICAO format:

(AFP-ABC123-A359-SDE2E3FGIJ1RWY/H-LFPG-ERIXU/0940F270-N0430F290 ERIXU UN860 ETAMO-LFBO-PBN/A1B1C1D1L1O1S2) Note In ICAO format, as the Equipment field is compulsory, the presence of R in field 10a requires

the PBN information to be present (as shown in the example above).


Examples of a message sequence: AFP – APL

AFP in ADEXP format:

-TITLE IAFP -ARCID ABC123 -ARCTYP A359 -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200417094000 –FL F270 -ROUTE N0430F290 ERIXU UN860 ETAMO -ADES LFBO APL output by the IFPS in ADEXP format after a route has been constructed (by IFPS or by IFPS staff) to connect the last point given in the AFP ROUTE field to the destination:

-TITLE IAPL -BEGIN ADDR -FAC CFMUTACT -FAC EDDAYGCD



-FAC LFFFSTIP -FAC LFBOZPZX -FAC LFYNZPZX -END ADDR -ADEP LFPG -ADES LFBO -ARCID ABC123 -ARCTYP A359 -CEQPT S -EOBD 200417 -EOBT 0932 -FILTIM 170941 -IFPLID AT00127879 -SEQPT S -WKTRC H -IFP 833UNKNOWN RVSMUNKNOWN -SRC AFP -TTLEET 0053 -RFL F290 -SPEED N0430 -FLTRUL I -FLTTYP G -ROUTE N0430F290 ERIXU UN860 EVPOK UN859 NARAK -ESTDATA -PTID ERIXU -ETO 200417094000 -FL F270 -BEGIN RTEPTS -PT -PTID LFPG -FL F004 -ETO 200417093205 -PT -PTID ERIXU -FL F270 -ETO 200417094000 -PT -PTID ERTOK -FL F290 -ETO 200417094414 -PT -PTID ETAMO -FL F290 -ETO 200417095025 -PT -PTID GUERE -FL F290 -ETO 200417095604 -PT -PTID ETENU -FL F290 -ETO 200417100102 -PT -PTID EVPOK -FL F290 -ETO 200417100322 -PT -PTID NARAK -FL F135 -ETO 200417101504 -PT -PTID LFBO -FL F005 -ETO 200417102825 -END RTEPTS -ATSRT UN860 ERIXU EVPOK -ATSRT UN859 EVPOK NARAK Note The Equipment information (see fields CEQPT and SEQPT above) states respectively S and

S because the AFP was received in ADEXP format and did not contain the equipment information. S and S are inserted by IFPS, being the default values when the equipment is absent in the AFP in ADEXP format.

AFP in ICAO format:

(AFP-ABC123-A359-SDE2E3FGIJ1RWY/H-LFPG-ERIXU/0940F270-N0430F290 ERIXU UN860 ETAMO-LFBO-PBN/A1B1C1D1L1O1S2) APL output by the IFPS in ICAO format after a route has been constructed (by IFPS or by IFPS staff) to connect the last point given in the AFP ROUTE field, to the destination:

(APL-ABC123-IG -A359/H-SDE2E3FGIJ1RWY/H -LFPG0932 -ERIXU/0940F270 -N0430F290 ERIXU UN860 EVPOK UN859 NARAK -LFBO0053 -PBN/A1B1C1D1L1O1S2 DOF/200417 SRC/AFP)



Upon receipt of an AFP message for a missing flight plan, the IFPS shall build an APL message. Any errors (for example, RAD or CDR errors) related to the cleared route given in the submitted AFP shall be automatically ignored by the IFPS.

Where the equipment information is not included (only possible in AFP in ADEXP format) in the message submitted to the IFPS, then the IFPS shall assume the following information:

Flight rules = I Flight type = G Communications equipment = S

Surveillance equipment = S

If the system, using the Propose Route Function, fails to automatically create a route to the destination, then the APL will be presented for manual processing with the warning and error:

WARN259: APL BUILT FROM AN IAFP

ROUTE303: NO VALID ROUTE FOUND TO CONNECT TO FLIGHT ROUTE.

If the system, using the Propose Route Function finds automatically a route to the destination, then the APL will be presented for manual processing with the warning and error:

WARN259: APL BUILT FROM AN IAFP

(Optional) ROUTE41: PLEASE CHECK NAS OF GENERATED ROUTE: <List of NAS>.



126 AFP for a Change of Route

1) General

The implementation of the AFP message for a change of route is covered by the following ESSIP/SLOa:

FCM03-ASP06 – Automatically provide AFP message for a change of route.

(2) Requirements

Coordination between ATC units and transfer of flights are handled over COPs (Coordination Points). COPs are either:

A point on an airway that is “on” or “near” the ATC unit AOR border (fixed COP), commonly used when the conventional ATS route network exists, or

A point covering an area along the ATC unit AOR border (area COP/floating COP), commonly used in Free Route environment.

An AFP for a change of route shall be sent automatically in ADEXP format by an ATC unit:

When the COP changes (fixed COP or area COP) and the next downstream ATC unit is new when compared to the flight plan route.

In cross border Free Route context, the last point of the AFP route shall not be expressed by geographical coordinates or point/bearing distance if

This is not allowed in FRA operations (see AIP) or if The point is located on the outer border of the Free Route Airspace.

Example 1: conventional ATS route network environment, no AFP required

Flight Plan route is: …A AWY1 E AWY2 F…

Flight Plan has been addressed by IFPS to ATC units: 1,2,3.

From its current position, the flight receives an ATC clearance to point X.

The fixed COP from ATC unit 1 changes (from C to X), but the next downstream ATC unit is not new when compared to the Flight Plan route, therefore no AFP is required.

The trajectory change is handled by OLDI messages.



When ATC unit 2 takes control of the flight, the latest Flight Plan data it has received indicates an exit COP at point E. Either the flight path re-connects to the original Flight Plan route within ATC unit 2 or it does not re-connect (and the exit COP changes) in which case the same requirements apply.

Example 2: conventional ATS route network environment, AFP required

Flight Plan route is: …A AWY1 E AWY2 F…


From its current position, the flight receives an ATC clearance to point X.

The fixed COP from ATC unit 1 changes (from C to X), and the next downstream ATC unit is new when compared to the Flight Plan route, therefore an AFP is required.

From the end of the clearance limit (last point in the AFP route, in this example point X), IFPS builds a route that either re-connects to the Flight Plan route (as in the above example) or all the way to destination.

IFPS addresses Flight Plan data to ATC units 4 and 5 by means of an APL message.

IFPS addresses update to the Flight Plan data to ATC units 2 and 3 by means of an ACH message.

From the moment the APL/ACH have been received and treated Y and W become the new fixed COP respectively from ATC units 5 and 4 and in case of any further change, the same requirements shall apply.

Example 3: cross-border Free Route airspace environment, no AFP required



Flight Plan route is: …FRA entry point A DCT FRA Intermediate point B DCT FRA EXIT point C…


From its current position, the flight receives an ATC clearance to FRA intermediate point D.

The area COP from ATC unit 1 changes (from Y to X), but the next downstream ATC unit is not new when compared to the Flight Plan route, therefore no AFP is required.

When ATC unit 2 takes control of the flight, the latest Flight Plan data it has received implies an exit area COP at point Z. Either the flight path re-connects to the original FPL route within ATC unit 2 or it does not re-connect (and the exit COP may change) in which case the same requirements apply.

Example 4: cross-border Free Route airspace environment, AFP required

Flight Plan route is: …FRA entry point A DCT FRA Intermediate point B DCT FRA EXIT point C…


From its current position, the flight receives an ATC clearance to FRA intermediate point D.

The area COP from ATC unit 1 changes (from Y to X) and the next downstream ATC unit is new when compared to the Flight Plan route, therefore an AFP is required.

From the end of the clearance limit (last point in the AFP route, in this example point D), IFPS builds a route that either re-connects to the Flight Plan route (as in the above example) or all the way to destination.

IFPS addresses Flight Plan data to ATC unit 4 by means of an APL message.

IFPS addresses update to the Flight Plan data to ATC units 2 and 3 by means of an ACH message.

From the moment the APL/ACH have been received and treated, Z becomes the new area COP from ATC unit 4 and in case of any further change, the same requirements shall apply.

(3) Message Format

AFP messages for a change of route may only be submitted in ADEXP format (IAFP).

An IAFP for a change of route that is submitted to the IFPS for processing shall contain at least the following information:

Message title. Aircraft identification. Departure aerodrome.

Estimate data. Route.





Example of an AFP for a change of route

-TITLE IAFP -ARCID ABC123 -ADEP LFPG -ESTDATA –PTID OKEKO –ETO 200415122528 –FL F270 -ROUTE N0430F290 OKEKO UL612 MOU UL178 LESPI -ADES LFBO


Example of a message sequence: FPL – AFP – ACH/APL

Original flight plan:

(FPL-ABC123-IS -A359/M-SDE2E3FGIJ1RWY/H -LFPG0545 -N0398F290 ERIXU UN860 EVPOK UN859 NARAK -LFBO0058 -PBN/A1B1C1D1L1O1S2 DOF/200424 REG/FGFVA) AFP submitted to the IFPS for processing:

-TITLE IAFP -ARCID ABC123 -ADEP LFPG -ESTDATA -PTID OKEKO -ETO 200424061015 -FL F270 -ROUTE N0430F290 OKEKO UL612 MOU UL178 LESPI -ADES LFBO ACH output by the IFPS in ICAO format:

(ACH-ABC123-LFPG0545-LFBO-DOF/200424-14/OKEKO/0610F270 -15/N0430F290 OKEKO UL612 MOU UL178 LESPI DCT LERGA UN869 NARAK -18/PBN/A1B1C1D1L1O1S2 DOF/200424 REG/FGFVA IFP/ERROUTE MODESASP SRC/AFP) Note In the above example, IFPS was not able to find automatically a route from LESPI either to

reconnect to the original nor to the destination. Therefore, the ACH went for manual processing. As it was not possible to find an IFPS compliant route, the IFPS staff force the message through (error on DCT segment LESPI-LERGA) and inserted the relevant IFP indicator (see section General Procedures).

ACH output by the IFPS in ADEXP format:

-TITLE IACH -BEGIN ADDR -FAC CFMUTACT -FAC EDDAYGCD -FAC LSASZQZG -FAC LFFFZGZX -FAC LFFFSTIP -FAC LFMMZGZX -FAC LFBOZPZX -FAC LFYNZPZX



-END ADDR -ADEP LFPG -ADES LFBO -ARCID ABC123 -ARCTYP A359 -CEQPT SDE2E3FGIJ1RWY -EOBD 200424 -EOBT 0545 -FILTIM 240611 -IFPLID AT00208564 -SEQPT H -WKTRC H -IFP ERROUTE MODESASP -PBN A1B1C1D1L1O1S2 -REG FGFVA -SRC AFP -TTLEET 0058 -RFL F290 -SPEED N0430 -FLTRUL I -FLTTYP S -ROUTE N0430F290 OKEKO UL612 MOU UL178 LESPI DCT LERGA UN869 NARAK -ESTDATA -PTID OKEKO -ETO 200424061000 -FL F270 -BEGIN RTEPTS -PT -PTID LFPG -FL F004 -ETO 200424055717 -PT -PTID OKEKO -FL F270 -ETO 200424061000 -PT -PTID OKEPI -FL F290 -ETO 200424061333 -PT -PTID OKIRA -FL F290 -ETO 200424061441 -PT -PTID MOU -FL F290 -ETO 200424061733 -PT -PTID OMANI -FL F290 -ETO 200424061949 -PT -PTID LESPI -FL F290 -ETO 200424062254 -PT -PTID LERGA -FL F290 -ETO 200424063008 -PT -PTID MOKDI -FL F290 -ETO 200424063426 -PT -PTID MINSO -FL F290 -ETO 200424063605 -PT -PTID ROMAK -FL F234 -ETO 200424063937 -PT -PTID NASEP -FL F200 -ETO 200424064143 -PT -PTID NARAK -FL F133 -ETO 200424064609 -PT -PTID LFBO -FL F005 -ETO 200424065932 -END RTEPTS -ATSRT UL612 OKEKO MOU -ATSRT UL178 MOU LESPI -DCT LESPI LERGA -ATSRT UN869 LERGA NARAK APL output by the IFPS in ADEXP format (to the new ATS units following the re-connection from the end of the clearance limit i.e. LESPI to the first point of the STAR i.e. NARAK):

-TITLE IAPL -BEGIN ADDR -FAC CFMUTACT -FAC EDDAYGCD -FAC LSASZQZG -FAC LFFFZGZX -FAC LFFFSTIP -FAC LFMMZGZX -FAC LFBOZPZX -FAC LFYNZPZX



-END ADDR -ADEP LFPG -ADES LFBO -ARCID ABC123 -ARCTYP A359 -CEQPT SDE2E3FGIJ1RWY -EOBD 200424 -EOBT 0545 -FILTIM 240611 -IFPLID AT00208564 -SEQPT H -WKTRC H -IFP ERROUTE MODESASP -PBN A1B1C1D1L1O1S2 -REG FGFVA -SRC AFP -TTLEET 0058 -RFL F290 -SPEED N0430 -FLTRUL I -FLTTYP S -ROUTE N0430F290 OKEKO UL612 MOU UL178 LESPI DCT LERGA UN869 NARAK -ESTDATA -PTID OKEKO -ETO 200424061000 -FL F270 -BEGIN RTEPTS -PT -PTID LFPG -FL F004 -ETO 200424055717 -PT -PTID OKEKO -FL F270 -ETO 200424061000 -PT -PTID OKEPI -FL F290 -ETO 200424061333 -PT -PTID OKIRA -FL F290 -ETO 200424061441 -PT -PTID MOU -FL F290 -ETO 200424061733 -PT -PTID OMANI -FL F290 -ETO 200424061949 -PT -PTID LESPI -FL F290 -ETO 200424062254 -PT -PTID LERGA -FL F290 -ETO 200424063008 -PT -PTID MOKDI -FL F290 -ETO 200424063426 -PT -PTID MINSO -FL F290 -ETO 200424063605 -PT -PTID ROMAK -FL F234 -ETO 200424063937 -PT -PTID NASEP -FL F200 -ETO 200424064143 -PT -PTID NARAK -FL F133 -ETO 200424064609 -PT -PTID LFBO -FL F005 -ETO 200424065932 -END RTEPTS -ATSRT UL612 OKEKO MOU -ATSRT UL178 MOU LESPI -DCT LESPI LERGA -ATSRT UN869 LERGA NARAK



127 AFP for a Change of Aircraft Type

1) General

The implementation of the AFP message for a change of aircraft type is covered by the following ESSIP/SLOa:

FCM03-ASP13 – Automatically provide AFP messages for a change of aircraft type.

(2) Requirements

An AFP message shall be sent to IFPS automatically in ADEXP format by an ATC Centre when that centre has identified that a flight is operated with another aircraft type when compared to the one indicated in the last flight plan data received from the IFPS.

(3) Message Format

AFP messages for a change of aircraft type may only be submitted in ADEXP format (IAFP).

An IAFP message for a change of aircraft type that is submitted to the IFPS for processing shall contain at least the following information:

Message title.

Aircraft identification.

Type of aircraft. Departure aerodrome. Estimate data.



For the Estimate data: in order to fulfill the requirement that the estimate point shall be explicitly or implicitly included in the AFP route field and in the absence of such a field in this type of AFP, the flight plan route field is considered instead.

In large cross-border Free Route Airspace, it may happen that the flight plan route for that part of the trajectory is described only with a FRA entry point followed by DCT followed by a FRA exit point. In this scenario, the FRA exit point should be used as the Estimate Point (which may be located in one of the downstream ATS unit).

Normally, the aircraft equipment should also change together with the aircraft type. It is required that when a change of aircraft type is noted, the aircraft equipment is also confirmed by the originating ATC unit, and is included in the AFP message. At least the following equipment and capabilities should be confirmed where possible:

8.33 kHz equipment status.

UHF equipment status. RVSM approval status.

PBN if CEQPT contains the letter ‘R’.

Example of an AFP with a change of aircraft type where the equipment does not change

-TITLE IAFP -ARCID ABC123 -ARCTYP A35K -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200415122528 –FL F260 -ADES LFBO



Example of an AFP with a change of aircraft type and change of aircraft equipment as well as an update to the PBN field:

-TITLE IAFP -ARCID ABC123 -ARCTYP A35K -BEGIN EQCST -EQPT E3/NO -END EQCST -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200415122528 –FL F260 -PBN A1B1C1D1L1O1S2 -ADES LFBO


Example of a message sequence: FPL – AFP – ACH


(FPL-ABC123-IS -A359/M-SDE2E3FGIJ1RWY/H -LFPG1200 -N0398F290 ERIXU UN860 EVPOK UN859 NARAK -LFBO0058 -PBN/A1B1C1D2L1O1S2 DOF/200415 REG/FGFVA) AFP submitted to the IFPS for processing (for a change of aircraft type without change of equipment):

-TITLE IAFP -ARCID ABC123 -ARCTYP A35K -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200415122528 –FL F260 -ADES LFBO ACH output by the IFPS in ICAO format:

(ACH-ABC123-LFPG0645-LFBO-DOF/200415-9/A35K/H-14/ERIXU/1225F260 -16/LFBO0101-18/PBN/A1B1C1D2L1O1S2 DOF/200420 REG/FGFVA SRC/AFP) AFP submitted to the IFPS for processing for a change of aircraft type and a change of equipment well as an update to the PBN field:

-TITLE IAFP -ARCID ABC123 -ARCTYP A35K -BEGIN EQCST -EQPT E3/NO -END EQCST -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200415122528 –FL F260 -PBN A1B1C1D1L1O1S2 -ADES LFBO ACH output by the IFPS in ICAO format:

(ACH-ABC123-LFPG1200-LFBO-DOF/200415-9/A35K/H-10/SDE2FGIJ1RWY/H-14/ERIXU/1225F260 -18/PBN/A1B1C1D1L1O1S2 DOF/200415 REG/FGFVA SRC/AFP)



Where an aircraft type is updated by an AFP message, the IFPS shall recalculate the profile of that flight using the performance characteristics of that new aircraft type. Should the revised profile contain errors such as RAD or route availability, the IFPS staff shall force that message through manual processing and attach the appropriate IFP indicators.

Where an aircraft type is updated by an AFP message, but no update to the aircraft equipment is included, the IFPS shall retain the equipment information in the existing flight plan.






128 AFP for a Change of Flight Rules (IFR/VFR)

1) General

The implementation of the AFP message for a change of flight rules or flight type is covered by the following ESSIP/SLOa:

FCM03-ASP08 – Automatically provide AFP message for a change of flight rules or flight type.

(2) Requirements

An AFP message shall be sent to the IFPS automatically in ADEXP format by an ATC Centre when the flight rules of a flight for part or the whole route are changed when compared with the flight rules indicated in the last flight plan data information received from the IFPS.

The AFP message shall contain the new flight rules of that flight.

(3) Message Format

AFP messages for a change of flight rules may only be submitted in ADEXP format (IAFP).

An IAFP message for a change of flight rules that is submitted to the IFPS for processing shall contain at least the following information:

Message title.

Aircraft identification. Flight rules.

Departure aerodrome. Estimate data.

Route. Destination aerodrome.


The route information shall include the appropriate flight rules indicators (IFR/VFR) and any necessary associated speed or level information inserted at the point at which the change is planned to take place.

Multiple possible scenarios may be covered by an AFP for a change of flight rules. Examples:

Insertion of a VFR portion inside a fully IFR flight plan. A change to VFR for the remainder of the flight (see Note) as in the example below.

Note IFPS shall consider the AFP route as valid and flown as indicated in the AFP message. IFPS will therefore accept a flight that will penetrate closed airspaces, fly along closed routes and against RAD restrictions on the AFP route.

That is the reason why it is expected that the change of flight rules takes place within the same ATC unit as the AFP originator ATC unit or the ATC unit directly downstream of the AFP originator ATC unit (in which there was a coordination between these two ATC units).

Example of an AFP with a change of flight rules

-TITLE IAFP -ARCID ABC456 -FLTRUL Y -ADEP LFSB -ESTDATA –PTID LUL –ETO 200420091134 –FL F180 -ROUTE N0220F180 TORPA V40 LUL G4 RLP VFR -ADES LFJL



The ROUTE field may also contain an RFL information at the point where the change of flight rules takes place. All the possible formats are covered in section Visual Flight Rules (VFR) under 3) Message Format.




(FPL-ABC456-IS -BE20/H-SDGRWY/C -LFSB0845 -N0220F180 TORPA V40 LUL G4 RLP G21 MONCE -LFJL0040 -PBN/B2D2 REG/FGFAF DOF/200420) AFP submitted to the IFPS for processing (indicating a change to VFR at the end of the flight):

-TITLE IAFP -ARCID ABC456 -FLTRUL Y -ADEP LFSB -ESTDATA –PTID LUL –ETO 200420091134 –FL F180 -ROUTE N0220F180 TORPA V40 LUL G4 RLP VFR -ADES LFJL ACH output by the IFPS in ICAO format:

(ACH-ABC456-LFSB0845-LFJL-DOF/200420-8/YS-14/LUL/0911F180 -15/N0220F180 TORPA V40 LUL G4 RLP VFR-18/PBN/B2D2 DOF/200420 REG/FGFAF SRC/AFP) Upon successful processing of an ACH for a change of flight rules, IFPS shall distribute an ACH to all ATC Units concerned with the flight that are situated downstream of the estimate point in the AFP, but not to the originator of the AFP message.



129 AFP for a Change of Flight Type

1) General

The implementation of the AFP message for a change of flight rules or flight type is covered by the following ESSIP/SLOa:

FCM03-ASP08 – Automatically provide AFP message for a change of flight rules or flight type.

(2) Requirements

An AFP message shall be sent to IFPS automatically in ADEXP by an ATC Centre when the flight type of a flight for a part or the whole route are changed when compared with the flight type indicated in the last flight plan data information received from the IFPS.

Note This requirement does not refer to a change to the type of flight information held in Item 8: Flight Rules and Type of Flight of a flight plan, but to a change of the type of flight that may be indicated in the route field with the designators OAT and/or GAT.

(3) Message Format

AFP messages for a change of flight type may only be submitted in ADEXP format (IAFP).

An IAFP message for a change of flight type that is submitted to the IFPS for processing shall contain at least the following information:

Message title. Aircraft identification. Departure aerodrome.

Estimate data.

Route. Destination aerodrome.


The route information shall include the appropriate flight type change indicators (OAT/GAT) and any necessary associated speed or level information inserted at the point at which the change is planned to take place.

Multiple possible scenarios may be covered by an AFP for a change of flight type. Examples:

Insertion of an OAT portion inside a fully GAT flight plan (as in the example below). A change to OAT for the remainder of the flight (see Note below).

Note IFPS shall consider the AFP route as valid and flown as indicated in the AFP message. IFPS will therefore accept a flight that will penetrate closed airspaces, fly along closed routes and against RAD restrictions on the AFP route.

That is the reason why it is expected that the change of flight type takes place within the same ATC unit as the AFP originator ATC unit or the ATC unit directly downstream of the AFP originator ATC unit (in which there was a coordination between these two ATC units).

Example of an AFP with a change of flight type

-TITLE IAFP -ARCID AF123 -ADEP ETAR -ESTDATA –PTID GTQ –ETO 200420121800 –FL F070



-ROUTE TOLEY2W TOMPI OAT Z818 MAKOT/N0320F180 G21 GTQ/N0320F230 GAT -ADES LICZ




(FPL-AF123-IM -C30J/M-SDFGHIRTUWXY/H -ETAR1200 -N0320F070 TOLEY2W TOMPI Z818 MAKOT/N0320F180 G21 GTQ/N0320F230 UN852 GILIR/N0320F250 DCT MILPA UN852 GIRKU Z532 VANAS UM730 ATMAD M730 TOP L50 ELB M729 PNZ Q789 VAKOR N982 LIBRO -LICZ0312 -STS/STATE PBN/A1B2B5C2C4D2D4 DOF/200420) AFP submitted to the IFPS for processing (inserting an OAT portion):

-TITLE IAFP -ARCID AF123 -ADEP ETAR -ESTDATA –PTID GTQ –ETO 200420121800 –FL F070 -ROUTE TOLEY2W TOMPI OAT Z818 MAKOT/N0320F180 G21 GTQ/N0320F230 GAT -ADES LICZ ACH output by the IFPS in ICAO format:

(ACH-AF123-ETAR1200-LICZ-DOF/200420-14/GTQ/1216F070 -15/N0320F070 TOLEY2W SARRI OAT Z818 MAKOT/N0320F180 G21 GTQ/N0320F230 GAT UN852 GILIR/N0320F250 DCT MILPA UN852 GIRKU Z532 VANAS UM730 ATMAD M730 TOP L50 ELB M729 PNZ Q789 VAKOR N982 LIBRO -18/STS/STATE PBN/A1B2B5C2C4D2D4 DOF/200420 ORGN/…….. SRC/AFP) Upon successful processing of an ACH for a change of flight rules, IFPS shall distribute an ACH to all ATC Units concerned with the flight that are situated downstream of the estimate point in the AFP, but not to the originator of the AFP message.



130 AFP for Diversion

1) General

The implementation of the AFP message for a diversion is covered by the following ESSIP/SLOa:

FCM03-ASP07 – Automatically provide AFP message for a diversion.

(2) Requirements

An AFP message shall be sent to IFPS automatically in ADEXP format by an ATC Centre when there is a change to the destination aerodrome indicated in the last message received from the IFPS.

(3) Message Format

AFP messages for a change of destination may only be submitted in ADEXP format (IAFP).

An IAFP for a change of destination that is submitted to the IFPS for processing shall contain at least the following information:

Message title.

Aircraft identification. Departure aerodrome.

Estimate data. Route.

Original destination aerodrome. New destination aerodrome.


The new destination aerodrome shall be included in the ADEXP primary field ADES.

The original destination aerodrome shall be included in the ADEXP primary field ADESOLD.

In case a flight is subject to multiple diversions, all related diversion AFP messages shall contain in the ADESOLD field the original destination aerodrome, as provided in the original filed flight plan, for message association purposes.

If used, the DESTZ ADEXP field shall contain the name of the new destination aerodrome.

The route field shall contain the route segment planned to be flown inside the airspace of the originating ATC Unit towards the new destination aerodrome.

Example of an IAFP for diversion

-TITLE IAFP -ARCID ABC123 -ADEP LFPG -ESTDATA -PTID TOU -ETO 200421095000 -FL F120 -ROUTE N0398F290 NARAK DCT TOU -ADES LFBT -ADESOLD LFBO


Example of a message sequence: FPL – AFP – ACH/APL – AFP – ACH/APL


(FPL-ABC123-IS



-A359/M-SDE2E3FGIJ1RWY/H -LFPG0900 -N0398F290 ERIXU UN860 EVPOK UN859 NARAK -LFBO0058 -PBN/A1B1C1D1L1O1S2 DOF/200421 REG/FGFVA) AFP submitted to the IFPS for processing:

-TITLE IAFP -ARCID ABC123 -ADEP LFPG -ESTDATA -PTID TOU -ETO 200421095000 -FL F120 -ROUTE N0398F290 NARAK DCT TOU -ADES LFBT -ADESOLD LFBO ACH in ICAO format output by IFPS:

(ACH-ABC123-LFPG0900-LFBO-DOF/200421-14/TOU/0950F120 -15/N0398F290 ERIXU UN860 EVPOK UN859 NARAK DCT TOU-16/LFBT0107 -18/PBN/A1B1C1D1L1O1S2 DOF/200421 REG/FGFVA IFP/MODESASP SRC/AFP SRC/DIV LFBO) APL in ICAO format output by IFPS:

(APL-ABC123-IS -A359/H-SDE2E3FGIJ1RWY/H -LFPG0900 -TOU/0950F120 -N0398F290 ERIXU UN860 EVPOK UN859 NARAK DCT TOU -LFBT0107 -PBN/A1B1C1D1L1O1S2 DOF/200421 REG/FGFVA IFP/MODESASP SRC/AFP SRC/DIV LFBO) AFP submitted to the IFPS for processing (for a further diversion):

-TITLE IAFP -ARCID ABC123 -ADEP LFPG -ESTDATA -PTID TOU -ETO 200421095200 -FL F120 -ROUTE N0398F290 TOU DCT MIRBA -ADES LFBD -ADESOLD LFBO The ADESOLD shall remain the ADES of the original flight plan. This is for association purposes of the AFP to the correct flight plan.

ACH in ICAO format output by IFPS:

(ACH-ABC123-LFPG0900-LFBO-DOF/200421-14/TOU/0952F120 -15/N0398F290 ERIXU UN860 EVPOK UN859 NARAK DCT TOU DCT MIRBA-16/LFBD0107 -18/PBN/A1B1C1D1L1O1S2 DOF/200421 REG/FGFVA IFP/MODESASP SRC/AFP SRC/DIV LFBO) APL in ICAO format output by IFPS:

(APL-ABC123-IS -A359/H-SDE2E3FGIJ1RWY/H -LFPG0900 -TOU/0952F120 -N0398F290 ERIXU UN860 EVPOK UN859 NARAK DCT TOU DCT MIRBA -LFBD0121 -PBN/A1B1C1D1L1O1S2 DOF/200421 REG/FGFVA IFP/MODESASP SRC/AFP SRC/DIV LFBO)



131 AFP for a Change of Aircraft Equipment

1) General

The implementation of the AFP message for a change of aircraft equipment is covered by the following ESSIP/SLOa:

FCM03-ASP08 – Automatically provide AFP messages for a change of aircraft equipment.

(2) Requirements

An AFP message shall be sent to the IFPS automatically in ADEXP format by an ATC Centre when the aircraft equipment is different when compared with the one indicated in the last flight plan data received from the IFPS.

Changes to any of the equipment information corresponding to the ICAO Field Type 10a and 10b may be transmitted.

(3) Message Format

AFP messages for a change of aircraft equipment may only be submitted in ADEXP format (IAFP).

An IAFP message for a change of aircraft equipment that is submitted to the IFPS for processing shall contain at least the following information:

Message title. Aircraft identification.

Revised aircraft equipment.

Departure aerodrome.

Estimate data. Destination aerodrome.

Please refer to section ATC FLIGHT PLAN PROPOSAL MESSAGE (AFP), (2) Requirements for the specific requirements of each AFP field.

For the Estimate data: in order to fulfill the requirement that the estimate point shall be explicitly or implicitly included in the AFP route field and in the absence of such a field in this type of AFP, the flight plan route field is considered instead.

In large cross-border Free Route Airspace, it may happen that the flight plan route for that part of the trajectory is described only with a FRA entry point followed by DCT followed by a FRA exit point. In this scenario, the FRA exit point should be used as the Estimate Point (which may be located in one of the downstream ATS unit).

The revised aircraft equipment shall start by –BEGIN EQCST and finish by –END EQCST and in between, each addition of deletion of equipment when compared to the equipment of the stored flight plan shall be preceded by –EQPT

For a change of equipment corresponding to ICAO Field Type 10a the format is as follows:

-EQPT equipment designator/status

The status can be: NO for NO, EQ for Equipped or UN for Unknown

Example

-EQPT W/UN –EQPT R/NO –EQPT Y/EQ

For a change of equipment corresponding to ICAO Field Type 10b, the surveillance is classified by class with specific designators in each class as follows:



Class Designators

A A, C

S E, H, I, L, P, S, X

ADSB B1, B2, U1, U2, V1, V2

ADSC D1, G1

The surveillance equipment can be amended by class. The format is as follows:

-SUREQPT Class/Status/equipment designator

Example:

-SUREQPT S/EQ/E –SUREQPT ADSB/NO/B1 –SUREQPT ADSC/EQ/D1

Example of an AFP with a change of equipment corresponding to ICAO Item 10a and 10b

-TITLE IAFP -ARCID ABC456 -BEGIN EQCST -EQPT E3/NO -EQPT E2/EQ -SUREQPT S/EQ/H -SUREQPT ADSB/EQ/B1 -END EQCST -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200422093517 –FL F250 -ADES LFBO)




(FPL-ABC456-IS -A359/M-SDE3FGIJ1RWY/C -LFPG0900 -N0398F290 ERIXU UN860 EVPOK UN859 NARAK -LFBO0058 -PBN/A1B1C1D1L1O1S2 DOF/200422 REG/FGFVA) AFP submitted to the IFPS for processing:

-TITLE IAFP -ARCID ABC456 -BEGIN EQCST -EQPT E3/NO -EQPT E2/EQ -SUREQPT S/EQ/H -SUREQPT ADSB/EQ/B1 -END EQCST -ADEP LFPG -ESTDATA –PTID ERIXU –ETO 200422093517 –FL F250 -ADES LFBO ACH in ICAO format output by the IFPS:

(ACH-ABC456-LFPG0900-LFBO-DOF/200422-10/SDE2FGIJ1RWY/CHB1-14/ERIXU/0935F250



-16/LFBO0101 -18/PBN/A1B1C1D1L1O1S2 DOF/200422 REG/FGFVA IFP/MODESASP SRC/AFP) ACH in ADEXP format output by the IFPS:

-TITLE IACH -BEGIN ADDR -FAC CFMUTACT -FAC EDDAYGCD -FAC LFFFSTIP -FAC LFFFZGZX -FAC LFBOZPZX -FAC LFYNZPZX -END ADDR -ADEP LFPG -ADES LFBO -ARCID ABC456 -ARCTYP A359 -CEQPT SDE2FGIJ1RWY -EOBD 200422 -EOBT 0900 -FILTIM 220801 -IFPLID AT00147722 -SEQPT CHB1 -WKTRC H -IFP MODESASP -PBN A1B1C1D1L1O1S2 -REG FGFVA -SRC AFP -TTLEET 0101 -RFL F290 -SPEED N0398 -FLTRUL I -FLTTYP S -ROUTE N0398F290 ERIXU UN860 EVPOK UN859 NARAK -ESTDATA -PTID ERIXU -ETO 200422093517 -FL F250 -BEGIN RTEPTS -PT -PTID LFPG -FL F004 -ETO 200422092644 -PT -PTID ERIXU -FL F250 -ETO 200422093517 -PT -PTID ERTOK -FL F290 -ETO 200422093958 -PT -PTID ETAMO -FL F290 -ETO 200422094638 -PT -PTID GUERE -FL F290 -ETO 200422095244 -PT -PTID ETENU -FL F290 -ETO 200422095807 -PT -PTID EVPOK -FL F290 -ETO 200422100038 -PT -PTID NARAK -FL F135 -ETO 200422101317 -PT -PTID LFBO -FL F005 -ETO 200422102750 -END RTEPTS -ATSRT UN860 ERIXU EVPOK -ATSRT UN859 EVPOK NARAK

Where an IAFP for a change of equipment is submitted to the IFPS for processing, the IFPS shall calculate a new flight profile and compare it with the new equipment. Compliance with RVSM and 8.33 kHz requirements shall be confirmed, with that IAFP failing automatic processing where the requirements are not fully met.






132 Flight Notification Message (FNM)

(1) General

The Flight Notification Message (FNM) is an estimate message transmitted by Gander OACC for those flights entering the North Atlantic airspace via Gander. The message is automatically generated at the oceanic entry point where the oceanic clearance is issued for that flight, and gives the complete oceanic routeing, with an estimate for the oceanic exit point.

Where an FNM is received, the IFPS shall associate the message with any existing relevant flight plan. In the event that the route details given in the FNM differ from those given in the original flight plan, or where no associated flight plan exists with the IFPS, the system shall automatically build a route to connect to the destination. Where this fails, the message shall be passed to the IFPS staff for manual correction.

The IFPS shall not distribute messages with title FNM; information submitted to the IFPS in the form of FNM shall be distributed as APL or ACH only, with source given as FNM.

The Aircraft Operator Control Centre (AOCC) shall receive an ACK message (containing a copy of the ACH) whenever an FNM associates with an existing flight plan and the resulting ACH contains a route different from the last filed FPL. The AOCC shall also receive an ACK message (containing a copy of the APL) where the FNM does not have a flight plan in the IFPS with which to associate.

(2) Requirements

The IFPS shall accept flight notification messages submitted by Gander OACC for those eastbound trans-Atlantic flights entering the IFPZ.

For those eastbound trans-Atlantic flights entering the IFPZ, the IFPS shall confirm compliance with the traffic flow restrictions present in the RAD.

Where the oceanic exit point or landfall point given in the FNM differs from that given in the flight plan for such flights, the IFPS shall ensure that the revised route is compliant with the traffic flow restrictions present in the RAD. Where a route must be constructed by the IFPS to connect the clearance limit given in the FNM to either the destination or to make a logical and coherent connection with the existing flight plan route, that route shall, wherever possible, be made compliant with all relevant RVSM, 8.33 kHz, RAD and route availabilities.

(3) Message Format

Item ADEXP FNM

3 TITLE Compulsory

7a ARCID Compulsory

7b SSRMODE Optional

7c SSRCODE Optional

8a FLTRUL Not Allowed

8b FLTTYP Not Allowed

9a NBARC Optional

9b ARCTYP Compulsory

9c WKTRC Optional

10a CEQPT Not Allowed



10b SEQPT Not Allowed

13a ADEP Compulsory

13b EOBT Optional

14a,b,c ESTDATA Compulsory

14d,e ESTDATA Not Allowed

15a,b SPEED & RFL Optional

15c ROUTE Compulsory

16a ADES Compulsory

16b TTLEET Not Allowed

18 various elements

Restricted to EET, TYP, IFP, RVR, DOF, DEP & DEST

Example of an FNM with no associated flight plan

Submitted message:

(FNM-ABC234-A342/H-KORD-M080F360 LOGSU 49N050W 49N040W 49N030W 50N020W SOMAX ATSUR T-LFPG-EST/ATSUR0601)

Message distributed by the IFPS after processing:

(APL-ABC234-IG -A342/H-S/C -KORD0844 -ATSUR/1500F360 -M080F360 LOGSU 49N050W 49N040W 49N030W 50N020W SOMAX DCT ATSUR DCT RATKA UN502 JSY UY111 INGOR UM25 DVL -LFPG0750 -DOF/130114 IFP/833UNKNOWN RVSMUNKNOWN ORGN/CZQXZQZX SRC/FNM) Example of an FNM with an associated flight plan:

Existing flight plan:

(FPL-ABC225-IS -B772/H-SDE2E3FGHIJ3J4J5M1RWXY/LB1D1 -KDEN0240 -N0479F330 YELLO3 HANKI J148 ONL J114 GEP J21 DLH J533 YQT DCT YMO DCT YKL DCT HO/M080F370 DCT LOACH DCT 55N050W 55N040W 55N030W 55N020W DCT VENER/N0458F370 DCT KOKIB DCT LIFFY UL975 WAL UY53 NUGRA BNN1B -EGLL0850 EGKK -PBN/A1B1C1D1L1O1S1S2 EET/CZWG0139 CZYZ0154 CZUL0229 50N050W0431 50N040W0511 EGGX0549 51N020W0627 MASIT0659 EISN0700 EGTT0728 REG/GCHGS SEL/EHJK OPR/ABC DOF/130113 RALT/CYQX LPLA EGFF RMK/TCAS) Submitted FNM:

(FNM-ABC225-B772/H-KDEN-M080F380 LOACH 55N050W 55N040W 55N030W 55N020W RESNO NETKI T-EGLL-EST/NETKI1007)

ACH presented to the IFPS staff, with warning:

(ACH-ABC225-KDEN0240-EGLL-14/NIBOG/1007F380-15/M080F380 LOACH 55N050W 55N040W 55N030W 55N020W NIBOG DCT NETKI DCT LIFFY UL975 WAL UY53 NUGRA BNN1B -18/ PBN/A1B1C1D1L1O1S1S2 EET/CZWG0139 CZYZ0154 CZUL0229 50N050W0431 50N040W0511



EGGX0549 51N020W0627 MASIT0659 EISN0700 EGTT0728 REG/GCHGS SEL/EHJK OPR/ABC DOF/130113 RALT/CYQX LPLA EGFF RMK/TCAS SRC/FNM ORGN/CZQXZQZX)

WARN256: ACH built from an IFNM

(Optional) ROUTE41: PLEASE CHECK NAS OF GENERATED PORTION: <List of NAS>.

ACH distributed by the IFPS after manual correction/check of the route by the IFPS staff:

(ACH-ABC225-KDEN0600-EGLL-14/NETKI/1440F380

-15/M080F380 LOACH 55N050W 55N040W 55N030W 55N020W RESNO DCT NETKI

DCT LIFFY UL975 WAL UY53 NUGRA-18/PBN/A1B1C1D1L1O1S1S2 EET/CZWG0139 CZYZ0154 CZUL0229 50N050W0431 50N040W0511 EGGX0549 51N020W0627 MASIT0659 EISN0700 EGTT0728 REG/GCHGS SEL/EHJK OPR/ABC DOF/130113 RALT/CYQX LPLA EGFF RMK/TCAS SRC/FNM ORGN/CZQXZQZX)


On receipt of an FNM, the IFPS shall check for any existing associated flight plan. Where such is found, the IFPS shall treat that FNM as an amendment message; where no such flight plan exists, the IFPS shall process that FNM as an APL.

Where a submitted FNM does not include all optional items, the IFPS shall assume no change from those items as specified in the original flight plan where such exists. If no associated flight plan has been received by the IFPS, default values shall be inserted into those optional items that have not been completed.

When processed by the IFPS, flight notification messages shall be distributed as ACH or APL, with source FNM.


When processing flight notification messages, the IFPS staff shall not be required to co-ordinate any necessary route modifications with the message originator.

Those FNM that are passed for manual treatment by the IFPS staff shall only have those modifications made to the route that are entirely necessary. See section ATC FLIGHT PLAN CHANGE (ACH): General Procedures for ACH with source FNM or MFS.

Where a route must be constructed by the IFPS to connect the clearance limit given in the FNM to either the destination (or where that flight exits the IFPZ) or to make a logical and coherent connection with the existing flight plan route. That route shall, wherever possible, be made compliant with all relevant RVSM, 8.33 kHz, RAD and route availability restrictions.

When errors are raised on the route portion right after the landfall point, the IFPS staff shall ensure that a re-routing does not take place on the route portion upstream of the landfall point.






133 Message from SHANWICK/SANTA MARIA (MFS)

(1) General

The Message from Shanwick/Santa Maria (MFS) is an estimate message transmitted by Shanwick OACC or Santa Maria OACC for those eastbound flights entering the Shanwick or Santa Maria airspaces. The message is automatically generated when the aircraft is 45 minutes before its oceanic exit point, and gives the estimate time for the oceanic exit point.

Where an MFS is received, the IFPS shall associate the message with any existing relevant flight plan. In the event that the route details given in the MFS differ from those given in the original flight plan, or where no associated flight plan exists with the IFPS, the system shall automatically build a route to connect to the destination. Where this fails, the message shall be passed to the IFPS staff for manual correction.

The IFPS shall not distribute messages with title MFS; information submitted to the IFPS in the form of MFS shall be distributed as APL or ACH only, and indicating that the source is an MFS.

The Aircraft Operator Control Centre (AOCC) shall receive an ACK message (containing a copy of the ACH) whenever an MFS associates with an existing flight plan and the resulting ACH contains a route different from the last filed FPL. The AOCC shall also receive an ACK message (containing a copy of the APL) where the MFS does not have a flight plan in the IFPS with which to associate.

(2) Requirements

The IFPS shall accept MFS submitted by Shanwick or Santa Maria for those eastbound trans-Atlantic flights entering the IFPZ.

For those eastbound trans-Atlantic flights entering the London, Scottish, Irish and Brest airspaces, those airspaces are defined in the RAD and relevant national AIPs as having mandatory oceanic exit routes and the IFPS shall confirm compliance with such. Where the oceanic exit point given in the MFS differs from that given in the flight plan for such flights, the IFPS shall ensure that the revised route is compliant with the appropriate mandatory routes. Where a route must be constructed by the IFPS to connect the clearance limit given in the landfall point in the MFS to either the destination (or where that flight exits the IFPZ) or to make a logical and coherent connection with the existing flight plan route, that route shall, wherever possible, be made compliant with all relevant RVSM, 8.33 kHz, RAD and route availability restrictions.

(3) Message Format

Item ADEXP MFS

3 TITLE Compulsory

7a ARCID Compulsory

7b SSRMODE Optional

7c SSRCODE Optional

8a FLTRUL Not Allowed

8b FLTTYP Not Allowed

9a NBARC Optional

9b ARCTYP Compulsory



9c WKTRC Optional

10a CEQPT Not Allowed

10b SEQPT Not Allowed

13a ADEP Compulsory

13b EOBT Optional

14a,b,c ESTDATA Compulsory

14d,e ESTDATA Optional

15a,b SPEED & RFL Not Allowed

15c ROUTE Not Allowed

16a ADES Compulsory

16b TTLEET Not Allowed

18 various elements Not Allowed

Example of an MFS with no associated flight plan

Submitted message: (MFS-ABC907-B763-KSEA-SUNOT/0601F370-LFPG-KESIX)

Message distributed by the IFPS after processing:

(APL-ABC907-IG -B763/H-LOV/C -KSEA0113 -SUNOT/0601F370 -N0459F370 SUNOT DCT KESIX DCT LEDGO UN160 NAKID UM25 DVL -LFPG0952 -DOF/130115 IFP/833UNKNOWN RVSMUNKNOWN SRC/MFS ORGN/EGGXZOZX) Example of an MFS with an associated flight plan

Existing flight plan:

(FPL-ABC225-IS -B772/H-SDE1E3FGHIJ3J5J6M1M2RWXYZ/LB1D1 -KDEN0040 -M083F380 PORGY 58N050W 59N040W 59N030W 58N020W SUNOT/N0482F380 DCT KESIX DCT MIMKU/N0427F350 UL10 WAL UY53 NUGRA -EGLL0831 EGKK -PBN/A1B1D1O1S2 NAV/RNVD1E2A1 SUR/TCAS DOF/130115 REG/GYMNN EET/KZDV0007 KZMP0040 CZWG0138 CZYZ0153 CZUL0228 CZQX0333 58N050W0429 BGGL0446 CZQX0456 59N040W0506 EGGX0542 58N020W0620 SUNOT0641 KESIX0645 EGPX0702 EISN0711 EGPX0715 EGTT0724 SEL/BKAE CODE/4007F0 RVR/075 ORGN/EGLLZPZX RALT/CYYR EINN) Submitted MFS presented to the IFPS staff, with warning:

(MFS-ABC225-B772-KDEN-BILTO/0620F380-EGLL-BEGID)

ACH presented to the IFPS staff, with warning and error:

(ACH-ABC225-KDEN0040-EGLL-DOF/130115-14/BILTO/0620F380

-15/N0482F380 BILTO DCT BEGID DCT MIMKU/N0427F350 UL10 WAL UY53 NUGRA BNN1B-18/ PBN/A1B1D1O1S2 NAV/RNVD1E2A1 SUR/TCAS DOF/130115 REG/GYMNN EET/KZDV0007 KZMP0040 CZWG0138 CZYZ0153 CZUL0228 CZQX0333

58N050W0429 BGGL0446 CZQX0456 59N040W0506 EGGX0542 58N020W0620



SUNOT0641 KESIX0645 EGPX0702 EISN0711 EGPX0715 EGTT0724 SEL/BKAE

CODE/4007F0 RVR/075 RALT/CYYR EINN ORGN/EGGXZQZX SRC/MFS)

WARN256: ACH built from an IMFS

(Optional) ROUTE41: PLEASE CHECK NAS OF GENERATED PORTION: <List of NAS>.

ACH distributed by the IFPS after manual correction/check of the route by the IFPS staff:

(ACH-ABC225-KDEN0040-EGLL-DOF/130115-14/BILTO/0620F380

-15/N0482F380 BILTO DCT BEGID DCT MIMKU/N0427F350 UL10 WAL UY53

NUGRA-18/PBN/A1B1D1O1S2 NAV/RNVD1E2A1 SUR/TCAS DOF/130115 REG/GYMNN EET/KZDV0007 KZMP0040 CZWG0138 CZYZ0153 CZUL0228 CZQX0333

58N050W0429 BGGL0446 CZQX0456 59N040W0506 EGGX0542 58N020W0620

SUNOT0641 KESIX0645 EGPX0702 EISN0711 EGPX0715 EGTT0724 SEL/BKAE

CODE/4007F0 RVR/075 RALT/CYYR EINN ORGN/EGGXZQZX SRC/MFS)


On receipt of an MFS, the IFPS shall check for any existing associated flight plan. Where such is found, the IFPS shall treat that MFS as an amendment message; where no such flight plan exists, the IFPS shall process that MFS as an APL.

Where a submitted MFS does not include all optional items, the IFPS shall assume no change from those items as specified in the original flight plan where such exists. If no associated flight plan has been received by the IFPS, default values shall be inserted into those optional items that have not been completed.

When processed by the IFPS, messages from Shanwick shall be distributed as ACH or APL, with source MFS.


When processing MFS, the IFPS staff shall not be required to co-ordinate any necessary route modifications with the message originator.

Those MFS that are passed for manual treatment by the IFPS staff shall only have those modifications made to the route that are entirely necessary. See section ATC FLIGHT PLAN CHANGE (ACH): General Procedures for ACH with source FNM or MFS.

Where a route must be constructed by the IFPS to connect the clearance limit given in the landfall point in the MFS to either the destination (or where that flight exits the IFPZ) or to make a logical and coherent connection with the existing flight plan route. That route shall, wherever possible, be made compliant with all relevant RVSM, 8.33 kHz, RAD and route availability restrictions.

When errors are raised on the route portion right after the landfall point, the IFPS staff shall ensure that a re-routing does not take place on the route portion upstream of the landfall point.






134 ATC Flight Plan (APL)

(1) General

The ATC flight plan (APL) is that flight plan message type distributed by the IFPS upon receipt and successful processing of an FNM, MFS, and AFP for which no valid associated flight plan exists in the IFPS or upon successful processing of an AFP for a change of requested flight level or change of route which results in a new ATC unit being concerned by the amended flight trajectory.

The APL message distributed by the IFPS shall represent information relevant to a flight as submitted to the IFPS by an ATC unit.

APL messages created as a result of missing flight plan or diversion should be accepted and processes by all downstream ATS units as they contain useful information which was not previously available, even in the case that the first downstream unit already received notification for the missing flight plan (by OLDI message).

On receipt of AFP, FNM and MFS messages, the IFPS shall check for any associated flight plan. Where such is found, the IFPS shall output any changes from the original flight plan as a modification message with title ACH. Where it is necessary to transmit the full flight details to a previously un-addressed ATCU due to a change in the trajectory of that flight caused by the new information that flight plan information shall be sent as a message with title APL.

Where no associated flight plan is found, the IFPS shall distribute the details of the AFP, FNM or MFS messages in the form of an APL message to the relevant ATCU.

(2) Requirements

The IFPS shall accept those messages with title AFP, FNM or MFS relating to IFR/GAT flights or parts thereof operating wholly or partly within the IFPZ that result in the creation of APL messages.

(3) Message Format

The APL is generated within the IFPS from AFP, FNM and MFS messages.


Where a submitted AFP, FNM or MFS does not include all optional items, the IFPS shall assume no change from those items as specified in the original flight plan where such exists.

Certain default values are used by the IFPS when processing AFP, FNM or MFS that have no associated flight plan from which to extract those values, and the submitted messages do not contain that information.

The default values assumed by the IFPS when creating an APL for a missing flight plan shall be:

Flight rules – I Flight type – G Communications equipment – S

Surveillance equipment – S

134.1 General Procedures for APL due to no Valid Association

Before to be presented for manual processing to an IFPS staff, the propose route function will attempt to build a route from the end of the clearance limit (from FNM, MFS or AFP) to the aerodrome of destination.



Whenever the Propose Route Function was unable to find a valid route, the APL is presented for manual processing with the following error:


Whenever the propose route function was able to find a valid route and the flight type is not military, the APL is presented for manual processing with the following error:

ROUTE41: PLEASE CHECK NAS OF GENERATED PORTION: <List>.

Whenever the propose route function was able to find a valid route and the flight type is military, the APL is presented for manual processing with the following error:

ROUTE305: FLIGHT TYPE IS MILITARY. PLEASE CHECK NAS OF GENERATED PORTION: <List>.

In all cases, the IFPS staff shall check the Flight Plan History to see whether or not the flight plan was previously filed and rejected. If such is found, the IFPS staff shall use this information. For more details please refer to the corresponding error.

134.2 APL Additional Addressing

The AOCC (see Note below) shall receive a copy of the ACK message of the APL or ACH whenever an FNM or MFS associates with an existing flight plan and the route is different than the route present in the original flight plan).

The AOCC (see Note below) shall also receive a copy of the ACK message of the APL where the FNM or MFS does not have a flight plan in the IFPS with which to associate.

Note This only occurs when the system is able to determine the aircraft operator from the ARCID [Section DETERMINATION OF THE AIRCRAFT OPERATOR BY THE IFPS]



135 ATC Flight Plan Change (ACH)

(1) General

The ATC flight plan change (ACH) is that modification message type distributed by the IFPS upon receipt and successful processing of an FNM, MFS, and AFP for which a valid associated flight plan exists in the IFPS.

The ACH distributed by the IFPS shall represent information relevant to a flight as submitted to the IFPS by an ATCU.

On receipt of AFP, FNM and MFS messages, the IFPS shall check for any associated flight plan. Where such is found, the IFPS shall output any changes from the original flight plan as a modification message with title ACH.

ACH messages should not be considered for updating of system flight plan (local FDPS) by the first downstream ATC unit, as the notification messages from the upstream units contain the most recent flight plan information. These messages arrived in most of the cases before the IFPS messages due to the different procedures and communication mechanism applied.

ACH messages should be accepted and processed by all downstream ATS units except the first one, as they are supposed to arrive before the OLDI message and thus improving the traffic predictability and awareness with the concerned ATS units.

(2) Requirements

The IFPS shall accept those messages with title AFP, FNM or MFS relating to IFR/GAT flights or parts thereof operating wholly or partly within the IFPZ that result in the creation of ACHs.

Where the message submitted to the IFPS contains incomplete route details, the IFPS staff shall construct a route to connect the last point given in the submitted message either to a logical connecting point on the existing route given in the flight plan or to the aerodrome of destination (or where that flight exits the IFPZ).

Any such constructed route shall, wherever possible, take into account all routeing restrictions of RAD, RVSM, 8.33 kHz and route availability.

(3) Message Format

The ACH is generated within the IFPS from AFP, FNM and MFS messages.


Where AFP, FNM and MFS messages submitted to the IFPS for processing associate with existing flight plans held by the IFPS, the IFPS shall produce an ACH to distribute those changes to the relevant ATCU downstream of the ATCU submitting the AFP, FNM or MFS message.

135.1 General Procedure for ACH with source FNM or MFS

Whenever an ACH with source FNM or MFS is presented for manual processing with errors downstream of the landfall point the IFPS staff shall first ensure that the RFL at the landfall point is consistent with the RFL from the flight plan.

System Processing: Whenever the flight plan contains an explicit RFL at the landfall point and it is the same landfall in ACH, then the system automatically re-inserts the RFL from the flight plan into the ACH.



In all other cases, the IFPS staff shall retrieve from the flight plan the RFL at the landfall point or if not present, the previous upstream RFL from the landfall point and insert it manually into the ACH route (F15), after the landfall point and only if it is higher than the RFL in the FNM/MFS.

135.2 ACH Additional Addressing

The AOCC (see Note below) shall receive a copy of the ACK message of the APL or ACH whenever an FNM or MFS associates with an existing flight plan and the route is different than the route present in the original flight plan.

Note This only occurs when the system is able to determine the aircraft operator from the ARCID [Section DETERMINATION OF THE AIRCRAFT OPERATOR BY THE IFPS]



136 Voice Communications System (VCS)

(1) General

The Voice Communications System (VCS) is a device used for voice communications within the NMOC. It is a digitised telephone system that contains up to a maximum of 15000 stored telephone contact numbers for AOs, handling agencies, ATSUs and FMPs. As the total number of contact details is limited, not all message originators may be contacted by telephone when necessary. The majority of contacts that are held in the system are located within the IFPZ, but several of the more regular contacts world-wide are also stored.

Within the IFPS, a large part of the coordination to correct flight plans and associated messages in addition to the handling of general queries is carried out using the VCS. As such coordination is considered to be an official part of the processing procedures of IFPS. Therefore all calls, both incoming and outgoing, using this system are recorded. Such recordings are made for investigative purposes, and are retained for a period of 15 months.

(2) Requirements

All telephone contact, both from and to the IFPS, related to flight plans and associated messages shall be made using the VCS.

All operational calls to the IFPS shall only use those contact numbers indicated in [see SECTION NETWORK MANAGER OPERATIONAL CONTACTS 98H].

All verbal arrangements for the correction of flight plans and associated messages made between the IFPS staff and message originators using the VCS shall be considered an official contract between the two parties.

Co-ordination between the IFPS staff and message originators for the correction of flight plans and associated messages shall be made via the VCS only, and this method shall not be substituted by the use of the Transmit function.


The VCS contains telephone contact numbers for a variety of organisations. In order to refine the search when an organisation’s ICAO code is entered, each contact number has been grouped under one of several titles:

FMP (Flow Management Position) ARO (ATS Reporting Office)

FMU (Flow Management Unit) AO (Aircraft Operator)

TWR (Aerodrome Tower) ACC (Area Control Centre)

136.1 General Procedure for Contingency Diversion of Voice Communications System (VCS)

It is possible to divert all incoming calls to an IFPS unit to the other unit either by the diverting IFPS unit or by means of an intervention by the VCS Support Team in the ENG Division. During extended outages (planned or unplanned) at an IFPS unit, the IFPS unit supervisors shall give consideration to arranging for all incoming calls at the unserviceable unit to be diverted to the other unit.

The explicit approval of the Operational Division management is required before requesting such an intervention.






137 The Transmit Function

(1) General

The Transmit function is a tool that enables the IFPS staff to construct and send plain text messages to SITA and AFTN addresses directly from the IFPS workstations. The purpose of this function is to enhance the service offered by the IFPS, but it shall not be used to replace any part of that service.

(2) Requirements

The Transmit function shall not be used to replace verbal co-ordination between the IFPS staff and the message originator where such co-ordination is required to correct any message.

The use of the Transmit function in any situation shall be dependent upon the workload of the IFPS staff at the time, and shall also be dependent upon the quality of submitted messages program.

(3) Message Format

The following pre-formatted texts are available for use by the IFPS staff:

PLEASE DO NOT SEND MESSAGES INTENDED FOR FLOW MANAGEMENT TO IFPS.

INCORRECTLY ADDRESSED MESSAGES COULD CAUSE DELAYS FOR THE FLIGHTS CONCERNED.

BEST REGARDS NMOC BRUSSELS - IFPS

ORIGINATOR +++XXXXXXXX+++ HAS ADVISED THAT THE ADDITIONAL ADDRESS +++XXXXXXXX+++ IS UNKNOWN. THE MESSAGE HAS NOT BEEN RECEIVED BY THIS ADDRESS.

PLEASE CHECK AND REPEAT YOUR MESSAGE DIRECTLY TO THE CORRECT ADDRESS.

PLEASE DO NOT REPEAT THE MESSAGE TO IFPS.

BEST REGARDS NMOC BRUSSELS - IFPS

ON BEHALF OF <XXXXX> ATSU, XXXXZQZX, THE FOLLOWING FPL <KEYFIELDS> CONTAINS ROUTE INCONSISTENCIES FOR XXXX AIRSPACE.

XXXX ATSU, IN LINE WITH COMMISSION REGULATION (EC) NO 1033/2006 HAS INFORMED IFPS AND REQUESTS A

CHG TO BE SENT IN ORDER TO CORRECT THE ROUTE AS FOLLOWS

(*****AMOD MSG GOES HERE*****)

A CHG OR CNL+ REFILE SHOULD BE SENT AS SOON AS POSSIBLE.

BEST REGARDS EUROCONTROL NMOC – IFPS

YOUR FLIGHT PLAN MESSAGE WAS NOT VALID AND WE WERE NOT ABLE TO CONTACT YOU.

YOUR MESSAGE HAS BEEN REJECTED, PLEASE REFILE.

ONE POSSIBLE SOLUTION IS:



BEST REGARDS EUROCONTROL NMOC - IFPS

BEST REGARDS EUROCONTROL NMOC – IFPS

(SPL-ARCID/SSR MODE+CODE-ADEP+TIME-ADES+EET+ALTERNATE-

REG/XXXX RMK/XXXX E/XXXX P/XXX R/X S/X J/X D/XX XXX C XXX A/XXXX N/XXXX C/XXXX)

FPL FOR ARCID-ADEP-ADES AVAILABLE, BUT NO ITEM 19 INFORMATION

RECEIVED BY THE IFPS.

MESSAGE SENT TO THE IFPS FROM [**SITA/**AFTN] ADDRESS <XXXXX>

NO FPL ARCID-ADEP-ADES HELD BY IFPS

YOUR DLA/CNL/CHG/DEP/ARR MESSAGE WAS TREATED MANUALLY BECAUSE OF INCORRECT ICAO 2012 FORMAT.

THE CORRECT FORMAT SHOULD READ:

(DLA-ARCID-ADEPEOBT-ADES-DOF/++++++)

(CNL-ARCID-ADEP-ADES-DOF/++++++)

(CHG-ARCID-ADEP-ADES-DOF/++++++-FIELD CHANGE)

(DEP-ARCID-ADEPATD-ADES-DOF/++++++)

(ARR-ARCID-ADEP-ADESATA-DOF/++++++)

In all these template messages, the text surrounded by +++ shall be manually replaced by the relevant details of the message involved by the IFPS staff preparing the message for transmission.

Where messages other than these pre-formatted texts are required, the information may be typed in manually or copied from other sources as necessary.


The Transmit function shall not be used to replace verbal co-ordination between the IFPS staff and the message originator where such co-ordination is required to correct any message.

The IFPS staff may use the Transmit function in the following situations:

All the situations matching the pre-formatted texts listed above.

When the IFPS staff consider further explanation or information than is contained in a reject message would be of benefit to a message originator.

To transmit a SPL upon receipt of an RQS message. To request information from a message originator, for example, a contact telephone number. To provide the correct contact details for ATFCM upon receipt of a message to do with flow

regulation. To indicate the procedure necessary to bring forward the departure time of a flight. To relay /forward rerouteing requests received from individual States (see 149.6).

The IFPS staff shall not use the Transmit Function in the following situation:

To provide a relay service for messages related to overflight permits, diplomatic clearances or messages of a political nature regarding flight plans distributed by the IFPS. The message originator



address is included (in Item 18 under ORGN/) in all flight plans and associated messages sent out by the IFPS in order that any such messages may be sent directly to the message originator.






138 Service and Other Non-Standard Messages

(1) General

On occasion, the IFPS receives plain text messages from a variety of different sources. Such messages may include:

Internal aircraft operator company messages that may not be relevant for the IFPS. Overflight permission refusals from individual States. Requests from individual States that a particular flight alters its flight planned route.

And various other types of message.

Service messages are also received from communications centres indicating that they have received from the IFPS a message with an unknown local address, or requesting re-transmission of a particular message.


All non-standard messages shall either be discarded or automatically rejected or be passed to the IFPS staff for manual processing.

138.1 Rerouteing Requests from Individual States

Explanation: A national authority may send the IFPS a message indicating the filed route a particular flight is not acceptable, and indicate an alternative routeing.

Instruction: If the re-routeing request is related to overflight permits, diplomatic clearance or of a political nature the IFPS staff shall not transmit/forward the message.

In all other cases, on receipt of such a message, the IFPS staff shall open a Transmit window, insert the following text:

‘IFPS has received the following message from <originator address> <original message text>

IFPS is taking no action on this matter and leaves all further action to yourselves’ and send the message to the originator address of the flight plan.

The IFPS staff shall raise an Ops Incident in Remedy CCMS, so that the originator of the message can be advised to send service messages in future directly to the originator of the flight plan and not to the IFPS.

138.2 Internal Aircraft Operator Messages

Explanation: Aircraft Operators occasionally send a copy of the fuel plan for a flight to the IFPS instead of, or as well as, the ICAO flight plan. Such messages are often several pages long, and are received as several individual messages.

Instruction: The originator of such messages should be contacted and advised that the IFPS does not accept fuel plans and



requested to refile, if and where necessary, a flight plan in the correct format.

138.3 Service Messages Requesting Re-transmission of a Particular Message

Explanation: Communications service centres occasionally receive corrupted or incomplete messages, and may send a request for the re-transmission of such messages.

Instruction: On receipt of such a message, the IFPS staff shall retrieve the relevant message from the IFPS Output log files.

On locating the message in the valid flight plan log, the IFPS staff shall make a manual Transmit of the requested message to the service message originator’s address.

138.4 Service Messages Indicating an Unknown Local Address

Explanation: Where the IFPS transmits a message to an unknown address, the communications centre dealing with that address may return a service message (SVC) or a free text message to the IFPS indicating the incorrect address and the date/time group of the transmitted message.

No details of the callsign are included in such messages.

Instruction: On receipt of such a message, the IFPS staff shall retrieve the relevant message from the IFPS Output log files.

Where the address has been generated automatically by the IFPS, an Ops Incident shall be raised in Remedy CCMS.

Where the incorrect address originates from the re-addressing function (AD line), then the IFPS staff shall send a message to the originator of that message informing them of the error.

The service message shall be deleted by the IFPS staff.

138.5 Other Free text Messages and TAF/METAR messages

Explanation: A free text message or a TAF/METAR message has been addressed to the IFPS.

Instruction: The message shall be deleted by the IFPS staff.



139 IFPS Unserviceabilities

139.1 General

The IFPS consists of two units (IFPS units: FP1, Haren and FP2, Brétigny). The IFPU1 Unit processes all messages while the IFPU2 Unit is the back-up.

Under normal operating conditions, an IFPS unit role exists where each IFPS unit has a certain role with respect to an IFPS Group; that role may be:

139.2 Responsible (IFPU1)

Where that IFPS unit shall be responsible for processing messages relating to flights departing within that aerodrome group.

139.3 Backup (IFPU2)

Where that IFPS unit shall not be responsible for processing messages relating to flights departing within that aerodrome group. Such messages shall be stored in the backup file of that IFPS unit.

139.4 None

Where one IFPS unit does not have either the role of Responsible or Backup for processing messages from an aerodrome group. Under the current organisation of IFPS units, this role only occurs during the full shutdown of an IFPS unit, normally for maintenance.

Should the Responsible IFPS unit suffer a critical failure, and the repair time is so long that message processing may start to suffer a significant effect, then the IFPS Contingency Plan requires that the Backup IFPS unit be able to take over responsibility for the failed IFPS unit. In this plan, the Backup IFPS unit may be instructed by the CSO to take over responsibility for the failed IFPS units aerodrome groups until that IFPS unit can be returned to service.

The decision to take over the responsibility will only be taken after an assessment of all factors, as a take-over, whether partial or whole, will have a significant impact on the operation of both IFPS units.

An IFPS unit having taken over responsibility for processing traffic following the failure of the other unit may experience some delay in processing new messages while the IFPS reprocesses existing flight plan data from Back-up to Responsible before processing new data.

139.5 General Procedures for IFPS Remote Login

A remote login facility has been developed to enable IFPS workstations at one IFPS unit to log in to and process the messages of the other IFPS unit.

Under normal conditions this facility remains inactive, and it is preferable to keep any periods where it is used to the minimum.

The IFPS unit supervisor managing the remote login shall advise the IFPS staff on the optimum processing strategy to be used based on experience and advice from technical staff and the Operational Division management.



Before any decision to activate the remote login facility is made, the IFPS unit supervisors shall consider all other alternatives such as aerodrome group switchover, calling in staff on overtime, etc.

The IFPS unit supervisor shall request CSO to advise whether the remote login can be used in the event of any serious technical problem affecting either IFPS unit.

The IFPS unit supervisor is authorised to request CSO to activate the remote login facility in the following circumstances:

in case of failure at either IFPS unit, CSO shall establish that the workstations of the failed IFPS unit might still be used to log in to the serviceable IFPS unit, if required, to assist in dealing with the increased workload;

where there is a severe temporary imbalance of the workload between the two IFPS units, and one IFPS unit has a significant capacity to assist the other;

should there be a failure of local IFPS unit workstations, during which failure the contribution of the remote operator login is needed.

The IFPS unit supervisor shall inform the COM and Operational Division management each time the remote login facility is activated.

Close coordination between IFPS unit supervisors and with CSO shall be maintained during any utilisation of the remote login facility.

139.6 Contingency Documentation

Internal IFPS Contingency Documentation

IFPS contingency procedures are described in detail in the IFPS System Operation Procedure (SOP) document. This document is available at:

\\CFMUFS01\Public\ENG\_doc\IFPS\Official\USD\SOP\15.006

Internal NMOC Contingency Documentation

NMOC Contingency Operations Manual contains relevant instructions and procedural information in the event of contingency situations. This manual is available at:\\sky.corp.eurocontrol.int\DFSRoot\Groups\DNM\OPSD\OPS_Documents\Disruption & Crisis\02_Internal & NMOC failure\NMOC Contingency Operations Manual\Official\



140 System Maintenance and Interventions

(1) General

140.1 System Maintenance

Regular preventative maintenance is required on the NM operational systems at both IFPS units. During these maintenance windows, the concerned IFPS units shall not process any flight plans or associated messages, nor shall they have access to any of the normal systems or databases.

Maintenance windows shall normally be scheduled for every second week in each IFPS unit, with alternate units undergoing the maintenance each week. The times of the maintenance windows in each unit are as indicated below (all times in UTC):

Section Maintenance Window Summer Winter

FP2 (Brétigny)

Monday night/Tuesday morning 2300-0000 0000-0100

FP1 (Haren) Tuesday morning 0000-0100 0100-0200

Before the IFPS is stopped, CSO shall make a co-ordination with the IFPS duty supervisor. Authorisation for the withdrawal of the IFPS may, in very exceptional circumstances, be delayed by the IFPS unit supervisor where an unusually high number of invalid messages are awaiting manual processing by the IFPS staff.

140.2 General Procedures for interventions

140.3 Planned Interventions

A list of planned interventions, as scheduled by the OCCB, is published each Thursday and sent to both IFPS unit supervisors via e-mail. Where required, urgent interventions may also be approved outside the normal OCCB schedule. Details of such interventions shall be sent to the IFPS unit supervisors via e-mail.

Planned intervention details are not normally distributed outside the NM, however, where such an intervention shall keep one IFPS unit out of service for longer than normal, the details may be published via an AIM.

140.4 Additional Interventions

Where a decision to approve the withdrawal of the IFPS for additional interventions is required, that decision shall be made by the Operational Division management.

Should the IFPS duty supervisor receive a request to stop the IFPS during or outside office hours, that request shall be referred to the Operational Division management unless previously approved.






141 ETFMS Unserviceabilities

(1) General

Under the guidelines laid out in the NMOC Contingency Operations Manual and the NM Disaster Recovery Plan, should it become necessary to evacuate the NMOC, the ATFCM staff may be required to move to a contingency site. In the event of a full evacuation of the NMOC in Haren, the ATFCM staff may be required to relocate to the contingency operations room at FP2 in Brétigny or to the 3rd site in Nossegem. In the event of either such relocation of the Flow Management operations, the ATFCM VCS telephone system shall also be diverted to the appropriate location.

In the event of a major failure of the ETFMS and of the NM communications in Brussels, or in the event of an evacuation of the NMOC, the FP2 supervisor may be required to issue ATFM contingency plan AIM messages on behalf of the NMOC.

(2) Requirements

The FP2 staff may be required to issue ATFM contingency plan messages on the instruction of the COM.

(3) Message Format

A number of pre-formatted messages and their associated address lists are held in the MPMT in FP2. Where non-standard messages are required, the text and format used shall be that which is appropriate for that specific message.


The FP2 supervisor shall issue operational Contingency Plan messages as instructed by the OM.

Preformatted ETFMS contingency plan messages and their associated address lists are stored in the MPMT terminal in local disk under: EUROCONTROL\MPMT\Prepared messages and in Section 6 of the G:\DNM\OPSD\OPS Documents\Disruption & Crisis\02 Internal & NMOC Contingency Operations Manual\Official\NMOC Contingency Operations Manual.pdf.

Among the types of contingency message that are stored in the FP2 MPMT terminal, the following are related to ETFMS contingency:

ETFMS not available flash

Alert Flash Message – Procedural Contingency Normal ETFMS Operations Resumed Recovery Flash Message – Procedural Contingency

The OM shall instruct the FP2 supervisor on the content of the message fields, and any necessary changes to the information content of the operational contingency plan messages. Messages shall be created and sent using the MPMT terminal (detailed information can be found in the Sections 5 and 6 of the G:\DNM\OPSD\OPS_Documents\Disruption & Crisis\02_Internal & NMOC failure\NMOC Contingency Operations Manual\Official\NMOC Contingency Operations Manual.pdf):

Start the MPMT program.

Press Connect to AN1 OPS Brétigny. Select Message/Create. In Prepared Messages select GET. Open the FLASH MESSAGES folder. Highlight the appropriate .mpm file and press open.



Fill the empty fields as requested by the COM.

In Collectives select AIM. Press send.



142 Manual Creation of Messages

(1) General

Occasionally the IFPS may receive messages via non-standard means such as fax messages. As a rule, this should be discouraged, as it is time-consuming and liable to errors in the input of the message, but where a message originator has no other option, it may be accommodated as the only available option.

(2) Requirements

The message originator must provide a SITA or AFTN address for the IFPS staff to enter in the message originator window in any manually-created message. This address shall receive subsequent appropriate operational reply messages.

The details of any message created manually by the IFPS staff shall be noted in the IFPS operations log, and any fax details shall be retained.


When manually creating messages, the IFPS staff shall always take any AFTN or SITA address given by the message originator and include it in the message originator window of the flight plan editor in order to facilitate the addressing of any relevant operational reply and flow regulation messages from the NMOC.

Where a message is created manually by the IFPS staff, and no information is entered into this window, the aircraft operator is unlikely to receive any of the flow regulation messages that may relate to that flight.

IFP Indicators

Not relevant.


Where the IFPS staff are contacted by an aircraft operator, via any means other than AFTN or SITA, who reports difficulties in submitting messages via AFTN or SITA, that aircraft operator should be encouraged to try all means of message submission before resorting to a fax message.

Where no other option is available, the IFPS staff may approve the submission of messages via fax, but the aircraft operator shall be instructed to include an appropriate AFTN or SITA address that may be used for the originator address in the manually-created message.

Note Before approving such actions, the IFPS staff should establish the urgency of the message: if it relates to a flight taking part several hours in the future, then the aircraft operator should be encouraged to continue to try all other means of message submission. Only where the message relates to a flight that is relatively close to its EOBT should the IFPS staff accept messages from sources other than AFTN or SITA.

The IFPS staff have two options available for the manual creation of messages:

directly via an IFPS workstation, using the Create facility. The IFPS staff shall ensure that where an originator address is given with the submitted message, it is copied to the originator window in the Create facility, also an appropriate date of flight shall be included by the IFPS staff in all messages.

via the AFTN/SITA/MPMT terminal, using the originator address code provided in the submitted message.



Note An IFPS address shall not be used as an originator address in any messages created manually by the IFPS staff.

The IFPS staff shall note the details of any message created manually in the IFPS operational log, and the original fax received shall be retained, as it represents an instruction received from an external user of the IFPS.



143 Message Rejected by Partner

(1) General

The IFPS may receive an alert message ‘MSG_REJECTED_BY_PARTNER’, indicating that the ETFMS or the ANg1 has been unable to accept a message it has received from the IFPS.

(2) Requirements

The alert message ‘MSG_REJECTED_BY_PARTNER’ may be caused by a variety of different problems, and must always be investigated by the IFPS supervisor to establish the cause of the rejection. The alert message shall be sent to all logged on workstations.


On receipt of the alert message ‘MSG_REJECTED_BY_PARTNER’, one of the IFPS supervisors at either unit (coordination shall take place to ensure that the alert message is dealt with and only once) shall retrieve the relevant message from the Activity Logs as follows:

In the CHMI select ‘Application’, then ‘IFPS’, then ‘Activity Logs’.

From the ‘Log Type’, select ‘Msg Rejected by Partner’.

Modify the date and time as necessary. Select ‘Execute’ from the command menu.

A list of any messages rejected by the ETFMS or ANg1 shall appear. The entry in the column ‘Program Name’ identifies which system has rejected the message:

vn_tactout = ETFMS

vn_an1out = ANg1

Depending on the contents of the message, the appropriate action should be taken by the IFPS supervisor, and all details noted in the IFPS operational log. The task may be delegated by an IFPS supervisor to an IFPS staff.

143.2 Message Rejected by ETFMS

Program Name ref. vn_tactout

Explanation: The error is generated when the message sent from IFPS to ETFMS is in a format that cannot be processed by the ETFMS system.

Instruction: The IFPS supervisor shall notify the Flow Management operations staff of the details of the rejection, and of any actions taken by the IFPUS supervisor as a result of that rejection.

If the reason for the rejection of the message has not previously been recorded via an incident, a new incident shall be created via CSO.

Note Due to the variety of possible causes of a message being rejected by the ETFMS, the IFPU supervisor shall have to carry out an analysis to determine the cause of the rejection, and the appropriate action in response. Where appropriate, it may be necessary to enlist the assistance of



departments within the NM to assist in determining the cause of the problem.

143.3 Message Rejected by the ANg1

Program Name ref. vn_an1out

Explanation: The error is generated when a message planned for distribution in ADEXP format exceeds the maximum number of characters possible for a message to be transmitted via AFTN (1800 characters maximum). Such messages are causing a rejection at AN1 level

The flight plan generating the error is valid in IFPS, and has been processed by TACT, but cannot be distributed in ADEXP because it exceeds the maximum characters limit. This should only occur whenever the flight plan covers an extensive distance and/or a long field 15 generating a large number of addresses, and numerous EETs; frequently military flights.

The consequence is the non-distribution of the flight plan message to all addresses requesting a distribution in ADEXP format.

Instruction: Whenever the IFPS supervisor receives a message regarding a message rejected by remote system such as ‘A message was rejected by the Remote System. Cause: P015: Error on data field.

Greater than network maximun length! Rejected Message is:

010429IFAAN1090622001216DAT704537 01AFTN00000408EDDAYGLZ08EDDXYIYT08EDYYZQZA08EGZYTT

AD<-TITLE IFPL

-BEGIN ADDR

-FAC CZQXZOZX’

Note AN1 indicates the system that has rejected the message.

The IFPS staff shall:

Check in the FPL history if any associated messages have been processed since the date/time stamp of the message rejected by the remote system. (DDHHMMSS format as underlined in the example above). If the same or an updated version of the rejected message has been processed, then do not action the rejected message and log the occurrence.

Otherwise:

The message needs to be reduced to a number of characters less than 1800.



Copy-paste the message into a Word document. Go to Review>Word count. It will open a window displaying the character count.

Apply as many of the following steps as necessary to reach a number of characters below 1800:

o Step 1: Remove the addressing lines from –BEGIN ADDR to –END ADDR (remove all lines after the -TITLE line until the –ADEP line).At this stage, care should be taken not to remove the first line of the message which is –TITLE as it is essential for units receiving messages in ADEXP.

o Step 2: Remove the lines appearing after: -END RTEPTS.

o Step 3: Remove the lines from -BEGIN RTEPTS until –END RTEPTS.

o Step 4: if present, remove the lines where the field names are –GEO and –RENAME (located after –EETFIR).

Use the Message Sender icon to open a free text transmit window and copy/paste the message from the word doc to the transmit window. Do not use the function “transmit this FPL” from the FPL history to transmit ADEXP format messages. This is to avoid some ADEXP fields from being dropped.

Transmit the messages to all requesting ADEXP addresses by checking in the history who should have received it in ADEXP format (not including the ETFMS).

Log/communicate the action to team members in case further transmit events are needed.






144 Dictionary of Abbreviations

ABBREVIATION DEFINITION

AA Aircraft Address

ACH ATC Flight Plan Change (message)

ACK IFPS Acknowledgement (message)

ADEP Aerodrome of Departure

ADES Aerodrome of Destination

ADOU Airspace Data Operations Unit

AFP ATC Flight plan Proposal (message)

AFTN Aeronautical Fixed Telecommunication Network

AFIL Airborne Filed Flight Plan

AIC Aeronautical Information Circular

AIM ATFCM Information Message

AIP Aeronautical Information Publication

AIRAC Aeronautical Information, Regulation and Control

ALTN Alternate aerodrome(s) indicator

ALTRV Altitude reservation

AME ATM Msg Exchange

AMOD ATC Modification (sort of abbreviation in order that a particular message type always fails automatic processing in the IFPS)

ANSP Air Navigation Service Provider

ANU Air Navigation Unit

AO Aircraft Operator

AOA Aircraft Operator Agency

AOWIR Aircraft Operator WHAT-IF Reroute

APL ATC Flight Plan (message)

ARCID Aircraft Identification

ARO Air Traffic Services Reporting Office

ARR Arrival




ATC Air Traffic Control

ATCU Air Traffic Control Unit

ATFCM Air Traffic Flow and Capacity Management

ATFM Air Traffic Flow Management

ATFMX ATFM measures exemption

AFTN Aeronautical Fixed Telecommunication Network

ATS Air Traffic Services

ATSU ATS Unit

AUA ATC Unit Airspace

AUP Airspace Use Plan

CACD Central Airspace and Capacity Database

CCMS Central Claim Management System

CDR Conditional Route

CFSP Computerised Flight Plan Service Provider

CHG Modification (message)

CHMI Collaboration Human Machine Interface

CNL Cancellation (message)

CODE Aircraft address

COM Communications applications or capabilities

CPDLC Controller Pilot Data Link Communications

CPDLCX CPDLC Exempted

CSO Customer technical Service desk and Operations

CTA Calculated Time of Arrival

CTOT Calculated Take-Off Time

DAT Data applications or capabilities

DCT Direct

DEP Departure aerodrome

DES De-suspension message




DEST Destination aerodrome

DLA Delay (message)

DLE En-route delay or holding (ICAO 2012)

DMR Data Modification Request

DOF Date of flight

DPI Departure Planning Information

EET Estimated Elapse Time

EFPM Extended Flight Plan Message

EM Error Message

EMER Emergency

EOBD Estimated Off-Block Date

EOBT Estimated Off-Block Time

ERR Error (message)

ETFMS Enhanced Tactical Flow Management System

ETOPS Extended-range Twin-engine Operational Performance Standard

ETOT Estimated Take-Off Time

EUR Europe

EUROCONTROL European Organisation for the Safety of Air Navigation

FDI FAA Departure Information

FFR Fire Fighting

FIR Flight Information Region

FLS Flight Suspension (message)

FLTCK Flight check (for calibration of navaids)

FMP Flow Management Position

FNM Flight Notification Message

FP1 NM - IFPS Unit Section - Haren Brussels (BELGIUM)

FP2 NM - IFPS Unit Section - Brétigny-sur-Orge (FRANCE)

FPL Flight Plan message (ICAO format)




FRA Free Route Airspace

FUA Flexible Use of Airspace

GAT General Air Traffic

GNSS Global Navigation Satellite System

HAZMAT Hazardous material

HEAD Head of State

HOSP Hospital flight

HUM Humanitarian mission

IACH Individual ATC Flight Plan Change

IATA International Air Transport Association

ICAO International Civil Aviation Organization

IDLA Individual Delay message

IFP Keyword from IFPS used in Field18 to provide a warning

IFPL Individual Flight Plan (message)

IFPS Integrated Initial Flight Plan Processing System

IFPU IFPS Unit

IFPUV IFPS Unit for Validation

IFPZ IFPS Zone

IFR Instrument Flight Rules

IS IFR Scheduled flight

IOBD Initial Estimated Off-Block Date

IOBT Initial Estimated Off-Block Time

kHz KiloHertz

LVL Level

MAN Manual (message)

MARSA Military Assumes Responsibility for Separation of Aircraft

MAX Maximum

MEDEVAC Medical evacuation




MFS Message from Shanwick/Santa Maria

MIL Military

MNPS Minimum Navigation Performance Specification

MSG Message

NAS National AirSpace

NAT North Atlantic Region (ICAO)

NAV Navigation

NEWCTOT New Calculated Take-Off Time

NLST New List

NM Network Manager

NMC NM – Network Management Cell

NMD Network Management Division

NMIC Network Management Incident Coordination Cell

NMOC Network Management Operations Centre

NONRVSM Non-RVSM capable flight

NOO Network Operations Officer

NOP Network Operations Plan

NOS Network Operations Specialist

NOSU Network Operations SUpervisor

NOTAM Notice to Airmen

OACC Scottish Oceanic Area Control Centre

OAT Operational Air Traffic

OBT Off-Block Time

OPR Operator

OPR Operational Problem Report

ORM Operational Reply Message

OTS Organized Track System

PBN Performance Based Navigation




PER Aircraft Performance

RAD Route Availability Document

RALT En-route alternate(s)

REG Registration

REG Regulation

REJ Reject (message)

RFL Requested Flight Level

RFP Replacement Flight Plan Procedure

RIF Reclearance In Flight

RLST Revised List

RMK Remark

RNAV Area Navigation

RNAVX Non- RNAV

RNP Required Navigation Performance

RRP Rerouteing Proposal Message

RQP Request Flight Plan (message)

RRTEREF Route Reference

RSA Restricted Airspace

RSI Regulated Slot Issued

RVR Runway Visual Range

RVSM Reduced Vertical Separation Minimum (in Europe)

SAFA Safety Assessment of Foreign Aircraft (Programme)

SAM Slot Allocation Message

SAR Search and rescue

SCP1 Standard Correction Procedure 1

SCP2 Standard Correction Procedure 2

SEL SELCAL

SEQ Sequence




SITA Société Internationale de Télécommunications Aéronautiques

SITATEX Software developed by SITA

SNOS Senior Network Operations Supervisor

SOTA Shannon Oceanic Transition Area

SP Significant Point

SRC Source Indicator

SRD Standard Route Document

SSR Secondary Surveillance Radar

STA Scheduled Time of Arrival

STATE State flight

STS Status Indicator

SUR Surveillance

TALT Take-off alternate

TFC Time of Arrival

TMA Terminal Manoeuvring Area

TO Time Over

TOT Take-Off Time

TP Terminal Procedure

TWR Tower

TYP Type

UFN Until Further Notice

UHF Ultra-High Frequency

UIR User Identification

UNT Until

UTC Coordinated Universal Time

VFR Visual Flight Rules

VHF Very High Frequency

VOR VHF Omni-Directional Radio-Range




WEF With Effect From

WIR WHAT-IF Reroute



145 EUROCONTROL Specification for the Initial Flight Plan

Traceability between Edition 1.3 of the Eurocontrol Specification for IFPL and this edition of the IFPS User Manual.

IFPSpec Requirement Identifier

Applicable IFPS User Manual Section

Context of EUROCONTROL Specification compliance with Regulation (EC) No 1033/2006 (as amended)

IFP-APP-001 - Applicability Definitions

IFP-RRS-001 - Definitions for roles & responsibilities

IFP-DEF-001 144, 147 Defined Terms and abbreviations

IFP-FMS-001 3, 4(1), 4.1, 4.2, 4.3, 5, 6 Message submission to the IFPS

IFP-FMS-002 3, 4(1), 4.1, 4.2, 4.3, 8, 9, 10, 11, 12.

ARO Message submission to the IFPS ARO coordination with AO

IFP-RMS-001 - Message submission to the IFPS

IFP-FCK-001 3, 23, 24, 25, 63-101, 114-119

Checking of Flight Plan Flight Plans and associated messages

IFP-FFT-001 63-101, 114-117 AO compliance with Format and data conventions for FPL, CHG, DLA, CNL

IFP-FFT-002 9, 10, 11, 12 IFPS compliance with format and data conventions for ACK, MAN, REJ

IFP-AFT-003 121-133 ATC compliance with formats and data conventions

IFP-FAS-001 23, 24 IFPS Flight Plan association checks

IFP-FAS-002 23, 24 IFPS Flight Plan association checks

IFP-FAS-003 23, 24 IFPS Flight Plan association process

IFP-ORM-001 9, 10, 11, 12 Operational Reply Messages from IFPS

IFP-ORM-002 12 Copies of Operational Reply Messages from the IFPS

IFP-ORM-004 8, 9, 10, 11 Operational Reply Messages from the IFPS

IFP-ACK-001 9 Acknowledgements from the IFPS

IFP-REJ-001 11 Rejections from IFPS

IFP-ORMA-001 9, 10 AO response to Long ACK or MAN messages

IFP-ORMA-002 12 Copies of ORMS

IFP-REJA-001 11 AO corrections to rejected Flight Plans






IFP-ORMD-001 17 Message originator making agreed flight plan available to AO

IFP-ORMF-001 8, 9, 10, 11 No ORM returned

IFP-REF-001 10, 11 Referral or rejection of Flight Plans by the IFPS

IFP-SCP-001 17, 18, 19 Standard correction procedures

IFP-SCP-002 17, 18, 19 Manual correction of errors in messages

IFP-4DPC-001 25 Four-Dimensional Profile Calculation

IFP-IDIS-001 5, 125, 134, 135 Distribution to ATS Units

IFP-EDIS-001 6 Distributions Using the IFPS Re-Addressing Function

IFP-FPLSUB-001 114 Submission of Flight Plan messages

IFP-FPLSUB-002 114 Submission of Flight Plan messages

IFP-FPLSUB-003 114, 64-75, 79, 81 Submission of Flight Plan messages

IFP-FPLREF-001 23, 24, 64, 68, 75, 116 Re-filing of Flight Plans

IFP-FPLCHK-001 64-75, 79, 81, 94 Checks to ensure Key IFP data provided in Flight Plans

IFP-FPLCHK-002 24, 114 Checking of FPLs that are treated as changes to an existing Flight Plan.

IFP-CHGSUB-001 23, 24, 114 Submission of Flight Plan Changes

IFP-CHGSUB-002 115 Submission of Flight Plan Changes

IFP-CHGSUB-003 115, 116 Submission of Flight Plan Changes

IFP-CHGSUB-004 - Flight Plan Changes

IFP-CHGCHK-001 115, 64-75, 79, 81, 94 Checks to ensure Key IFP data provided for changes

IFP-CHGCHK-002 115, 116 Delays provided in CHGs

IFP-DLASUB-001 115, 116 Submission of Delay (DLA) messages

IFP-DLASUB-002 116 Submission of Delay (DLA) messages

IFP-DLATFM-001 116 + ATFCM User Manual

Compliance with ATFCM Slot Management Procedures

IFP-DLAPRO-001 116 IFPS Processing of DLA Messages

IFP-DLAPRO-002 116 IFPS Processing of DLA Messages

IFP-CNLSUB-001 117 Filing of Flight Cancellations

IFP-CNLSUB-001 24, 117 Filing of Flight Cancellations






IFP-RQSUB-001 120, 125 Submission of Flight Plan Data Requests

IFP-RQPRO-002 97, 120, 134 IFPS Processing of Flight Plan Data Requests

IFP-AFPSUB-001 125 Missing Flight Plans - AFP Submission

IFP-AFPSUB-002 125 Missing Flight Plans - AFP Submission

IFP-AFPPRO-001 124, 134, 135 Missing Flight Plans - IFPS Processing of an AFP Message

IFP-AFPPRO-003 124 Missing Flight Plans - IFPS Processing of an AFP Message

IFP-REVAL-001 20 Pre-Flight Updates & Revalidation - flight Suspension

IFP-REVAL-002 20 Pre-Flight Updates & Revalidation - flight Suspension

IFP-REVAL-006 20 Pre-Flight Updates & Revalidation - flight Suspension to ATC Units

IFP-REVAL-003 20 Actions Following Suspensions Triggered by Environment Data Changes

IFP-REVAL-004 20 + ATFCM User Manual Actions Following Suspensions Triggered by Environment Data Changes

IFP-REVAL-005 20 Actions Following Suspensions Triggered by Environment Data Changes

IFP-ACFT-001 9 Communication of Flight Plan Conditions of Acceptance to Aircraft

IFP-ATCCOO-001 126 Coordination by ATC Units with IFPS

IFP-ATCCOO-002 126, 134, 135 Coordination by ATC Units with IFPS

IFP-AOOPI-001 - Aircraft Operator Responsibility for Proceeding With the Flight

IFP-ACID-001 64 Aircraft Identification

IFP-FR&TYP-001 65 Flight Rules and Type of Flight

IFP-FR&TYP-002 65 IFPS processing of Flight Rules and Type of Flight

IFP-ACT&WC-001 66 Aircraft Type & Wake Turbulence Category






IFP-ACT&WC-002 66 IFPS processing of Aircraft Type & Wake Turbulence Category

IFP-ACEQPT-001 67 Aircraft Equipment & its related capabilities

IFP-ACEQPT-002 67 IFPS processing of Aircraft Equipment & its related capabilities

IFP-ACEQPT-003 67 IFPS processing of defaults for Aircraft Equipment & its related capabilities

IFP-ADEP&T-001 68 ADEP & EOBT fields

IFP-ADEP&T-002 68 IFPS processing of ADEP & EOBT fields

IFP-ROUTE-001 69-74 Route field

IFP-ROUTE-002 69-74 IFPS processing of the Route field

IFP-ADES-001 75-89 ADES field

IFP-ADES-002 75-89 IFPS processing of the ADES field

IFP-EOBD-001 93 The EOBD (DOF) field

IFP-EOBD-002 93 The EOBD (DOF) field

IFP-AIPPUB-001 36 Submission of AIP

IFP-RADPUB-001 36 Publishing of the RAD



146 IFPS Error Messages

146.1 Error Class/Error Id: SYN32

Error Message(s)

SYN32: MISSING ADEXP EQCST

Note

When multiple syntax errors are raised for a message, it might be triggered by the first error reported. Therefore it is recommended to treat/analyse the errors in the order they are reported by the system. Correcting the first one may result in all the subsequent syntax errors to disappear.

Possible values in Error Message

NA

Can be ignored

NO (This field refers to internal manual processing. In this situation, an error may be ignored by an IFPS staff for reasons such as an anomaly or the results of a procedure).

Reason

This error is related to messages filed in ADEXP format only and in particular to AFP messages for a change of equipment .The Equipment (EQCST) is missing or cannot be found due to another syntax error.

Requirements

The correct syntax shall be used.

IFPS Procedures

The IFPS staff shall correct the syntax error and proceed with any subsequent error(s) raised if any.

If this is not possible (missing EQCST), then the IFPS staff shall apply SCP1.

Related Sections

Standard Correction Procedure 1 (SCP1)

AFP for a Change of Aircraft Equipment




Error Message(s)

SYN33: (Indicator Name) NOT ALLOWED IN ROUTE

Note



Indicator Name: various possibilities.

Can be ignored


Reason

The specified indicator is invalid for IFPS.

Requirements


IFPS Procedures


If this is not possible, then the IFPS staff shall apply SCP1.

Related Sections





Error Message(s)

SYN60: INVALID WAKE TURBULENCE CATEGORY AT ROW= x, COL= y (WKTRC)

Note



x and y: numbers to indicate in the message the row and column where the error is located. WKTRC: WaKe TuRbulence Category.

Can be ignored


Reason

The aircraft type is filed ZZZZ, and the wake turbulence category specified is neither L, M, H nor J.

Requirements

Where an aircraft type is filed as ZZZZ, the correct wake turbulence category shall be specified.

IFPS Procedures

The IFPS staff shall attempt to contact the message originator and

If contact is achieved, the IFPS staff shall insert the wake turbulence category given or If no contact is achieved, the IFPS staff shall insert the most appropriate wake turbulence

category based on the flight plan elements.

Related Sections

ITEM 9: Number and Type of Aircraft and Wake Turbulence Category




Error Message(s)

SYN62: UNKNOWN OR UNEXPECTED FIELD AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: large number or values.

Can be ignored


Reason

The message has an incorrect syntax which causes the IFPS to be unable to distinguish between the expected fields.

Requirements


IFPS Procedures

The IFPS staff shall apply SCP1.

Related Sections

Various. Refer to the section corresponding to the field name specified in the error message.




Error Message(s)

SYN64: MISSING OR INVALID AIRCRAFT ID

Note



NA

Can be ignored


Reason

This error is related to messages filed in ICAO format only. The first character specified in the aircraft identification field (ARCID) is neither a number nor a letter.

Requirements

The aircraft identification field (ARCID) shall contain only numbers/letters with a minimum of 2 and a maximum of 7 characters.

IFPS Procedures


Related Sections


ITEM 7: Aircraft Identification and SSR Mode/SSR Code




Error Message(s)

SYN65: UNEXPECTED SEPARATOR AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: ROUTE

Can be ignored


Reason

A field separator (e.g ‘/’) is incorrectly placed in the route field of the message, after an airway for example.

Requirements

In the route field, the separator ‘/’ shall only be present after a point then followed by speed and level.

IFPS Procedures

The IFPS staff shall remove the separator identified as causing the error to be raised.

Related Sections

ITEM 15: Route

Initial Speed and Level

En-Route Change of Speed and Level




Error Message(s)

SYN66: ADDITIONAL DATA FOLLOWS TRUNCATION INDICATOR

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: ROUTE

Can be ignored


Reason

A remote letter 'T' has been identified in the route field, indicating the truncation point of that route, but further route data has been identified after that designator.

Requirements

Where a route is truncated using the individual letter 'T', no further route items should be inserted.

IFPS Procedures

The IFPS staff shall analyze the route field and

If the letter ‘T’ appears in the route field because of an extra space (for example: ABBO T or T AKAT), then the IFPS staff shall delete the space or

If the letter ‘T’ indicates a truncated route, the IFPS staff shall remove it and proceed with the manual treatment.

Related Sections

NA




Error Message(s)

SYN67: TOO MANY ALTERNATE AERODROMES

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only. More than two alternates have been specified, preceded each time by –ALTRNT.

Requirements

When submitting messages in ADEXP format, a maximum number of 2 alternate aerodromes can be specified preceded respectively by –ALTRNT1 and -ALTRNT2.

IFPS Procedures


Related Sections





Error Message(s)

SYN68: TOO MANY ADDRESSES ON LINE AT ROW= x, COL= y

Note

When multiple syntax errors are raised for a message, it might be triggered by the first error reported. Therefore, it is recommended to treat/analyse the errors in the order they are reported by the system. Correcting the first one may result in all the subsequent syntax errors to disappear.


x and y: numbers to indicate in the message the row and column where the error is located.

Can be ignored


Reason

The maximum number of 7 AD line addresses has been exceeded in the indicated line, or a following line has not been prefixed by the AD indicator.

Requirements

Each line in the re-addressing function shall contain a maximum of 7 addresses and should be prefixed by the letters ‘AD’; any more addresses should be carried on to a new ‘AD’ line.

IFPS Procedures


Related Sections

RE-ADDRESSING





Error Message(s)

SYN69: EXPECTED TIME DESIGNATOR NOT FOUND AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: EOBT, TTL_EET, SPL_E, ATD, ATA, ETO/ATO.

Can be ignored


Reason

The time designator is missing or IFPS is not able to identify it: EOBT, EET etc

Requirements

Where a time designator is required, it shall be included and specified in the correct format.

IFPS Procedures

For field type SPL_E: The IFPS staff shall move the closing bracket of the message from the end of Item 19 to the end of Item 18.

For field type ATD, ATA, EOBT, TTL_EET: The IFPS staff shall apply SCP1.

For field type ETO/ATO: (concerns AFIL messages):

When the ATO/ETO is missing from the message; the IFPS staff shall contact the message originator to obtain the ATO/ETO and

Where no contact with the message originator is possible, the IFPS staff shall insert the filing time of the message, in association with the appropriate date of flight.

Related Sections


ITEM 13: Aerodrome of Departure (ADEP) and Estimated Off-Blocks Time (EOBT)

ITEM 16: A) Destination Aerodrome B) Total Estimated Elapsed Time C) Alternate Aerodrome(s)

Total Fuel Endurance: E/

Departure (DEP)

Arrival (ARR)

Air-Filed Flight Plans (AFIL)




Error Message(s)

SYN70: FIELD TEXT TOO SHORT AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: wide range of possibilities such as ARCTYP, RVR, ORGN, ARCID, SSRCODE,

SEQPT, EOBT, REG, SEL, TYP, COM, DAT, NAV, DEP, DEST, ADEP, ADES, ALTNZ, ALTRNT, RALT, RFP, SUR, TALT, ATD, ATA, DLE.

Can be ignored


Reason

The syntax for the field that is identified in the error message is not correct.

Requirements


IFPS Procedures

The IFPS staff shall apply SCP1, unless there is no doubt about the intended content of the field in error.

Related Sections


Runway Visual Range (RVR)

Originator (ORGN) Indicator



ITEM 10: Equipment & Capabilities



Aircraft Registration (REG)

SELCAL (SEL)

Aircraft Type (TYP)

Communications Equipment (COM)

Data Link Capability (DAT)

Navigation Equipment (NAV)

Departure Aerodrome (DEP)

Destination Aerodrome (DEST)

Alternate Destination Aerodrome (ALTN)



En-Route Alternate Aerodrome (RALT)

Replacement Flight Plan (RFP)

PBN (Performance Based Navigation)

Surveillance (SUR)

Take-off Alternate (TALT)

En-Route Delay or Holding (DLE)

Pilot in Command: C/

Departure (DEP)

Arrival (ARR)




Error Message(s)

SYN71: FIELD TEXT TOO LONG AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: wide range of possibilities such as FLTTYP, ADEP, ADES,RVR, ORGN, ARCID,

SSRCODE, SEQPT, EOBT, REG, SEL, TYP, COM, DAT, NAV, DEP, ALTNZ, ALTRNT, RALT, RFP, SUR, TALT, DLE.

Can be ignored


Reason


Requirements


IFPS Procedures

The IFPS staff shall apply SCP1, unless there is no doubt about the intended content of the field in error.

Related Sections





ITEM 8: Flight Rules and Type of Flight




SELCAL (SEL)

Aircraft Type (TYP)







En-Route Alternate Aerodrome (RALT)





Surveillance (SUR)



Pilot in Command: C/

Departure (DEP)

Arrival (ARR)




Error Message(s)

SYN72: SUSPECT TEXT TOO LONG AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: wide range of possibilities.

Can be ignored


Reason


Requirements


IFPS Procedures

The IFPS staff shall identify the field where the error is located and amend the message to obtain a correct syntax. When such action would affect important elements of the message, then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

1) SYN73: SUSPECT INVALID FIELD AT ROW= x,COL= y (F18 <Sub-field Name> AFTER F19 <Sub-field Name> (x,y))

2) SYN73: SUSPECT INVALID FIELD AT ROW= x, COL= y (ICAO EQPT/ in RMK DATA)

Note




Sub-Field Name: any subfield from item 18 and any subfield from item 19.

Can be ignored


Reason

Either an item 18 sub-field indicator has been detected inside item 19 or

In Item 18 sub-field texts, where ‘/’ is used with an Item 19 sub-field indicator before it, the system may misinterpret that piece of data as an Item 19 entry. Where the text following the ‘/’ is appropriate for that heading, the system may automatically extract that information string as Item 19 data. If the text following the ’/’ is incorrect for the sub-field heading, then the system shall raise an error, based on the assumption that it is an Item 19 sub-field.

Requirements

Item 18 sub-fields shall not be indicated after item 19 indicators.

IFPS Procedures

In the first case (see above, Reason), the IFPS staff shall remove the item 18 sub-field found after an item 19 sub-field and shall insert it in the item 18 or

In the second case (see above, Reason), where the system suspects that an item 18 information string is an item 19 sub-field, that information must be disguised by the IFPS staff; normally, replacing the ‘/’ with a space is sufficient.

Related Sections

ITEM 18: Other Information

ITEM 19: Supplementary Information




Error Message(s)

SYN74: EXPECTED SSR EQUIPMENT DESIGNATOR AT ROW= x,COL=Y (SEQPT)

Note



x and y: numbers to indicate in the message the row and column where the error is located. SEQPT: Surveillance Equipment.

Can be ignored


Reason

The surveillance equipment designator(s) is/are missing from the submitted message.

Requirements

The surveillance equipment shall be indicated by either N or one or more of the equipment designators approved by ICAO.

IFPS Procedures

If the SSR equipment is present but not read due to a syntax error, then the IFPS shall amend the message to the correct syntax or

If the SSR equipment is missing then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

SYN76: NO PARALLEL ALLOWED IN FIELD AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: wide range of possibilities.

Can be ignored


Reason


Requirements


IFPS Procedures

The IFPS staff shall identify the field where the error is located and amend the message to obtain a correct syntax. When such action would affect important elements of the message, then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

SYN77: EXPECTED NUMERIC ROW= x,COL=y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: wide range of possibilities such as SPL_P (Supplementary Information Persons

on Board).

Can be ignored


Reason


Requirements


IFPS Procedures

The IFPS staff shall identify the field where the error is located and amend the message to obtain a correct syntax.

For example, when it concerns Supplementary Information (Item 19), the IFPS staff shall move the closing bracket of the message from the end of Item 19 to the end of Item 18.

When such action would affect important elements of that message, then the IFPS staff shall apply SCP1.

Related Sections


Total Number of Persons on Board: P/




Error Message(s)

SYN78: NO CHANGES ALLOWED IN KEY FIELD AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: ARCID, ADEP, ADES, DOF.

Can be ignored


Reason

It is not possible to make changes to the indicated key field. The key fields are: Aircraft Identification, Aerodrome of Departure, Aerodrome of Destination and Date of Flight.

Requirements

Key fields shall only be changed by cancelling the existing flight plan and re-filing with the new key field data.

IFPS Procedures


Related Sections


Key Fields




Error Message(s)

SYN80: MULTIPLE MATCHING LONGITUDE FOUND IN ROUTE, CANNOT EXPAND MERIDIAN

Note



NA

Can be ignored


Reason

In Item 18, an EET using only a longitude as a referent point has more than one route point indicating the same longitude.

Requirements

Where a route contains more than one geographical coordinate on the same longitude, any associated EET must contain the full geographical coordinates for that estimate.

IFPS Procedures

The IFPS staff shall insert the full geographical coordinates in the sub field EET in Item 18 for the concerned entry.

Related Sections

Points

Estimated Elapsed Time (EET)




Error Message(s)

SYN81: MULTIPLE MATCHING LATITUDE FOUND IN ROUTE, CANNOT EXPAND PARALLEL

Note



NA

Can be ignored


Reason

In Item 18, an EET using only latitude as a reference point has more than one route point indicating the same latitude.

Requirements

Where a route contains more than one geographical coordinate on the same latitude, any associated EET must contain the full geographical coordinates for that estimate.

IFPS Procedures

The IFPS staff shall insert the full geographical coordinates in the sub field EET in Item 18 for the concerned entry.

Related Sections

Points





Error Message(s)

SYN83: MISSING PARENTHESIS

Note



NA

Can be ignored


Reason

The message does not contain the correct pairing of parenthesis.

Requirements

The correct format shall be used.

IFPS Procedures


Related Sections

NA




Error Message(s)

SYN84: MISSING OR INVALID LEVEL

Note



NA

Can be ignored


Reason

The expected level information in the message cannot be identified.

Requirements


IFPS Procedures

The IFPS staff shall apply SCP1 unless there is no ambiguity with the intended level.

Related Sections







Error Message(s)

SYN85: MISSING FIELD ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: ARCID, FIELD 18.

Can be ignored


Reason

The field specified is missing or cannot be found due to another syntax error.

Requirements

The correct syntax shall be used. In associated messages, a correctly formatted Item 18 shall be present in the following message types: CNL, DLA, CHG, DEP, RQS, and RQP.

IFPS Procedures

When the message is an RQP, the IFPS staff shall reject that message.

In all other cases the IFPS staff shall insert ‘0’ as Item 18, and in case the message matches multiples flight plans, the IFPS staff shall apply SCP1.

Related Sections



Modification (CHG)

Delay (DLA)

Cancel (CNL)

Departure (DEP)

Request Flight Plan (RQP)

Request Supplementary Flight Plan (RQS)




Error Message(s)

SYN86: MISSING OR INVALID SIGNIFICANT POINT DESIGNATOR

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only. A specific point is missing or cannot be found due to another syntax error.

Requirements


IFPS Procedures


If this is not possible (missing field or point cannot be identified) then the IFPS staff shall apply SCP1.

Related Sections


Points




Error Message(s)

SYN87: MISSING OR INVALID ETO

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only.The Estimated Time Over (ETO) is missing or cannot be found due to another syntax error or is invalid.

Requirements


IFPS Procedures


If this is not possible (missing ETO or ETO cannot be identified) then the IFPS staff shall apply SCP1.

Related Sections

ATS DATA EXCHANGE PRESENTATION (ADEXP)



ATC Flight Plan Proposal Message (AFP)




Error Message(s)

SYN88: MISSING OR INVALID END KEYWORD

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only.The END KEYWORD is missing or cannot be found due to another syntax error or is invalid.

Requirements


IFPS Procedures



Related Sections






Error Message(s)

SYN89: MISSING OR INVALID ADEXP ADDRESS

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only. An ADDRESS is missing or cannot be found due to another syntax error or is invalid.

Requirements


IFPS Procedures



Related Sections






Error Message(s)

SYN90: NO MERIDIAN ALLOWED IN FIELD AT ROW= x,COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: various possibilities.

Can be ignored


Reason

A geographical coordinate is not allowed in the field specified.

Requirements


IFPS Procedures


Related Sections





Error Message(s)

SYN91: DUPLICATE DATA

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only and when a duplicate data is found in sets e.g. a duplicate REF, GEO, REN etc.

Requirements


IFPS Procedures

The IFPS staff shall correct the syntax error (be deleting one of the duplicate entry) and proceed with any subsequent error(s) raised if any.

Related Sections


Related Document(s):

IFPS and RPL Dictionary of Messages




Error Message(s)

SYN92: MISSING OR INVALID TITLE

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only. The message title contains invalid characters or is incomplete or is not an allowed title for input to IFPS.

Requirements

All messages submitted to IFPS in ADEXP format shall contain one of the defined message titles that are recognised by IFPS.

IFPS Procedures

If the message is in the correct ACH/APL format then the IFPS staff shall reject that message.

In all other cases, the IFPS staff shall apply SCP1 unless there is no ambiguity about the correct message title.

Related Sections


ITEM 3: Message Title






Error Message(s)

SYN93: INVALID TIME DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: EETPT Estimated Elapsed Time at Point (EET sub field in Item 18)

Can be ignored


Reason

The indicated time designator in the EET sub-field in Item 18 does not conform to the standard 24-hour format.

Requirements

The correct syntax shall be used: HHMM.

IFPS Procedures

The IFPS shall try to identify the intended time. If this is not possible or in case of any doubt then the IFPS shall try to contact the message originator.

If no contact can be achieved then the IFPS staff shall ‘cut’ and ‘paste’ the point or FIR/estimated elapsed time group to the RMK sub-field in Item 18.

Related Sections





Error Message(s)

SYN95: INVALID SPEED DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: SPEED.

Can be ignored


Reason

An incorrect syntax for the speed has been used. For example: M for ‘Mach’ followed by 4 digits (should be 3).

Requirements

The speed indication shall be specified with one the allowed manner and in the correct format.

IFPS Procedures

The IFPS staff shall try to identify the intended speed. If this is not possible or in case of any doubt then the IFPS shall apply SCP1.

Related Sections







Error Message(s)

SYN96: INVALID SOURCE

Note



NA

Can be ignored


Reason

The SRC sub-field in Item 18 is present in a message submission.

Requirements

SRC sub-field shall never be present in a message sent to the IFPS. This is a field which is added automatically by the IFPS after successful processing and may be found in messages output.

IFPS Procedures

The IFPS staff shall delete the SRC sub-field from the incoming message and proceed with any subsequent error(s) raised if any.

Related Sections

Source (SRC) Indicator




Error Message(s)

SYN97: INVALID SEPARATOR AT ROW= x, COL= y

Note



NA

Can be ignored


Reason

The message has errors that cause the IFPS to be unable to distinguish between the expected fields.

Requirements


IFPS Procedures


Related Sections

NA




Error Message(s)

SYN98: INVALID POINT

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only where there is/are problem(s) with points in fields. Example: missing PTID in a REF point.

Requirements


IFPS Procedures


Whenever this is not possible, then the IFPS staff shall apply SCP1.

Related Sections








Error Message(s)

SYN99: INVALID LONGITUDE DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: EETPT: Estimated Elapsed Time Point, for the Item 18 EET sub-field.

Can be ignored


Reason

The indicated longitude value does not contain 3 or 5 numbers.

Requirements

The IFPS can only accept longitude values given as 3 or 5 numbers in the EET sub-field in Item 18.

IFPS Procedures

The IFPS shall try to identify the intended longitude. If this is not possible or in case of any doubt then the IFPS staff shall try to contact the message originator.

If no contact can be achieved, then the IFPS shall ‘cut’ and ‘paste’ the geographical coordinates/estimated elapsed time group to the RMK sub-field in Item 18.

Related Sections





Error Message(s)

SYN100: INVALID LIST

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only where there is the field -BEGIN followed by an unexpected keyword (i.e. one that isn't ADDR, RTE_PTS, EQCST).

Requirements


IFPS Procedures



Related Sections








Error Message(s)

1) SYN101: INVALID LEVEL DESIGNATOR AT ROW= x, COL= y (RFL) 2) SYN101: INVALID LEVEL DESIGNATOR (ROUTE)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: RFL Requested Flight Level.

Can be ignored


Reason

1) An incorrect syntax for the RFL has been used. 2) An RFL above F195 in visible portion (GAT, IFR, IFPSTART) does not end with a zero.

Requirements

1) The RFL indication shall be specified with one the allowed manner and in the correct format. 2) The RFL indication above F195 for a visible portion (GAT, IFR, IFPSTART) shall always end

with a zero.

IFPS Procedures

+ (2): The IFPS staff shall try to identify the intended RFL.

If this is not possible or in case of any doubt then the IFPS shall apply SCP1.

Related Sections







Error Message(s)

SYN102: INVALID LATITUDE DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: EETPT: Estimated Elapsed Time Point, for the Item 18 EET sub-field.

Can be ignored


Reason

The indicated latitude value does not contain 2 or 4 numbers.

Requirements

The IFPS can only accept latitude values given as 2 or 4 numbers in the EET sub-field in Item 18.

IFPS Procedures

The IFPS shall try to identify the intended latitude. If this is not possible or in case of any doubt then the IFPS staff shall try to contact the message originator.

If no contact can be achieved, then the IFPS shall ‘cut’ and ‘paste’ the geographical coordinates/estimated elapsed time group to the RMK sub-field in Item 18.

Related Sections





Error Message(s)

SYN103: INVALID ID USED IN FIELD AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: STAY.

Can be ignored


Reason

Multiple STAY indicators with the same sequence number have been used in the route field.

Requirements

Where more than one STAY indicator is used in the route, each indicator must have a separate and consecutive sequence number, to a maximum value of 9.

IFPS Procedures

The IFPS staff shall correct the STAY indicators numbering in order to have a separate and consecutive sequence number.

In case of any doubt (the flight path appears illogical when compared to ADES and ADES) then the IFPS staff shall apply SCP1.

Related Sections


En-Route Stay Indicator




Error Message(s)

SYN104: INVALID FIELD AT ROW=x, COL=y (Field Name)

SYN104: INVALID FIELD AT ROW=x, COL=y

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: various possibilities such as TITLE, RFL, ROUTE.

Note The Field Name is only present where the IFPS was able to identify in which field is located the error.

Can be ignored


Reason

One or more invalid characters are used in the specified field.

Requirements


IFPS Procedures



Related Sections






Error Message(s)

SYN105: INVALID DISTANCE DESIGNATOR

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only when there is badly formed distance field in a reference (REF) point.

Requirements


IFPS Procedures



Related Sections





AFP For a Missing Flight Plan

AFP for a Change of Route

AFP for Diversion




Error Message(s)

SYN106: WRONG POINT FOR GEO <Point Name>

Note



NA

Can be ignored


Reason

A point expressed with geographical coordinates is linked with a point name but the coordinates do not match with the specified point. The error is only raised when a specific IFPS internal format is used. Therefore this error is not visible to external IFPS clients and to IFPUV users.

Requirements


IFPS Procedures

NA

Related Sections

Points




Error Message(s)

SYN108: INVALID DATE DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: EOBD Estimated Off Block Date

Can be ignored


Reason

The message contains an invalid date, for example an alphabetic character in the DOF.

Requirements


IFPS Procedures

The IFPS staff shall try to identify the intended DOF. If this is not possible or in case of any doubt then the IFPS staff shall apply SCP1.

Related Sections


Date of Flight (DOF)




Error Message(s)

SYN109: FIELD CONTAINS INVALID CHARACTER(S) AT ROW = x, COL = y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: STS, ORGN, SSRCODE, SEQPT, SEL, RMK, PBN, SUR, TALT, SPL_R, SPL_S, SPL_J,

Can be ignored


Reason

STS: One on the STS descriptor is not recognized. Only the STS descriptors published in ICAO doc.4444 are allowed and shall be filed with an exact character match.

ORGN: Special characters such as ‘!’, ‘@’ are present. The ORGN sub-field shall not contain any special characters.

SSRCODE: The SSR code contains a letter other than the permitted letter A. Only the letter A may be used to indicate the SSR mode.

SEQPT: The surveillance equipment contains invalid characters or N is present together with other descriptors. The character(s) used in the equipment designators may only be those indicators approved by ICAO and shall be compatible.

SEL: A character other than a letter has been used. The characters used to specify the SELCAL shall be letters only.

RMK: One or more invalid characters have been used in the text. Ensure only valid characters are used in the text.

PBN: One of more PBN descriptors does not match any of the valid descriptors. Only the published PBN descriptors are allowed.

SUR: Characters other than alphanumeric are present in the sub-field SUR. The characters in the sub-field SUR shall be only alphanumeric characters.

TALT: Special characters such as ‘!’, ‘@’ are present. The TALT sub-field shall not contain any special characters.

SPL_R: The letter(s) used do not correspond to the prescribed indicators for the subfield. The letters used in the emergency radio subfield may only be U, V and/or E.

SPL_S: The letter(s) used do not correspond to the prescribed indicators for the subfield. The letters used in the survival equipment sub-field may only be P, D, M and/or J.

SPL_J: The letter(s) used do not correspond to the prescribed indicators for the subfield. The letters used in the life jackets sub-field may only be L, F, U and/or V.

COMMENT (only in ADEXP): an ACH (SRC/AFP) with a successful route merge results in an invalid message. The ADEXP field – COMMENT is added as last field in the message in order to inform the IFPS staff of the original flight plan route.

Requirements




IFPS Procedures

STS: Where the STS descriptor can be identified without any doubt, the IFPS staff shall correct that descriptor in order to have an exact character match with the published descriptor; in all other

cases the IFPS staff shall apply SCP1.

Example: STS/AZMAT may be corrected to STS/HAZMAT

ORGN: The IFPS staff shall remove any special character(s) from the content of the ORGN sub-field.

SSRCODE: In all cases where a C is submitted as an SSR designator, the IFPS staff shall change that designator to A.

SEQPT, SEL, PBN: The IFPS staff shall apply SCP1.

RMK: Where contact with the message originator is possible, the IFPS staff shall agree the most suitable correction. If no contact with the message originator is possible, the IFPS staff shall delete the invalid character(s) and replace them with a character space.

SUR: The IFPS staff shall remove any special character(s) from the content of the SUR sub-field.

TALT: The IFPS staff shall remove any special character(s) from the content of the TALT sub-field.

SPL_R, SPL_S, SPL_J: The IFPS staff shall move the closing bracket of the message from the end of Item 19 to the end of Item 18.

COMMENT (only in ADEXP): The IFPS staff shall delete the entire COMMENT field from the ACH.

Related Sections


Special Status Flights (STS)

STS/SAR Indicator

STS/HEAD Indicator

STS/ATFMX Indicator

STS/HOSP Indicator

STS/HUM Indicator

STS/STATE Indicator

STS/NONRVSM Indicator

STS/FFR Indicator

STS/FLTCK Indicator

STS/HAZMAT Indicator

STS/MARSA Indicator

STS/MEDEVAC Indicator

STS/ALTRV Indicator





Surveillance (SUR)





Survival Equipment: S/




Error Message(s)

SYN110: INVALID BEARING DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: ROUTE or DLE.

Can be ignored


Reason

The indicated bearing designator is outside the range 000 to 360.

Requirements

Any bearing indication must reflect to a maximum value of 360º.

IFPS Procedures


Related Sections



Points





Error Message(s)

SYN111: MISPLACED INDICATOR. MUST BE AFTER A POINT AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: ROUTE.

Can be ignored


Reason

An indicator (VFR, IFR, GAT, OAT, STAY etc.) in the route field does not follow a point.

Requirements

A change of rules, flight type, etc shall be put in the route field after a point designator.

IFPS Procedures


Related Sections


General Air Traffic/Operational Air Traffic (GAT/OAT)

Visual Flight Rules (VFR)


ITEM 15: Route




Error Message(s)

SYN112: INCORRECT USAGE OF BRACKETS '(' AND ')'

Note



NA

Can be ignored


Reason

The submitted message contains more brackets than just the opening and closing bracket.

Requirements

The opening and closing indicators of any message are '(' and ')' respectively, thus they cannot be used within a message in any other way.

IFPS Procedures



Related Sections





Error Message(s)

SYN114: EXPECTED ‘/’ AT ROW= x, COL= y

Note




Can be ignored


Reason

A '/' is expected for correct formatting, but is missing.

Requirements

Where a '/' is necessary in the format of an item, it must be present in the submitted message.

IFPS Procedures



Related Sections





Error Message(s)

SYN115: EXPECTED FLIGHT TYPE AND RULES AT ROW= x, COL= y (FLTTYP)

Note



x and y: numbers to indicate in the message the row and column where the error is located. FLTTYP: Flight Type.

Can be ignored


Reason

The flight type and flight rules are either missing or using an invalid designator.

For a military flight, it may be that the designator OAT (Operational Air Traffic) is inserted in Item 8: Flight Rules and Flight Type.

Requirements

The flight type and flight rules shall be present, and shall use approved designator(s).

IFPS Procedures

If Item 8 has been filed as IOM for a military flight and if OAT/GAT changes are clearly indicated in either the route or other information, then the IFPS staff shall correct by inserting OAT/GAT as appropriate, and changing IOM to IM; otherwise the IFPS staff shall apply SCP1 or

The IFPS staff shall try to identify the flight type and rules. If this is not possible or in case of any doubt, then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

SYN116: EXPECTED OR INVALID FLIGHT TYPE AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: FLTTYP: Flight Type.

Can be ignored


Reason

The flight type is either missing or using an invalid designator. Can be S, N, G, M, X.

Requirements

The flight type shall be present, and shall use an approved indicator.

IFPS Procedures

The IFPS staff shall try to identify the flight rules. If this is not possible or in case of any doubt, then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

SYN117: EXPECTED OR INVALID FLIGHT RULES AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message the row and column where the error is located. Field Name: FLTRUL: Flight Rules.

Can be ignored


Reason

The flight rules are either missing or using an invalid designator. Can be I, Z or Y.

Requirements

The flight rules shall be present, and shall use an approved indicator.

IFPS Procedures

The IFPS staff shall try to identify the flight rules.

If this is not possible or in case of any doubt, then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

SYN118: EXPECTED END OF MESSAGE

Note



NA

Can be ignored


Reason

A syntax error is causing IFPS to be unable to find the end of the submitted message.

Requirements


IFPS Procedures



Related Sections





Error Message(s)

SYN119: EQPT FIELD NOT ALLOWED

Note

When multiple syntax errors are raised for a message, it might be triggered by the first error reported. Therefore, it is recommended to treat/analyse the errors in the order they are reported by the system. Correcting the first one may result in all the subsequent syntax errors to disappear.


NA

Can be ignored


Reason

The RPL specific EQPT field is specified in a flight plan message. Example: RMK/EQPT/LORWY/H

Requirements


IFPS Procedures



Related Sections






Error Message(s)

SYN120: INTERNAL ERROR

Note



NA

Can be ignored


Reason

Internal IFPS error.

Requirements

NA

IFPS Procedures

NA

Related Sections

NA




Error Message(s)

SYN121: DUPLICATE ERROR AT ROW=x, COL=y (Sub-Field name)

Note




Sub-Field Name: DEP, DEST, EOBD (DOF), OPR, RVR, SEL, REG, PBN, CODE, ORGN, PER, RFP.

Can be ignored


Reason

There is a duplicate for the specified sub-field (in Item 18), which is not permitted.

Requirements

Some sub-fields in Item 18 shall be specified only once.

IFPS Procedures

RVR:

If the duplicate entry is identical, the IFPS staff shall delete one of the entries.

In all other cases, the IFPS staff shall apply SCP1.

If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC then the IFPS staff shall delete the entry with the lowest RVR value.

ORGN:



If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC then the IFPS staff shall move one entry under the RMK without ‘/’.

REG:

Where the flight concerned is a single aircraft and the duplicate entry is identical, the IFPS staff shall delete one of the entries.

Where the flight concerned is a formation flight, then the IFPS staff shall copy all the registrations into a single entry, and separate each entry by a space.


If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC then the IFPS staff shall move one entry under RMK without ‘/’.

SEL:





If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall delete the SEL entries.

OPR:

If the duplicate entry is identical or the content is equivalent, then the IFPS staff shall delete one of the entries.


If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall move one entry under RMK without ‘/’.

PER:

If the duplicate entry is identical the IFPS staff shall delete one of the entries.

In all other cases the IFPS shall apply SCP1.

If no contact is possible except and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or

STS/MEDEVAC, then the IFPS staff shall delete the entry with the highest performance data.

DEP:


In all other cases the IFPS staff shall apply SCP1.

If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall try to identify if possible the closest departure location to the first point on the route and move the other entry under RMK without the ‘/’ preceded by the comment: ‘second filed DEP’.

DEST:



If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall try to identify if possible the closest destination location to the last point on the route and move the other entry under RMK without the ‘/’ preceded by the comment: ‘second filed DEST’.

EOBD (DOF):



If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall delete both DOF entries.

RFP:



If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall delete the entry with the lowest value after ‘Q’.

CODE:





If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall delete the both CODE entries.

PBN:



If no contact is possible and if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC, then the IFPS staff shall combine the content of both entries into one.

If the maximum amount of characters is exceeded, then the IFPS staff shall apply the Guidance for the Provision of NAV/COM/SUR information accessible from the CHMI>TEM>ICAO2012 (internally) or via the Eurocontrol website (internally and externally) at:

https://trainingzone.eurocontrol.int/clix/data/reading/icao_2012_guidance_latest_6711316.pdf

Related Sections




ITEM 18: Other Information


SELCAL (SEL)

Aircraft Operator (OPR)

Aircraft Performance (PER)





CODE


https://trainingzone.eurocontrol.int/clix/data/reading/icao_2012_guidance_latest_6711316.pdf




Error Message(s)

SYN122: EXPECTED DATE DESIGNATOR NOT FOUND

Note



NA

Can be ignored


Reason

The format of the DOF field is not correct.

Requirements

The DOF field shall be specified in the correct format YYMMDD and only one ‘/’ separator shall be used.

IFPS Procedures

The IFPS staff shall try to identify the intended DOF. If this is not possible or in case of any doubt, then the IFPS staff shall apply SCP1.

Related Sections






Error Message(s)

SYN123: EXPECTED CNA EQUIPMENT DESIGNATOR AT ROW= x, COL= y (Field Name)

Note



x and y: numbers to indicate in the message, the row and column where the error is located. Field Name: CEQPT: Communication Equipment which includes radio communication,

navigation and approach aid equipment.

Can be ignored


Reason

The radio communication, navigation and approach aid equipment designators are missing from the submitted message or cannot be identified due to another syntax error.

Requirements

The radio communication, navigation and approach aid equipment shall be indicated by either N or S and/or the equipment designators approved by ICAO.

IFPS Procedures



Related Sections






Error Message(s)

SYN124: MISSING OR INVALID CHANGE RULES

Note



NA

Can be ignored


Reason

This error is related to messages filed in ADEXP format only (like ICHG, IAFP) when the CHGRUL field has been incorrectly defined. The CHGRUL field is used to indicate change of flight rules (VFR/IFR) or the type of flight (OAT/GAT).

Requirements


IFPS Procedures



Related Sections










Error Message(s)

SYN153: INVALID COMBINATION OF MODE S CAPABILITY AT ROW=x, COL=y

Note




Can be ignored


Reason

The Mode S indication is not unique or ADS-B & ADS-C is notified without any transponder mode indicated (A, C or S).

Requirements

When the aircraft is equipped with Mode S surveillance, being ‘I’,’P’,’X’, only one descriptor is allowed as they mutually exclude each other. Also, when either I, P or X is present, E, H, L and S cannot be present. ADS-B/ADS-C descriptors are optional and cannot be present without any indication of transponder modes.

IFPS Procedures


If the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC and contact with the message originator is not possible then the IFPS staff shall identify the conflicting surveillance designators and shall delete the highest designator.

If the error is raised because only ADS-B and/or ADS-C designator(s) are filed but no transponder mode is present (being A, C or S), then the IFPS staff shall insert C in item 10b.

Related Sections






Error Message(s)

SYN400: INVALID STANDARD ROUTE SEQUENCE NUMBER IN THE AIRCRAFT ID FIELD

Note



NA

Can be ignored


Reason

NA

Requirements


IFPS Procedures

NA

Related Sections

NA



146.62 Error Class/Error Id: EFPM31

Error Message(s)

EFPM31: FLIGHT PLAN ALREADY LOCKED BY ANOTHER USER


NA

Can be ignored


Reason

This is an internal IFPS error. An IFPS staff is selecting an invalid message which is already edited by another IFPS staff.

Requirements

A message shall only be editable once at the same time.

IFPS Procedures

NA

Related Sections

NA




Error Message(s)

EFPM34: AIRAC DATA NOT AVAILABLE (Field Name)


Field name: EOBD Estimated Off Block Date

Can be ignored


Reason

While using IFPS or IFPUV, the flight plan message as a date of flight in the future (usually 5 days or more) and that date falls into the next AIRC and the AIRAC data is not available yet.

Requirements

A flight plan message can be submitted with a maximum of 5 days in advance and when the AIRAC data is available.

IFPS Procedures

NA

Related Sections






Error Message(s)

EFPM35: MFS ETO IS NOT IN ACCEPTABLE RANGE: HH:MM TO HH:MM (Field Name)


HH:MM: first group defines the earliest time the estimate data can be accepted while the second group defines the latest time the estimate data can be accepted.

Field name: EST_DATA Estimated Data.

Can be ignored

YES (This field refers to internal manual processing. In this situation, an error may be ignored by an IFPS staff for reasons such as an anomaly or the results of a procedure).

Reason

This error is related to MFS messages only. The estimate provided in the MFS (ETO) is outside the acceptable range. The acceptable range is +/- 2 hours compared to IFPS time at the time of processing.

Requirements

The ETO provided in the message shall be within the acceptable range.

IFPS Procedures

The IFPS staff shall check the flight plan history for existing flight plan data.

If there is no existing flight plan data for the associated airborne message, the IFPS staff shall contact the originator of the airborne message for correct/processable data in order to proceed with an APL processing.

If it is not possible to obtain the correct data or if there is an existing flight plan data, the message shall be rejected.

Related Sections


Airborne Message Types

Message from SHANWICK/SANTA MARIA (MFS)




Error Message(s)

EFPM36: FNM ETO IS NOT IN ACCEPTABLE RANGE: HH:MM TO HH:MM (Field Name)




Can be ignored


Reason

This error is related to FNM messages only. The estimate provided in the FNM (ETO) is outside the acceptable range. The acceptable range is 420 minutes in the future and 0 minutes in the past when compared to IFPS time at the time of processing.

Requirements


IFPS Procedures




Related Sections



Flight Notification Message (FNM)




Error Message(s)

EFPM37: AFP ETO IS NOT IN ACCEPTABLE RANGE: HH:MM TO HH:MM (Field Name)




Can be ignored


Reason

This error is related to AFP messages only. The estimate provided in the AFP (ETO) is outside the acceptable range. The acceptable range is +/- 2 hours compared to IFPS time at the time of processing.

Requirements


IFPS Procedures




Related Sections







Error Message(s)

EFPM38: AFIL ETO IS NOT IN ACCEPTABLE RANGE: HH:MM TO HH:MM (Field Name)




Can be ignored


Reason

This error is related to AFIL messages only. The estimate provided in the AFIL (ETO) is outside the acceptable range. The acceptable range is +/- 2 hours compared to IFPS time at the time of processing.

Requirements


IFPS Procedures




Related Sections







Error Message(s)

EFPM39: ACTUAL DATE AND TIME OF DEPARTURE IS NOT IN ACCEPTABLE RANGE: HH:MM TO HH:MM. (Field Name)


HH:MM: first group defines the earliest time of departure that can be accepted while the second group defines the latest time of departure that can be accepted.

Field name: ATD Actual Time of Departure.

Can be ignored


Reason

This error is related to DEP messages only which are expected to provide an ATD within a given time window around the EOBT of the associated flight. The time window shall be set by default to minus 60 minutes to plus 240 minutes around the EOBT.

Requirements

The ATD must be within the acceptable range.

IFPS Procedures

Where association of the DEP message with an existing FPL data can be identified and the departure time is correct (for example, a previous DLA that is time compatible with the DEP message was rejected) the IFPS staff shall ignore the error.


Related Sections


Departure (DEP)




Error Message(s)

EFPM40: ACTUAL DATE AND TIME OF ARRIVAL IS NOT IN ACCEPTABLE RANGE: HH:MM TO HH:MM. (Field Name)


HH:MM: first group defines the earliest time of arrival that can be accepted while the second group defines the latest time of arrival that can be accepted.

Field name: ATA Actual Time of Arrival.

Can be ignored


Reason

This error is related to ARR messages only which are expected to provide an ATA within a time window defined by a given time parameter before the EOBT and the IFPS ‘close’ time of the associated flight. The time parameter shall be set by default to 0 (zero).

Requirements

The ATA must be within the acceptable range.

IFPS Procedures

Where association of the ARR message with an existing FPL data can be identified and the arrival time is correct (for example, a previous DLA that is time compatible with the ARR message was rejected) the IFPS staff shall ignore the error.


Related Sections


Arrival (ARR)




Error Message(s)

EFPM51: FPL PROCESSED AFTER ESTIMATED TIME OF ARRIVAL


NA

Can be ignored


Reason

Under certain circumstances, the DOF calculated by the IFPS may be such that the Estimated Time of Arrival (derived from the EOBT + calculated profile of the FPD) of the flight is in the past when compared to the message processing time in IFPS.

Requirements

NA

IFPS Procedures

The IFPS staff shall apply SCP1 to confirm the correctness of the date and time information, with the exception that where contact with the message originator is not possible and the message is an airborne message or an FPL with an associated DEP message, the EOBT of the message shall be corrected by the IFPS staff to be the same as the estimate/DEP time given by the message originator.

Related Sections







Error Message(s)

1) EFPM166: Z PRESENT BUT COM/DAT/NAV ABSENT (Field Name) 2) EFPM166: PBN PRESENT BUT R ABSENT (Field Name) 3) EFPM166: R PRESENT BUT PBN ABSENT (Field Name)


Field Name: CEQPT communication equipment of the aircraft (corresponding to Item 10a of the ICAO flight plan message) which includes navigation and approach aid equipment.

Can be ignored


Reason

1) The equipment specified in Item 10a contains Z and no explanation is given in Item 18 as neither COM, DAT nor NAV is present.

2) The Item 18 subfield PBN is present and the item 10a does not contain the letter R. 3) The equipment specified in Item 10a contains R and the subfield PBN is not present in item

18.

Requirements

1) When Z is specified in the equipment of a flight plan, it is necessary to include the relevant data in the corresponding item 18 subfields, being COM and/or DAT and/or NAV.

2) When PBN is specified in the item 18 of a flight plan, it indicates the Performance Based Navigation (PBN) levels and/or the Required Navigation Performance (RNP) levels that can be met. It can only be present if the aircraft is PBN approved which shall be notified by the letter R in the equipment of that flight plan.

3) When R is specified in the equipment of a flight plan, it is necessary to include the Performance Based Navigation (PBN) levels and/or the Required Navigation Performance (RNP) levels that can be met by inserting in item 18 PBN/ followed by the relevant descriptors.

IFPS Procedures

1) The IFPS staff shall contact the message originator and correct as agreed or If no contact with the message originator is possible and a clear indication of the equipment

is present (under RMK/ for example), the IFPS staff shall add NAV/ or COM/ or DAT/ in front of that indication or

If no clear indication of the equipment is present or in case of any doubt, as not contact could be achieved, the IFPS staff shall reject the message.

Exception: if the flight plan contains STS/FFR, STS/SAR, STS/HOSP or STS/MEDEVAC then the IFPS staff shall delete ‘Z’ from item 10a and insert the IFP indicator ERREQPT.

2) The IFPS staff shall insert the letter ‘R’ in item 10a and insert the IFP indicator ERREQPT. 3) Messages raising that error shall be automatically rejected. However, there are some

exemptions when one of the following STS is present in the message: FFR, SAR, HOSP or MEDEVAC. If a message is presented for manual processing with that error, it means that the message matches the criteria set for an exemption. Therefore the following procedure shall be applied by IFPS staff:

The IFPS staff shall apply SCP1 and

If contact with the message originator is not possible then the IFPS staff shall delete ‘R’ from item 10a, insert the IFP indicator ERREQPT, and



If subsequently a RAD error is raised due to Flight Property Restriction on TP (SID, STAR for R-NAV equipped A/C), then the IFPS staff shall ignore that error and insert IFP/ERROUTRAD.

Related Sections

Improvement in Quality of Submitted Messages










Error Message(s)

EFPM167: FILED PBN REQUIRES CEQPT <Equipment Descriptor>


Equipment Descriptor: One or a combination of the following equipment descriptors depending on the filed PBN: D, G, I, O, S

Can be ignored


Reason

The content of the equipment field (Item 10a of the ICAO flight plan or CEQPT field in ADEXP) is not consistent with the filed PBN.

Requirements

Some PBN descriptors are only valid if the corresponding equipment is specified. The message filer shall ensure consistency between the equipment field and the PBN sub-field.

IFPS Procedures

The IFPS staff shall apply SCP1 and if contact with the message originator is not possible then the IFPS staff shall insert the missing equipment descriptor(s) stated in the error message into the equipment field order to be consistent with the filed PBN. In the case a descriptor is added the IFPS staff shall also insert the IFP indicator ERREQPT.

Related Sections







Error Message(s)

EFPM209: STS/NONRVSM IS NOT EXPECTED FOR AN RVSM APPROVED FLIGHT WITHIN EUR RVSM AIRSPACE


NA

Can be ignored


It will result in IFP/RVSMVIOLATION to be inserted automatically in the message output.

Reason

In the submitted message, the equipment field contains ‘W’ and STS/NONRVSM is present in the message.

Requirements

Within the EUR RVSM airspace, where a flight indicates ‘W‘ in the equipment field, then STS/NONRVSM shall not be present in the message.

IFPS Procedures


Related Sections


Reduced Vertical Separation Minima (RVSM)

IFP Indicators




Error Message(s)

EFPM210: NON RVSM APPROVED FLIGHT WITHIN EUR RVSM AIRSPACE AND STS/NONRVSM IS NOT EXPECTED FOR A CIVIL AIRCRAFT


NA

Can be ignored


It will result in IFP/NONRVSM to be inserted automatically in the message output.

Reason

In the submitted message, the flight type is not given as M, the equipment does not contain W, and STS/NONRVSM is present in item 18.

Requirements

Within the EUR RVSM airspace, civil flights shall not be given STS/NONRVSM.

IFPS Procedures


Related Sections



IFP Indicators




Error Message(s)

EFPM211: STS/NONRVSM IS REQUIRED FOR NON RVSM APPROVED STATE FLIGHT


NA

Can be ignored


It will result in IFP/NONRVSM to be inserted automatically in the message output if the flight has one part outside the RVSM area.

Reason

In the submitted message, the flight type is given as M; the equipment does not contain W, and STS/NONRVSM is not found in the message.

Requirements

Within the EUR RVSM airspace, an approved State flight (flight type ‘M‘) that is non-RVSM equipped is required to indicate that state approval by including STS/NONRVSM in item 18.

IFPS Procedures


Related Sections



IFP Indicators




Error Message(s)

EFPM212: FIELDS 10 AND/OR 18 INCORRECT FOR STATE FORMATION FLIGHT IN EUR RVSM AIRSPACE


NA

Can be ignored



Reason

In the submitted message, the flight type is given as M; the number of aircraft indicated is more than 1, and:

W is included in the equipment field or

STS/NONRVSM is not included in the message or

Both W and STS/NONRVSM are included.

Requirements

Within the EUR RVSM airspace, State formation flights shall not include W in the equipment field, but must include STS/NONRVSM in the message.

IFPS Procedures


Related Sections



IFP Indicators




Error Message(s)

EFPM213: UNEXPECTED ROUTE DATA


NA

Can be ignored


Reason

The route field is found in an unexpected message (e.g. MFS message).

Requirements

Each message submitted to the IFPS shall consist of fields allowed for that type of message.

IFPS Procedures



Related Sections





Error Message(s)

EFPM214: MISSING ROUTE DATA


NA

Can be ignored


Reason

The message contains Initial Speed and Flight Level (item 15a and 15b in ICAO format messages or in the ROUTE field in ADEXP format messages), but no route elements are present.

Requirements

It is mandatory to fill in as much relevant detail as possible in the route field of a flight plan. The minimum possible element in the route field is ‘DCT’.

IFPS Procedures


Related Sections


ITEM 15: Route




Error Message(s)

EFPM215: FLIGHT PLAN DATA HAS RESTRICTED ACCESS


NA

Can be ignored


Reason

This error is related to RQP messages only and can only be seen internally. The requested flight plan is not available for unauthorised access as it was submitted with EUR/PROTECTED.

Requirements

The requested flight plan has been classified as sensitive and shall not be available for unauthorised access.

IFPS Procedures

NA

Related Sections

EUR/PROTECTED





Error Message(s)

EFPM216: POSSIBLE DOF SUBFIELD WITH WRONG SYNTAX DETECTED IN FIELD18. (Field Name)


Field Name: EOBD Estimated Off Block Date.

Can be ignored


Reason

A possible incorrectly formatted DOF has been identified in Item 18 of the message.

Requirements

The IFPS shall check for a DOF in the correct format of DOF/YYMMDD. The IFPS shall also check for any sequence of the letters D, O and F, even when other characters may separate those letters, and raise the error as a warning where this is found.

IFPS Procedures

The IFPS staff shall check the Item 18 of the message and:

If the date of flight information is present, but is incorrectly formatted, e.g. RMK/DOF090608, then the IFPS staff shall correct the syntax or

If the date of flight information (DOF) is not present (which means that the letters D,O and F have been found across the Item 18), then the IFPS staff shall ignore the error.

Related Sections





Error Message(s)

EFPM217: FPL WITH SAME ARCID AND OVERLAPPING FLYING PERIOD EXISTS: <Flight Details>


Flight Details: ARCID ADEP/EOBT ADES/EET DOF

Can be ignored


Reason

A valid flight plan exists in the IFPS with a given total flying time that overlaps with that given in the submitted message.

Requirements

The IFPS cannot accept a flight plan that has the same callsign and a flying time, based on the EOBT and total estimated elapsed flying time that overlaps with an existing valid flight.

IFPS Procedures

The IFPS shall apply SCP1.

Related Sections





Error Message(s)

EFPM219: NON RVSM APPROVED FLIGHT WITHIN EUR RVSM AIRSPACE


NA

Can be ignored



Reason

In the submitted message, the flight rules are not M, the equipment does not contain W, and STS/NONRVSM is not found in the message.

Requirements

Flights within the EUR RVSM airspace are required to be suitably equipped (equipment includes ‘W‘) or to be a military flight (flight type is ‘M‘) and the exemption STS/NONRVSM.

IFPS Procedures


Related Sections



IFP Indicators




Error Message(s)

EFPM220: NO EXISTING FILED FLIGHT PLAN MATCHING THIS MESSAGE


NA

Can be ignored


Reason

This error is related to messages with title DLA, CHG, DEP, ARR, RQP, CNL messages or to their equivalent in ADEXP format, respectively IDLA, ICH, IDEP, IARR, IRQP and ICNL. The referent flight plan may or may not have been filed; the referent flight plan may or may not have been accepted by IFPS; it may have been cancelled or closed by another party, or the key fields in the submitted

message do not match.

Requirements

An associated message shall only be submitted to the IFPS when it can refer/associate to a valid flight plan.

IFPS Procedures


Related Sections


Message Association

Modification (CHG)

Delay (DLA)

Cancel (CNL)

Departure (DEP)

Arrival (ARR)





Error Message(s)

EFPM223: EOBT IN THE PAST COMPARED TO IFPS SYSTEM TIME: <IFPS System Time>


IFPS System Time: HH:MM hours and minutes.

Can be ignored


Reason

This error is related to DLA messages only. At the time of processing (IFPS time), the DLA has an EOBT in the past.

Requirements

A DLA message shall only be for the future, compared to IFPS time at the time of processing of that message.

IFPS Procedures


Related Sections


Delay (DLA)




Error Message(s)

EFPM224: MESSAGE MATCHES MULTIPLE FLIGHT PLANS


NA

Can be ignored


Reason

The submitted message matches more than one existing flight plan.

Requirements

Where there is more than one matching flight plan held in the IFPS, the correct message association may be increased in accuracy by adding the EOBT (except for DEP) and DOF of the relevant flight plan in that associated message.

IFPS Procedures

The IFPS staff shall apply SCP1 unless there is no doubt about the flight plan that associated message refers to.

Related Sections


Message Association

Modification (CHG)

Delay (DLA)

Cancel (CNL)

Departure (DEP)

Arrival (ARR)




Error Message(s)

EFPM225: MISSING OR ERRONEOUS FIELD (Field Name)


Field Name: FLTTYP, ROUTE.

Can be ignored


Reason

FLTTYP: The message does not contain an indication of the type of flight.

ROUTE: The ROUTE field is present but cannot be used to create a profile.

Requirements

FLTTYP: The type of flight shall be indicated in the message.

ROUTE: The ROUTE field shall be present and semantically correct.

IFPS Procedures

FLTTYP:

Where the message originator can be contacted, the IFPS staff shall correct accordingly or

Where the message originator cannot be contacted, the IFPS staff shall change the type of flight to G if the aircraft identification is a registration and to N if the aircraft identification is an alphanumeric company callsign.

ROUTE: The IFPS staff shall apply SCP1.

Related Sections





ITEM 15: Route





Error Message(s)

EFPM226: THIS <Message Title> MESSAGE ASSOCIATES WITH THE FPD: <Flight Plan Key Fields>


Message Title: can be FNM, MFS or AFP. Flight Plan Key fields: ARCID, EOBT, ADEP, ADES, DOF.

Can be ignored


Reason

This is an internal IFPS error raised when an APL message created from FNM/MFS/AFP partially associates with an existing FPD.

Requirements

NA

IFPS Procedures

The aim of this error when raised is to inform about the message association. The IFPS staff shall proceed with normal manual processing.

Related Sections







Error Message(s)

EFPM227: MANUAL ADDRESSING REQUIRED. PRESS APPLY TO CONTINUE


NA

Can be ignored


Reason

This is an internal error to inform the IFPS staff to add any ATS units’ addresses following the use of IFPSTO/IFPSTART.

Requirements

NA

IFPS Procedures

The IFPS shall add manually if needed any ATS units addressee to cover the part of the flight which is in inside the IFPSTOP/IFPSTART portion.

Related Sections

IFPSTOP/IFPSTART




Error Message(s)

EFPM228: INVALID VALUE <Field Name>


Field Name: ARCTYP, ADEP, ADES, ALTRNT1 (and/or ALTRNT2. The number is indicating the ALTRNT position), ADARR, EOBT, EOBD, ESTDATA, STS.

Can be ignored


Reason

ARCTYP: An unknown aircraft type designator has been filed.

ADEP: The departure aerodrome contains an unknown or unidentifiable location indicator.

ADES: The destination aerodrome contains an unknown or unidentifiable location indicator.

ALTRNT: The alternate aerodrome contains an unknown or unidentifiable location indicator.

ADARR: The arrival aerodrome in a diversion arrival message (ARR) is unknown or has an unidentifiable location indicator.

EOBT: An incorrect EOBT has been filed.

EOBD: An incorrect EOBD has been filed.

ESTDATA: An incorrect ESTDATA has been filed. (FNM, MFS). Example: EST/ATSUR1560. The AFP associates to a FPL that is too far in the past (AFP).

STS: An incorrect STS value has been filed.

Requirements

ARCTYP: A known ICAO aircraft type designator must be used, or indicated as ZZZZ with the appropriate aircraft type details in item 18 in the subfield TYP/.

ADEP: When the departure aerodrome is not a known ICAO designator, it must be indicated as

ZZZZ and item 18 shall contain the sub-field DEP/ with the details of the aerodrome.

ADES: When the destination aerodrome is not a known ICAO designator, it must be indicated as

ZZZZ and item 18 shall contain the sub-field DEST/ with the details of the aerodrome.

ALTRNT: When the alternate aerodrome is not a known ICAO designator, it must be indicated as

ZZZZ and item 18 shall contain the sub-field ALTN/ with the details of the aerodrome.

ADARR: The arrival aerodrome in a diversion arrival message (ARR) shall be a known ICAO designator or shall be ZZZZ.

EOBT: The EOBT shall be formatted as HHMM.

EOBD: The EOBD shall be formatted as YYMMDD.

ESTDATA: FNM, MFS): The ESTDATA shall be formatted as HHMM (FNM, MFS).

STS: Special flights status must only indicated by one of the standardised STS descriptors.

Note AFP messages submitted to the IFPS are associated with all flights that have an EOBT in the past or up to 30 minutes in the future compared to the AFP estimate time.

IFPS Procedures

ARCTYP:



If a valid ICAO designator may be clearly identified, the IFPS staff shall correct that designator or

If a valid ICAO designator cannot be identified, the IFPS staff shall contact the message originator and

o If contact with the message originator is made, the IFPS staff should obtain the correct aircraft type value and if that is not possible, shall coordinate the correction (see below for the options) with the message originator or

o If no contact with the message originator is possible, the IFPS staff shall either: Change aircraft type to ZZZZ and insert TYP/ <original type> in item 18 and

then select the appropriate ZZZZ performance from the performance table (see Note below) or

If the error appears to be caused by an NM CACD deficiency, change the aircraft type to ZZZZ and insert TYP/<original type> in item 18 and select then the appropriate ZZZZ performance from the performance table (see Note below). Raise an Ops Incident in Remedy CCMS, and in Service Affected, select Airspace Data and GIC (Group In Charge), select OPSD_AD.

Note ZZZZ generic aircraft performances:

SEEE (SINGLE ENGINE)

MEEE (MULTI-ENGINE)

TPPP (TURBO-PROP)

TJJJ (TURBO-JET)

These aircraft performance categories are applied internally by the IFPS staff, and are required in order that the IFPS may build a more accurate profile for that flight.

ADEP, ADES, ALTRNT and ADARR: the IFPS staff shall apply SCP2.

EOBT, EOBD: the IFPS staff shall apply SCP1.

ESTDATA: The IFPS staff shall check the flight plan history for existing flight plan data and

If there is no existing flight plan data for the associated airborne message, the IFPS staff shall contact the originator of the airborne message to obtain correct/processable data and

If it is not possible to obtain the correct data or if there is existing flight plan data, the message shall be rejected.

STS: The IFPS staff shall delete any descriptor that is not one of the standardised descriptor. The IFPS staff shall correct the descriptor if the descriptor can be identified as one of the standardised descriptor. Example: STS/STATES can be changed to STS/STATE.

Related Sections








Arrival (ARR)






Error Message(s)

EFPM229: INVALID FORMAT


NA

Can be ignored


Reason

This error is related to messages in ADEXP format and with title AFIL only. The ETO in an AFIL message is in an incorrect format.

Requirements

The correct format shall be used. Example: -AFIL_DATA –PTID POINT-FL FXXX –ETO YYMMDDHHMMSS

IFPS Procedures

The IFPS staff shall contact the message originator in order to obtain the correct ETO. If no contact is possible, then the IFPS staff shall insert the filling time of the message, in association with the appropriate date of flight.

Related Sections





Error Message(s)

EFPM230: ASSOCIATION NO LONGER VALID THE FPD IS CLOSED


NA

Can be ignored


Reason

Whilst processing an associated message, a FPD became ‘closed’.

Requirements

An associated message shall only be submitted to the IFPS when it can refer/associate to a valid flight plan.

IFPS Procedures


Related Sections





Error Message(s)

EFPM231: CIVIL FORMATION FLIGHT NOT PERMITTED IN EUR RVSM AIRSPACE


NA

Can be ignored


Reason

In the submitted message, the flight type is not given as M, and the number of aircraft indicated is more than 1.

Requirements

Within the EUR RVSM airspace, formation flights are only allowed for military flights.

IFPS Procedures


Related Sections






Error Message(s)

EFPM232: FLIGHT PLAN ALREADY RECEIVED FROM ADDRESS <Address>


Address: AFTN or SITA address.

Can be ignored


Reason

A FPL with the same details has already been received and processed by IFPS.

Requirements

The IFPS shall not accept a duplicate FPL from an address different than the address of the original, stored FPL.

IFPS Procedures

The IFPS staff shall reject the FPL.

Related Sections

Message Association




Error Message(s)

EFPM234: ESTIMATED OFF BLOCK DATE AND TIME IS NOT WITHIN ACCEPTABLE RANGE AFTER FILING TIME. (EOBD)


EOBD: Estimated Off Block Date.

Can be ignored


Reason

The filing time is later than the EOBDT.

Requirements

When comparing the filing time of a message to the EODBT of the flight plan, the EOBDT shall be within the following parameters: -10 minutes/+ 12 hours.

IFPS Procedures


Related Sections




Delay (DLA)

Modification (CHG)




Error Message(s)

EFPM235: FIELD FORBIDDEN IN THIS TYPE OF MESSAGE (Field Name)


Field Name: various values such as ESTDATA

Can be ignored


Reason

The field that is specified in the error message is not expected for the type of message submitted. Example: EST DATA field in a FPL received in ADEXP format.

Requirements

Submitted messages shall only contain field that are permitted for that message type.

IFPS Procedures

The IFPS staff shall check that the message title is coherent with the message content and

If the title is correct, the IFPS staff shall remove the offending field or If the title is incorrect, the IFPS staff shall change the title to the correct one or

In case of any doubt, the IFPS staff shall apply SCP1.

Related Sections







Error Message(s)

EFPM236: ESTIMATED OFF BLOCK DATE AND TIME NOT IN THE ACCEPTABLE RANGE: DDHHMM TO DDHHMM


DDHHMM: Day number (01 to 31), Hours and Minutes. The two values define the window in which IFPS would accept the message.

Can be ignored


Reason

For a FPL, the filed EOBDT is more than 12 hours in the past, or more than 120 hours (5 days) in the future, when compared to current system time at the time of processing of that message.

For a DLA or a CHG updating the EOBT, the filed EOBT is more than 0 minutes in the past when compared to the current system time, or more than 20 hours in the future compared to the EOBT of the flight at the time of processing of that message.

Requirements

For FPLs containing a DOF, the IFPS may accept these messages with an EOBT up to 12 hours in the past, and up to 120 hours (5 days) in advance of the system time at the time of processing, but those FPLs with an EOBT of more than 30 minutes in the past shall fail automatic processing in the IFPS.

For a DLA or a CHG updating the EOBT, the filed EOBT shall be in the future when compared to the current system time at the same of processing and shall not delay that flight for an EOBT more than 20 hours in the future compared to the current EOBT of that flight.

Note Those FPL messages not containing a DOF shall be processed automatically, but shall be considered to take place in the 24 hour period that starts 30 minutes in the past when compared to the system at the time of processing, with the DOF being inserted automatically by the IFPS in message output.

IFPS Procedures

For FPLs, the IFPS staff shall apply SCP1.

For DLAs and CHGs, the IFPS staff shall reject the message.

Related Sections



Delay (DLA)




Error Message(s)

EFPM237: MESSAGE MATCHES EXISTING INVALID MESSAGES


NA

Can be ignored


Reason

The message associates with another message that has failed automatic processing and is awaiting or undergoing manual treatment by the IFPS staff.

Requirements

Where any message fails automatic processing and is moved to the manual treatment queue, all subsequent associated messages with matching ARCID, ADEP and ADES, shall be linked to that invalid message and shall not be treated until that invalid message has been treated by the IFPS staff. This is a safety check to ensure that messages are treated in the correct sequence.

IFPS Procedures

The IFPS staff shall press ‘Test’ or ‘Apply’ and continue with the manual processing. This error is a warning and does not require any specific action.

Related Sections

NA




Error Message(s)

EFPM238: MESSAGE FILED BEFORE MATCHING FILED FLIGHT PLAN


NA

Can be ignored


Reason

The message has a filing time earlier than that of an existing flight plan.

Requirements

The IFPS shall treat all associated messages in order of filing time.

IFPS Procedures

The IFPS staff shall press ‘Test’ or ‘Apply’ and continue with the manual processing. This error is a warning and does not require any specific action.

Related Sections

NA




Error Message(s)

EFPM239: DATE AND TIME GIVEN ARE INCONSISTENT WITH <ESTDATA>


ESTDATA: Estimated Data.

Can be ignored


Reason

The AFP associates to a FPL that is too far in the past.

Requirements

The error is related to messages type AFP only. AFP messages submitted to the IFPS are associated with all flights that have an EOBT in the past or up to 30 minutes in the future compared to the AFP estimate time.

IFPS Procedures

If the flight is for the previous day and has been suspended by ETFMS because it was not activated, the IFPS staff shall delete the flight and process the AFP.

Related Sections





Error Message(s)

EFPM241: MESSAGE ASSOCIATES TO <FLTSTATE> FLIGHT


FLTSTATE: OFF BLOCKS, ACTIVATED, TERMINATED, TACT DELETED

Can be ignored


Reason

OFF BLOCKS and ACTIVATED: The submitted message associates to a stored flight plan that has been activated. The OFF BLOCKS flight state can only be triggered whenever the departure aerodrome has a status of ‘Full CDM’ or ‘Advanced ATC Tower’.

TERMINATED: The submitted message associates to a stored flight plan that has been terminated in the ETFMS system.

DELETED: The submitted message associates to a stored flight plan that has been cancelled manually in the ETFMS system.

Requirements

It is not permitted to update a stored flight plan when the flight has been activated, terminated or deleted.

IFPS Procedures

DELETED:

For FNM/MFS, the messages are automatically rejected. If the message originator or the aircraft operator contacts IFPS, then the IFPS staff shall inform the FM DOM that airborne messages are received for a flight that has been manually cancelled in the ETFMS.

For AFP, the IFPS staff shall ignore the error and shall inform the FM DOM (see Note) that airborne messages are received for a flight that has been manually cancelled in the ETFMS.

For RQP, the IFPS staff shall ignore the error and shall inform the FM DOM (see Note) that the flight details are requested by ATC but the flight has been manually cancelled in the ETFMS.

Note When informing the FM DOM, the IFPS staff shall refer to a flight cancelled in the ETFMS and not to a flight deleted as stated in the IFPS error message. This is to avoid confusion as the manual action performed in the ETFMS was ‘Cancel’ and not ‘Delete’.

OFF-BLOCKS:

This state is only applicable to CNL, DLA and CHG (route or EOBT) messages. These messages are automatically rejected.

If the message originator or the aircraft operator contacts IFPS, they should be asked to contact the tower of the aerodrome of departure or their CDM Partner.

ACTIVATED:

This state is only applicable to CNL, DLA and CHG (route or EOBT) messages. These messages are automatically rejected.

If the message originator has contacted the IFPS and indicated that the flight has been incorrectly activated, the IFPS staff shall check the information available in the ETFMS system.



If the information available in the ETFMS system indicates that the flight has been correctly activated, the IFPS staff shall inform the message originator of the evidence of the activation and reject the message.

If the information available in the ETFMS system supports that the flight has been incorrectly activated and

If the activation was caused by an incorrect DEP/ AFP/ MFS/ FNM, the flight plan must be cancelled and refiled (to ensure ATC are correctly notified) so the IFPS staff shall:

o request the flight to be de-activated (done via the ‘undo activation’ button) in the ETFMS

o for CNL, process the message after the FUM o for DLA/CHG, reject the message and ask the message originator to cancel the flight

plan and re-file with the new details. Or if the activation was caused by an incorrect message in the ETFMS (FSA, etc), the flight

shall be de-activated in the ETFMS system and after the status has been updated in the IFPS the message may be processed.

TERMINATED:

DEP/CNL/CHG/DLA/FNM/MFS messages are automatically rejected.

For RQP messages, the IFPS staff shall ignore the error.

For an AFP indicating that the flight is diverting, the ETFMS system may have assumed that the flight has landed at its destination and the flight will have been terminated. In this case the IFPS staff shall request the flight to be de-activated (done via the ‘undo activation’ button) in the ETFMS and after the status has been updated in the IFPS the AFP (ACH) message can be processed in IFPS.

For AFP others than for diversion or if the message originator has contacted the IFPS for a rejected DEP/CNL/CHG/DLA message and indicates that the flight has been incorrectly terminated, the IFPS staff shall check the information available in the ETFMS.

If the information available in the ETFMS indicates that the flight has been correctly terminated, the IFPS staff shall inform the message originator of the evidence of the termination and delete the message or

If the information available in the ETFMS supports that the flight has been incorrectly terminated and

o If the activation was caused by an incorrect DEP/ AFP/ MFS/ FNM, the flight plan must be cancelled and refiled (to ensure ATC are correctly notified) so the IFPS staff shall:

request the flight to be de-activated (done via the ‘undo activation’ button) in the ETFMS

for CNL, process the message after the FUM for DLA/CHG, reject the message and ask the message originator to cancel

the flight plan and re-file with the new details. o Or, if the termination was caused by ETFMS (no FSA/CPR received for more than 3

hours), the IFPS staff shall request the flight to be de-activated (done via the ‘undo activation’ button) in the ETFMS and after the status has been updated in the IFPS the message can be processed.

o And, if the de-activation (done via the ‘undo activation’ button) is not possible (flight has been terminated for more than 3 hours), then the IFPS staff shall ignore the error and process the message.

When there is any doubt about the correct “terminated” status of the flight plan to which the AFP/FNM/MFS messages apply, then the IFPS staff shall ignore the error.

Related Sections

Improvement in Quality of Submitted Messages

IFPS Monitoring Flight Evolution




Error Message(s)

EFPM243: AIRCRAFT TYPE IS ZZZZ BUT TYP Z IS NOT PRESENT (ARCTYP)


NA

Can be ignored


Reason

The aircraft type is filed a ZZZZ, and the subfield TYP is not present in Item 18.

Requirements

Where ZZZZ is filed as an aircraft type designator in item 9, the sub-field TYP shall be present item 18 giving the details of the aircraft.

IFPS Procedures

If a valid ICAO designator may be clearly identified from within the item 18, the IFPS staff shall insert that designator in Item 9 or

If an aircraft type information may be found in item 18 (under RMK/ for example), the IFPS staff shall insert TYP/ in front of that information or

In all other cases, the IFPS staff shall contact the message originator to co-ordinate a correction. o If no contact with the message originator is possible, the IFPS staff shall insert

TYP/UNKNOWN in Item 18 and when the window Aircraft ZZZZ Dialog appears, the IFPS staff shall select the appropriate ZZZZ performance.

Related Sections


Aircraft Type (TYP)




Error Message(s)

EFPM245: AIRCRAFT TYPE AND TYPZ PRESENT (TYPZ)


NA

Can be ignored


Reason

Item 9 contains an aircraft type designator other than ZZZZ and the subfield TYP is present in item 18.

Requirements

When item 9 contains an aircraft type designator, the subfield TYP shall not be present in item 18.

IFPS Procedures

If the aircraft type given in item 9 is a valid ICAO designator, the IFPS staff shall delete the subfield TYP in item 18 or

If the aircraft type given in item 9 is not a valid ICAO designator or cannot be clearly identified, then the IFPS staff shall replace the type in item 9 by ZZZZ.

Related Sections


Aircraft Type (TYP)




Error Message(s)

EFPM246: AMBIGUOUS VALUE <Value>


Value

Can be ignored


Reason

The value specified in the error message is ambiguous.

Requirements

Values in a message shall not be ambiguous.

IFPS Procedures

The IFPS staff shall try to determine the value. If this is not possible or in case of any doubt then the IFPS staff shall apply SCP1.

Related Sections





Error Message(s)

EFPM247: ALTERNATE AERODROME IS ZZZZ BUT ALTN INFO IS NOT PRESENT (ALTRNT1 or ALTRNT2)


ALTRNT 1 or 2: 1 or 2 indicates if it concerns the first or the second alternate aerodrome specified in Item 16c.

Can be ignored


Reason

The first (ALTRNT1) and/or the second (ALTRNT2) alternate aerodrome is/are given as ZZZZ but no ALTN sub-field is present in Item 18.

Requirements

Where an alternate destination aerodrome is indicated as ZZZZ, it is necessary to include the sub-field ALTN in item 18 with relevant details of that aerodrome.

IFPS Procedures

The IFPS staff shall check the Item 18 for possible ALTN information incorrectly formatted (Example: ALT/EBAW) and

If Item 18 does contain any indication about an alternate aerodrome; the IFPS staff shall make any appropriate correction to ensure that the sub-field is recognized by the IFPS or

If Item 18 does not contain any indication about an alternate aerodrome, then the IFPS staff shall delete the ZZZZ indication present as alternate aerodrome.

Related Sections






Error Message(s)

EFPM248: AERODROME IS ZZZZ BUT DEP Z IS NOT PRESENT (ADEP)

EFPM248: AERODROME IS ZZZZ BUT DEST Z IS NOT PRESENT (ADES)


ADEP/ADES: Aerodrome of Departure/Aerodrome of Destination.

Can be ignored


Reason

The departure aerodrome is given as ZZZZ and the sub-field DEP is not present in Item 18.

The destination aerodrome is given as ZZZZ and the sub-field DEST is not present in Item 18.

Requirements

Where a departure aerodrome is given as ZZZZ, it is necessary to include the sub-field DEP in Item 18 with relevant details of the aerodrome.

Where a destination aerodrome is given as ZZZZ, it is necessary to include the sub-field DEST in Item 18 with relevant details of the aerodrome.

IFPS Procedures


Related Sections







Error Message(s)

EFPM249: ACTUAL DATE AND TIME OF DEPARTUE IS NOT WITHIN ACCEPTABLE RANGE, AFTER RECEPTION TIME. (ATD)


ATD: Actual Time of Departure.

Can be ignored


Reason

This error is related to DEP/IDEP messages only. The filed departure time is more than 10 minutes in the future, when compared to the current system time.

Requirements

When a DEP message is received, the arrival time should not be in the future.

IFPS Procedures


Related Sections






Error Message(s)

EFPM250: ACTUAL DATE AND TIME OF ARRIVAL IS NOT WITHIN ACCEPTABLE RANGE, AFTER RECEPTION TIME. (ATA)


ATA: Actual Time of Arrival.

Can be ignored


Reason

This error is related to ARR/IARR messages only. The filed arrival time is more than 10 minutes in the future, when compared to the current system time.

Requirements

When an ARR message is received, the arrival time should not be in the future.

IFPS Procedures


Related Sections


Arrival (ARR)




Error Message(s)

EFPM321: FPL WITH SAME REG MARKINGS AND OVERLAPPING FLYING PERIOD EXISTS: <Flight Details>


Flight Details: ARCID ADEP/EOBT ADES/EET DOF

Can be ignored


Reason

A valid flight plan exists in the IFPS with the same registration markings (REG/), ADEP, ADES and overlapping flying time.

Requirements

The IFPS shall raise an error when a new FPL submission matches (same registration markings, ADEP and ADEs) a valid FPL and when the flying time periods of the two FPLs overlaps.

IFPS Procedures


Related Sections





Error Message(s)

EFPM330: ROUTE CROSSES TOO MANY AIRSPACES <Value> MORE THAN <Maximum value>


Value: amount of airspaces crossed by the flight trajectory. Maximum value: threshold value set for triggering the error.

Can be ignored


Reason

The amount of airspaces crossed by the flight trajectory exceeds the set maximum value.

Requirements

NA

IFPS Procedures

The IFPS staff shall plot and analyse the route field in order to identify the airway or point triggering the error as such occurrence may happen when the trajectory has some DCT back and forth across the IFPZ (may be caused by homonym(s) issue).

In all cases the IFPS staff shall apply SCP1 unless there is no ambiguity about the intended flight trajectory (i.e. homonym issue solved).

Related Sections





Error Message(s)

EFPM401: NOT ALLOWED TO USE A FPL TO UPDATE THE EOBT. DLA OR CHG IS REQUIRED


NA

Can be ignored


Reason

A second flight plan is filed in order to modify the first one, where the EOBT is different.

Requirements

The update of the EOBT with a second flight plan is not permitted in IFPS.

IFPS Procedures


Related Sections


Flight Plan (FPL)

Modification (CHG)

Delay (DLA)



146.111 Error Class/Error Id: ROUTE29

Error Message(s)

ROUTE29: FORBIDDEN TO CROSS THE BORDER BETWEEN < Airspace Name> AND < Airspace Name> on DCT <Point A> .. <Point B>. [<Restriction ID>]


Airspace Name: specifies the name of the airspaces in between which the cross border if forbidden.

Point A and B: specifies the DCT segment from the route which crosses the border in between the two airspaces.

Restriction ID: Reference of the restriction.

Can be ignored


Reason

It is not allowed to cross the border in between the two airspaces on that specific segment.

Requirements

When filing a route in Free Route Airspace (FRA), the route shall comply with all the requirements associated to the FRA: DCT limit, forbidden segment, levels, times, cross border allowed or not, etc

IFPS Procedures

The IFPS staff shall analyse the route to determine whether or not the error is correctly raised and

If the error is incorrectly raised, then the IFPS staff shall ignore that error or

If the error is correctly raised then the IFPS staff shall apply SCP1.

Related Sections


Airways




Error Message(s)

ROUTE30: INVALID DCT <Point A>..<Point B>: (<DCT Length> NM). DCT LONGER THAN (<Max Restriction Distance> NM) ARE NOT ALLOWED TO CROSS THE BORDER BETWEEN < Airspace Name> AND < Airspace Name>. [<Restriction ID>]


Point A and B: specifies the DCT segment from the route which crosses the border in between the two airspaces.

DCT Length in NM of the distance between Point A and Point B. Max Restriction Distance in NM specifying the maximum distance permitted.

Airspace Name: specifies the name of the airspaces in between which the cross border if forbidden.

Restriction ID: Reference of the restriction.

Can be ignored


Reason

The length of this DCT segment is greater than the Cross-border DCT limit defined for those adjacent airspaces.

Requirements

When filing a route in Free Route Airspace (FRA), the route shall comply with all the requirements associated to the FRA: DCT limit, forbidden segment, levels, times, cross border allowed or not, etc

IFPS Procedures


If the error is incorrectly raised, then the IFPS staff shall ignore that error or If the error is correctly raised then the IFPS staff shall apply SCP1.

Related Sections


Airways




Error Message(s)

ROUTE41: PLEASE CHECK NAS OF GENERATED PORTION: <List of NAS>.


<List of NAS>: first two letters of the country code, for example EI for Ireland.

Can be ignored


Reason

This error is used as a warning for ACH/APL messages. The applicable mode for airborne message processing is set to manual. In the manual mode, the IFPS shall try to build a route using the Propose Route Function from the end of the clearance limit given in the airborne message (FNM/MFS/AFP) to the flight plan route or to the aerodrome of destination. When the Propose Route Function finds a valid route, then the error is raised and contains the list of NAS corresponding to the “system generated portion”.

Requirements

Whenever the Propose Route Function is able to build a route from the end of the clearance limit to the flight plan route or to the aerodrome of destination and the generated route portion penetrates new NAS when compared to the flight plan route, then the IFPS shall invalidate that message in order for an IFPS staff to be able to verify the system generated portion.

IFPS Procedures

For ACH messages:

The IFPS staff shall note the NAS listed in the error and then press on “Test”. As a result the error will disappear. The IFPS staff shall plot the route on the CHMI map and analyse the overall trajectory and

When the generated portion to re-connect to the flight plan route is logical, then the message can be processed without any further changes to the route or

When the generated portion to re-connect to the flight plan is not logical, then the IFPS staff shall manually built a route for this portion of the trajectory.

Additionally:

When the error has listed NAS which are downstream of the re-connection to the flight plan route, then the IFPS shall ensure that the route remains identical to the flight plan for this portion of the trajectory.

For APL messages:

The IFPS staff shall first check the Flight Plan History to see whether the flight plan was previously filed and rejected and then the IFPS staff shall plot the route on the CHMI map and analyse the generated portion.

If Flight Plan History data exists: o And it is possible to have a logical route by using the route present in the Flight Plan

History, then the IFPS staff shall use that data or o It is not logical to use the route present in the Flight Plan History:

And the route of the generated portion is logical, then the IFPS staff shall process the message or

The route of the generated portion is not logical, then the IFPS staff shall manually modify/built a route.



If Flight Plan History data does not exist: o And the route of the generated portion is logical, then the IFPS staff process the

message or o The route of the generated portion is not logical, then the IFPS staff shall manually

modify/built a route.

Related Sections





Error Message(s)

ROUTE42: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE RUNWAY IN USE.


SID/STAR: Standard Instrumental Departure, Standard Instrumental Arrival. TPD ID: Terminal Procedure full designator. Example: DKB6F.

Can be ignored


Reason

The given terminal procedure does not comply with the runway in use and no valid terminal procedures exist to replace it.

Requirements

Whenever specified in a message, a valid TP shall be filed.

IFPS Procedures



Related Sections


SID/STAR




Error Message(s)

ROUTE43: The <SID or STAR> <TP ID> IS NOT VALID BECAUSE THE RFL IS BELOW MIN LEVEL ON <LAST OR FIRST> SEGMENT OF <SID or STAR>.


SID/STAR: Standard Instrumental Departure, Standard Instrumental Arrival.

TPD ID: Terminal Procedure full designator. Example: DKB6F. First segment if it is a STAR and last segment if it is a SID.

Can be ignored


Reason

The given terminal procedure does not comply with the RFL for that portion of the flight (Example: FPL has an RFL of 080 and the SID specified has for the last segment a minimum level of 090) and no valid terminal procedure exist to replace it.

Requirements


IFPS Procedures



Related Sections


SID/STAR




Error Message(s)

ROUTE44: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE IT IS CLOSED.



Can be ignored


Reason

The given terminal procedure does not comply with the requirement because of a terminal procedure closure and no valid terminal procedures exist to replace it.

Requirements


IFPS Procedures



Related Sections


SID/STAR




Error Message(s)

ROUTE45: The <SID or STAR> <TP ID> is not valid because of the aircraft equipment. [<Restriction ID>].



TPD ID: Terminal Procedure full designator. Example: DKB6F. Restriction ID: number of the restriction.

Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of an aircraft equipment condition in the restriction, and no valid terminal procedures exist to replace it.

Requirements


IFPS Procedures

The IFPS staff shall analyse the error to determine whether or not the error is correctly raised and

If the error is incorrectly raised, then the IFPS staff shall ignore that error or If the error is correctly raised then the IFPS staff shall apply SCP1 (primarily to determine if

the required equipment has been omitted and secondly to agree on a rerouting if the equipment has not been omitted).

Related Sections


SID/STAR






Error Message(s)

ROUTE46: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE AIRCRAFT TYPE. [<Restriction ID>].




Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of an aircraft type condition in the restriction, and no valid terminal procedures exist to replace it.

Requirements


IFPS Procedures



Related Sections


SID/STAR


Aircraft Type (TYP)




Error Message(s)

ROUTE47: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE FLIGHT TYPE. [<Restriction ID>]



TPD ID: Terminal Procedure full designator. Example: DKB6F. Restriction ID: Reference of the restriction.

Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of a flight type condition in the restriction, and no valid terminal procedures exist to replace it.

Requirements


IFPS Procedures



Related Sections


SID/STAR





Error Message(s)

ROUTE48: THE <SID or STAR> <TP ID> IS NOT VALID. <TP ID> IS SUGGESTED.



Can be ignored


Ignoring the error results in IFPS using the TP that is suggested.

Reason

The flight does not comply with the parameters of the terminal procedure indicated in the message. One terminal procedure is suggested by the system.

Requirements


IFPS Procedures

The IFPS staff shall analyse the route to determine why the filed TP is not valid.

If the TP is not valid because of aircraft equipment, it may have been omitted. In this case the IFPS staff shall contact the message originator and/or

If no contact with the message originator can be achieved or the error is not due to aircraft equipment then the IFPS staff shall replace the SID or STAR by the one suggested by the system providing that the suggested TP has the same designator and only a different sequence number or

If the suggested TP has a different designator then the IFPS staff shall apply SCP1.

Related Sections


SID/STAR




Error Message(s)

ROUTE49: THE POINT <Point Name> IS UNKNOWN IN THE CONTEXT OF THE ROUTE


Point Name: Name of the point being a navaid or a waypoint.

Can be ignored


Reason

A point is present in the given route that is regarded as being illogical.

Requirements

NA

IFPS Procedures

The IFPS staff shall analyse the route together with the point given in the error message and also considering the homonyms. The IFPS staff shall then replace the point by either the correct point or the geo coordinates of the given point.

Related Sections

ITEM 15: Route

Points




Error Message(s)

ROUTE52: THE DCT SEGMENT <Point A>..<Point B> IS FORBIDDEN. RESTRICTION: <Restriction ID>

Free Route Airspace error message:

ROUTE52: THE DCT SEGMENT <Point A> <Point Error>..<Point B> <Point Error> IS FORBIDDEN: <Restriction ID>


Point A and B: specifies the DCT segment from the route which is forbidden. For FRA errors: specifies the points of the segment which are not compliant with the FRA en-route and/or cross-border conditions.

Point Error: specifies the missing point roles (can be present after Point A and/or after Point B). Can be empty (when there are no issues for this point) or [NOT AN ALLOWED <Point Role> FRA POINT <Matching Error><Border Restriction ID>]

o Point Role: can be empty (when no roles exist for this point) or ENTRY, EXIT or INTERMEDIATE (the role that come closest to matching)

o Matching Error: Can be empty (when no role exists for any time, level or distance to a border)

or AT TIME <YYMMDDHHMMSS> (when the role is not allowed at the calculated

time at the border) or AT LEVEL <Fddd> (when the role is not allowed at the calculated level in

hundreds of feet at the point) or AT DISTANCE <NNN> (when the role is not allowed at the calculated distance

in nautical miles between the point and the border) o Border Restriction ID:

Can be empty (when no active border restriction is crossed at the calculated time at the border and at the calculated level at the point or

A colon followed by the Reference of the FRA cross-border restriction (always present when <Matching Error> is AT DISTANCE <NM>). Note: when a border is not crossed by the segment the error does not refer to the cross-border restriction that provided an Entry/Exit role.

Restriction ID: Reference of the restriction. For Free Route Airspace errors, it refers to the en-route restriction.

Can be ignored


Reason

The specified DCT routeing is not allowed.

For FRA: the point used is not compliant with the FRA conditions. A point shall be used with its correct role (entry, exit, both entry/exit, intermediate, and within the correct level band).

Requirements

The specified direct route in the submitted flight plan is defined as being not allowed. An alternative routeing is required.

For FRA: routings in FRA shall be compliant with all the FRA conditions.

IFPS Procedures






Related Sections


Airways




Error Message(s)

ROUTE125: FLIGHT RULES Z WITH NO IFR PART.


NA

Can be ignored


Reason

The flight rule is indicated as Z (VFR followed by IFR) and there is no IFR indication in the route.

Requirements

The route filed should be consistent with the flight rules, being I, V, Y or Z.

IFPS Procedures

The IFPS staff shall try to identify whether the flight rule is incorrect or the route field and correct accordingly.


Related Sections







Error Message(s)

ROUTE126: FLIGHT RULES Y WITH NO VFR PART.


NA

Can be ignored


Reason

The flight rule is indicated as Y (IFR followed by VFR), and there is no VFR indication in the route.

Requirements


IFPS Procedures



Related Sections







Error Message(s)

ROUTE127: FLIGHT RULES V WITH IFR PART.


NA

Can be ignored


Reason

The flight rule is indicated as V (VFR), and there is an IFR indication in the route.

Requirements


IFPS Procedures



Related Sections







Error Message(s)

ROUTE129: INSUFFICIENT DATA TO RESOLVE HOMONYM AT <Point Name>


Point Name: name of the point for which there is an homonym.

Can be ignored


Reason

The specified point exists in more than one location and IFPS is unable to determine which of those points is the intended one, given the information in the message.

Requirements

NIL

IFPS Procedures

Once the correct point has been identified, the IFPS staff shall replace the point by its geographical coordinates.

Related Sections

Points




Error Message(s)

ROUTE130: UNKNOWN DESIGNATOR <Designator ID>


Designator ID: name of the designator which is unknown.

Can be ignored


Reason

The mentioned designator does not exist in the NM CACD or it may be a military designator and the OAT indication had been omitted in the message submission.

Requirements

Designators in the route field of flight plan messages shall be correct, published designators.

This error is subject to an auto-correction attempt by the IFPS:

When the unknown designator is the first or last item of the flight plan route, the IFPS shall attempt the following auto-correction before to present the message for manual processing:

IFPS shall correct the designator when only one possible TP (Terminal Procedure) exists with the same name. Example: ALIVO2 corrected to ALIVO2A.

IFPS shall remove the unknown designator when it is followed (for a SID) or preceded (for a STAR) by a designator with the same name. Example for a STAR: ABIRI ABIRI2

IFPS shall correct the designator when a TP matches the first 4 characters of the unknown designator. Example for s SID: GRON1G GRONY and SID GRONY1G exist. Whenever the message has only error(s) that is/are auto-correctable and the auto-correction is successful then the message shall be automatically processed and a long ACK shall be sent. In all the other cases (for example the message raises ROUTE130 error and another error for which there is no auto-correction performed by IFPS), then the message is presented for manual processing in its original state.

IFPS Procedures

If the unknown designator is a TP, then the IFPS staff shall apply manually the corrective actions that are described under Requirements.

Else:

The IFPS shall apply SCP1 unless the correct intended designator has been identified without any doubt. Example: ABIKI for AKIBI.

Related Sections

Acknowledgement (ACK) Message



Military Points and Routes

SID/STAR

Points

Airways




Error Message(s)

ROUTE131: TRUNCATED ROUTE


NA

Can be ignored


Reason

The route as filed has been truncated and is therefore incomplete.

Requirements

The message should be submitted with the complete route.

IFPS Procedures


Related Sections



Military Points and Routes

SID/STAR

Points

Airways




Error Message(s)

ROUTE132: THE <SID or STAR> IS NOT VALID. <SID or STAR> IS SUGGESTED. OTHER POSSIBLE TPS VIA <List Of Connecting Points> ARE <List of TPs>


SID or STAR: SID or STAR followed by the full designator of the SID or STAR that is not valid and that is suggested.

List of Connecting Points: connecting points of the other TPs suggested by the IFPS.

List of TPs (Terminal Procedures): full designator of the TP suggested by the IFPS.

Can be ignored


Ignoring the error results in IFPS using the SID/STAR that is suggested.

Reason

There are several terminal procedures available at this aerodrome and the flight does not comply with the parameters of the terminal procedure indicated in the message. The first compliant terminal procedure is assumed by the system. Other possibilities are presented to the IFPS staff.

Requirements

A valid TP shall be used.

IFPS Procedures

Whenever the suggested SID STAR ends or starts at the same point as the one originally filed (only the sequence number is different, DKB6E for DKB7F for example) then the IFPS staff shall insert manually the suggested SID/STAR.

In all other case the IFPS staff shall apply SCP1.

Related Sections


SID/STAR




Error Message(s)

ROUTE133: THE STAY PORTION AT POINT <Point Name> IS NOT PERMITTED FOR A FLIGHT GOING OUT OF THE IFPZ


Point Name: name of the point where the STAY portion is specified.

Can be ignored


Reason

A STAY indicator has been used for a flight that intends to operate outside the IFPZ as well as inside.

Requirements

The STAY indicator is only permitted for use with those flights that remain entirely within the IFPZ.

IFPS Procedures

The IFPS staff shall apply SCP1, as all STAY indicators must be removed from the route or the entire route must remain within the boundaries of the IFPZ.

Related Sections






Error Message(s)

ROUTE134: THE STAR LIMIT IS EXCEEDED FOR AERODROME <Aerodrome Name> CONNECTING TO <Point Name>


Aerodrome Name: ICAO Location indicator of the aerodrome of destination.

Point Name: name of the last point on the route.

Can be ignored


Reason

No existing/valid arrival procedure or exists between the aerodrome and the specified last point of the route, and/or the direct distance exceeds the maximum allowed for arrivals at that aerodrome and the last point of the route is not defined as a connecting point for that aerodrome.

Requirements

Where an arrival procedure exists and is valid, a connecting point from a valid TP should be used to link the aerodrome with the route field. Where no arrival procedure exists or are valid nor connecting points exist, the distance from the arrival aerodrome to the last point of the route must be within the limits for that aerodrome.

IFPS Procedures

POGO Flights in the Paris TMA:

Non-standard routeings detailed in the French AIP: Positioning flights within the Paris TMA may use standard routes between the departure and destination aerodromes. Where such are used, the route is given in Item 15 as DCT, with an indication POGO in the Item 18 sub-field RMK.

Note LFOB is located outside the Paris TMA, but flights from LFOB to LFPN/LFPV (and vice-versa) are allowed to use POGO routeings.

Where DCT error(s) (en-route and/or SID/STAR) is/are raised for a flight entirely within the Paris TMA or from LFOB to LFPN/LFPV (and vice-versa), and the POGO indicator is found in Item 18, the IFPS staff shall ignore any DCT limit errors.

Else:

The IFPS shall check that the filed destination aerodrome is correct based on the route and that there is no semantic error in the filed aerodrome; Example: LFBP submitted instead of LFPB.

In case of any doubt and in all other cases, then the IFPS staff shall apply SCP1.

Related Sections


SID/STAR




Error Message(s)

ROUTE135: THE SID LIMIT IS EXCEEDED FOR AERODROME <Aerodrome Name> CONNECTING TO <Point Name>


Aerodrome Name: ICAO Location indicator of the aerodrome of departure.

Point Name: name of the first point on the route.

Can be ignored


Reason

No existing/valid departure procedure or exists between the aerodrome and the specified first point of the route, and/or the direct distance exceeds the maximum allowed for departures at that aerodrome and the first point of the route is not defined as a connecting point for that aerodrome.

Requirements

Where a departure procedure exists and is valid, a connecting point from a valid TP should be used to link the aerodrome with the route field. Where no departure procedure exists or are valid nor connecting points exist, the distance from the departure aerodrome to the first point of the route must be within the limits for that aerodrome.

IFPS Procedures

POGO Flights in the Paris TMA:




Else:

The IFPS shall check that the filed departure aerodrome is correct based on the route and that there is no semantic error in the filed aerodrome; Example: LFBP submitted instead of LFPB.

In case of any doubt and in all other cases, then the IFPS staff shall apply SCP1.

Related Sections


SID/STAR




Error Message(s)

ROUTE138: CANNOT HAVE A ROUTE BETWEEN THE SAME POINT; ROUTE: <Airway Name>, POINT: <Point Name>


Airway Name: name of the airway present in between the two identical points.

Point Name: name of the point repeated twice apart of a route name.

Can be ignored


Reason

An airway has been filed in between the same point.

Requirements

The filed route must ensure that the point - airway - point sequence is correct and progressive.

IFPS Procedures

If the route can be corrected without change of trajectory or doubt, then the IFPS staff shall amend the route to have a correct sequence of airway - point - airway.


Related Sections


Points

Airways




Error Message(s)

ROUTE139: <Airway Name> IS PRECEDED BY <Point Name> WHICH IS NOT ONE OF ITS POINTS


Airway Name: airway designator as stated in the route field. Point Name: point designator as stated in the field.

Can be ignored


Reason

The indicated point is not published as a part of the given airway.

Requirements

Any point filed as part of an airway must be recognised as being associated with that airway.

IFPS Procedures

If this error is raised due to an NM CACD deficiency, the IFPS staff shall raise a report and connect the point with the following point on the route via a DCT or use IFPSTOP/IFPSTART around the problem, while checking any necessary manual addressing that may result.


Related Sections


Points

Airways




Error Message(s)

ROUTE140: <Airway Name> IS FOLLOWED BY <Point Name> WHICH IS NOT ONE OF ITS POINTS



Can be ignored


Reason

The indicated point is not published as a part of the given airway.

Requirements

Any point filed as part of an airway must be recognised as being associated with that airway.

IFPS Procedures



Related Sections


Points

Airways




Error Message(s)

ROUTE141: THE POINT <Point Name> IS NOT ON THE ROUTE <Airway Name>



Can be ignored


Reason

The indicated point is not part of the given route.

Requirements

Any point filed as part of a route must be recognised as being attached to that route.

IFPS Procedures



Related Sections


North Atlantic (NAT) Traffic

Points




Error Message(s)

ROUTE142: POINT AMBIGUOUS <Geographical Coordinates>, POSSIBLE CHOICES ARE <Point Names>


Geographical Coordinates: expressed in LAT/LONG.

Point Names: names of points matching the geographical coordinate.

Can be ignored


Reason

The route contains a point expressed with geographical coordinates which matches with several co-located points and IFPS is unable to identify which point that shall be used for the profile calculation.

Requirements

Points shall be identifiable for IFPS profile calculation.

IFPS Procedures

NA

Related Sections

Points




Error Message(s)

ROUTE143: A POINT DESIGNATOR IS EXPECTED BEFORE <Airway Name>


Airway Name: airway designator as stated in the route field.

Can be ignored


Reason

This error is related to AFIL messages only. The first item mentioned in the route is an airway or DCT or an unknown designator, instead of a known navigation beacon indicator.

Requirements

The route must not start with an unknown navigation beacon, an airway, a DCT or any designator other than a known ICAO designator for a navigation beacon, a navigation beacon with bearing/range, or a set of geographical coordinates.

IFPS Procedures

The IFPS staff shall attempt to contact the message originator to agree a correction. If contact is not possible:

Where DCT is the first point in the route, the IFPS staff shall delete the DCT or

Where the first point in the route is an unknown designator, the IFPS staff shall insert IFPSTART after the first recognised point in the route, then plot the route and check for any necessary manual addressing or

Where the first point in the route is an airway, the IFPS staff shall insert the first point on that airway in the airspace of the originating ATC Unit.

Related Sections





Error Message(s)

ROUTE144: NO ROUTE BETWEEN <Point A> and <Point B>


Point A and Point B: name of the points as stated in the route field.

Can be ignored


Reason

The IFPS cannot identify a route segment between the two points.

Requirements

In between two points an airway or ‘DCT’ shall be indicated.

The error is subject to an auto-correction attempt by the IFPS.

The IFPS shall attempt to insert DCT between the two points before to present the message for manual processing.

Whenever the message has only error(s) that is/are auto-correctable and the auto-correction is successful then the message shall be automatically processed and a long ACK shall be sent. In all the other cases (for example the message raises ROUTE144 error and another error for which there is no auto-correction performed by IFPS), then the message shall be presented for manual processing in its original state.

IFPS Procedures

The IFPS staff shall insert DCT in between the two points. If error(s) is/are still raised then the IFPS staff shall apply SCP1.

Related Sections



Airways




Error Message(s)

ROUTE145: A POINT IS EXPECTED AFTER A STAY INDICATOR


NA

Can be ignored


Reason

A STAY indicator has been filed without the required point after the indicator.

Requirements

The STAY indicator shall be preceded by the point at which the STAY starts, and shall be followed by the point at which the flight resumes the flight planned route.

IFPS Procedures


Related Sections






Error Message(s)

ROUTE146: JUNCTIONS EXIST BETWEEN <Airway 1> and <Airway 2> BUT CANNOT BE USED. Junctions are <List of Points>


Airway 1 and Airway 2: name of the airway as stated in the route field.

List of Points: names of navaids and waypoints which are common to the both airways and which can be used as intersection point.

Can be ignored


Reason

In the route field of the message, there are two consecutives airways without a point specified in between them and the system needs a usable point at the intersection of the two airways.

Requirements

In between two airways, a valid intersection point shall be specified.

IFPS Procedures

The IFPS staff shall use the first proposed point and plot the route on the CHMI map. If the route is illogical or in case of any doubt (where it is thought that a change of trajectory would be induced by manual correction) then the IFPS staff shall apply SCP1.

Related Sections


Points

Airways




Error Message(s)

ROUTE147: THE NAT TRACK <NAT Track ID> IS NOT ACTIVE.


NAT Track ID: identifier of the concerned NAT track. Example: NAT V.

Can be ignored


Reason

The North Atlantic track indicated is not valid in the IFPS at the time the flight is intending to use it.

Requirements

The North Atlantic tracks for that period must be valid in the IFPS. The NAT eastbound tracks are valid from 0100 until 0800. The NAT westbound tracks are valid from 1130 until 1900. All times UTC.

IFPS Procedures

The IFPS staff shall apply SCP1. Where the message has to be forced into the IFPS as a result of SCP1, the IFPS staff shall insert DCT and ignore DCT limit errors, should those arise.

Related Sections


North Atlantic (NAT) Traffic




Error Message(s)

ROUTE148: NO JUNCTION BETWEEN <Airway 1> AND <Airway 2>


Airway 1 and Airway 2: name of the airway as stated in the route field.

Can be ignored


Reason

No known junction exists between the indicated airways.

Requirements

In the route field, in between two airways should be a valid navaid or waypoint which belong to the two airways.

IFPS Procedures

Where a correct junction point can be positively identified to connect the two routes without changing the trajectory, the IFPS staff shall correct.


Related Sections


Points

Airways




Error Message(s)

ROUTE149: MISSING DESIGNATOR


NA

Can be ignored


Reason

There is a missing point in an EET or DLE field.

Requirements

All required and complete fields shall be present in submitted messages.

IFPS Procedures


Related Sections







Error Message(s)

ROUTE150: MISSING CRUISING FLIGHT LEVEL


NA

Can be ignored


Reason

No flight level has been filed in the route or that filed flight level is unrecognisable.

Requirements

The cruising flight level must be indicated in the route.

IFPS Procedures


Related Sections







Error Message(s)

ROUTE151: THE POINT (Point Name) CANNOT BE USED TO LEAVE OR JOIN THE TP (TP ID)


Point Name: name of the point as stated in the route field used to leave a SID or join a STAR. TP ID: full designator of the TP for which it is not allowed to leave or join at the point specified.

Can be ignored


Reason

The filed route is leaving or joining a SID or a STAR at an intermediate point which is not allowed.

Requirements

It shall not be possible to leave or to join a SID at a point which is not defined at a connecting point.

IFPS Procedures


Related Sections


SID/STAR




Error Message(s)

ROUTE152: FLIGHT NOT APPLICABLE TO IFPS


NA

Can be ignored


Reason

The submitted message gives no indication of an IFR or GAT portion of that flight within the IFPZ.

Requirements

Those flights planning to operate within the IFPZ must have at least an identifiable IFR/GAT portion within the IFPZ.

IFPS Procedures

Where the error is raised as a result of Y flight rules with no IFR indicator in the route, the IFPS staff shall apply SCP1 or

Where the error is raised as a result of no GAT indicator in the route, the IFPS staff shall reject the message or

Where, after plotting the route, it is clear that the flight does not enter the IFPZ at any time; the IFPS staff shall reject the message.

Note For those flights indicating mixed flight rules, or mixed OAT/GAT conditions, the IFPS staff should first check for any other information in the message that may assist in identifying IFR or GAT points in the route.

Related Sections


Profile Calculation/Route Analysis







Error Message(s)

ROUTE155: MULTIPLE JUNCTIONS BETWEEN <Airway 1> AND <Airway 2>. (Point Name) IS SUGGESTED.


Airway 1 and Airway 2: name of the airways at stated in the route field in between which there are multiple junctions.

Point Name: name of the point suggested by the system for the unction in between the airways.

Can be ignored


Reason

More than one possible junction point exists between the indicated airways.

Requirements

A specific point must be given at the junction between two airways.

IFPS Procedures

Where a correct junction point can be positively identified to connect the two routes without changing the trajectory, the IFPS staff shall correct.


Related Sections


Points

Airways




Error Message(s)

ROUTE157: FLIGHT RULES I WITH VFR PART.


NA

Can be ignored


Reason

The flight rule is indicated as I (IFR), and there is a VFR indication in the route.

Requirements


IFPS Procedures

The IFPS staff shall change the flight rules to Y or Z (whichever is relevant for that flight).

Related Sections






Error Message(s)

ROUTE161: THIS FIELD VALUE IS INCONSISTENT WITH THE FLIGHT RULES. (RFL)


RFL: Requested Flight Level.

Can be ignored


Reason

The flight rules are I or Y and the route field indicates an initial requested flight level as VFR.

Requirements

The flight rules and any changes thereto in the route field must correspond.

IFPS Procedures


Related Sections







Error Message(s)

ROUTE162: THE POINT <Point Name> FROM DLE DATA IS NOT IN THE FLIGHT ROUTE

ROUTE162: THE POINT <Point Name> FROM ESTIMATE DATA IS NOT IN THE FLIGHT ROUTE


Point Name: name of the point which is specified as a DLE point or as ESTIMATE point.

Can be ignored


Reason

FPL messages: The point specified in the DLE indicator is not in the route or the point is expressed as geographical coordinates is located outside the IFPZ and IFPS considers that the point is not on the route.

Airborne Message Types:

AFIL: the first point in the route is an unknown designator.

FNM, MFS, AFP and AFIL messages: the point for which an estimate is given in the airborne message is not present in the flight route.

Requirements

FPL messages: A point specified in the DLE indicator shall be explicitly or implicitly present in the flight route.


AFIL: The route shall not start with an unknown navigation beacon, a DCT, an airway, or any designator other than a known ICAO designator for a navigation beacon or a set of geographical coordinates.

FNM, MFS, AFP: The point specified in the estimate field shall be present on the route.

IFPS Procedures

FPL messages:

If the DLE point indicated as geographical coordinates is located outside the IFPZ or If the flight contains STS/FFR, STS/SAR,STS/HOSP or STS/MEDEVAC and no contact with

the originator is possible, then that DLE sub-field shall be moved under RMK with ‘/’ removed between DLE and the point.



AFIL: The IFPS staff should contact the message originator to agree a correction. If contact is not possible:

Where DCT is the first point in the route, the IFPS staff shall delete the DCT or

Where the first point in the route is an unknown designator, the IFPS staff shall insert IFPSTART after the first recognised point in the route, then plot the route and check for any necessary manual addressing or

Where the first point in the route is an airway, the IFPS staff shall insert the first point on that airway in the airspace of the originating ATC Unit.

FNM, MFS, AFP: The IFPS staff shall apply SCP1.

Related Sections










Error Message(s)

ROUTE165: THE DCT SEGMENT <Point A>..<Point B>: (XX NM) IS TOO LONG FOR <AUA ID> : <FL>:<FL>. MAXIMUM IS : <XX NUM> [<Restriction ID>]

ROUTE165: THE DCT SEGMENT <Point A>..<Point B>: (XX NM) IS TOO LONG FOR <AUA ID>. MAXIMUM IS : <XX NUM> [<Restriction ID>]


Point A and point B: defines the segment raising the error. XX NM: expresses the distance in nautical miles between A and B, second group specifies

the maximum distance allowed in the airspace. AUA ID: ATC unit airspace reference, i.e the ATC center where the DCT limit is set for.

FL: two values to define the level band when applicable where the restriction applies. Restriction ID: reference of the restriction.

Can be ignored


Reason

The entire DCT segment is within one AUA and exceeds the authorized DCT limit or

The entire DCT segment crosses two airspaces (AUA) horizontally or vertically and exceeds one or both authorized DCT limits or

The DCT is allowed (see RAD Appendix 4 DCTs) within that AUA but restricted to specific traffic.

Note Due to software limitations, some of the DCT conditions mentioned in the RAD document Appendix 4 DCTs are not implemented in the NM CACD.

Requirements

Filed DCTs shall be allowed.

IFPS Procedures

POGO flights:




MARPOL flights:

Flight plans with the callsign MARPOL, followed by one letter or numeric, are exempted from DCT errors.

The IFPS staff shall verify that the message contains the information OPR/DOUANES and RMK/DETECT POLLU and if so shall ignore the error.

In all other cases, the IFPS staff shall follow the flow chart here below:



Related Sections

ITEM 15: Route

Airways




Error Message(s)

ROUTE168: INVALID DCT <Point A .. Point B>. DCT ARE NOT ALLOWED TO CROSS THE BORDER BETWEEN <AUA ID> AND <AUA ID>. [<Restriction ID>]


Point A and point B: defines the segment raising the error.

AUA ID: ATC unit airspace reference, i.e the ATC centers in between which a DCT is not allowed.

Restriction ID: reference of the restriction.

Can be ignored


Reason

DCT segments are not allowed to cross the border of the two adjacent AUA (ATC Unit Airspaces).

Requirements

Each AUA may specify whether or not it will allow DCT routeings across its border, so the specified DCT routeing is not allowed as it crosses the indicated AUA border.

IFPS Procedures


Related Sections


ITEM 15: Route

Airways




Error Message(s)

ROUTE169: CONSECUTIVE STAY INDICATORS NOT ALLOWED


NA

Can be ignored


Reason

Consecutive STAY indicators have been found associated with the same point.

Requirements

Each STAY indicator must have a point before and after that STAY information. It is not possible to have consecutive STAY indicators at the same point.

IFPS Procedures


Related Sections






Error Message(s)

ROUTE170: CANNOT FIND ENTRY/EXIT POINT ON <Route Name>


Route Name: name of the route as stated in the route field on which the system cannot find and ENTRY/EXIT point.

Can be ignored


Reason

The IFPS is unable to automatically determine the IFPZ entry or exit point of the flight.

Requirements

An IFPZ entry or exit point should be included in the route.

IFPS Procedures


Related Sections


Points




Error Message(s)

ROUTE171: CANNOT EXPAND THE ROUTE <Route Name>


Route Name: name of the route as stated in the route field that the system cannot expand.

Can be ignored


Reason

The flight has been calculated to transit an artificial route segment (GAP).

Requirements

Such a route segment cannot be used; an alternative route must be used instead.

IFPS Procedures


Related Sections


Airways




Error Message(s)

ROUTE172: MULTIPLE ROUTES BETWEEN <Point A> AND <Point B}. <Route Name> IS SUGGESTED. OTHER CANDIDATES ARE: <Route List>


Point A and point B: defines the segment in between which no route is specified.

Route Name: name of the route that is suggested between Point A and Point B. Route List: name of the route(s) which are also possible.

Can be ignored


Reason

In the route field two points have been specified without any route in between and more than one available route exists between the indicated points.

Requirements

The route field shall be constructed as Point Route Point etc…unless there is not airway in between two points in which case DCT shall be explicitly inserted.


The IFPS shall insert the route that is suggested before to present the message for manual processing.

Whenever the message has only error(s) that is/are auto-correctable and the auto-correction is successful then the message shall be automatically processed and a long ACK shall be sent. In all the other cases (for example the message raises ROUTE172 error and another error for which there is no auto-correction performed by IFPS), then the message shall be presented for manual processing in its original state.

IFPS Procedures

The IFPS staff shall insert the route that is suggested.

Related Sections


Airways




Error Message(s)

ROUTE174: INVALID TIME GIVEN FOR <Point> (EET PT)

ROUTE174: INVALID TIME GIVEN FOR <FIR> (EET FIR)


Point: Navaid or Waypoint designator.

FIR: Flight Information Region ICAO 4 letter code. EET PT: Estimated Elapsed Time Point. EET FIR: Estimated Elapsed Time to Flight Information Region.

Can be ignored


Reason

The time given at a point or at a boundary in the sub-field EET is greater than 23 hours and 59 minutes.

Requirements

The time given for an EET point or EET FIR shall not be more than 23 hours and 59 minutes.

IFPS Procedures


Related Sections






Error Message(s)

ROUTE175: SPEED AT <Point Name> IS INVALID OR INCOMPATIBLE WITH AIRCRAFT PERFORMANCE


Point: name of the point as stated in the route field where the specified speed is causing the error to be raised.

Can be ignored


Reason

The speed filed at the given point is either incorrect or beyond the known performance of the filed aircraft type.

Requirements

The IFPS holds a performance table for each aircraft type that includes the maximum known speeds at certain flight levels attainable for that type. Where the filed cruising speed is either incorrect or beyond the known performance of the filed aircraft type at that level, an error is generated.

IFPS Procedures


Where the data is confirmed as correct* by the message originator and/or where the message must be forced into the system (as a result of SCP1 or due to a NM CACD deficiency), the IFPS staff shall:

Change the aircraft type to ZZZZ. Insert TYP/<original type> and IFP/ERRTYPE in Item18. Select an appropriate aircraft performance type (single engine, multiple engine, turboprop,

and turbojet).

Note It might be necessary to include a space amongst the characters of the aircraft type designator in order to prevent the IFPS from automatically replacing the ZZZZ value with the recognised aircraft type in that sub-field.

(*): An Ops incident in Remedy CCMS shall be filed in order to consider a possible amendment of the NM CACD.

Related Sections






Error Message(s)

ROUTE176: FLIGHT LEVEL AT <Point Name> IS INVALID OR INCOMPATIBLE WITH AIRCRAFT PERFORMANCE


Point: name of the point as stated in the route field where the specified flight level is causing the error to be raised.

Can be ignored


Reason

The flight level filed at the given point is either incorrect or beyond the known performance of the filed aircraft type.

Requirements

The IFPS holds a performance table for each aircraft type that includes the maximum known flight level attainable for that type. Where the filed flight level is either incorrect or beyond the known performance of the filed aircraft, an error is generated.

IFPS Procedures



Change the aircraft type to ZZZZ. Insert TYP/<original type> and IFP/ERRTYPE in Item 18. Select an appropriate aircraft performance type (single engine, multiple engine, turboprop,

and turbojet).


(*): An Ops Incident in Remedy CCMS shall be filed in order to consider a possible amendment of the NM CACD.

Related Sections






Error Message(s)

ROUTE177: UNKNOWN DESIGNATOR <Designator Name>


Designator Name: name of the designator (route, navaid or waypoint) which is not known in the NM CACD.

Can be ignored


Reason

An element specified in the route field is not known.

Requirements

Routes, navaids and waypoints specified in the route field shall be valid designators.

IFPS Procedures

The IFPS staff shall try to identify the intended element (might be a simple spelling mistake) and if this not possible or in case of any doubt, then the IFPS shall apply SCP1.

Related Sections


ITEM 15: Route

Points

Airways




Error Message(s)

ROUTE178: CRUISING SPEED IS INVALID OR INCOMPATIBLE WITH AIRCRAFT PERFORMANCE


NA

Can be ignored


Reason

The filed cruising speed is either incorrect or beyond the known performance of the filed aircraft type.

Requirements

The IFPS holds a performance table for each aircraft type that includes the maximum known speeds at certain flight levels attainable for that type. Where the filed cruising speed is either incorrect or beyond the known performance of the filed aircraft type at that level, an error is generated.

IFPS Procedures



Change the aircraft type to ZZZZ.

Insert TYP/<original type> and IFP/ERRTYPE in Item 18.

Select an appropriate aircraft performance type (single engine, multiple engine, turboprop, and turbojet).


(*): An OPS incident shall be filed in order to consider a possible amendment of the NM CACD.

Related Sections






Error Message(s)

ROUTE179: CRUISING FLIGHT LEVEL IS INVALID OR INCOMPATIBLE WITH AIRCRAFT PERFORMANCE


NA

Can be ignored


Reason

The filed cruising flight level is either incorrect or beyond the known performance of the filed aircraft type.

Requirements

The IFPS holds a performance table for each aircraft type that includes the maximum known speeds at certain flight levels attainable for that type. Where the filed cruising flight level is either incorrect or beyond the known performance of the filed aircraft type at that level, an error is generated.

IFPS Procedures



Change the aircraft type to ZZZZ.

Insert TYP/<original type> and IFP/ERRTYPE in Item 18. Select an appropriate aircraft performance type (single engine, multiple engine, turboprop,

and turbojet).


(*): An OPS incident shall be filed in order to consider a possible amendment of the NM CACD.

Related Sections






Error Message(s)

ROUTE180: ROUTE ANALYSIS HAS ABORTED


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. Where the error ‘Route Analysis Has Aborted’ is given, no route plot function is available. It might be possible to identify in which part of the route the problem is, by using temporarily the IFPSTOP function, in order to force the IFPS to give a different error. A detailed analysis is required in order to identify the cause for this message (i.e. NM CACD deficiency or system deficiency).

Requirements

NA

IFPS Procedures

NA

Related Sections





Error Message(s)

ROUTE301: NO VALID CONNECTION POINT FOUND ON FLIGHT PLAN ROUTE.


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. It is used as a warning to inform the IFPS staff that the Propose Route Function has not found a valid connection point.

Requirements

NA

IFPS Procedures

NA

Related Sections

NA




Error Message(s)

ROUTE302: CANNOT AUTOMATICALLY GENERATE ROUTE WITH IFPSTOP PORTION


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. It is used as a warning to inform the IFPS staff that the Propose Route Function cannot function when IFPSTOP is present in the route field.

Requirements

NA

IFPS Procedures

NA

Related Sections

NA




Error Message(s)



NA

Can be ignored


Reason

This error is used as a warning for ACH/APL messages to inform the IFPS staff that the Propose Route Function has failed to find a route from the end of the clearance limit given in the airborne message (FNM/MFS/AFP) to the flight plan route or to the aerodrome of destination.

Requirements

Before to be presented for manual processing to an IFPS staff, the Propose Route Function shall attempt to build a route from the end of the clearance limit to the flight plan route or to the aerodrome of destination. Whenever the Propose Route Function was unable to find a valid route, the message (ACH or APL) shall be presented for manual processing.

IFPS Procedures

For ACH messages:

The IFPS staff shall build a logical route from the end of the clearance limit to the flight plan route or to the aerodrome of destination. In the case it is not possible to find an IFPS compliant route then the IFPS staff shall ignore the error(s) and insert the relevant IFP indicators.

For APL messages:

The IFPS staff check the Flight Plan History to see whether or not the flight plan was previously filed and rejected.

If such is found, the IFPS staff shall use this information in the most appropriate way in order to build a route to the destination.

If no previous Flight Plan History data is available then the IFPS staff shall build a logical route from the end of the clearance limit to the aerodrome of destination.

In the case it is not possible to find an IFPS compliant route then the IFPs staff shall ignore the error(s) and insert the relevant IFP indicators.

Related Sections



AFP for a Change of Route



ATC Flight Plan (APL)




Error Message(s)

ROUTE304: CANNOT AUTOMATICALLY GENERATE ROUTE WITH VFR OR OAT PORTION


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. It is used as a warning to inform the IFPS staff that the Propose Route Function cannot function when an OAT or VFR portion is present in the route field.

Requirements

NA

IFPS Procedures

NA

Related Sections

IFP Indicators




Error Message(s)

ROUTE305: FLIGHT TYPE IS MILITARY. PLEASE CHECK NAS OF GENERATED PORTION: <List>


<List of NAS>: first two letters of the country code, for example EI for Ireland.

Can be ignored


Reason

This error is used as a warning for ACH/APL messages. The applicable mode for airborne message processing is set to manual. In the manual mode, the IFPS shall try to build a route using the Propose Route Function from the end of the clearance limit given in the airborne message (FNM/MFS/AFP) to the flight plan route or to the aerodrome of destination. When the Propose Route Function finds a valid route and the flight type is military, then the error is raised and contains the list of NAS corresponding to the “system generated portion”.

Requirements

Whenever the Propose Route Function is able to build a route from the end of the clearance limit to the flight plan route or to the aerodrome of destination and the generated route portion penetrates new NAS when compared to the flight plan route and where the message relates to a military flight (flight type ‘M’), then the IFPS shall invalidate that message in order for an IFPS staff to be able to verify the system generated portion vs the diplomatic clearances or other constraints linked to the flight type being “Military”.

IFPS Procedures

The IFPS staff shall note the NAS listed in the error and then press on “Test”. As a result the error will disappear. For an APL message, the error will list all the NAS along the route.

The IFPS staff shall attempt to coordinate with the flight plan originator to agree on the best way to proceed with processing the airborne message and

For ACH messages:

If the flight plan originator cannot be reached, then the IFPS staff shall ensure that the ACH route does not penetrate NAS which were previously untouched and shall (if necessary) ignore the corresponding errors and insert the relevant IFP indicator(s).

For APL messages:

If the flight plan originator cannot be reached, then the IFPS staff shall check the Flight Plan History to see whether or not the flight plan was previously filed and rejected.

If such is found, the IFPS staff shall use this information in the most appropriate way in order to build a route to the destination ensuring that the APL route does not penetrate NAS which were previously untouched and shall (if necessary) ignore the corresponding errors and insert the relevant IFP indicator(s).

If no previous Flight Plan History data is available then the IFPS staff shall process the APL as such unless the generated portion is not logical is which case the IFPS staff built a logical route.

Related Sections

IFP Indicators





AFP for Diversion







Error Message(s)

ROUTE308: THE <SID or STAR><TP ID> IS NOT VALID BECAUSE THERE IS NO CONNECTING POINT WITH ROUTE.



TPD ID: Terminal Procedure full designator. Example: DKB6F.

Can be ignored


Reason

There is no connection between the SID or STAR and the route.

Requirements

SID and STAR specified in the route field shall be connected to the route.

IFPS Procedures


Related Sections


SID/STAR




Error Message(s)

ROUTE310: IFPSRA NO ROUTE FOUND


NA

Can be ignored


Reason

This is an internal IFPS error and is used as a warning for the IFPS staff. The FPL has been filed with RMK/IFPSRA and the route field contained speed/level and DCT or speed/level only. Before to be presented to an IFPS staff for manual processing the Propose Route Function has been run and the result is displayed in the error message. This error message is used as a warning message for the IFPS staff.

Requirements

NA

IFPS Procedures

The IFPS staff attempt to find a valid route using the tools available. Where no route can be found by the IFPS staff then the flight plan shall be rejected.

Related Sections

IFPS Re-Route Accepted (IFPSRA)




Error Message(s)

ROUTE311: IFPSRA NO ACK


NA

Can be ignored


Reason

This is an internal IFPS error and is used as a warning for the IFPS staff. The FPL has been filed with RMK/IFPSRA and the route field contained speed/level and DCT or speed/level only. Before to be presented to an IFPS staff for manual processing the Propose Route Function has been run and a valid route has been found but IFPS identified that the message originator will not receive and ACK message and therefore will not be made aware of the route found by IFPS.

Requirements

Those message originators who wish to use the IFPSRA automatic functionality shall ensure that the setting for their entity in the NM CACD is set to ACK receive ‘YES’ and long ACK.

IFPS Procedures

NA

Related Sections

IFPS Re-Route Accepted (IFPSRA)




Error Message(s)

ROUTE312: ROUTE AUTOMATICALLY BUILT. PLEASE CHECK.


NA

Can be ignored


Reason

This is an internal IFPS error and is used as a warning for the IFPS staff. The FPL has been filed with RMK/IFPSRA and the route field contained speed/level and DCT or speed/level only. Before to be presented to an IFPS staff for manual processing the Propose Route Function has been run and a valid route has been found which needs to be validated by an IFPS staff.

Requirements

NA

IFPS Procedures

NA

Related Sections


IFP Indicators




Error Message(s)

ROUTE314: INVALID RFL IN VFR PORTION


NA

Can be ignored


Reason

The RFL for a VFR portion is above F195.

Requirements

It is not allowed to fly VFR above FL195.

IFPS Procedures

The IFPS staff shall apply SCP1 except if the message is an AFP and the VFR indication is before the AFPEND, in which case the IFPS staff shall ignore the error and insert the IFP/ERROUTE indicator.

Related Sections






Error Message(s)

ROUTE315: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE AIRCRAFT OPERATOR CODE. [<Restriction ID>]




Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of an aircraft operator code condition in the restriction and no valid terminal procedures exist to replace it.

Requirements


IFPS Procedures



Related Sections

Determination of Aircraft Operator by IFPS



SID/STAR

Aircraft Operator (OPR)




Error Message(s)

ROUTE316: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE AIRCRAFT REGISTRATION. [<Restriction ID>]




Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of an aircraft registration condition in the restriction (i.e. the aircraft registration is missing in the flight plan) and no valid terminal procedures exist to replace it.

Requirements

RVSM equipped aircraft shall indicate in the flight plan there registration in item 18 under REG/ (or the equivalent field in ADEXP or B2B).

IFPS Procedures




Related Sections



SID/STAR





Error Message(s)

ROUTE317: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE 24 BIT AIRCRAFT ADDRESS. [<Restriction ID>]




Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of a 24 BIT aircraft address condition in the restriction (i.e. the aircraft code is missing in the flight plan) and no valid terminal procedures exist to replace it.

Requirements

The usage of this TP is linked to the presence of the 24 BIT aircraft address in item 18 of the flight plan under CODE/ (or its equivalent in ADEXP format).

IFPS Procedures




Related Sections


SID/STAR

CODE




Error Message(s)

ROUTE318: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE FLIGHT PLAN SOURCE. [<Restriction ID>]




Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of a flight plan source condition in the restriction (i.e. the aircraft is RSVM equipped and the aircraft registration is missing in the flight plan.

Requirements

RVSM equipped aircraft shall indicate in the flight plan there registration in item 18 under REG/ (or the equivalent field in ADEXP or B2B).

IFPS Procedures




Related Sections



Source (SRC) Indicator

SID/STAR




Error Message(s)

ROUTE319: THE <SID or STAR> <TP ID> IS NOT VALID BECAUSE OF THE FLIGHT PLAN STATUS. [<Restriction ID>]




Can be ignored


Reason

The given terminal procedure does not comply with the restriction because of a flight plan status condition in the restriction and no valid terminal procedures exist to replace it.

Requirements


IFPS Procedures



Related Sections



SID/STAR



146.180 Error Class/Error Id: PROF50

Error Message(s)

PROF50: CLIMBING/DESCENDING OUTSIDE THE VERTICAL LIMITS OF SEGMENT <Point A><Route Name><Point B>


Point A and B: specifies the route segment in which the climb or descent is calculated outside the vertical limit of the airway.

Route Name: name of the route as stated in the route field for which the profile does enter its vertical limits.

Can be ignored


Reason

The profile of a flight has been calculated by the system to climb or descend on a route segment, mentioned in field 15, outside the defined vertical limits of the airway.

Requirements

The route field shall reflect the intended route horizontally and vertically.


The IFPS shall attempt to insert/remove the prefix U for the concerned route or DCT where the layout is just one segment before to present the message for manual processing.

Whenever the message has only error(s) that is/are auto-correctable and the auto-correction is successful then the message shall be automatically processed and a long ACK shall be sent. In all the other cases (for example the message raises PROF50 error and another error for which there is no auto-correction performed by IFPS), then the message shall be presented for manual processing in its original state.

IFPS Procedures

The IFPS staff shall:

Replace the route by the lower/upper corresponding route whenever it is available and co-located (no change of trajectory) and if the error remains,

Replace the route with DCT (providing that there is no change of trajectory) and if an error remains then the IFPS staff shall apply SCP1.

Exceptions:

Where a profile tuning restriction forces the route profile outside the vertical limits of the airway and the lower/upper corresponding route does not exist or is not available, the IFPS staff shall ignore the error and raise an OPS incident in CCMS.

Where a change of flight level appropriate for the availability over the route portion is made, but the error is raised because the profile does not reach the requested level within that route portion, the IFPS staff shall ignore the error.

Related Sections


IFP Indicators






Error Message(s)

PROF53: THE DCT SEGMENT <Point A> .. <Point B> IS NOT ALLOWED: <Distance> ALONG AIRSPACE BORDER BETWEEN <Airspace Designator> and <Airspace Designator>


Point A and B: specifies the route segment which is not allowed.

Distance: expresses the distance in nautical miles in between point A and B. Airspace Designator: names of the airspaces on each side of the border.

Can be ignored


Reason

A trajectory between two points filed as DCT is within 0.5 NM of an AUA border for at least 15 NM.

Exceptions: the error is not reported by IFPS when the 2 AUAs belong to the same State or both of them are of type OCA (Oceanic) or one is of type OCA the other one is of type non IFPZ.

Requirements

It shall not be possible to file a DCT segment aligned with the operational airspace border of an ACC if it is too close for a considerable distance. ’Too close’ parameter: within 0.5 NM from the AUA border. ‘Considerable distance’ parameter: 15 NM or more.

IFPS Procedures


Related Sections





Error Message(s)

PROF173: RS:<Ref Loc ID> IS CLOSED FOR DCT REF:[<Restriction Id>] <Description>


Ref Loc ID: code of the airspace where the restriction is located. Restriction ID: reference of the restriction. Description: more information.

Can be ignored


Reason

The flight trajectory penetrates an airspace using a DCT segment and the airspace penetration is not permitted for “DCT”

Requirements

It is not allowed to penetrate an airspace restricted for DCT using a “DCT”.

IFPS Procedures


Related Sections





Error Message(s)

PROF188: FLIGHT PLAN DOES NOT COMPLY WITH 8.33 CARRIAGE REQUIREMENTS


NA

Can be ignored


Ignoring the error results in IFP/NON833 to be automatically inserted in the message output.

Reason

The flight does not comply with those mandatory conditions associated with 8.33 kHz airspace.

Requirements

The flight must be compliant with all 8.33 kHz conditions in Items 10, 15 & 18 when the flight is planned to enter 8.33 kHz airspace.

IFPS Procedures


Related Sections


8.33 kHz Channel Spacing




Error Message(s)

PROF189: NON 8.33 BUT UHF EQUIPPED AIRCRAFT IN 8.33 AIRSPACE NOT HANDLING UHF


NA

Can be ignored


Reason

The indicated equipment contains U (UHF), but the flight is calculated to enter a sector(s) that require(s) Y (8.33 kHz) equipment.

Requirements

Some sectors require that all flights shall carry the full 8.33 kHz equipment (Y in item 10a); UHF (U in Item 10a together with COM/EXM833 in Item 18 for state flights) alone as indicated in the submitted message is not sufficient.

IFPS Procedures


Related Sections






Error Message(s)

PROF190: NON 8.33 AND NON UHF EQUIPPED AIRCRAFT IN 8.33 AIRSPACE


NA

Can be ignored


Ignoring the error results in IFP/NON833 to be automatically inserted in the message output.

Reason

An unequipped flight penetrates an IFPZ 8.33 kHz airspace in which both 8.33 kHz equipped and UHF-only equipped state flights are allowed.

Requirements

Some sector(s) require(s) that all flights shall carry either the full 8.33 kHz equipment (Y in Item 10); or UHF (U in item 10a together with COM/EXM833 for state flights) in the submitted message.

IFPS Procedures


Related Sections






Error Message(s)

PROF191: TTL_EET DIFFERENCE > (value) %, CALCULATED TTL_EET FROM <ADEP> TO <ADES>= <Time> (HHMM).


Value: 40, 120 or 200% (40% for long flights >299 minutes, 120% for medium flights >59 minutes and <299 minutes, 200% for short flights <59 minutes).

ADEP-ADES: ICAO location indicator of the aerodrome of departure and arrival.

Time: as calculated by IFPS in format HHMM (hours, minutes).

Can be ignored


There are two cases in which the filed total EET differs from the calculated total EET:

The filed total EET is greater than the calculated total EET: using the ignore function results in the filed total EET being used to calculate the flight profile.

The filed total EET is less than the calculated total EET: using the ignore function results in the calculated total EET being used to calculate the flight profile.

In both cases, the use of the ignore function results in the filed total EET being used in the IFPS output.

Reason

The total EET given is greater or lesser than the time calculated by the IFPS for this trajectory.

Requirements

The IFPS shall calculate a total estimated flying time for all flight plans, based on the speed(s) and flight level(s), and will raise a warning where the total EET of the submitted message is outside the accepted percentage error based on this figure.

IFPS Procedures

The IFPS staff shall plot the route and

If the error is raised for a mixed flight VFR/IFR flight and the error is raised because of the VFR portion, the IFPS staff shall ignore the error or

If the error is raised for a STAY incorrectly formatted, then the IFPS staff shall correct the format and continue with the normal message processing or

If the error is raised for a STAY portion indicated at a point expressed with bearing/distance (in which case IFPS disregards the STAY time), then the IFPS staff shall change that point into geographical coordinates and continue with the normal message processing or

If the route plot reveals a homonym problem, the IFPS staff shall insert IFPSTOP/IFPSTART around the homonym then plot the route to check the flight trajectory. If the error is cleared, the IFPS staff shall check the addressing and continue with the normal message processing or

If the error is raised when the flight type is not indicated as ‘X’ and or more of the following conditions are encountered:

o Training flights o Round robin flights o OAT/GAT flights o IFPSTOP/START o Replacement of an invalid TP for a valid TP in the profile calculation for short flights

(where the TP designator is not output).



The IFPS staff shall check the aircraft speeds and where they are in accordance with the performance table, then the IFPS staff shall ignore the error or

In all other cases (example: inaccurate aircraft speed), the IFPS staff shall apply SCP1.

Related Sections









Error Message(s)

PROF192: TOTAL STAY/DLE TIME GREATER THAN TOTAL ESTIMATED ELAPSED TIME.


NA

Can be ignored


Reason

The submitted message contains en-route STAY indicator(s) and/or DLE and the total time of the STAY portion(s) and/or DLE is greater than the total estimated elapsed time indicated in Item 16b (ICAO) or TTLEET field (ADEXP).

Requirements

The IFPS shall check the given EET for a submitted flight plan, and where STAY indicator(s) and/or DLE is/are used, the associated time is also checked. Where the STAY/DLE time is incompatible with the calculated total EET (including its accepted percentage error), an error is generated.

IFPS Procedures


Related Sections








Error Message(s)

PROF193: IFR OPERATIONS AT AERODROME <Aerodrome ID> ARE NOT PERMITTED [<Restriction ID>]


Aerodrome ID: ICAO location indicator of the aerodrome.

Restriction ID: reference of the restriction.

Can be ignored


Reason

The specified aerodrome is not accessible under IFR flight rules.

Requirements

The flight shall operate to/from the aerodrome under VFR flight rules. The flight rules in the flight plan shall be Y or Z.

IFPS Procedures


Related Sections



Route Availability Document (RAD)




Error Message(s)

PROF194: <Point> <Route> <Point> IS NOT AVAILABLE IN FL RANGE <FL Range>


Point: name of the points in between which the route is not available in the specified level range.

Route: name of the route not available in the specified level range. FL Range: Fxxx..Fxxx lower and higher in which the unavailability is taking place.

Can be ignored


Reason

The given route is classified as unavailable at the requested flight level between the indicated points.

Requirements

The profile calculation for each flight plan will check the calculated arrival time and flight level of the flight for each part of a route, and cross-check this time against the published availability conditions for that part of that route at that time.

IFPS Procedures

If an alternative route is available and does not require a change of trajectory, then the IFPS staff shall insert the alternative route or

If any change of trajectory is required, then the IFPS staff shall apply SCP1.

Related Sections



Airways




Error Message(s)

(1) PROF195: <Point> <Route> <Point> DOES NOT EXIST IN FL RANGE <FL Range>

(2) PROF195: <Point> <Route> <Point> DOES NOT EXIST IN FL RANGE


Point: name of the points in between which the route does not exist in the specified level range.

Route: name of the route which does not exist available in the specified level range.

FL Range: Fxxx..Fxxx lower and higher in which the route does not exist.

Can be ignored


Reason

(1): The profile of a flight has been calculated by the system to transit a route segment, above or below the defined vertical limit of the airway.

(2): The profile of a flight has been calculated by the system to transit a route segment in the defined vertical limits of the airway during a time the airway is undefined (i.e. does not exist).

Requirements



The IFPS shall attempt to replace the route portion with a valid alternative co-located or DCT where the route layout is just one segment before to present the message for manual processing.

Whenever the message has only error(s) that is/are auto-correctable and the auto-correction is successful then the message shall be automatically processed and a long ACK shall be sent. In all the other cases (for example the message raises PROF195 error and another error for which there is no auto-correction performed by IFPS), then the message shall be presented for manual processing in its original state.

IFPS Procedures

(1) The IFPS staff shall replace the route by the corresponding lower/upper route whenever it is available and co-located. Should there be no such corresponding route then the IFPS staff replace the route with DCT (see note below) providing that there is no change of trajectory. Where neither of these options is possible, the IFPS staff shall apply SCP1.

(2) The IFPS staff shall replace the route with DCT (see note below) providing that there is no change of trajectory. Should this be not possible then the IFPS staff shall apply SCP1.

Exceptions for both (1) and (2):

Where the error refers to those flights planning to operate above airways that are defined only up to FL460. In such cases the IFPS staff shall check the vertical view and ignore the error where the route is only defined up to FL460 and is available at that level.

Where the error is raised because the profile is pushed into airspace where no route is defined, by a Profile Tuning Restriction, in which case the IFPS staff shall ignore the error and report the PTR for further investigation.



Note The IFPS staff shall not replace a route with DCT if the error is raised because the flight profile is going below the minimum level of a route (such a minimum level might be due to terrain).

Related Sections



Airways




Error Message(s)

PROF197: RS: <Ref Loc ID>:FXXX..FXXX IS CLOSED FOR CRUISING REF:[<Restriction ID>] <Description>


Ref Loc ID: code of the airspace where the restriction is located.

Restriction ID: reference of the restriction. Description: more information.

Can be ignored


Reason

The RFL stated in the message is forbidden for cruising in the airspace listed in the error message.

Requirements

The filed route must comply with all relevant RAD restrictions.

IFPS Procedures

The IFPS staff shall verify the correctness of the raised error and

If the error has been raised incorrectly (due to an CACD deficiency), then shall file an OPS Incident via Remedy CCMS) or

If the error has been raised correctly, but an exemption is granted by the relevant FMP, the IFPS staff shall ignore the error and make an entry in the log book or


Related Sections







Error Message(s)

PROF198: <Point> <Route> <Point> IS A CLOSED CDR_3 IN FL RANGE <FL Range>


Point: name of the points in between which the route is a closed CDR3 in the specified level range.

Route: name of the route which is CDR3 in the specified level range. FL Range: Fxxx..Fxxx lower and higher in which the route is CDR3.

Can be ignored


Reason

The given route segment is classified as unavailable CDR3 at the calculated time of use by this flight.

Requirements


IFPS Procedures


Related Sections



Flexible Use of Airspace (FUA)/Conditional Routes (CDR)

Airways




Error Message(s)





Can be ignored


Reason


Requirements


IFPS Procedures

If an alternative route is available and does not require a change of trajectory (a change of RFL is to be considered as a change in trajectory), the IFPS staff shall correct or

If an alternative available route requires a change of trajectory, then the IFPS staff shall apply SCP1.

Related Sections




Airways




Error Message(s)





Can be ignored


Reason


Requirements


IFPS Procedures

If an alternative route is available and does not require a change of trajectory (a change of RFL is to be considered as a change in trajectory), the IFPS staff shall correct or

If an alternative available route requires a change of trajectory, then the IFPS staff shall apply SCP1.

Related Sections




Airways




Error Message(s)

1) PROF201: CANNOT CLIMB OR DESCEND ON <Point> <Route> <Point> IN FL RANGE <FL Range> BECAUSE OF UNAVAILABLE LEVELS ON <Route List>

2) PROF201: CANNOT CLIMB OR DESCEND ON <Point> <Route> <Point> BECAUSE OF UNAVAILABLE LEVELS ON <FL Range> ON <Route List>


Point: name of the points in between which the route has unavailable levels or is closed. Route: name of the route with unavailable levels or closed. FL Range: Fxxx..Fxxx lower and higher levels or blank (in some cases when route is

undefined). Route List: one or more routes co-located which have unavailable levels.

Can be ignored


Reason

1. The flight has been calculated to climb or descend on a route segment, but there are no levels available on this segment between the previous and current flight level

2. The profile of a flight has been calculated by the system to transit a route segment in climb or descent during a time period in which that segment is undefined (i.e. when it does not exist).

Requirements

When building a flight profile, the IFPS must find at least one available level between the previous and current flight level on the route segment in which the climb or descent takes place.

IFPS Procedures

1. The IFPS staff shall apply SCP1.

2. The IFPS staff shall replace the route segment with DCT (see note below) providing that there is no change of trajectory; Should this be not possible, then the IFPS staff shall apply SCP1.

Note In the en-route phase, the IFPS staff shall not replace a route with DCT if the error is raised because the flight profile is going below the minimum level of a route (such a minimum level might be due to terrain

Related Sections





Airways




Error Message(s)

PROF202: <Point> <Route> <Point> IS NOT AVAILABLE IN FL RANGE <FL Range>


Point: name of the points in between which the route is not unavailable at the specified level range.

Route: name of the route not available in the specified level range. FL Range: Fxxx..Fxxx lower and higher levels.

Can be ignored


Reason

The flight has been calculated to fly on a closed CDR-0.

Requirements


IFPS Procedures


Related Sections






Error Message(s)

PROF203: PROFILE ANALYSIS STOPPED


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. This is due to a software deficiency. Where the error ‘PROFILE ANALYSIS STOPPED’ is given, no route plot function is available. It might be possible to identify in which part of the route the problem is, by using temporarily the IFPSTOP function, in order to force the IFPS to give a different error. A detailed analysis is required in order to identify the cause for this message (i.e. NM CACD deficiency or system deficiency).

Requirements

NA

IFPS Procedures

NA

Related Sections





Error Message(s)

PROF204: RS: TRAFFIC VIA <Ref Loc ID> IS ON FORBIDDEN ROUTE REF:[<Restriction Id>] <Textual Description> or

PROF204: RS: TRAFFIC VIA <Ref Loc Id>:<FL Range>[<DDHHMM..DDHHMM>] IS ON FORBIDDEN ROUTE REF:[<Restriction ID>] <Textual Description>


Ref Loc ID: code of the airspace where the restriction is located. Restriction ID: reference of the restriction. FL Range indicates the level in which the restriction is active.

Textual Description: more information.

DDHHMM: Days Hours and Minutes defining the time window in which the restriction applies.

Can be ignored


Reason

The route detailed in the submitted message follows the listed forbidden RAD route.

Requirements


IFPS Procedures


If the error is covered by the procedure RAD errors for profile (45.4) then it shall be treated as per procedure or

If the error has been raised incorrectly (due to an CACD deficiency), then shall file an OPS Incident via Remedy CCMS) and ignore the error or

If the error has been raised correctly, but an exemption (see Note) is granted by the relevant FMP/ATC, the IFPS staff shall ignore the error and make an entry in the log book or

If the error is for EUIFPS001A (aircraft registration is invalid) or EUIFPS002A (aircraft registration is required), which applies only to flights that contain either STS/SAR, FFR, HOSP, MEDEVAC (Error Management Auto-reject for other flights) then the IFPS staff shall:

o If the error is for EUIFPS002A and if present in Item 7, copy/paste the aircraft registration under REG/ in item 18. If not present in item 7, ignore the error or

o If error the error is for EUIFPS001A, contact the originator. If the aircraft registration can be obtained, insert it under REG/ in item 18. If the aircraft registration cannot be obtained, ignore the error.

Or


Note If the exemption is the result of a coordination initiated by the IFPS staff, then the IFPS shall insert the IFP indicator ERRTECOORD.

Related Sections



RAD for Military Flights





Error Message(s)

PROF205: RS: TRAFFIC VIA <Ref Loc ID> IS OFF MANDATORY ROUTE REF:[<Restriction Id>] <Textual Description>


Ref Loc ID: code of the airspace where the restriction is located.

Restriction ID: reference of the restriction. Textual Description: more information.

Can be ignored


Reason

The route detailed in the submitted message does not comply with the specified mandatory route.

Requirements


IFPS Procedures


If the error is covered by the procedure RAD errors for profile (45.4) then it shall be treated has per procedure or


If the error has been raised correctly, but an exemption (see Note 1) is granted by the relevant FMP/ATC, the IFPS staff shall ignore the error and make an entry in the log book or


Note 1 If the exemption is the result of a coordination initiated by the IFPS staff, then the IFPS shall insert the IFP indicator ERRTECOORD.

Note 2 Check 83.5 if mandatory routeing is a DCT segment co-located with a closed airway.

Related Sections



RAD for Military Flights


Airways




Error Message(s)

PROF206: THE DCT SEGMENT <Point A> .. <Point B> IS NOT AVAILABLE IN FL RANGE <FL Range> (UNAVAILABLE ROUTE <Route ID>)


Point A and Point B defines the segment raising the error.

FL Range: Fxxx..Fxxx lower and higher in which the unavailability is taking place. Route ID: name of the unavailable route co-located with the DCT segment.

Can be ignored


Reason

In the route field of the message, a DCT between two points is co-located with an airway which is not available at the requested flight level.

Requirements

Between two points, an available airway or an available direct route (DCT) shall be filed.

IFPS Procedures



If the error has been raised correctly, but an exemption is granted by the relevant FMP, the IFPS staff shall ignore the error and make an entry in the log book or


Related Sections






146.201 Error Class/Error Id: GEN207

Error Message(s)

GEN207: UNABLE TO GENERATE A COMPLETE REPLY


NA

Can be ignored


Reason

NA

Requirements

NA

IFPS Procedures

NA

Related Sections

NA




Error Message(s)

GEN277: MESSAGE REQUIRES SPECIAL HANDLING


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. It is used as a warning for RQS and AMOD messages and these message types require special handling.

Requirements

Where the IFPS receives a message titled RQS or AMOD, that message shall be invalidated and shall be presented to an IFPS staff with a warning: GEN277: MESSAGE REQUIRES SPECIAL HANDLING.

IFPS Procedures

NA

Related Sections

ATC Pre-departure FPL modification (AMOD)


Request Supplementary Flight Plan (RQS)




Error Message(s)

GEN280: RULE <Rule Name> IFPS MONITORING: MATCHING STRINGS <String Description>


NA

Can be ignored


Reason

This is an internal IFPS error and therefore is not visible to external IFPS users. It is used as a warning for the IFPS staff to inform that the incoming FPL or APL (after conversion from FNM, MFS or AFP) is matching an active rule in the IFPS message monitoring feature.

Requirements

NA

IFPS Procedures

NA

Related Sections

NA



146.204 Error Class/Error Id: RA274

Error Message(s)

RA274: NBROUTE ARGUMENT INVALID


NA

Can be ignored


Reason

This error messages is related to the use of Propose Routes. On the NOP, IFPUV Free Text Editor the box ‘Max number of proposals’ has a value specified which equals ‘0’ (zero).

Requirements

The box ‘Max number of proposals’ shall contain a value between 1 and 10.

IFPS Procedures

NA

Related Sections

NA



146.205 Error Class/Error Id: RA281

Error Message(s)

RA281: NUMBER OF CONSTRAINTS FOR ROUTE GENERATION EXCEEDS </NUMBER>


Number: indicates the maximum number of constraints that the system can handle.

Can be ignored


Reason

The user has specified too many constraints for the Route Generation.

Requirements

Route Generation can only work up to a maximum number of constraints.

IFPS Procedures

NA

Related Sections

NA



146.206 Error Class/Error Id: WARN256

Error Message(s)

WARN256: ACH BUILT FROM AN <Message Title>


Message Title: can be IFNM, IMFS or IAFP.

Can be ignored


Reason

The route in the submitted message differs from the route in the existing flight plan.

Requirements

NA

IFPS Procedures

The IFPS staff shall press ‘Test’ and continue with normal message processing.

Related Sections




ATC Flight Plan Change (ACH)




Error Message(s)

WARN257: INVALID AIRCRAFT ADDRESS (CODE) HAS NOT BEEN STORED


CODE: 24-bit aircraft address (CPDLC).

Can be ignored


Reason

The sub-field CODE is present in a message submitted to the IFPS for processing and does not contain 6 alphanumeric in the correct format, and the IFPS does not hold a CODE value from a previously-processed associated message.

Requirements

Flights planning to use CPDLC over the aeronautical telecommunication network (ATN) shall include in Item 18 of the flight plan the indicator CODE/ followed by the 24-bit aircraft address.

IFPS Procedures

When this warning message is presented in an invalid message, no action shall be taken by the IFPS staff to validate the message against that warning message.

Should the warning message be presented at the same time as any other error messages, only those other errors shall be corrected.

Related Sections

CODE




Error Message(s)

WARN257: INVALID AIRCRAFT ADDRESS (CODE) HAS NOT BEEN STORED. PREVIOUS AIRCRAFT ADDRESS HAS BEEN REMOVED


CODE: 24-bit aircraft address (CPDLC).

Can be ignored


Reason

Whenever the sub-field CODE is present in a message submitted to the IFPS for processing that does not contain 6 alphanumeric in the correct format, and the IFPS does hold a CODE value from a previously processed associated message, then the sub-field CODE and its contents shall be automatically removed from that message and from the previously processed associated message.

Requirements

Flights planning to use CPDLC over the aeronautical telecommunication network (ATN) shall include in Item 18 of the flight plan the indicator CODE/ followed by the 24-bit aircraft address.

IFPS Procedures

When this warning message is presented in an invalid message, no action shall be taken by the IFPS staff to validate the message against that warning message.

Should the warning message be presented at the same time as any other error messages, only those other errors shall be corrected.

Related Sections

CODE




Error Message(s)

WARN259: APL BUILT FROM AN <Message Title>


Message Title: can IFNM, IMFS or IAFP.

Can be ignored


Reason

The ATC Flight Plan (APL) was triggered by the reception of an FNM, MFS or AFP, which means that there was no matching valid flight plan in the IFPS database.

Requirements

NA

IFPS Procedures

The IFPS staff shall press ‘Test’ and continue with normal message processing.

Related Sections








Error Message(s)

WARN262: WHAT-IF-REROUTE MESSAGE


NA

Can be ignored


Reason

The message is the result of an action in NOP or CHMI where an aircraft operator chose an alternative routeing and let NOP or CHMI create and send a modification message (CHG) or a cancel (CNL) to IFPS. The AWR/Rn qualifier present in the message prioritizes the invalid message to the top of the invalid queue.

Requirements

NA

IFPS Procedures

The message created as a result of the AOWIR functionality shall be treated in IFPS the same way as any other message.

Therefore on receipt of such a message, the IFPS stall shall apply SCP1.

Note Messages as a result of AOWIR have been checked against IFPS; therefore they should, only in rare cases, come for manual processing.

When the message is an FPL, this means that the originator has used the “Apply” feature in which ETFMS send a CNL message to IFPS.

Subsequently ETFMS send an RRN message containing the new route description. In some cases the re-filing is linked to a slot booking.

The originator is expected to refile a FPL in a specific time window, with the route received in the RRN message and it should be an exact character match between the RRN route and the route field of the FPL (Item 15).

A reason for which the FPL is coming for manual processing in IFPS might be due to the fact that the originator has modified part of the route (thus raising an error in IFPS) resulting in the refiling not matching exactly the RRN routeing and subsequently not matching the slot which had been booked for that flight.

Related Sections


Aircraft Operator What-if Re-Route (AOWIR)




Error Message(s)

WARN313: TRAJECTORY INFO DISCARDED <Info discarded>


Info discarded: (INCONSISTENT DISTANCE, ALL INFORMATION DISCARDED) when a distance supplied within the trajectory is too far outside of tolerance when compared to the NM calculated distance. All trajectory information was discarded. Only the route information was used for the processing of the flight plan.

Info discarded: (NO CORRESPONDING REQUESTED CRUISING LEVEL FOR LEVEL AT <Item><Role>) when the point (<Item>) is the beginning/end of a level flight segment in the trajectory that has no corresponding requested cruising level in the route (route-trajectory flight level consistency check). Role can be: TOD,TOC,BOD,BOC.

Info discarded: (DISTANCE DOES NOT INCREASE WITH TIME) when the distance does not increase between two consecutive trajectory points while time does increase.

Info discarded: (TRAJECTORY PROCESSING PROVIDED ONLY FOR FLIGHTS THAT ARE ENTIRELY IFR/GAT) when the flight is not purely IFR/GAT (i.e. has VFR or OAT in any section of the route).

Info discarded: (NOT ON ROUTE ; location + BOC,BOD,TOC,TOD) and (NOT IN ROUTE SEQUENCE: POINT Id PT) when the profile tuning element is not found on the route or there is an ordering issue.

Info discarded: (EXACT DUPLICATE ; distance + BOC,BOD,TOC,TOD) when the item is duplicated.

Info discarded: (Point Id NOT IMPLEMENTED ; Point location (Lat/Long, bearing/distance) + Point Id) when there are significant points not supported by the software (Lat/Long, bearing/distance).

Info discarded: (NO AERODROME ; ALL INFO DISCARDED) or (FIRST NOT ADEP ; ALL INFO DISCARDED) or (LAST NOT ADES ; ALL INFO DISCARDED) when there is missing information such as the aerodrome.

Info discarded: (INVALID DATA <ITEM>) when some data is missing such as distance or time or level.

Can be ignored


Reason

Some additional information provided in the flight plan could not be processed by IFPS.

Requirements

Additional info, when provided within the flight plan shall be syntactically and semantically correct, otherwise it is discarded by IFPS.

IFPS Procedures

When this warning message is presented in an invalid message, no action shall be taken by the IFPS staff to validate the message against that warning message except to select “Apply.”

This will result in the warning(s) to disappear.



Related Sections





Error Message(s)

WARN320: AIRCRAFT TYPE ZZZZ, CALCULATED DEFAULT CATEGORY <Category>


SEEE: Single Engine

MEEE: Multi Engine

TPPP: Turbo-prop

TJJJ: .Turbo-jet.

Can be ignored


Reason

The message was submitted with the value ZZZZ as aircraft type and based on the speed and RFL specified in the route field, IFPS has automatically allocated an aircraft category in order to able to calculate a profile.

Requirements

Where the aircraft type is filed with the value ZZZZ, and TYP/ does not contain a known aircraft type from CACD, IFPS shall automatically allocate one of the 4 aircraft category (based on the specified speed and RFL) in order to be able to calculate a profile.

IFPS Procedures

If the message contains ROUTE/PROFILE error(s), the IFPS staff shall check the allocated generic aircraft performance which can be found in the WARN320 error text and

If the aircraft category is incorrect, the IFPS staff shall overwrite manually to the correct one and continue with normal processing (i.e. error(s) may disappear but if they remain, the IFPS staff shall apply the procedure related to this/these error(s)) or

If the aircraft category is correct, then the IFPS staff shall continue with normal processing

When this warning message is presented in a valid or invalid message while using IFPUV via CHMI, no action shall be taken by the user.

Related Sections


Aircraft Type (TYP)






Abbreviations

Abbreviations and acronyms used in this document are available in the EUROCONTROL Air Navigation Inter-site Acronym List (AIRIAL) which may be found online:

http://www.eurocontrol.int/airial/definitionListInit.do?skipLogon=true&glossaryUid=AIRIAL.

http://www.eurocontrol.int/airial/definitionListInit.do?skipLogon=true&glossaryUid=AIRIAL

http://www.eurocontrol.int/airial/definitionListInit.do?skipLogon=true&glossaryUid=AIRIAL




2019

2019