Working Paper Circulation Navigation Data Base (NDB) Subcommittee October 9-11, 2018, in Gdansk, Poland. 1. Long Term TFRs Garmin

Transcription

1 To NDB Subcommittee Date October 1, 2018 From Sam Buckwalter tel Reference /NDT-176 kpp Subject Working Paper Circulation Navigation Data Base (NDB) Subcommittee October 9-11, 2018, in Gdansk, Poland Attachments Subject Source 1. Long Term TFRs Garmin 2. Empty Continuation Records Garmin 3. Airspace Narrative Time Continuation Records Garmin 4. Pad Shape Duplicate Garmin 5. TAA Sector Minimum Altitude 5 Garmin 6. Duplicate Indicator Garmin 7. Additional Data for Helipad, Primary Record Elbit Systems 8. Quiet Climb SID Restore Point The Boeing Company 9. Changes to Path Terminator Field Requirements Lufthansa Systems 10. Helipad Alignment Lufthansa Systems 11. ATN Logon Codes Lufthansa Systems 12. Population of GLS Data FSEMC 13. Free Route Airspace Designation Jeppesen 14. Helipad Shape Values, Cleanup Jeppesen 15. Runway Identifiers Jeppesen This document is published information as defined by 15 CFR Section of the Export Administration Regulations (EAR). As publicly available technology under 15 CFR 74.3(b)(3), it is not subject to the EAR and does not have an ECCN. It may be exported without an export license Melford Blvd., Suite 120, Bowie, Maryland USA

2 16. IFPP Report Jeppesen 17. Discussion About Coding Examples Lufthansa Systems 18. Clean up of Approach Coding Rules in Attachment 5 Lufthansa Systems 19. TF Over FC/CF AeroNavData 20. Addition of 5.46 to HP Record AeroNavData 21. TCH Definition Update AeroNavData 22. Clarification on Runway Stopway Impact to Runway Length 23. Correction to Runway Stopway Source/Content 24. Redefinition of Approach AF Leg Recommended Navaid Requirements Honeywell Honeywell Honeywell Comments & Inquiries The staff welcomes comments on the attached material. Comments should be directed to Sam Buckwalter.

3 Attachment 1 Attachment 1

4 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 LONG-TERM TFRS V.1 Joshua Fenwick, Garmin SUMMARY At the FAA ACF there was a discussion about how the FAA publishes long-term TFRs on the Enroute Charts in some cases. Since these long-term TFRs are on the Enroute Charts we would like to add these as a new type of Restricted Airspace.

5 1.0 INTRODUCTION/ BACK GROUND At the most recent FAA Aeronautical Charting Forum (ACF) AOPA submitted Recommendation Document which discusses the publication of long-term Temporary Flight Restrictions (TFR) on the VFR Sectionals and Terminal Area Charts. The RTCA Tactical Operations Committee, co-chaired by AOPA and Jeppesen, delivered a report to the FAA in December 2016 which contained the following recommendations: 1. Long-term TFRs should be charted on Sectional and Terminal Area Charts 2. Long-term TFRs should be identified using standardized criteria 3. The FAA should retain the issuance process for long-term TFR NOTAMs, regardless of part-time or full time activation, even after that TFR NOTAM has been charted. 4. The FAA should standardize the charting requirement documents for TFRs to ensure consistency and to reduce pilot confusion. 5. The FAA should modernize the Sectional and Terminal Area Chart production process to achieve a 56-day charting cycle. 6. The FAA should make sporting event venues and their 3NM radius lateral rings available on controller charts 7. The FAA should depict sporting event venues with over 30,000 seats on ATC radar maps. 8. The FAA should depict long-term TFRs on ATC radar maps See the FAA s ACF Website for the full RD : Quote from part of AOPA s recommendation document: The VFR pilots who choose not to talk to air traffic control are the target audience for this intervention as they are the individuals most likely to violate a TFR unknowingly. Sectional and Terminal Area Charts are the primary resource for VFR navigation and are therefore the most important resources on which TFRs could be charted. Examples of long-term TFRs that are published today on FAA charts: 1. Disneyland Theme Park near KLAX: 2

6 2. Kennedy Space Center near KMXR 3. Camp David 3

7 Examples of long-term TFRs that the RTCA committee would like to be published: 1. Andersen Air Force Base Radiation area (example, FDC 6/5131) 2. Beale Air Force Base Unmanned Aircraft area (example, FDC 6/3017) 3. Corpus Christi Naval Air Station Unmanned Aircraft area (example, FDC 6/2539) 4. Dallas, Texas Former President Bush (example, FDC 9/2934) 5. Grand Forks Air Force Base Unmanned Aircraft area (example, FDC 6/3025) 6. Kilauea, Hawaii Volcano (example, FDC 5/7637) 7. Libby Army Airfield Unmanned Aircraft area (example, FDC 6/4292) 8. Vieques, Puerto Rico Naval Training Range unexploded ordinance area (example, FDC 6/1484) 9. New York, New York Trump Tower (example, FDC 7/5997) 2.0 DISCUSSION and or ACTION Garmin brought this item as a Discussion Item to the January 2018 NDB Working Group in Phoenix, AZ. At this meeting there was support to add the long-term TFRs to the ARINC 424 specification as a new Restrictive Airspace Type. 3.0 Changes as depicted (Track Changes is Helpful) 1. Add a new Restrictive Airspace Type (5.128) of L Long-term TFR Restrictive Airspace Type (REST TYPE) Definition/Description: The Restrictive Airspace Type field is used to indicate the type of Airspace in which the flight of aircraft is prohibited or restricted. The restriction may be continuous or specified for certain times. Source/Content: The Restrictive Airspace Type should be derived from official government publications. Type Alert Caution Danger Long-term TFR Military Operations Area National Security Area Prohibited Restricted Training Warning Unspecified or Unknown Field A C D L M N P R T W U Used On: Length Character Type Restrictive Airspace and Enroute Airway Flight Planning Continuation records 1 character Alpha 2. XML: Add a new RestrictiveAirspaceType enumeration of LongTermTFR 4

8 Attachment 2 Attachment 2

9 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 EMPTY CONTINUATION RECORDS V.1 Joshua Fenwick, Garmin SUMMARY I noticed that there are 5 Continuation records that are completely empty. Do these records serve a purpose? Or, should these records be removed?

10 1.0 INTRODUCTION/ BACK GROUND I discovered that the Airport/Heliport Localizer Marker, Airways Marker Continuation, FIR/UIR Continuation, Geographical Reference Continuation, and the GLS Continuation records do not contain any data and is only filled with Reserved (Expansion) space. This made me ask the purpose of these tables. 2

11 2.0 DISCUSSION and or ACTION I would like to know if these tables are being used or whether they should be removed from the ARINC 424 specification. There are other continuation records that only have the Notes (5.61) field, which is sometimes used to add tailored data elements, but these records have no fields. Questions: 1. Is anyone using these tables? If so, what is the purpose of this tables? 2. Should these tables have the 69-character Notes (5.61) field? 3. Does anyone think these should remain in the ARINC 424 specification? 3.0 Changes as depicted (Track Changes is Helpful) No changes Discussion Item Only. May change to a proposal based on the answers to the questions above. 3

12 Attachment 3 Attachment 3

13 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 AIRSPACE NARRATIVE TIME CONTINUATION RECORDS V.1 Joshua Fenwick, Garmin SUMMARY The ARINC 424 specification is missing the Record Layouts for the Narrative Time Continuation records related to the Airspace (UC/UR) records.

14 1.0 INTRODUCTION/ BACKGROUND The ARINC 424 specification mentions that the times of operation data can be output in two formats. By looking at the Continuation Record Application Type (APPL) field you can determine which Record Layout table (5.x.x) to use, which includes the formatted time and narrative time records. T Formatted Time record U Narrative Time record By looking at the Time Narrative (5.285) field you can see that the Restrictive Airspace (UR) and Controlled Airspace (UC) records are listed as Used On. The Time Narrative field was added by Jeppesen in the specification when they proposed the Communication (EV/HV/PV) records redesign. 2

15 2.0 DISCUSSION and or ACTION There are record descriptions in Chapter 5 to describe the format the T Formatted Time records for the Restrictive Airspace (UR) and Controlled Airspace (UC), but there no record descriptions in Chapter 5 to describe the format of the U - Narrative Time records. Example of the formatted times on the Restrictive Airspace (UR) continuation record: 3.0 Changes as depicted (Track Changes is Helpful) 1. Rename to Restrictive Airspace Formatted Time Continuation Records Restrictive Airspace Formatted Time Continuation Records 2. Add new # table for the Restrictive Airspace Narrative Time Continuation Records Restrictive Airspace Narrative Time Continuation Records Column Filed Name (Length) Reference 1 thru 24 Fields as on Primary Records 25 Continuation Record Number 5.16 (1) 26 Application Type (1) Time Code (1) NOTAM (1) Time Indicator (1) thru 99 Narrative Time (70) thru 123 Controlling Agency (24) thru 128 File Record Number (5) thru 132 Cycle Date (4) Rename to Controlled Airspace Formatted Time Continuation Records Controlled Airspace Formatted Time Continuation Records 3

16 4

17 4. Add new # table for the Controlled Airspace Narrative Time Continuation Records Controlled Airspace Narrative Time Continuation Records Column Filed Name (Length) Reference 1 thru 24 Fields as on Primary Records 25 Continuation Record Number 5.16 (1) 26 Application Type (1) Time Code (1) NOTAM (1) Time Indicator (1) thru 99 Narrative Time (70) thru 123 Controlling Agency (24) thru 128 File Record Number (5) thru 132 Cycle Date (4) Remove the Call Sign text from the Continuation Record Application Type (5.91) field with the field content of B and C. This is no longer a valid Application Type value since the Call Sign (5.105) field moved to the Communication (EV/HV/PV) Primary records in Field Content A B C E L N T U V P S W Description A standard ARINC 424 Continuation containing Notes or other formatted data not covered by a define Continuation Combined Controlling Agency/Call Sign and formatted Time of Operation Call Sign/Controlling Agency Continuation Primary Record Extension VHF Navaid/TACAN Only Navaid Limitation Continuation A Sector Narrative Continuation A Time of Operations Continuation, formatted time data A Time of Operations Continuation Narrative time data A Time of Operations Continuation, Start/End Date A Flight Planning Application Continuation Simulation Application Continuation An Airport or Heliport Procedure Data Continuation 5

18 Attachment 4 Attachment 4

19 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 PAD SHAPE DUPLICATE CIRCLE V.1 Joshua Fenwick, Garmin SUMMARY The Helipad Shape (5.303) field definition has two entries for the C Circle value.

20 1. INTRODUCTION/ BACKGROUND I discovered that the Helipad Shape (5.303) had two entries in the same table for the C Circle. 2. DISCUSSION and or ACTION This table should only have one C Circle entry. 3. Changes as depicted (Track Changes is Helpful) 1. Delete the last row in the table 2

21 Attachment 5 Attachment 5

22 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 TAA SECTOR MINIMUM ALTITUDE 5 V.1 Joshua Fenwick, Garmin SUMMARY The Airport & Heliport TAA (PK/HK) records have had a typo on columns since The columns should represent the 5 th Sector Minimum Altitude (5.147).

23 1.0 INTRODUCTION/ BACK GROUND The Airport TAA (PK) and Heliport TAA (HK) records went through a big change in the ARINC specification. As part of this overhaul of the PK and HK records, an error was introduced in the Chapter 4 tables. 2.0 DISCUSSION and or ACTION As it is right now it shows the Sector Radius field on the PK/HK records as 4 characters long and residing in columns (7 columns long). And these tables are missing the 5 th Sector Minimum Altitude (3 characters long) Airport TAA Primary Records (PK) Column Field Name (Length) Reference 95 thru 101 Sector Radius 1 (4) Heliport TAA Primary Records (HK) Column Field Name (Length) Reference 95 thru 101 Sector Radius 1 (4) Changes as depicted (Track Changes is Helpful) The Chapter 4 tables should be corrected to show the 5 th Sector Minimum Altitude as columns and the 5 th Sector Radius should be shown as columns Airport TAA Primary Records (PK) Column Field Name (Length) Reference 95 thru 97 Sector Minimum Altitude (3) thru 101 Sector Radius 1 (4) Heliport TAA Primary Records (HK) Column Field Name (Length) Reference 95 thru 97 Sector Minimum Altitude (3) thru 101 Sector Radius 1 (4)

24 Attachment 6 Attachment 6

25 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 DUPLICATE INDICATOR V.1 Joshua Fenwick, Garmin SUMMARY The Holding Pattern (EP) record s Duplicate Indicator (5.114) can cause one holding pattern to turn into multiple duplicates, which makes them difficult to use. I would like to separate the airspace usage data from the Duplicate Indicator and just use a Sequence Number (5.12) for the unique key.

26 1. INTRODUCTION/ BACKGROUND The Holding Pattern (EP) record currently uses the Duplicate Indicator/Identifier (5.114) field as one of the EP records key fields. The Duplicate Indicator (5.114) has two characters which help to uniquely identify the following: 1. Character 1: Airspace Structure (High, Low, SID, etc.) 2. Character 2: Multiple Indicator (0, 1, 2, etc.) 2. DISCUSSION and or ACTION The problem with the current Duplicate Indicator (5.114) field is that the Airspace Structure causes one holding pattern to be output as multiple EP records, even though all the rest of the fields are the same (Inbound Holding Course, Turn Direction, Leg Length, etc.). 2

27 For example, the GLENO INT in the United States has 3 holding patterns on the FAA s form: Figure 1: GLENO Holding Patterns These three holding patterns are used on High Airways, Low Airways, SIDs, and Approaches. Figure 2: GLENO Fix Use The GLENO Pat # 1 is on High Awy (J80), Low Awy (V134, V591), & 3 Approaches at KASE. The GLENO Pat # 2 is on 1 SID, and 2 Approaches at KASE. The GLENO Pat # 3 is on 1 Approach at KASE. Using the current Holding Pattern (EP) record design this could result as many as 6 EP records. Each NavDB supplier seems to do this differently which results in more or less than 6 holding patterns. 3

28 FAA Pat # Crs, Turn, Leg Length Duplicate Indicator Duplicate Indicator Char 1 Char , L, 1.5 min 1 High , L, 1.5 min 2 Low , L, 1.5 min 6 Missed Approach , L, 8 NM 3 SID , L, 8 NM 6 Missed Approach , L, 1.5 min 6 Missed Approach 2 Figure 3: GLENO EP Records Part of the problem is that the NavDB suppliers interpret the Enroute Holding Pattern Duplicate Indicator differently resulting in different EP records. For example, for the GLENO INT listed above, we get 3 EP records from one NavDB supplier and 7 EP records from the other. The other problem is that when we get duplicates of the same holding pattern, it becomes difficult to know which ones are the same holding pattern. 3. Changes as depicted (Track Changes is Helpful) The Holding Pattern (EP) record s Duplicate Indicator (5.114) can cause one holding pattern to turn into multiple duplicates, which makes them difficult to use. I would like to separate the airspace usage data from the Duplicate Indicator and just use a Sequence Number (5.12) for the unique key. 1. Update the Holding Pattern Primary Records Column Field Name (Length) Reference 1 Record Type (1) thru 4 Customer/Area Code (3) Section Code (1) Subsection Code (1) thru 10 Region Code (4) 5.41 Note 1 11 thru 12 ICAO Code (2) 5.14 Note 1 13 thru 27 Blank (Spacing) (15) 28 thru 29 Duplicate IdentifierSequence Number (2) 30 thru 34 Fix Identifier (5) thru 36 ICAO Code (2) Section Code (1) Subsection Code (1) Continuation Record No. (1) thru 43 Inbound Holding Course (4) Turn Direction (1) thru 47 Leg Length (3) thru 49 Leg Time (2) thru 54 Minimum Altitude (5) thru 59 Maximum Altitude (5) thru 62 Holding Speed (3) thru 65 RNP (3) thru 71 Arc Radius (6) thru 74 Vertical Scale Factor (3) thru 77 RVSM Minimum Level (3) thru 80 RVSM Maximum Level (3) Leg Inbound/Outbound Indicator (1)

29 82 Hold Usage thru 98 Reserved (Expansion) (1716) 99 thru 123 Name (25) thru 128 File Record No. (5) thru 132 Cycle Date (4) Update the field definition for 5.12 Sequence Number (SEQ NR) 5.12 Sequence Number (SEQ NR) Definition/Description: For Route Type Records A route of flight is defined by a series of records taken in order. The Sequence Number field defines the location of the record in the sequence defining the route of flight identified in the route identifier field. For Boundary Type Records A boundary is defined by a series of records taken in order. The Sequence Number field defines the location of the record in the sequence defining a boundary. For Record Types requiring more than one primary record to define the complete content In a series of records used to define a complete condition, the Sequence Number is used to define each primary record in the sequence. For Airport and Heliport TAA Records Sequence Number 1 will always be assigned to the record based on the Center Fix upon which the Straight-In Area is predicated, Sequence Number 2 will always be assigned to the record based on the Center Fix upon which the Left Base Area is predicated, and Sequence Number 3 will always be assigned to the record based on the Center Fix upon which the Right Base Area is predicated. Therefore, if a TAA Record has a Straight-In Area and a Right Base Area, but no Left Base Area, only Sequence Numbers 1 and 3 will be used. If a TAA Record has a Straight-In Area and a Left Base Area but no Right Base Area, only Sequence Numbers 1 and 2 will be used. Source/Content: Sequence numbers are assigned during the route, boundary or sequence definition phase of the data file assembly. Sequence numbers are assigned so as not to be duplicated within the route, boundary or sequence assigned a unique identification/designation. For three or four-digit Sequence Numbers, initially, an increment of ten should be maintained between the sequence numbers assigned to consecutive records. For one or two-digit Sequence Numbers, the initial increment is one. In route or boundary records, should subsequent maintenance of the file necessitate the addition of a record or records, the new record(s) should be located in the correct position in the sequence and assigned a sequence number whose most significant characters are identical to those in the sequence number of the preceding record in sequence. The unit character should be assigned a value midway between the units character values of the preceding and following record sequence numbers. For example, if it is desired to add one record to the sequence and the units characters of both the preceding and following records at the desired location are zeros (indicating no previous modification at this point), the units character or the inserted record s sequence number should be five (5). For records taken in sequence with one or two-digit sequence numbers, additional data must be entered in the proper sequence and all subsequent records will be up numbered accordingly. When an enroute airway crosses the boundary separating two geographical areas (Section 5.3), the airway fix lying on or closest to the boundary shall be coded twice, once for each geographical area, and should be assigned the same sequence number in each case. Record uniqueness in such cases is maintained through the Boundary Code (Section 5.18). Enroute airway record sequence numbers should be assigned in a manner which permits them to be arranged into continuous airway routes in flight sequence order when sorted according to the Route Identifier and Sequence Number only, without regard to their applicable Geographical Area Code. 5

30 When used on Enroute, Airport and Heliport Communications Primary and Continuation records, the Sequence Number is used as a record counter within a given Identifier and Communications Class for providing output file record uniqueness. When used on Holding Pattern Records, the Sequence Number is used as a record counter within a given Identifier for providing output file record uniqueness. Used On: Holding Pattern Records, Enroute Airways, Airport and Heliport MSA Records, Airport and Heliport TAA Records, Airport and Heliport SID/STAR/Approach, Company Route, Cruise Tables, FIR/UIR, Restrictive Airspace, Controlled Airspace, Preferred Routes, Flight Planning Arrival/Departure Data and VHF Navaid Limitation Continuation Records, Helicopter Operations Company Routes, TACAN-Only NAVAID Limitation Continuation Record Length: 4 characters - Enroute Airways, Preferred Routes, FIR/UIR, and Restrictive Airspace 3 characters - SID/STAR/Approach and Company Routes 2 characters - VHF Navaid Limitation Continuation Records and TACAN-Only NAVAID Limitation Continuation Record Character Type: Numeric Examples 0010, 0135, 2076, 120, 030, 01, 84, 3 3. Update the field definition for 5.82 Waypoint Usage 5.82 Waypoint/Hold Usage Definition/Description: The waypoint/hold usage field is employed to indicate the structure in which the waypoint/hold is utilized. Source/Content: Usage HI and LO Altitude HI Altitude LO Altitude Terminal Use Only (not used enroute) Record Column Content 31 B H L Blank Used On: Length: Character Type: Holding Pattern Records, Waypoint (EA/PC) and Heliport Terminal Waypoint (HC) records 1 character Alpha/Numeric 4. Delete the field definition for Duplicate Indicator Duplicate Indicator (DUP IND) Definition/Description: The Duplicate Identifier field is used to further define holding patterns when official government source has designated more than one Holding Pattern on a Navaid or Waypoint. 6

31 Source/Content: Holding Patterns are derived from official government sources documents. That documentation will normally specify the airspace structure in which the holding is to be used. That documentation may also designate more than one Holding Pattern for a single Navaid or Waypoint. This field will contain details on airspace structure and multiple designations. More than one holding is designated on a single fix when one or more of the following elements are different for holdings within the same airspace structure. Inbound Holding Course, Turn Direction, Altitude, Leg Length or Leg Time, and Holding Speed. If only one Holding Pattern is designated for a fix and the airspace structure in which that holding is to be used is not defined, the field will contain 00. If only one Holding Pattern is designated for a fix and the airspace structure in which that holding is to be used is defined or if the same holding is designated for more than one airspace structure, the first position of the Duplicate Indicator will contain a digit of 1 through 6 and the second position will contain a zero. If more than one holding is designated for a single fix in one type of airspace structure, the first position will contain a digit of 1 through 6 and the second position will contain a digit of 0 through 9, depending on the number of holdings on that fix within that airspace structure. If multiple holdings are designated in official source documents for a single fix and some of those holding are not associated with a defined airspace structure, then those with undefined airspace structure will carry the digit 7 in position one and a digit of 0 through 9 in position two. Table 5-23 Multiple Holding Patterns Duplicate Indicator Usage Position One Airspace Position Two Multiple Undefined (None Defined) 0 See Note 1 High Altitude 1 See Note 1 Low Altitude 2 See Note 1 SID 3 See Note 1 STAR 4 See Note 1 Approach 5 See Note 1 Missed Approach 6 See Note 1 Undefined (with other defined) 7 See Note 1 All Altitude 8 See Note 1 Note 1: If there is only one holding pattern on a given fix within an airspace structure, position 2 will contain a 0. For additional holdings on that same fix within the same airspace structure, position 2 will be incremented by 1. Used On: Holding Pattern Records Length: 2 characters Character Type: Numeric Examples: 00, 10, 61, Updated remaining table names in Section 5 to include updated table numbers: Section Table # Table (in table Center Fix header) Table (in paragraph) 7

32 8

33 Attachment 7 Attachment 7

34 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 ADDITIONAL DATA FOR HELIPAD PRIMARY RECORDS (HH) V1.2 Ziv Goldenberg, ELBIT SYSTEMS LTD SUMMARY I would like a discussion that asks the users of the ARINC 424 data to add additional data to the existing helipad primary records (HH) in order to code in a more accurate and complete manner related data to helipads as published in Aeronautical Information Publications (AIP)

35 1.0 INTRODUCTION/ BACK GROUND Display of Helipads by Synthetic Vision Systems on head down or head up displays is becoming a common practice with the introduction of advanced avionics systems. In addition the in work standard for MINIMUM AVIATION SYSTEM PERFORMANCE STANDARDS (MASPS) FOR A COMBINED VISION SYSTEMS FOR HELICOPTER OPERATIONS further emphasize the need for such capability. In order to display the helipad in conformity with the outside world some gaps exist between the data currently coded in the ARINC and the information available via AIP publication or other means. Paragraph 2 provides details regarding the existing gaps and paragraph 3 provides the suggested changes to incorporate into the ARINC standard. 2.0 DISCUSSION and or ACTION The mapping of missing data below is referenced to the existing data defined in ARINC Helipad Helipad Primary Records (HH) 1. Helipad type In order to provide consistency between terrain elevation and helipad data and correctly display the helipad there is a need to define whether helipad is surface level or elevated. For example some hospitals have several helipads, some on ground level and other elevated. 2. TLOF, FATO and Safety area dimensions In the current coding it is not clear whether the dimensions represent the TLOF or FATO (or just parking area). It will be very useful to have all available dimensions. 3. Rectangular Helipad orientation- There is no coding for rectangular helipad orientation. This information is available in some AIP (usually as true bearing) 4. Helipad marking orientation- The helipad marking is usually oriented according to the preferred approach direction which will not necessary be the same as the physical helipad orientation 5. Maximum rotor diameter The maximum rotor diameter is physically painted on the helipad lower right corner Below the Maximum weight (which is already coded in the ARINC ) The discussion and actions are: a. Review the suggested changes in order to incorporate them into the next ARINC-424 revision. b. Consider the changes for inclusion in the DO-201B standard (via the RTCA SC-217 committee) 2

36 3.0 Changes as depicted In reference to Heliport Helipad Record (HH) Heliport Helipad Primary Records Column Field Name (Length) Reference 1 Record Type (1) thru 4 Customer/Area Code (3) Section Code (1) Blank (Spacing) (1) 7 thru 10 Heliport Identifier (4) thru 12 ICAO Code (2) Subsection Code (1) thru 18 Helipad Identifier (5) thru 21 Blank (Spacing) (3) 22 Continuation Record No. (1) Helipad Shape (1) thru 31 Helipad TLOF Dimension (8) Reserved (Expansion) (1) 33 thru 41 Helipad Latitude (9) thru 51 Helipad Longitude (10) Helipad Surface Code (1) thru 57 Helipad Surface Type (4) thru 60 Max Allowable Helicopter Weight (3) Helicopter Performance Requirement (1) thru 64 Helipad Maximum rotor diameter (3) Helipad type thru 66 Reserved (Expansion) (51) 67 thru 71 Helipad Elevation (5) thru 79 Helipad FATO Dimension (8) thru 87 Safety area Dimension (8) thru 91 Rectangular Helipad bearing (4) thru 95 Helipad marking bearing (4) thru 123 Reserved (Expansion) (5228) 124 thru 128 File record No. (5) thru 132 Cycle Date (4)

37 New references Helipad Maximum rotor diameter Source/Content: Helipad Maximum Rotor diameter Pad dimensions will be derived from official government sources and entered into the field in feet with a resolution of one foot. Rationale is to maintain the maximum foreseen rotor size, which currently exceed 100 feet (e.g., 105 feet in Mi-26). Blank when not available Used On: Helipad Records Length: 3 characters Character Type: Numeric Examples: 105, 150, Helipad Type Source/Content: Helipad type indicates whether helipad is located on surface or elevated (e.g., roof top). Helipad Type will be derived from official government sources. Used On: Helipad Records Length: 1 character Helipad Type Field Content Surface S Elevated E Other types or unknown Blank Character Type: Character Examples: S, E, Blank Rectangular Helipad/Helipad marking Bearing Definition/Description: The rectangular helipad bearing or the helipad marking bearing of the helipad identified in the helipad identifier Source/Content: Rectangular helipad bearing or helipad marking bearing is derived from official government sources The values are entered into the field in degrees and tenths of a degree, with the decimal point suppressed. For helipad bearings published with the intent to be used as true bearings, the last character of this field will contain a T following the tenths of a degree coding. Used On: Runway and Helipad Records Length: 5 characters Character Type: Alpha/numeric Examples: 18000, 23020, 06050, 3470T 4

38 Attachment 8 Attachment 8

39 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 QUIET CLIMB SID RESTORE POINT V.0 Matthew Colburn, The Boeing Company SUMMARY Introduce new data parameter Quiet Climb SID Restore Point as a new Waypoint Description code under section 5.17 Table INTRODUCTION/ BACK GROUND Quiet Climb thrust reduction procedures may be required for noise sensitive geographical location on departure. The Quiet Climb SID restore point is to be used as an indicator on procedure SID records as a waypoint descriptor when reduction in thrust for noise abatement sensitive areas is no longer applicable geographically and restore to normal planned climb thrust. The indicator is analogous to Engine Out SID Missed Approach Disarm Point in its function. 2.0 DISCUSSION and or ACTION 3.0 Changes as depicted (Track Changes is Helpful) Table 5-15 Waypoint Description 4.0 Waypoint Description Used On Column Column Column Column Remarks Type/ Function/ Attribute Enroute, SID, STAR, APCH Airport as Fix SID, STAR, APCH A Note 6 Essential Waypoint Enroute, SID, STAR, APCH E Note 1 Off Airway Floating Waypoint Enroute F Note 1 Runway as Fix, Helipad as Fix SID, STAR, APCH G Heliport as Waypoint SID, STAR, APCH H Note 6 NDB Navaid as Waypoint Enroute, SID, STAR, APCH N Phantom Waypoint SID, STAR, APCH P Note 1 Non-Essential Waypoint Enroute R Note 1 Transition Essential Waypoint Enroute T Note 1 VHF Navaid As Fix Enroute, SID, STAR, APCH V

40 Flyover Waypoint, Ending Leg SID, STAR, APCH B Note 2 End of Continuous Segment Enroute, SID, STAR, APCH E Note 2 Uncharted Airway Intersection Enroute U Note 1 Fly-Over Waypoint APCH, SID, STAR, Y Note 2 Unnamed Stepdown Fix Final Approach Segment APCH A Unnamed Stepdown Fix Intermediate Approach Segment APCH B ATC Compulsory Reporting Point SID, STAR, APCH Enroute C Note 1 Oceanic Gateway Waypoint Enroute G Note 1 First Leg of Missed Approach Procedure APCH M Note 3 Fix used for turning final approach APCH R Note 4 Named Stepdown Fix APCH S Initial Approach Fix APCH A Note 1 Intermediate Approach Fix APCH B Note 1 Holding at Initial Approach Fix APCH C Initial Approach Fix at FACF APCH D Final End Point APCH E Note 1 Final Approach Fix APCH F Note 1 Source provided Enroute Waypoint without Holding Enroute G Source provided Enroute Waypoint with Holding Enroute SID, STAR, APCH H Final Approach Course Fix APCH I Note 1 Missed Approach Point APCH M Note 1 Engine Out SID Missed Approach Disarm Point SID (Engine Out), APCH N Note 5 Initial Departure Fix SID P Note 7 Quiet Climb SID Restore Point SID Q Note 8 Note 8: A Q in column 43 of a SID record designates a waypoint where restore of planned climb thrust to be used on procedure SID records when reduction in thrust for noise abatement sensitive areas is no longer required geographically. For example, if a reduced thrust takeoff is required for noise abatement procedure is required on initial take off, thrust may be restored once the waypoint is sequenced automatically by the system. 2

41 Attachment 9 Attachment 9

42 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 CHANGES TO PATH TERMINATOR FIELD REQUIREMENTS V.3 Martin Zillig, Lufthansa Systems FlightNav SUMMARY This proposal addresses a request to remove the need for a recommended navaid on certain path terminators for PBN procedure coding. Additionally, it aims to clarify differences between PBN approach coding and ground based VOR/DME RNAV approach coding, i.e. RNAV(VOR/DME).

43 1.0 INTRODUCTION/ BACK GROUND The requirement to code a co-located VOR/DME or VORTAC recommended navaid on CF, FA and FM legs for procedures designed and published in accordance with the ICAO performance based navigation document and as such not following any track from any ground based navaids raised many questions, initiated discussions and caused some confusion. Considering that the only reason such a navaid must be coded is as a source for magnetic variation, which can already be provided for procedures using different fields. Among the main problems is the fact that states typically do not designate such a navaid. The selection of the correct navaid is in most cases up to the data house. As a result, a published change of magnetic variation of any navaid may have undesired consequences to terminal procedures which are unknown to the procedure designer. The requirement to code a recommended navaid when it is not used for track guidance is further complicated by the fact that some states start to decommission VOR stations, resulting in many suitable VOR/DMEs becoming DME only and therefore unsuitable for recommended navaid coding. Additionally, a change in the declination of a VOR/DME might result in changes to the ground track of many CF legs which were neither intended nor controlled by state publications. ARINC 424 already allows coding the magnetic variation for procedure legs, however, rules still require a recommended navaid to be coded. Finally, during updating rules to remove the requirement for recommended navaids under certain conditions, I updated some rules to better distinguish between PBN and non PBN procedures. 2.0 DISCUSSION and or ACTION This proposal intends to change ARINC 424 rules so that for path terminators requiring recommended navaids for the sole purpose of providing a magnetic variation, a procedure magnetic variation can be provided instead. Additionally, rules are changed so that for PBN procedures no recommended navaids shall be coded, but the magnetic variation must be provided in the procedure design magnetic variation fields (5.290 and 5.291). For path terminators CF, FA, FC, FM and PI, the recommended navaid becomes optional if the procedure magnetic variation is provided. For PBN procedures, the recommended navaid will be blank for CF, FA and FM legs, the PDMV must be coded. I also tried to include these changes in table 5-18, but maybe that is making table 5-18 too complex. Additionally, in attachment 5, words have been updated to clearly differentiate between the ground-based VOR/DME RNAV in rules 6.6 and 8.3, and the PBN RNAV in rules 6.9 and 8.7. I reorganized the legend to table 3 in attachment 5 for my own better understanding. This new layout does not necessarily need to be included in the 424 document, only the editorial DME isof Dme and the addition of the new letter M. Editorial changes to table 3 in attachment 5 include the shading of Alt2 for the HA leg to match the other xa legs, to change the PI leg Distance field from P to X as it is not a path length, and to change the xa comments from will to must. The group is asked to consider these changes to better code terminal procedures and to be able to efficiently use PBN procedures in the future. 2

44 3.0 Changes as depicted (Track Changes is Helpful) 5.23 Recommended NAVAID (RECD NAV) Definition/Description: The Recommended Navaid field allows the reference facility for the waypoint in a given record Fix Ident field or for an Airport or Heliport to be specified. VHF, NDB (Enroute and Terminal), Localizer, TACAN, GLS, and MLS Navaids may be referenced. Source/Content: The 1, 2, 3, or 4-character identification of the Navaid appears in this field. Navaids recommended for waypoint reference in official government publications will be used when available. The following general rules on field content apply: Procedures that use coding which require leg types referenced to specific navaids are covered by the procedure coding rules in Attachment 5 to this specification. The specific requirement for recommended navaid to provide a declination as a source for magnetic variation can be substituted when providing a procedure magnetic variation. a. A VHF Navaid may be any VOR, DME, VORDME, VORTAC, TACAN, Un-Biased ILSDME or MLSDME available in the database following the specific rules in Table b. A NDB Navaid may be any NDB or Locator available in the Enroute or Terminal NDB files in the database. c. Localizers and MLS Azimuth are used as Recommended Navaids for procedures that reference those navaids, including RNAV Transitions to these types of procedures. d. The Recommended Navaid in final approach coding will be the procedure reference facility. As not all Final Approach Procedure reference a Navaid, i.e. RNAV and GPS, the Recommended Navaid is not provided in these types of procedure, see Attachment 5 for specific rules. e. The Recommended Navaid in Airport and Heliport Records will be any VOR, VORDME, or VORTAC available in the database. f. The Recommended Navaid in any Enroute Airway Record, when provided, will be any VORDME or VORTAC available in the database. g. The Recommended Navaid in any Terminal Procedure Record other than the final approach coding will be the procedure reference facility of a type from the Definition/Description paragraph above and will be in accordance with the rules governing Recommended Navaids for Path Terminators and coding rule as defined in Attachment 5 of this specification. h. The rules for Recommended Navaids for Converging ILS Approach Procedures are the same as for ILS Approach Procedures. i. The Recommended Navaid used in a GLS Approach Procedure will be the GLS Reference Path identifier appropriate to the runway and approach. j. The use of non-collocated facilities of the types VORDME, VORTAC, and Localizer/ILSDME or ILSTACAN as the recommended navaid in terminal procedure coding is limited to defined circumstances only. For a definition of non-collocated, refer to Section 5.35 of this specification. For the defined circumstances, refer to Table 5-18 of this specification. Used On: Enroute Airway Record, Airport and Heliport SID/STAR/Approach Records, Airport and Heliport Record Length: 4 characters max. Character Type: Alpha/numeric Examples: P, PP, DEN, LAX, ILAX, MJFK 3

45 Table 5-18 Procedure Use Procedure User Facility Type SID/STAR Approach Transition Missed Approach Procedure Path Terminator - AF Path Terminator - CR, VR Path Terminator - CD, VD, FD Localizer Final Approach & Transitions of Course or Heading to Intercept Localizer VORDME/VORTAC Final Approach VOR Only Final Approach Coding NDB Only Final Approach Coding NDB + DME Final Approach Coding TACAN Final Approach Coding GLS Final Approach Coding MLS Final Approach Coding & Transitions of Course or Heading to Intercept MLS Airports Collocated VORDME/ VORTAC X X X X X X X 2 X Noncollocated VORDME/ VORTAC X X X 2 X Localizer X X X X VOR X X X X X DME X X 2 TACAN X X X X X X 2 X X NDB X X X 1 ILSDME or ILSTACAN & 3 GLS X X MLS X X PDMV X X X 1 On FACF and FAF Records 2 On Runway/MAP Records Only 3 ILSDMEs and ILSTACANs must be unbiased for use as a recommended navaid. They do not have to be collocated with the frequency paired localizer for use as a recommended navaid in the instances allowed. 4

46 5.290 Procedure Design Mag Var (PDMV) Definition/Description: The Procedure Design Mag Var field specifies the angular difference between True North and Magnetic North at the location defined in the record. That location may be the airport for which the procedure was designed, the so-called Airport Magnetic Variation of Record, or may be the procedure leg defined in the record. Which location is intended can be determined from the content of the data coded to Section (Procedure Design Mag Var Indicator). The Procedure Design Mag Var may substitute for a recommended navaid, see Attachment 5 for specific rules. Source/Content: Procedure Design Mag Var is obtained from official government procedure data sources and is understood to be the Epoch Year value used when the procedure last revised. This value may differ from magnetic variation data in the primary record of the airport for which the procedure was designed and from data for individual navaids or waypoints used in the procedure. Updating of this value is based only on procedure source data change. Position one of the field contains an alpha character taken from the table below. Positions 2 thru 5 carry the angular difference value expressed in degrees and tenths of a degree with the decimal point suppressed. When Position one is set to T, Positions 2 thru 5 will be all zeros. Field Content E W T Description Procedure Designed based on Magnetic Variation (angular difference) that is East of True North Procedure Designed based on Magnetic Variation (angular difference) that is West of True North Procedure Designed based on True North Length: 5 characters Character Type: Alpha/numeric Examples: E0140, E0007, T0000 5

47 ATTACHMENT Leg Data Fields The following table provides detail on Required and Optional parameters used to define each leg type. An O in the table indicates that the parameter is considered optional and may be omitted as required in individual cases. All other entries indicate some type of a required situation for leg definition. PT W/P ID OVR FLY HLD TD TDV RMD NAV THETA RHO OBD MAG CRS Leg Data Fields Table 3 TM/ DST ALT ONE SPD ALT LMT TWO ANG VRT AF X O O X X X X R O O O CA O O C + O CD O O X C D O O O CF X B O O O XM X X C P O O O O CI O O O O C O O O CR O O X X C O O O ARC RAD ARC CTR COMMENTS OB MAG CRS=BNDY RDL, THETA=FIX RDL ALT TERM WILL MUST BE AT OR ABOVE OB MAG CRS IS CRS TO SPECIFIED FIX DF X B O O O O O O O O FA X E O O XM X X C + O FC X B E O O X M X X C P O O O FD X E O O X O X C D O O O FM X E O O X M X X C O O HA X O X O O O C X + O F HF X O X O O O C X O O O F ALT TERM WILL MUST BE AT OR ABOVE HOLDING IS AT FIX HOLDING IS AT FIX HOLDING IS AT FIX HOLDING IS AT FIX ALT TERM WILL MUST BE AT OR ABOVE HM X O X O O O C X O O O F IF X O O O O O O O PI X X X M X X C PX X O RF X O X O I T A O O O O X X TF X B O O O O O O O O O O O O VA O O H + O VD O O X H D O O O VI O O O O H O O O VM O O O H O O VR O O X X H O O O DIST IS EXCURSION DIST FROM FIX ALT TERM WILL MUST BE AT OR ABOVE FOR W/P ID SEE STAR CODING RULES 6

48 LEGEND: + At Or Above Only A Along Track Distance B Required For CF/DF, DF/DF, TF/DF, or FC/DF Combinations; Otherwise Optional C Course D Dme DME Distance E Optional Field: Fix Must Be Part of the Terminal Procedure Route F Required for holds that contain an RNP value. H Heading I The inbound tangential track is provided for leg combinations IF/RF, AF/RF, RF/RF, or DF/RF; otherwise, the inbound tangential track is contained in the previous leg. M Optional if procedure magnetic variation (PDMV) is coded; Otherwise required. O Optional Field P Path Length R Boundary Radial Shaded Not Applicable Field T Provided for the leg combinations of RF/RF, or RF/Hx, and when the RF is the last leg of the procedure; otherwise, the outbound tangential track is contained in the next leg. X Required Field 7

49 3.0 Path and Termination Related Rules Valid For All Procedure Types Except RNAV Terminal Procedures That Do Not Reference Ground-based Navaids Path and Termination Related Rules Valid For All RNAV Terminal Procedures That Do Not Reference Ground-based Navaids 3.19 The CF leg is available as a leg type in RNAV Terminal Procedures only when specifically called out in the government source documentation. When this is the case, the leg data will include a reference from which the magnetic variation for use in flying the CF Leg can be determined. This reference will be provided in the Recommended Navaid field of the procedure record. For CF, FA and FM legs in PBN procedures, the recommended navaid must be blank. The magnetic variation required to construct these legs must be provided in the procedure design magnetic variation field (PDMV) either as a procedure value or as a leg value. 6.6 VOR, VORDME, VORTAC, and Area Navigation ApproachVOR/DME RNAV Procedure Coding The following rules apply to the Final Approach Coding of all VOR based approach procedures, regardless of the reference facility type, and to VOR/DME RNAV (VOR DME) Approach Procedures VOR/DME RNAV- Area Navigation Procedures This section provides coding guidelines for VOR/DME RNAV Approach Procedures.-Area Navigation procedures These in the context of this attachment are the so called RNAV Procedures that requirevor/dme RNAV Approach Procedures must referencing reference ground -based navigational aids. These procedures are not designed as PBN Procedures and typically are published using a title RNAV (VOR/DME) or VOR/DME RNAV.also referred to as VOR DME RNAV Procedures All VOR/DME RNAV- Area Navigation approach procedures will be coded to a runway threshold or a Fictitious Threshold Point (FTP) as the last leg in the Final Approach Coding sequence. The runway threshold or FTP may be a source defined name waypoint The recommended navaid for VOR/DME RNAV approaches will must be the procedure VOR/DME or VORTAC. Theta and Rho values will be provided from that facility in all Final Approach Coding sequences Final Approach Coding will be accomplished using IF and, CF or and TF legs only. RF legs may be used in RNAV approaches when and where specified by source documentation For VOR/DME RNAV Approach procedures to a Point-in-Space, a separate procedure must be coded for each Airport or Heliport that the procedure serves, as defined by source documentation. 8

50 6.9 RNAV Procedure Coding This section provides coding guidelines for RNAV Approach Procedures. The terman RNAV Approach Procedure is defined as an approach procedure that was designed to provide lateral and vertical path guidance without using criteria that do not relying on radials, bearings, DME arcs or glide paths from groundbased navaids. As such, an RNAV Approach Procedure will not include references to ground-based navaid associated information such as VOR radials, NDB bearings, DME distances, ILS courses, MLS Azimuths and ILS or MLS glideslopes. These Approach Procedures are designated as PBN Navigation Specifications RNP APCH or RNP AR APCH, and typically are published using a title RNAV (GPS), RNAV (GNSS), RNAV (RNP) or RNP. Exceptions to this standard may be outlined in the rules that follow. Navaids may be referenced as waypoints in the coding of the RNAV Approach Procedures Recommended Navaids RNAV Approach Procedures in the context of this section do not require referencing a specific ground-based navaid. As such, no Recommended Navaid will be provided for these procedures.the exception to this rule is that in those cases where the official government source a specified a Path and Termination (leg type) that requires a Recommended Navaid (see Table 1.5, Leg Data Fields), the navaid will be included in the coding of the RNAV Approach Procedure as a Recommended Navaid. Including a Recommended Navaid does not imply that this navaid is required to be used in the navigation solution The magnetic variation required to construct path terminators must be provided in the procedure design magnetic variation field either for the procedure or as a minimum for such legs (see and 5.291).The Final Approach Coding of RNAV Approach Procedures covered by this Section 6.9 do not require a Recommended Navaid except as governed by other rules in this attachment Final Approach Coding must be accomplished using IF, RF and TF legs only. When the final approach coding starts with a precision arc, use an IF leg at the FACF or FAF, followed by the RF leg. This ensures compliance with the Beginning/Ending Leg Table. According to RF leg rules, at least one fix terminated approach transition to the same fix used in the IF leg of the final approach coding must be included. The track in the transition(s) must be tangent to the arc.the track from the FACF (when coded) to the FAF and the FAF to MAP must be coded as TF or RF legs. The RF leg is not allowed as the first leg of the Final Approach Coding according to the Beginning/Ending Leg Table. The preferred coding when an approach starts with a precision arc is IF at the (FACF), followed by RF to the FAF. 9

51 8.3 Final Approach Path Coding - VOR-based Procedures The following rules apply to the Final Approach Coding of non-precision VORbased approach procedures. These procedures may include VOR, VOR/DME, VORTAC, TACAN, and VOR/DME RNAV Area Navigation procedures When the reference facility is VOR/DME or VORTAC or TACAN, the following applies: The recommended navaid must be the procedure reference VOR/DME or VORTAC or TACAN. Theta and Rho values must be provided from that facility in all Final Approach Coding sequences, including any step-down fixes that are included When the procedure reference is VOR/DME RNAV (VORDME), the following applies: Final Approach Coding must be accomplished using IF, and CF orand TF1 legs only. RF legs may be used in RNAV approaches when and where specified by source documentation All VOR/DME RNAV- Area Navigation approach procedure missed approach points must be at or prior to a runway threshold or helipad alighting point. These points may be a source defined named waypoint The recommended navaid is not required unless specified by source or if required by the leg type. The recommended navaid must be the procedure reference VOR/DME or VORTAC. Theta and Rho values must be provided from that facility in all final approach sequences where the recommended navaid is coded, including any step-down fixes. The Recommended Navaid, Theta and Rho are never provided on fixes associated with the start and end of a precision arc (RF) leg used in the final approach coding sequences. 10

52 8.7 Final Approach Path Coding RNAV Procedure This section provides coding guidelines for RNAV Approach Procedures. The terman RNAV Approach Procedure is defined as an approach procedure that was designed to provide lateral and vertical path guidance withoutusing criteria that do not relying on radials, bearings, DME arcs or glide paths from groundbased navaids. As such, an RNAV Approach Procedure will not include references to ground-based navaid associated information such as VOR radials, NDB bearings, DME distances, ILS courses, MLS Azimuths and ILS or MLS glideslopes. These Approach Procedures are designated as PBN Navigation Specifications RNP APCH or RNP AR APCH, and typically are published using a title RNAV (GPS), RNAV (GNSS), RNAV (RNP) or RNP.Exceptions to this standard may be outlined in the rules that follow. Navaids may be referenced as waypoints in the coding of the RNAV Approach Procedures Final Approach Coding must be accomplished using IF, RF and TF legs only. When the final approach coding starts with a precision arc, use an IF leg at the FACF or FAF, followed by the RF leg. This ensures compliance with the Beginning/Ending Leg Table. According to RF leg rules, at least one fix terminated approach transition to the same fix used in the IF leg of the final approach coding must be included. The track in the transition(s) must be tangent to the arc.the track from the FACF (when coded) to the FAF is coded with TF or RF legs. The RF leg is not allowed as the first leg of the approach coding according to the Beginning/Ending Leg Table. The preferred coding when an approach starts with a precision arc is the use of an IF leg at the FACF or FAF, followed by RF to the FAF or MAP. According to the rules on RF legs, this must require that a straight line, fix terminated, approach transition to the FACF or FAF has been included. The track in the transition must be tangent to the arc. The rule also does not exclude the use of an RF leg in between FAF and the final TF leg to the missed approach point. Such RF legs must be coded with the 4th character of the Waypoint Description field blank The magnetic variation required to construct path terminators must be provided in the procedure design magnetic variation field either for the procedure or as a minimum for such legs (see and 5.291).The Final Approach Coding of RNAV Approach Procedures covered by this Section 8.7 do not require a Recommended Navaid except as governed by other rules in this attachment Deleted by Supplement 23.RNAV Approach Procedures coded as GLS Procedure according to Section 5.7 must reference the GLS facility as a Recommended Navaid. 11

53 Attachment 10 Attachment 10

54 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 HELIPAD ALIGNEMENT V.1 Martin Zillig, Lufthansa Systems FlightNav SUMMARY This proposal addresses a request to be able to draw correctly oriented pads to improve situational awareness.

55 1.0 INTRODUCTION/ BACK GROUND We received a request to provide the geographical orientation of helipads so that they could be shown closer to reality and improve situational awareness when approaching a heliport. The orientation should be provided in true, meaning the angular difference between true north and the longer side for rectangular and runway shaped pads, and for square shapes, the angular difference between true north and that axis of the pad which is closer to true north. That value should be provided if provided in source or if it can be measured from other source. For circle shapes or if unknown, the field will remain blank. An additional request was to go one step further and provide the orientation of the pad identifier in reference to true north, so that the identifier can be shown according reality on a display, even for circled shaped pads. The field can be left blank if unknown. 2.0 DISCUSSION and or ACTION If the group believes an additional flag is required to indicate the source of the information, two one character fields could be added to indicate if the content originated from state source or from other sources. 2

56 3.0 Changes as depicted (Track Changes is Helpful) Airport Helipad Primary Records Column Field Name (Length) Reference 1 Record Type (1) thru 4 Customer/Area Code (3) Section Code (1) Blank (Spacing) (1) 7 thru 10 Airport or Heliport Identifier (4) thru 12 ICAO Code (2) Subsection Code (1) thru 18 Helipad Identifier (5) thru 21 Blank (Spacing) (3) 22 Continuation Record No. (1) Helipad Shape (1) thru 31 Helipad Dimension (8) Reserved (Expansion) (1) 33 thru 41 Helipad Latitude (9) thru 51 Helipad Longitude (10) Helipad Surface Code (1) thru 56 Helipad Surface Type (4) thru 59 Max Allowable Helicopter Weight (3) Helicopter Performance Requirement (1) thru 65 Reserved (Expansion) (5) 66 thru 70 Helipad Elevation (5) thru 75 Helipad Orientation (5) thru 80 Helipad Identifier Orientation (5) thru Reserved (Expansion) (5343) thru 128 File record No. (5) thru 132 Cycle Date (4)

57 Heliport Helipad Primary Records Column Field Name (Length) Reference 1 Record Type (1) thru 4 Customer/Area Code (3) Section Code (1) Blank (Spacing) (1) 7 thru 10 Heliport Identifier (4) thru 12 ICAO Code (2) Subsection Code (1) thru 18 Helipad Identifier (5) thru 21 Blank (Spacing) (3) 22 Continuation Record No. (1) Helipad Shape (1) thru 31 Helipad Dimension (8) Reserved (Expansion) (1) 33 thru 41 Helipad Latitude (9) thru 51 Helipad Longitude (10) Helipad Surface Code (1) thru 56 Helipad Surface Type (4) thru 59 Max Allowable Helicopter Weight (3) Helicopter Performance Requirment (1) thru 6665 Reserved (Expansion) (65) thru Helipad Elevation (5) thru 75 Helipad Orientation (5) thru 80 Helipad Identifier Orientation (5) thru Reserved (Expansion) (5253) thru 128 File record No. (5) thru 132 Cycle Date (4)

58 5.332 Helipad Orientation Definition/Description: This field provides the true orientation of the helipad. It defines the angular difference between true north and the longer axis of runway and rectangular shaped helipads. See table below for more information. Source/Content: The content of this field may be coded from state source or from other sources. True orientations are entered into the field in degrees, tenths of a degree and hundredths of a degree, with the decimal point suppressed. Shape Circle Square Rectangular Runway Undefined Field Content Blank The orientation of the axis closer to true north The orientation of the longer axis The orientation of the longer axis Blank The field may be blank if the orientation cannot be established. Used On: Airport Helipad and Heliport Helipad Primary Records Length: 5 characters Character Numeric Type: Examples: 35998, 27020, Helipad Identifier Orientation Definition/Description: This field provides the true orientation of the helipad identifier. It defines the angular difference between true north and the up direction of the letters and/or numbers forming the helipad identifier, i.e. a value of defines an identifier written from south to north.. Source/Content: The content of this field may be coded from state source or from other sources. True orientations are entered into the field in degrees, tenths of a degree and hundredths of a degree, with the decimal point suppressed. Shape Circle Square Rectangular Runway Undefined Field Content Blank The orientation of the axis closer to true north The orientation of the longer axis The orientation of the longer axis Blank The field may be blank if the orientation cannot be established. Used On: Airport Helipad and Heliport Helipad Primary Records Length: 5 characters Character Numeric Type: Examples: 35998, 27020,

59 6

60 Attachment 11 Attachment 11

61 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 ATN LOGON CODES V.0 Martin Zillig, Lufthansa Systems FlightNav Matthew Colburn, The Boeing Company SUMMARY Proposal: Create a new record table under Section code T with new subsection L. The new table includes ATN data table with pertinent ATN logon addresses and supporting data adapting from ICAO EUR Doc 028, Appendix A: ATN NSAP Addressing table. The proposed record schema with supporting data elements is applicable to functional applications that require ATN connectivity to the correct ATSU.

62 1.0 INTRODUCTION/ BACK GROUND For Controller-Pilot Data Link Communications (CPDLC) using Aeronautical Telecommunications Network (ATN) technology, the routing information must be provided to the avionics systems to provide the means to logon to an Air Traffic Service Unit (ATSU). Currently, CPDLC via ATN is a domestic European airspace implementation. While most ATN Logon addresses belong to ATSUs, there are some exceptions to that for testing facility and similar purposes. Therefore, all addresses are proposed for implementation in ARINC 424 named ATN Data. The ATN Data can be defined in a table format (Section code T) because the source data is in table format containing ground facility identifiers, ATN address details, and applicable FIR/UIR names. 2.0 DISCUSSION and or ACTION 3.0 Changes as depicted (Track Changes is Helpful) ATN Data Section (T), Subsection (L) The ATN Data Table should contain a listing of all ground facility logon codes along with supporting facility Address data ATN Data (ATN NSAP) Record (TL) The ATN Data record contains all ATN Ground Facility logon codes and supporting ATN Network Service Access Point (NSAP) Address data for the CPDLC system to logon to the ATSU where CPDLC is provided via ATN ATN Data Primary Records Column Field Name (Length) Reference 1 Record Type (1) thru 4 Blank (Spacing) (3) 5 Section Code (1) Subsection Code (1) thru 14 Ground Facility Identifier (8) thru 22 Reserved (Expansion) (8) 23 Continuation Record No. (1) thru 25 Authority and Format Identifier (2) thru 29 Initial Domain Identifier (4) thru 31 Version Identifier (2) thru 37 Administrative Identifier (6) thru 39 Routing Domain Format (2) thru 45 Administrative Region Selector (6) thru 49 Location Identifier (4) thru 61 System Identifier (12) thru 63 NSAP Selector (2) thru 67 CM Transport Selector (4) thru 123 Reserved (Expansion) (56) 2

63 124 thru 128 File Record No. (5) thru 132 Cycle Date (4) Subsection Code (SUB CODE) Definition/Description: The Subsection Code field defines the specific part of the database major section in which the record resides. Additionally, records that reference other records within the database use Section/Subsection Codes to make the reference, together with the record identifier. This is true for fix information in Holdings, Enroute Airways, Airport and Heliport SID/STAR/APPROACH, all kinds of Communications, Airport and Heliport MSA, Airport and Heliport TAA, Company Routes, Enroute Airway Restrictions, Preferred Routes and Alternate Records. The Section Code will define the major database section, the Subsection Code permits the exact section (file) to be identified and the fix (record) can then be located within this file. Source/Content: Table 5-1 shows the database Subsection Encoding Scheme. Used On: Length: Character Type: All records 1 character Alpha 3

64 Section Code Table 5-1 Section and Subsection Encoding Scheme Section Name Subsection Code Subsection Name A MORA S Grid MORA D Navaid Blank VHF Navaid B NDB Navaid T TACAN Duplicates E Enroute A Waypoints M Airway Markers P Holding Patterns R Airways and Routes S Special Activity Areas T Preferred Routes U Airway Restrictions V Communications H Heliport A Pads Reference Points C Terminal Waypoints D SIDs E STARs F Approach Procedures H Helipads K TAA S MSA P SBAS Path Point V Communications P Airport A Reference Points B Gates C Terminal Waypoints D SIDs E STARs F Approach Procedures G Runways H Helipads I Localizer/Glide Slope K TAA L MLS M Localizer Marker N Terminal NDB P SBAS Path Point Q GBAS Path Point R Flt Planning ARR/DEP S MSA T GLS Station V Communications R Company Routes Blank Company Routes (Master Airline File) A Alternate Records H Helicopter operation Routes (Master Helicopter File) T Tables C Cruising Tables G Geographical Reference L ATN Data V Communication Type U Airspace C Controlled Airspace F FIR/UIR R Restrictive Airspace 4

65 5.125 FIR/UIR Name Definition/Description: The FIR/UIR Name field contains the official name of the controlling agency of the FIR/UIR of which this record is an element. Source/Content: The FIR/UIR name will be derived from official publications. The areas without a specific FIR/UIR designation will be labeledlabelled NO FIR. The FIR/UIR name will be derived from coded from either State publication or from ICAO documentation when used on ATN DATA records. Used On: Length: Character Type: Examples: Ground Facility Identifier FIR/UIR and ATN Data records 25 characters Alpha/numeric ACCRA, FIR, ASUNCION FIR/UIR, NO FIR, DNEPROPETROVSK Definition/Description: The Ground Facility Identifier contains a logon code specific to the ATSU designator for ATN CPDLC service. Source/Content: The field will be coded from either State publication or from ICAO documentation. Typically, the Logon Code is the Location Indicator of the assigned ACC as published in ICAO Doc 7910 or other official documentation Used On: Length: Character Type: Examples: Authority Format Identifier (AFI) ATN Data Code Primary Records 4 or 8 characters Alphanumeric LSAZ, EDGG, EGTT, TESTLDZO Definition/Description: The Authority Format Identifier identifies the format and allocation procedures for the Initial Domain Identifier (IDI) and the format of the remainder of the NSAP Address. This field is required by ISO/IEC 8348 as an element of the Initial Domain Part (IDP) and is also part of the ISO/IEC Area Address. Source/Content: The field will be coded from either State publication or from ICAO documentation. Used On: ATN Data Code Primary Records Length: 2 characters Character Type: Numeric Examples: Initial Domain Identifier (IDI) Definition/Description: The Initial Domain Identifier is required by ISO/IEC 8348 as an element of the IDP and is also part of the ISO/IEC Area Address. Source/Content: The field will be coded from either State publication or from ICAO documentation. Used On: ATN Data Code Primary Records Length: 4 characters Character Type: Numeric Examples:

66 5.324 Version (VER) Definition/Description: The purpose of the VER field is to partition the Network Addressing Domain into a number of subordinate Addressing Domains. Source/Content: The field will be coded from either State publication or from ICAO documentation. Used On: Length: Character Type: Examples: Administration (ADM) ATN Data Code Primary Records 2 characters Alpha/numeric 01, 41, 81, C1 Definition/Description: The purpose of the ADM field is to sub-divide each of the Network Addressing Domains introduced by the VER field into a further set of subordinate Network Addressing Domains, and to permit devolved administration (i.e. address allocation) of each resulting domain to an ICAO Region, individual State, airline, or aeronautical organization. Source/Content: The field will be coded from either State publication or from ICAO documentation. Used On: Length: Character Type: Examples: Routing Domain Format (RDF) ATN Data Code Primary Records 6 characters Alpha/numeric 83474C Definition/Description: There is no absolute requirement for the remainder of the DSP in each of the above defined Network Addressing Domains to be allocated according to a co-ordinated addressing plan, or for even the same fields to exist, or the NSAP Addresses to have the same length. However, in order to encourage common equipment development, the existence, size and use of the RDF, ARS and LOC fields are specified hereunder. The reason for the existence of the RDF field is historical. Source/Content: The field will be coded from either State publication or from ICAO documentation. Typically, the field is set to 00. Used On: ATN Data Code Primary Records Length: 2 characters Character Type: Alpha/numeric Examples: Administrative Region Selector (ARS) Definition/Description: In Fixed Network Addressing Domains, the purpose of the ARS field is to distinguish Routing Domains or Routing Domains and subordinated Routing Areas respectively operated by the same State, airline or Organization. In Mobile Network Addressing Domain, the purpose of the ARS field is to identify the aircraft on which the addressed system is located. When the systems onboard an aircraft form a single Routing Domain, then the ARS field also identifies the Routing Domain. When the systems onboard an aircraft form multiple Routing Domains, then part of the LOC field is used to distinguish them. Source/Content: The field will be coded from either State publication or from ICAO documentation. 6

67 Used On: Length: Character Type: Examples: Location (LOC) ATN Data Code Primary Records 6 characters Alpha/numeric 01534E Definition/Description: In Fixed Network Addressing Domains, the purpose of the LOC field is to distinguish Routing Areas within the same Routing Domain. In Mobile Network Addressing Domains, the LOC field is used to distinguish Routing Areas within the same Mobile Routing Domain, or, when more than one Routing Domain is located on a single Aircraft, to distinguish each Routing Domain and the Routing Areas contained within them. Source/Content: The field will be coded from either State publication or from ICAO documentation. Used On: ATN Data Code Primary Records Length: 4 characters Character Type: Alpha/numeric Examples: System Identifier (SYS) Definition/Description: ISO/IEC defines the System Identifier as a variable length field which uniquely identifies an End or Intermediate System within an ISO/IEC Routing Area. Within a Routing Area, all System Identifiers are of the same length, although a Router is not able to make assumptions about the length of this field outside of its own Routing Area. Source/Content: The field will be coded from either State publication or from ICAO documentation. The field shall be right aligned and filled with the character 0 from the left. Used On: ATN Data Code Primary Records Length: 12 characters Character Type: Alpha/numeric Examples: 45532D524D53, Network Service Access Point Selector (NSEL) Definition/Description: The NSAP Selector (NSEL) field identifies the End System or Intermediate System network entity or network service user process responsible for originating or receiving Network Service Data Units (NSDUs) and is one octet in length. Source/Content: The field will be coded from either State publication or from ICAO documentation. Used On: ATN Data Code Primary Records Length: 2 characters Character Type: Alpha/numeric Examples: Context Management Transport Selector (CM TSEL) Definition/Description: The Context Management (CM) Transport Service Access Point (TSAP) Selector element (CM TSEL) which locates the Transport Service User for the CM application within the ATN System. 7

68 Source/Content: The field will be coded from either State publication or from ICAO documentation. Typically, the CM TSEL is published as 636D. Used On: Length: Character Type: Examples: ATN Data Code Primary Records 4 characters Alpha/numeric 636D 8

69 Attachment 12 Attachment 12

70 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 GLS DATA V.0 Sam Buckwalter, On Behalf of the FSEMC SUMMARY Question form the FSEMC on GLS Data

71 1.0 INTRODUCTION/ BACK GROUND Item No. Summary Title Component Part No. (Sim Mfr & Vendor) TDM/Vendor Name Year of Mfr Aircraft Type From User 1 GLS Data All Various LAT More and more aircrafts and airports support GLS approaches. The associated data are needed to simulate these approaches. For LAT s existing simulators with GLS, a cumbersome manual process has to be performed. The data for every single GLS approach have to be collected from the airports and edited manually. There is no automated update process of even notification if the data changes. It is expected that the required data for GLS approaches can automatically be read via ARINC 424 file like ILS data and any other navigational data. ARINC 424 Supplement 21 is understood to contain the required definitions. Will the FSEMC take action in case the ARINC 424 standard needs updating to fully support simulation of GLS approaches? Will data suppliers like Jeppesen, LIDO, NavBlue, etc., collect the worldwide GLS data and populate their ARINC 424 databases with them? Will operators and TDMs approach their data suppliers to get the GLS data delivered? Operators, supplier TDMs, and FSEMC comment please. 2.0 DISCUSSION and or ACTION 3.0 Changes as depicted (Track Changes is Helpful) 2

72 Attachment 13 Attachment 13

73 ARINC 424 NDB Draft 1 of Supplement 23 Proposal Location Gdansk, Poland October 9-11, 2018 FREE ROUTE AIRSPACE DESIGNATION V1.0 Stephen Moody, Jeppesen SUMMARY This proposal duplicates the Free Route Airspace (FRA) fields in the Waypoint Flight Planning Continuation Record into the VHF and NDB Flight Planning Continuation Records.

74 1.0 INTRODUCTION/ BACK GROUND We are now receiving State source that contains Free Route Airspace designations on navaids in addition to waypoints. The following is taken from a Free Route Airspace chart in the Hungary AIP. 2.0 DISCUSSION and or ACTION In order for data providers to be able to deliver the Free Route Airspace designations on VHF and NDB navaids, in addition to waypoints, the FRA Transition fields (Chapter 5, para 5.311) need to be added to the VHF and NDB Navaid Flight Planning records. 3.0 Changes as depicted (Track Changes is Helpful) 132 Character format: FIR/FRA Transition Waypoint Definition/Description: The Flight Information Region (FIR) Free Route Airspace (FRA) Waypoint columns allows designation of specific waypoint types used to enter, exit, and/or transition through FRA areas. These waypoint designations will normally be provided by host nation authorities via their AIP. 2

75 Source/Content: The field content will be derived from official government sources. The content will be selected from the table below. A waypoint may havethere may be multiple values assigned by the State airspace authority. Column Field Content Description 44 E Entry Point 45 X Exit Point 46 A Arrival Transition Point 47 D Departure Transition Point 48 I Intermediate Point 49 H Terminal Holding Point Used On: Length: Character Type: Waypoint, VHF NAVAID, and NDB NAVAID Flight Planning Continuation Records 1 Character Alpha/Numeric VHF NAVAID Flight Planning Continuation Records This Continuation Record is used to indicate the FIR and UIR within which the VHF NAVAID defined in the Primary Record is located. Column Field Name (Length) Reference 1 thru 21 Fields as on Primary Records 22 Continuation Record No. (1) Application Type (1) thru 27 FIR Identifier (4) thru 31 UIR Identifier (4) thru 43 Blank (Spacing) (12) 44 FIR/FRA Entry Point (1) FIR/FRA Exit Point (1) FRA Arrival Transition Point (1) FRA Departure Transition Point (1) 48 FRA Intermediate Point (1) FRA Terminal Holding Point (1) thru Reserved (Expansion) (8074) thru File Record No. (5) thru 132 Cycle Date (4) NDB NAVAID Flight Planning Continuation Records This Continuation Record is used to indicate the FIR and UIR within which the NDB NAVAID defined in the Primary Record is located. Columns Field Name (Length) Reference 1 thru 21 Fields as on Primary Records 22 Continuation Record No. (1) Application Type (1) thru 27 FIR Identifier (4) thru 31 UIR Identifier (4)

76 32 thru 43 Blank (Spacing) (12) 44 FIR/FRA Entry Point (1) FIR/FRA Exit Point (1) FRA Arrival Transition Point (1) 47 FRA Departure Transition Point (1) 48 FRA Intermediate Point (1) FRA Terminal Holding Point (1) thru Reserved (Expansion) (8074) thru 128 File Record No. (5) thru 132 Cycle Date (4) 5.32 XML Format: I propose adding these fields to the VOR, TACAN, and NDB Complex Types. The fields could be included in a new element called FirFraTransition. <Vor> <FirFraTransition> <isfirorfraentrypoint>{0,1}</isfirorfraentrypoint> <isfirorfraexitpoint>{0,1}</isfirorfraexitpoint> <isfraarrivaltransitionpoint>{0,1}</isfraarrivaltransitionpoint> <isfradepaturetransitionpoint>{0,1}</isfradepaturetransitionpoint> <isfraintermediatepoint>{0,1}</isfraintermediatepoint> <isfraterminalholdingpoint>{0,1}</isfraterminalholdingpoint> </FirFraTransition > </Vor> <Ndb> <FirFraTransition> <isfirorfraentrypoint>{0,1}</isfirorfraentrypoint> <isfirorfraexitpoint>{0,1}</isfirorfraexitpoint> <isfraarrivaltransitionpoint>{0,1}</isfraarrivaltransitionpoint> <isfradepaturetransitionpoint>{0,1}</isfradepaturetransitionpoint> <isfraintermediatepoint>{0,1}</isfraintermediatepoint> <isfraterminalholdingpoint>{0,1}</isfraterminalholdingpoint> </FirFraTransition > </Ndb> <Tacan> <FirFraTransition> <isfirorfraentrypoint>{0,1}</isfirorfraentrypoint> <isfirorfraexitpoint>{0,1}</isfirorfraexitpoint> <isfraarrivaltransitionpoint>{0,1}</isfraarrivaltransitionpoint> <isfradepaturetransitionpoint>{0,1}</isfradepaturetransitionpoint> <isfraintermediatepoint>{0,1}</isfraintermediatepoint> <isfraterminalholdingpoint>{0,1}</isfraterminalholdingpoint> </FirFraTransition > </Tacan> 4

77 Attachment 14 Attachment 14

78 ARINC 424 NDB Draft 1 of Supplement 23 Proposal Location Gdansk, Poland October 9-11, 2018 HELIPAD SHAPE VALUES CLEANUP V1.0 Stephen Moody, Jeppesen SUMMARY This proposal removes a duplicate Helipad Shape value from the content list.

79 1.0 INTRODUCTION/ BACK GROUND In chapter 5, paragraph Helipad Shape, there are two duplicate values for Circle in the listing. 2.0 DISCUSSION and or ACTION Remove the 2 nd Circle Helipad Shape from the listing found in chapter 5, paragraph Helipad Shape. 3.0 Changes as depicted (Track Changes is Helpful) 132 Character Format: Helipad Shape Definition/Description: The Helipad Shape field defines the geometric shape of a helipad as being either circle, runway or rectangular. Source/Content: The field contains the shape of the helipad derived from official government sources when available. The content will be selected from the table below: Field Content C S R U C Used On: Length: Character Type: Description Circle Square / Rectangle Runway Undefined, helipad shape not provided in source Circle Airport Helipad Records, Heliport Helipad Records 1 character Alpha XML Format: No changes needed. 2

80 Attachment 15 Attachment 15

81 ARINC 424 NDB Draft 1 of Supplement 23 Proposal Location Gdansk, Poland October 9-11, 2018 RUNWAY IDENTIFIERS V1.0 Stephen Moody, Jeppesen SUMMARY This proposal requests that the Runway Identifier field 5.46 be modified to allow additional 5 th character values, and adds a new XML element called runwaysuffix.

82 1.0 INTRODUCTION/ BACK GROUND Some source providers are publishing runway designators that are currently not supported in the 5.46 Runway Identifier field. These runway designators contain a character following the numeric runway numbers; such as G, W, or U. The following description is from the FAA Runway Ident section found in the FAA AC 150/ A document The following suffixes can be used in conjunction with runway identification numbers even if the runway is not painted accordingly: G = Glider Runway W = Water Sealane or Waterway U = Ultralight Runway For Example: RWY 18W/36W, etc. The following are examples of some of these characters used in source publications. KMEV Source - Runway ID = 12G/30G KMEV - Airfield Diagram 2

83 PAEN Source - Runway ID = 02W/20W PAEN - Airfield Diagram 2.0 DISCUSSION and or ACTION In order to facilitate data providers delivering the source provided runway identifiers, field 5.46 should be modified to include the additional source published 5 th character designations of W, U, and G. 3.0 Changes as depicted (Track Changes is Helpful) 132 Character format: 5.46 Runway Identifier (RUNWAY ID) Definition/Description: The Runway Identifier field identifies the runways described in runway records and runways served by the ILS/MLS described in ILS/MLS records. Source/Content: Runway identifiers are derived from official government sources and are shown in the following format: 3

84 The two letters RW are followed by two numeric, 01 thru 36, and may contain a fifth character designation of one of the following: C L R W G U Center (Runway of three parallel runways) Left (Runway of two or three parallel runways) Right (Runway of two or three parallel runways) Water Sealane or Waterway Glider Runway Ultralight Runway Any other designations (suffixes), such as North, South, East, West, True, or STOL will not be included in the ARINC 424 database file. Used On: Length: Character Type: Examples: Airport and Heliport ILS and MLS, GLS Runway, Airport and Heliport Localizer Marker, Path Point, and GLS Records. 5 characters max Alpha/numeric RW26L, RW08R, RW26C, RW05, RW02W, RW12G XML Format: I would like to add a new optional XML element called runwaysuffix that will allow the enumerations of: Water Sealane or Waterway Glider Runway Ultralight Runway This new element will be an optional element under runwayidentifier. <runwayidentifier> <runwayleftrightcentertype>{0,1}</runwayleftrightcentertype> <runwaynumber>{1,1}</runwaynumber> <runwaysuffix>{0,1}</runwaysuffix> </runwayidentifier> 4

85 Attachment 16 Attachment 16

86 AEEC NDB Meeting, Gdansk, October 9-11, 2018 ICAO IFPP Briefing Stephen Moody ICAO IFPP ARINC Member October 2018 Copyright 2018 Jeppesen. All rights reserved.

87 ICAO IFPP Briefing ICAO Instrument Flight Procedure Panel (IFPP) The IFPP is one of several ICAO Air Navigation Commission technical panels. The IFPP is tasked to develop and maintain flight procedures SARPs and guidance material (e.g., PANS- OPS, Docs 8697, 9905 and 9906 Specifically this includes: a) new instrument flight procedure (IFP) design criteria to address improvements in air navigation, evolving aircraft capabilities and new operational concepts; b) instrument flight procedure oversight requirements; c) harmonization of charting criteria, databases, and avionics systems guidance with IFP design standards and the facilitation of an efficient communication between ATC and Flight Crews; d) necessary consequential amendments to impacted Annexes and ICAO Documents as a result of changes to IFP design SARPs and criteria Copyright 2018 Jeppesen. All rights reserved. 2

88 ICAO IFPP Briefing New PBN Naming Convention Status: ICAO Doc 8168 Vol II currently states that until 30 November 2022, approach charts depicting procedures that meet the RNP APCH navigation specification criteria can be identified as RNAV(GNSS) RWYxx or RNP RWY xx. Beginning on 1 December 2022 all RNP APCH charts will be identified as RNP RWY xx. The latest ICAO Circular 353 did not change these implementation dates. It only provides the framework for a global transition plan, which includes a framework for developing a regional transition plan by the ICAO regional offices, as well as provides States with guidance on how to develop a State transition plan. If States cannot meet the 2022 dates, new dates will be proposed for Doc 8168 Vol II. Copyright 2018 Jeppesen. All rights reserved. 3

89 ICAO IFPP Briefing Copyright 2018 Jeppesen. All rights reserved. 4

90 ICAO IFPP Briefing HELICOPTER POINT-IN-SPACE (PINS) DEPARTURES FROM HELIPORTS Departure Types: PinS departure Proceed visually direct VS (Visual Segment) PinS departure Proceed visually manoeuvring VS (Visual Segment) PinS departure Proceed VFR. Early entry into IMC is allowed for PinS Proceed visually direct VS departures when there is a note on the chart stating: IMC entry prior to crossing the (IDF NAME) at or above the (IDF MCA) is permitted. Coding implications: If PinS departure Proceed visually direct VS and an early entry IMC note, the first sequence of the recommended tabular coding will have a CF leg as the first leg of the departure with the CF leg leading into the IDF. Otherwise, the departure is expected to begin with an IF leg sequence at the IDF. Copyright 2018 Jeppesen. All rights reserved. 5

91 ICAO IFPP Briefing Example ICAO chart showing the early entry IMC note Copyright 2018 Jeppesen. All rights reserved. 6

92 ICAO IFPP Briefing ATS Route Classifications In order to develop PBN charting requirements for ATS Routes (PBN Navigation Specification, etc), it was a pre-requisite to address the classification of ATS Routes in Annex 15. Clear delineation between conventional route and area navigation route attributes was needed. Since Annex 15 requires, as part of the detailed description of a route, upper and lower limits and airspace classification, this is sufficiently covered for charting and coding purposes and the previous classifications are not required. ENR 3.1 Lower Conventional ATS routes ENR 3.2 Upper ATS routes ENR 3.2 Area navigation routes ENR 3.4 Helicopter routes ENR 3.3 Other routes The Upper and Lower ATS route designation was originally used to accommodate the differences between long range VORs (for Upper) and normal VORs (for Lower). Copyright 2018 Jeppesen. All rights reserved. 7

93 ICAO IFPP Briefing VPT RNAV procedures Background: There have been several States that have implemented RNAV Visual type procedures in order to provide guidance to runways where instrument approaches could not be developed. Without ICAO criteria guidance on how to construct these procedures, there has been inconsistency in the procedures design and the aircraft requirements needed to conduct approach. A new VPT RNAV task force group was created to develop the concept and the criteria for creating RNAV Visual type procedures that would be public procedures and would leverage existing PBN Navigation Specifications and design criteria. This has proven to be a challenge. For now, the VPT RNAV group has changed focus and is working on creating and publishing a new ICAO circular that will provide guidance to States on the process to follow when developing non-standard procedures (Specials), instead of creating the design criteria for public use. I do not current see any needed updates to ARINC 424. Copyright 2018 Jeppesen. All rights reserved. 8

94 ICAO IFPP Briefing RNP AR Departure New PBN Navigation Specification is in work and is planned to be released in ICAO Doc 9613 (PBN Manual) 5 th Edition. This should be ready toward the end of Once the Doc 9613 content is finalized, the IFPP will begin work on the procedure design and charting criteria. SID and STAR transitions concept Not much progress has been made on implementing a SID/STAR transition concept within ICAO materials. A CONOPS was created, however subsequent discussions indicate that the group first needs to create a problem statement that clearly identifies the issues that the group is trying to solve. SID/STAR transitions might not be the appropriate solution to the issues Copyright 2018 Jeppesen. All rights reserved. 9

95 ICAO IFPP Briefing Coding of PBN Procedures There is an action for the next IFPP update cycle IFPP/15 to revise Doc 8168 PANS-OPS Volume II to review the currency and applicability of the coding information contained within the document. In addition, there is an action to update the document to provide additional coding guidance and the application of path terminators on PBN procedures. This includes: Allowable leg type pairings Leg type usages Better guidance for the procedure designers on populating the tabular description of PBN procedures to help eliminate mistakes RNP accuracy values Copyright 2018 Jeppesen. All rights reserved. 1

96 ICAO IFPP Briefing Charted Altitudes The following updates to how altitudes are to be charted has been approved. This update better aligns what gets charted with the altitude descriptions allowed in ARINC 424. Copyright 2018 Jeppesen. All rights reserved. 1

97 ICAO IFPP Briefing Doc 8697, Definitions Procedure altitude/height. A specified altitude/height flown operationally at or above the minimum altitude/height and established to accommodate a stabilized descent at a prescribed descent gradient/angle in the intermediate/final approach segment. A published altitude/height used in defining the vertical profile of a flight procedure, at or above the minimum obstacle clearance altitude/height where established. This new definition reflects it s use within the updated charting table: Copyright 2018 Jeppesen. All rights reserved. 1

98 ICAO IFPP Briefing PDMV Over the last few years, the ARINC 424 Procedure Design Magnetic Variation concept has been discussed within the IFPP to determine if there is a specific need to adopt a new concept for the procedures designers called PDMV. Discussions have led to the understanding that the existing magnetic variation fields used in publishing PBN procedures may be sufficient to express the required procedure magnetic information required by the ARINC 424 PDMV field. However, there should be additional guidance provided to eliminate an ambiguities that could lead to inconsistent use of the fields. Additionally, for cycle IFPP/15, we will be working on removing the recommended navaid requirements from PANS-OPS for those leg types that we will allow for PBN procedure design, i.e. CF leg. Note: Procedure designers view the use of the Course to Fix legs on PBN procedures as valuable procedure design elements. Copyright 2018 Jeppesen. All rights reserved. 1

99 Additional Items RF-TF Concurrent Operations The FAA PARC working group is creating a new action committee that will be tasked to continue the development of this new concept. The group will evaluate industry feedback and determine which method will move forward. They will also be identifying a couple of airports where the initial testing of the RF-TF Concurrent Operations will occur. Jeppesen will be actively participating in this new action committee. Copyright 2018 Jeppesen. All rights reserved. 1

100 ICAO IFPP Briefing Questions? Copyright 2018 Jeppesen. All rights reserved.

101 Attachment 17 Attachment 17

102 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 CLEAN UP OF APPROACH CODING RULES IN ATTACHMENT 5 V.1 Martin Zillig, Lufthansa Systems FlightNav SUMMARY This proposal addresses rules that are repeated in different parts of attachment 5, most notable rules in 6.x and in 8.x

103 1.0 INTRODUCTION/ BACK GROUND During writing proposals, I noticed that several rules were sometimes exactly copied in various parts of attachment 5, sometimes, however, with different wording. One example is the altitude at the FACF for LOC based approaches, were one rule says if not published in source, the lowest initial altitude will be used, in another part, it says that it will be left blank. Therefore, I tried to clean up attachment 5, approach coding rules. 2.0 DISCUSSION and or ACTION This is a short summary with most changes I propose under 3. But some might be missing here Deleted, already covered in Since it covers "multiple procedure rules" in a way, moved here Reduced rule, because altitude 2 coding for SDFs was removed Helicopter equivalent no longer needed. Final Approach Coding is defined as to stop at the MAP. Specific rules are covered in each section (Check 40nm rule) Updated language to use "must", and changed "one" to "any" to indicated that "when at least one" condition is met, an FACF must be coded. Moved the FACF or FAF must be the first fix into Integrated the rule about ending at FAF also when an FACF is coded into Changed to the FACF must be first fix when coded, else the FAF must be first fix a Updated initial altitude to final altitude, as the initial altitude could be the start of the teardrop. final altitude would describe the altitude from which the final descend begins Moved here to be in general rules from Moved to New wording Changed wording Reused for general transition recommended navaid rules, as no special rules for VOR based approach transitions are necessary Assigned a rule number. Changed wording to must Regrouped into those legs requiring the localizer, the AF requiring a VORDME and those legs allowing either Changed formatting to bold Changed formatting to bold 2

104 6.3.9 Deleted as no special rules are required for circling approaches New rules for PBN transitions Deleted, rule repeated in Deleted, rule repeated in Deleted, rule integrated into Already covered in , 6.2.9, Already covered in , Deleted, rule repeated differently in and The FACF is coded as an IF leg with an altitude assigned, based on the source document or equal to the altitude of a procedure turn or the altitude of the last transition leg The FACF is coded as an IF leg. An altitude will not be assigned to the FACF unless specified in government source documents The FACF is coded as an IF leg with an altitude only when assigned by government source Deleted, rule repeated in and Deleted, rule repeated in and Deleted, rule repeated in and Moved new and Question: Is it really applicable to non precision LOC based approaches? Moved to new All rules in 6.5 are exactly duplicated in Deleted, most rules were already included in 8.3, some rules in 8.3 were slightly adapted to fully align with 6.6, e.g. examples of VOR Coding moved to Deleted as all rules were included in different setup in Deleted. Moved example NDB coding text to new Deleted. Rules covered in 8.7. Some rules were different, please review specifically: 8.7.2, and (vs 6.9.5) 6.10 Deleted. Rules covered in 8.6, except , which I added as Deleted. Rules covered in 8.7, except the text in 6.11, which I added as text in 8.7 and as a new rule Deleted. Rules covered in 8.8 and in all other rules for specific approach types. 3

105 3.0 Changes as depicted (Track Changes is Helpful) ATTACHMENT Approach Procedure Rules Valid For All Procedure Types This section rules are applicable to all sequences for all approach procedure types, including approach transition, final approach as well as missed approach. Specific rules for precision approaches can be found in section 7, specific rules for non-precision approaches in section 8 and specific rules for missed approach coding in section 9 of this attachment. Specific rules do overrule general rules except if stated otherwise. 6.1 Multiple Approach Procedure Coding Multiple Approach Procedure Definition Approach procedures are generally named using the procedure reference facility type 1. ILS Localizer 8. RNAV (Area Navigation) 15. FMS 2. IGS Localizer 9. VOR/DME and VORTAC 16. GPS 3. LDA Localizer 10. VORTAC 17. GLS 4. SDF Localizer 11. VOR (no DME) 18. RNP 5. LOCLocalizer (Only) 12. TACAN 6. LOC BCLocalizer 13. NDB + DME Backcourse 7. MLS (all types) 14. NDB Notes: FMS, GPS, GLS, RNAV, and RNP are not facility types but rather an equipment classification. The term RNAV is used for a wide range of procedures, ranging from the legacy VOR/DME RNAV approach up to the PBN RNP AR APCH. RNAV procedures use VORDME or VORTAC navaids along with the RNAV equipment. For the purpose of these rules, RNAV is to be considered a facility type. This will allow coding of a RNAV and VORDME or VORTAC procedure to the same runway or helipad. For GPS, GLS, a GPS or GLS sensor input to the equipment is required. It is possible to have multiple RNAV-type approach procedures to the same runway due to official government source procedure designations, such as VOR/DME RNAV, RNAV VISUAL and RNAV (GPS). These procedure designations are handled according to the rules for Route Type in Section 5.7. It is also possible to have multiple RNAV Terminal Approach Procedures of the same type to the same runway, due to official government source procedure designations such as RNAV Y Rwy 27 and RNAV Z Rwy 27. These multiple procedures of the same type are handled according to the rules for Approach Procedure Idents in Section 5.10 Circle to Land minimum version of the various approach sensors are covered through the Approach Route Qualifier (see Section 5.7). Circle-To-Land is not a facility type but rather a weather minimum criteria. For the purpose of these rules, Circle-To-Land is to be considered an equal to the procedure reference facility. There are three types of MLS Approach, each with a unique Route Type. Normally, there will only be one approach referencing MLS to any given runway or helipad. 4

106 GLS provides the necessary corrections to ensure precision navigation for alignment and descent during final approach. GLS-based approaches are consequently considered precision approach procedures. For GLS-based procedures, a GNSS and GLS GBAS sensor input is required Multiple Approach Procedure Identifiers Multiple approach procedures are identified by unique procedure identifiers and unique route types (refer to Sections 5.7 and 5.10 of this specification) Multiple Approach Procedure Waypoints Multiple approach procedures to one and the same runway or helipad may require multiple Final Approach Coding waypoints of the same category such as FACF, FAF and MAP. Where such waypoints are not established with unique identifiers through source documentation, they must be created following the rules for identifiers in Section of this specification Multiple Approach Procedure Detail Specific details of approach procedures such as speed, altitudes and vertical angles are considered unique for the procedure and must be coded in those records where they apply, including duplication of such detail where appropriate Transitions in Multiple Approach Procedure CodingRule deleted by Supplement Rule deleted by Supplement 23.Approach transitions are coded to be used together with specific approach procedures. As such, a transition route must be unique to a given approach, multiple use with more than one approach cannot be coded. Transition routes required for more than one approach must be coded multiple times Rule deleted by Supplement 23.If an approach transition route is be coded multiple times, it must be coded with an identifier that is unique to the approach procedure for which it is to be used When an approach procedure serves more than one airport or heliport, the complete procedure must be coded for each airport or heliport that the procedure serves, as defined by source documentation. This situation is common for PinS approaches. 6.2 General Rules, Applicable to all Approach Route coding Altitudes used in approach route coding between the final approach course fix (FACF) and the runway or helipad or missed approach point will be coded in combination with Altitude Description Codes as detailed in Section 5.29 of this specification and in accordance with government source documents. This coding rule is intended to match the altitude publishing methods in official government sources, which may specify altitudes as minimum, maximum, mandatory, recommended, or between altitudes, defined with a minimum and a maximum altitude. These definitions include two kinds of altitudes. One is procedural altitudes information on mandatory or minimum altitudes at designated fixes along the final approach path. The other is the altitude related to the electronic Glideslope or published vertical angle with recommended altitudes. The ordering of Procedural and Glideslope altitudes in the first and second altitude fields is accomplished in accordance with Section

107 6.2.2 All fixes associated with the lateral and vertical path of approach procedures must be coded, including step-down fixes, both before and after the Final Approach Fix With the exception of the NDB + DME Approach or a Helicopter version of a NDB + DME Approach Procedure, the recommended Navaid must be the same facility for all sequences in the final approach coding, excluding the missed approach procedure sequences, which require a recommended facility. The recommended facility must be the procedure reference facility. For Approach Transitions, the recommended Navaid must be the procedure reference facility or a VORDME or VORTAC facility. When a VORDME or VORTAC is coded as the recommended Navaid in Final Approach Coding, the Navaid will be within 40 NM of the fix in which it is coded. GPS approach procedures do not include a recommended Navaid. GLS approach procedures must reference the GLS facility. For specific rules on recommended Navaid for NDB + DME Approach Procedures, see Rule b of this Attachment PI Leg Coding Requirements If a PI leg is from the FAF waypoint and the distance between the FACF and the FAF is less than 6.0 NM, code a CF leg after the PI, with the FACF as the fix in the CF. The route distance leg data field on the CF leg will be the difference between the distance coded on the PI leg and the distance between the FACF and FAF waypoints If a PI-CF coding would result in a distance between PI and CF waypoints equal to 6.0 NM or more, and the Maximum Excursion Distance (turn limit) is greater than 10 NM, then a new fix must be inserted on the outbound axis at less than 6.0 NM before the CF fix, and the PI leg must be anchored at that fix. The Maximum Excursion Distance must be modified accordingly If the procedure turn is specified by an outbound time greater than one minute, then a new fix must be inserted on the outbound axis 3.5 NM (~ 1 minute) before the turning point, assuming a ground speed of 210 knots. The PI leg must be anchored at that fix. The Maximum Excursion Distance must be modified accordingly Approach Procedure Fix Requirements: The Final Approach Coding of all instrument approach procedures must include requires the coding of a Final Approach Fix (FAF) and a Missed Approach Point Fix (MAP). The Final Approach Coding of all instrument approach procedures must include requires the coding of a Final Approach Course Fix (FACF) when one any of the following conditions applies: o The approach procedure type is ILS, LOC, SDF, LDA, IGS, or LOC Backcourse. o There is a single published fix designated as an Intermediate Fix o There is a published fix designated as a FACF o There is a published and named fix other than the FAF that is the common ending point for all transitions (except HF leg transitions, which may end at the FAF) o A transition ends in the intercept of a track rather than to a fix. 6

108 o The course or track inbound to the FAF is different than the course or track from the FAF to the MAP. This requirement will be met by the addition of data supplier created FACF waypoint as indicated in Rule o When a FACF is coded, it must be the first waypoint of the Final Approach Coding. o When a FACF is not coded, the first waypoint of the Final Approach Coding must be the FAF Transitions may end at a FAF fix regardless of whether a FACF is coded for the procedure or not. When an FACF is coded, it must be the first waypoint of the Final Approach Coding. When an FACF is not coded, the first waypoint of the Final Approach Coding must be the FAF If no waypoint is established by source documentation for the final approach course fix and one is required by the requirements in Rule 6.2.5, one must be computed by the data supplier. For Localizer based approach procedures, the computer FACF will be on the localizer course at a distance of 2 to 8NM from the Final Approach Fix (FAF). For all other approach types, the FACF will be computed on the published course to the FAF at a distance not less than 2NM to the FAF. Section 2, Subsection 2.3, Special Navigation Terms, Altitude coding for this fix is defined in Rule If no waypoint is established by source documentation for the Final Approach Fix (FAF), one must be computed a b For non-precision approach procedures such as VOR or NDB, one must be computed on the final approach course, using the initial final approach altitude and the vertical descent angle (source or computed). The minimum distance between the FAF and the runway threshold or helipad alighting point (or MAP) will be 4 nautical miles. For precision based approach procedures, establish the FAF, when none is provided by source, at the nominal outer marker position. If no nominal outer marker position is published in source, use the glide slope intercept position Except as indicated by specific rules within this Attachment, the source provide published Missed Approach Point (MAP) is always coded as part of the approach procedure. This MAP may be a runway threshold (Landing Threshold Point, LTP), a helipad alighting point or a dedicated missed approach point fix. The published missed approach point may be replaced by a database provider established fix when it can be determined that the published fix was intended to be the runway threshold or helipad alighting point. For more detail, see section 8.10 of this Attachment In general, the design of missed approach procedures requires that the runway, helipad or missed approach point be overflown prior to commencing any turn. In these cases, to ensure procedure coding reflects design specific intentions, the Overfly Indication must be coded into the Waypoint Description field. However, certain types of approach procedures design do require a turn prior to the runway, helipad or missed approach point. In these cases, to ensure procedure coding reflects design specific intentions, the Overfly Indication will not be set in the Waypoint Description field of the appropriate record Removed by Supplement 19. 7

109 6.2.7 Removed by Supplement Intentionally left blank Lateral Coding Rules All approach procedure coding must be to the published Missed Approach Point, as indicated below. Missed Approach Procedure coding must begin at that point. For missed approach procedure coding, refer to Section Nine of this Attachment. For the rules that follow, the term runway threshold is meant to refer either to the Landing Threshold Point (LTP) of an actual runway or to a Fictitious Threshold Point (FTP) when the procedure is coded to a helipad If the published Missed Approach Point is a fix prior to the runway threshold, lateral coding is to that published Missed Approach Point If the published Missed Approach Point is the runway threshold, lateral coding is to the runway threshold as the published Missed Approach Point If the published missed approach point is beyond the runway threshold and the runway threshold will be coded as a fix in the lateral path that fix will be on the established path, with no course changes If the published Missed Approach Point is beyond the runway threshold and a runway threshold fix cannot be inserted as defined in Rule 8.10, a Final End Point fix is to be inserted into the final approach coding sequence. For complete details, see Rule If the published Missed Approach Point is abeam the runway threshold, lateral coding must be to the published Missed Approach Point. Refer to the Examples 1 through 15 at the end of this section for a visual depiction of these rules For Point-in-Space approaches, lateral coding is to that published Missed Approach Point and does end at this point. Descent Points will not be coded Vertical Coding Rules, Procedure Fix Altitudes Vertical Approach Procedure Coding is provided through two elements, Procedure Fix Altitudes and a Vertical Angle. This section covers the general Fix Altitude rules. Sections 7 and 8 cover the specific Fix Altitude and Vertical Angle rules for Precision and Non-Precision Approach Procedures Procedure Fix Altitudes, Final Approach Course Fix and Final Approach Fix. Procedure Fix Altitudes for the Final Approach Course Fix will be coded according to official government sources and will be left blank when no altitude data is provided by the source. When coded, these altitudes will be assigned altitude descriptions codes indicating the altitude as mandatory, minimum or recommended between (see Section 5.29 of this specification). When the coded Final Approach Fix is established by the government source procedure data, the altitudes for this fix will also be coded according to official government sources. These altitudes will be assigned altitude descriptions codes indicating the altitude as mandatory, minimum or recommended between (see Section 5.29 of this specification). For government supplied altitude data, both Altitude 1 and Altitude 2 may be provided. If the Final Approach Fix is as an established fix rather than a published fix and no altitude for this location is published in government source, the altitude 8

110 for this fix must be computed using the procedures detailed in Sections 7 and 8 of this Attachment. For calculated altitude data, only Altitude 1 will be provided Procedure Fix Altitudes for the published Missed Approach Point, a runway threshold fix prior to the published Missed Approach Point or a Final End Point prior to the Missed Approach Point must be as indicated below a b c d e f For a published Missed Approach Point prior to the runway threshold, an at altitude equal to the computed altitude at the published Missed Approach Point must be coded in Altitude 1. (See example 7) For a published Missed Approach Point at the runway threshold, an at altitude equal to the runway threshold elevation plus the published TCH must be coded in Altitude 1. If no procedure TCH is specified by source, then use 40 or 50 feet (See Section 5.67of this standard). For a published Missed Approach Point beyond the runway threshold and where a landing threshold point fix has been inserted into the final approach coding by the data supplier, based on the rules in Rule 8.10 of this Attachment, code an at altitude equal to the runway threshold elevation plus the published TCH (if no procedure TCH is specified by source, then use 40 or 50 feet) in Altitude 1 of the landing threshold point fix record. See Rule 8.10 of this attachment. For a published Missed Approach Point beyond the runway threshold and where a final end point fix has been inserted into the final approach coding by the data supplier, based on the rules in Rule 8.10 of this Attachment, code an at altitude equal to the runway threshold elevation plus the published TCH (if no procedure TCH is specified by source, then use 40 or 50 feet) in Altitude 1 of the final end point fix record. See also Rule 8.10 of this attachment. For a published Missed Approach Point abeam the runway threshold, code the altitude equal to the runway threshold elevation plus the published TCH. If no TCH is specified by source, then use 40 or 50 feet (See Section 5.67of this standard). For a published Missed Approach Point located at a Point-in-Space, and at an altitude equal to the source provided, Obstacle Clearance Altitude (OCA) or Minimum Descent Altitude/Decision Altitude (MDA/DA) must be coded in Altitude Step down fixes will have altitude codes according to the government source documentation. These altitudes will be assigned altitude descriptions codes indicating the altitude as mandatory, minimum, maximum or recommended betweenand altitudes on the vertical path (see Section 5.29 of this specification). Both Altitude 1 and Altitude 2 will be used on step-down fixes For RF Leg Fixes not at Procedure Fix locations, Waypoint Description Code, 3rd position of R, will have altitudes coded according to government source documentation. If no altitude information is provided for these fixes in source data, Altitude 1 and 2 will be left blank Vertical angle information is in Section 7 and 8 of Attachment 5 in this document Rule deleted by Supplement 23.Missed Approach Point In general, the design of missed approach procedures requires that the runway, helipad or missed approach point be overflown prior to commencing any turn. In these cases, to ensure procedure coding reflects design specific intentions, the Overfly Indication must be coded into the Waypoint Description field. However, certain 9

111 types of approach procedures design do require a turn prior to the runway, helipad or missed approach point. In these cases, to ensure procedure coding reflects design specific intentions, the Overfly Indication will not be set in the Waypoint Description field of the appropriate record. 6.3 Approach Transition Route Coding Rules When an approach transition ends at a fix, this fix must be the FACF or the FAF of the final approach. Ending at the FAF is allowed regardless if the final approach has an FACF or not. An approach transition ending with an HF leg which is based on a fix other than the FACF or the FAF must be substituted by a series of legs representing the original flight path and ending with a CF or TF leg at the FACF or the FAF. If this rule cannot be followed, e.g. the transition would end at the missed approach point or a step-down fix, the transition must be omitted.recommended coding on approach transitions that end in leg to fix (XF) is that the fix in the ending leg must be either the Final Approach Course Fix or the Final Approach Fix. If this is not the case, for example HF leg type transitions on fixes off-set from the final approach path, a series of legs must be substituted representing the original flight path, but ending with a CF or TF 1 leg type to one of these two fixes. If neither of these two coding recommendations can be followed, such as in cases where the XF would terminate at the missed approach waypoint or a step-down fix not associated with the lateral guidance of the final approach, the transition must be omitted When a holding pattern used for course reversal or a procedure turn is part of an approach route, it will be included in an approach transition route If an approach transition for a specific runway, or helipad or PinS is common to more than one approach, that transition must be coded for each approach, with a transition identifier that must correspond to the approach procedure identifier Rule Deleted by Supplement Recommended Navaid requirementstransitions of VOR based approach procedures, TACAN based approach procedures, and RNAV (VOR DME) approach procedures Any recommended navaid used in coding must be a VOR, VORDME, VORTAC, TACAN, DME, NDB or Un-Biased ILS/ DME, see Section 5.23 of this document. Special rules for ending legs for transition to certain procedure type are covered in rules , and Transitions for Localizer Based Approach Procedures TransitionsThe ending leg of for all localizer-based transitions procedures will must either End at the FACF (AF, CF, RF, TF, HF, HM) End in an intercept of the localizer inside the FACF (PI, CI or VI) End in a course reversal, normally at the FAF (HF, HM) The ending leg of all localizer-based transitions will contain a recommended Navaid: 1 In general CF legs are used in final approach coding. TF legs are used in FMS and GPS Approach Procedures, some types of MLS Procedures and in other procedure types where the determination has been made that a TF will work better than a CF. 10

112 For If CF, RF, TF, CI or and VI legs, the recommended Navaid will must be the procedure reference localizer ForIf AF, HF, HM or PI legs, the recommended Navaid will must be a VORDME, or VORTAC or TACAN ForThe HF, HM and PI legs, the recommended Navaid may usewill be the procedure reference localizer, when a VORDME, a VORTAC or a TACAN is not available Deleted by Supplement Legs ending in an intercept will ideally be at angles of 30 degrees to the track intercepted. Angles greater than 10 degrees may be coded as required by source documentation, provided the resulting intercept is within the reception area of the localizer. Intercept angles greater than 90 degrees must have a distance between the FACF and FAF that is at or greater than 4 NM When a CF leg is used as the ending leg of a transition to a localizer-based procedure, the maximum leg distance will be within 8NM of the FACF or within the reception area of the localizer as depicted in Figure A Note: For precision approaches relying on an electronic glideslope, an FC/CF is preferred over a TF as illustrated in Figure A5-6-1 for those legs ending at a fix. CF LEG 8 MILES OR LESS FACF 4 Miles or Less Figure A5-6-1 CF Leg When a CI or VI leg is used as the ending leg of a transition to a localizer-based procedure, the intercept will be between the FACF and the FAF, at no less than 2 NM to the FAF Transitions for NDB Based Approach Procedures Transitions for NDB Based Approach Procedures: Transitions for NDB based approach procedures may use a NDB Navaid as the recommended Navaid, except for transitions that are DME Arcs Transitions for MLS/GLS Approach ProceduresTransitions for MLS/GLS Approach Procedures: MLS/GLS approach procedure coding is such that the rules can be identical to those used for Localizer based procedure coding. See Rule above Rule deleted by Supplement 23.Transitions for Circle-To-Land Approach Procedures 11

113 Rule deleted by Supplement 23.If the Circle-To-Land approach procedure is runway or helipad dependent, the rules on transition route coding are identical to those of the reference facility procedure type, e.g. for a VOR Circle-To-Land that is runway dependent, follow the VOR based approach procedure rules for approach transition route coding Rule deleted by Supplement 23.If the Circle-To-Land approach procedure is not runway or helipad dependent, being valid for more than one landing direction, the rules for coding approach transitions routes are as follows Rule deleted by Supplement 23.Recommended navaids used in coding all legs except ending legs must be a VOR, VORDME, VORTAC, TACAN, DME or Un- Biased ILSDME. For the ending leg sequences, the recommended navaid, where required, must be the procedure reference facility, see Section 5.23 of this document PBN Transitions to non PBN Approach Procedures PBN Transitions will be coded without recommended navaid with the exception of the ending leg for localizer based approach transitions The magnetic variation required to construct path terminators will be provided in the procedure design magnetic variation field either for the procedure or as a minimum for such legs (see and 5.291), with the exception of the ending leg for localizer based approach transitions. 6.4 Rule deleted by Supplement 23.Localizer Based Approach Procedure Coding Rule deleted by Supplement 23.The following rules apply to the Final Approach Coding of Localizer-based approach procedures. These procedures may include Full ILS (Localizer and Glideslope), Localizer Only, Localizer Backcourse, Instrument Guidance System (IGS), Localizer Directional Aid (LDA) and Simplified Directional (SDF) procedures Rule deleted by Supplement 23.All Localizer based approach procedures must begin at the FACF. They must consist of a FACF, FAF, and missed approach point (MAP) Rule deleted by Supplement 23.For precision approach, the missed approach point will be a runway fix (landing threshold) unless otherwise indicated in government source documents. When a MAP is not provided by source and the published missed approach procedure requires a turn prior to the landing threshold, the missed approach point must be created on the glideslope at the highest published Decision Altitude Rule deleted by Supplement 23.For non-precision approach the source supplied missed approach point is to be used Rule deleted by Supplement 23.The FACF is defined as a fix located on the localizer beam center, 8NM or less from the FAF or within the reception range of the Localizer. This may be a source document provided fix or a fix created using these positioning rules Rule deleted by Supplement 23.The FACF is coded as an IF leg with an altitude assigned, based on the source document or equal to the altitude of a procedure turn or the altitude of the last transition leg. 12

114 Rule deleted by Supplement 23.The track from the FACF to the FAF is coded as a CF or a TF leg with altitude constraints as indicated for the specific procedure types below Rule deleted by Supplement 23.The recommended navaid will be the procedure reference localizer. Theta and Rho will be provided from the localizer for each sequence of the final approach, including the runway fix and/or missed approach point Rule deleted by Supplement 23.The Outbound Magnetic Course field in all sequences will be equal to the localizer magnetic bearing, rounded to the nearest whole degree, derived from official government source Rule deleted by Supplement 23.No Localizer based approach procedure may include a Final End Point Fix (FEP). For this reason, the Rules , , c, d do not apply Rule deleted by Supplement 23.Full ILS (Localizer and Glideslope) Precision Approach Procedure Rule deleted by Supplement 23.For full ILS procedures and GLS procedures, code the glideslope intercept altitude in the altitude 2 field of the FAF records, Rule removed in Supplement Rule deleted by Supplement 23.MLS Approach Procedure Coding MLS Approach Procedures utilizing raw azimuth and elevation data will be coded as localizer equivalent. The rules applied for the Final Approach Coding must be identical with those stated in Section 6.4 of this attachment. The Route Type of such procedures will be coded as M. Approach procedures predicated on the use of MLS Area Navigation (MLS/RNAV) will be coded with a W or Y described below. There are three types of MLS/RNAV approaches, listed in increasing level of complexity, computed lateral/raw vertical guidance, computer lateral and vertical guidance and curved path Rule deleted by Supplement 23.Approaches using computed lateral path and raw vertical path guidance, also referred to as Type A, will be used primarily where the MLS azimuth transmitter cannot be located on the extended runway centerline, but the elevation transmitter is sited normally abeam the touchdown point. All legs will be straight and aligned with the inbound course. There will be codes with Route Type W in column 20 of the primary approach record. Path definition will be the equivalent of a full ILS approach (Rule 6.4.2) with the exception that the leg from the PFAF inbound will be a TF leg, terminating at the runway waypoint, with the published final approach source in the Outbound Magnetic Course field. The PFAF will be coded as the Final Approach Fix in the Waypoint Description field and the first fix prior to the PFAF will be coded as the Final Approach Course Fix Rule deleted by Supplement 23.Approach using computed lateral and vertical guidance by no curved legs, also referred to as Type B, will be coded as Route Type Y in column 20 of the primary approach record. All legs will be straight and aligned with the inbound course. Path definition will be the equivalent of the full ILS approach (Rule 6.4.2) with the exception that the leg from the PFAF inbound will be a TF leg, with the published final approach course in the Outbound Magnetic Course field. The altitude of the PFAF and all waypoints inbound from it will be the glide path altitude at that point. The PFAF will be coded as the Final Approach Fix 13

115 in Waypoint Description field and the first fix prior to the PFAF will be coded as the Final Approach Course Fix Rule deleted by Supplement 23.MLS/RNAV approaches using curved legs, also referred to as Type C, will be used for a variety of reasons, including parallel sidestep approaches, separation of different categories of aircraft, noise abatement, etc. These will always be precision approaches. They will be coded a with a Route type of Y in column 20 of the primary approach record. The following rules apply: Rule deleted by Supplement 23.The first leg of an MLS/RNAV approach with curved legs will be an IF/TF leg combination. All other straight legs will be coded as TF legs. All TF legs in an MLS/RNAV with curved legs procedure will have the published course included in the Outbound Magnetic Course field Rule deleted by Supplement 23.All curved legs will be coded as RF legs. Every leg preceding or following an RF leg will be tangent to the RF leg at that point Rule deleted by Supplement 23.The initial portion of a MLS/RNAV approach with curved legs may be an IF/RF combination provided a straight leg approach transition is coded to the point in the IF and the rules in Section are complied with Rule deleted by Supplement 23.The PFAF will be coded as the Final Approach Fix in the Waypoint Description field and the first fix prior to the PFAF will be coded as the Final Approach Course Fix. If there is not a fix at the glide path intercept, then the first fix after the intercept will be the PFAF. There must be one and only one PFAF for each MLS/RNAV approach with curved legs Rule deleted by Supplement 23.The last leg of an approach transition prior to an MLS/RNAV approach will be one of the following types CF, CI, HF, PI, RF or TF, except as indicated in Section If the leg type is CF, CI, RF or TF, then the Recommended Navaid will contain the identifier of the MLS used for the approach. If the leg type is PI or HF, then the Recommended Navaid will contain the VHF Navaid the defines the PI or HF leg Rule deleted by Supplement 23.If the last leg prior to the approach is a CI leg, the intercept angle will be 30 degrees or less, and the intercept point will be between the first and second terminator fixes in the approach, but no closer that 2NM to the second fix Rule deleted by Supplement 23.The PFAF altitudes will be coded according to the rules outlined for Precision Approach Procedures in Rule Rule deleted by Supplement 23.The PFAF will be used in precision MLS/RNAV approaches. It is defined as that fix along the lateral path where the published barometric altitude intercepts the glideslope. Prior to the PFAF, the aircraft is expected to fly barometric altitude to intercept the glide path. All waypoints up to the PFAF should be coded using the published barometric crossing altitude. The PFAF and all waypoints after it should be coded using the true altitude of the glide path at those points. 6.6 Rule deleted by Supplement 23.VOR, VORDME, VORTAC, and Area Navigation Approach Procedure Coding The following rules apply to the Final Approach Coding of all VOR based approach procedures, regardless of the reference facility type, and to RNAV (VOR DME) Approach Procedures. 14

116 6.6.1 Rule deleted by Supplement 23.Reference Facility Specific Rules The following rules apply to the Final Approach Coding of specific reference facility VOR based approach procedures Rule deleted by Supplement 23.When the reference facility is VOR only or there is no DME collocated with VOR (see VOR coding examples 1, 3 and 8), the following applies: a b c Rule deleted by Supplement 23.Final Approach Coding will be accomplished using IF and CF or TF legs only. Rule deleted by Supplement 23.Final Approach Coding must include either a FAF and a runway fix or FAF and missed approach point fix. Rule deleted by Supplement 23.The recommended navaid will be the procedure reference VOR. Theta values will be provided from that facility in all Final Approach Coding sequences Rule deleted by Supplement 23.When the reference facility is VORDME or VORTAC (see VOR coding examples 2 and 6), the following applies: a b c Rule deleted by Supplement 23.Final Approach Coding will be accomplished using IF and CF or TF legs only. Rule deleted by Supplement 23.Final Approach Coding must include FAF and either a runway fix or missed approach point fix. The Final Approach Coding will include a FACF when one is required by Rule Rule deleted by Supplement 23.The recommended navaid will be the procedure reference VORDME or VORTAC. Theta and Rho values will be provided from that facility in all Final Approach Coding sequences Rule deleted by Supplement 23.Examples of VOR Coding Rule deleted by Supplement 23.Example of missed approach point before the runway threshold, refer to VOR coding examples 7 and Rule deleted by Supplement 23.Example of missed approach point at the runway threshold, refer to VOR coding example 1 and Rule deleted by Supplement 23.Example of missed approach point beyond the runway threshold and the final course passes over the runway threshold, refer to VOR coding examples 3 and Rule deleted by Supplement 23.Example of missed approach point beyond the runway threshold and the final approach course does not cross runway threshold, refer to VOR coding examples 5 and Rule deleted by Supplement 23.RNAV- Area Navigation Procedures RNAV-Area Navigation procedures in the context of this attachment are the so called RNAV Procedures that require referencing ground based navigational aids. These procedures are also referred to as VOR DME RNAV Procedures Rule deleted by Supplement 23.All RNAV- Area Navigation approach procedures will be coded to a runway threshold or a Fictitious Threshold Point (FTP) as the last leg in the Final Approach Coding sequence. The runway threshold or FTP may be a source defined name waypoint Rule deleted by Supplement 23.The recommended navaid for VORDME RNAV approaches will be the procedure VORDME or VORTAC. Theta and Rho values will be provided from that facility in all Final Approach Coding sequences. 15

117 Rule deleted by Supplement 23.Final Approach Coding will be accomplished using IF and CF or TF legs only. RF legs may be used in RNAV approaches when and where specified by source documentation Rule deleted by Supplement 23.Final Approach Coding must include either a FAF and a runway fix or FAF and missed approach point fix Rule deleted by Supplement 23.For RNAV Approach procedures to a Point-in- Space, a separate procedure must be coded for each Airport or Heliport that the procedure serves, as defined by source documentation. 6.7 Rule deleted by Supplement 23.TACAN Approach Procedure Coding The following rules apply to the Final Approach Coding of all TACAN based approach procedures, regardless of the reference facility type Rule deleted by Supplement 23.Final Approach Coding will be accomplished using IF and CF or TF legs only Rule deleted by Supplement 23.Final Approach Coding must include, FAF and either a Runway Fix or Missed Approach Point Fix. The Final Approach Coding must also include a FACF when one is required by the rules in Deleted by Supplement Rule Deleted by Supplement Rule deleted by Supplement 23.The Recommended Navaid will be the procedure reference TACAN or VORTAC.Theta and Rho values will be provided from that facility in all Final Approach Coding sequences Rule deleted by Supplement 23.Vertical Angle Rules Vertical angle will be coded per the Rules in Section Rule deleted by Supplement 23.NDB Approach Procedure Coding The following rules apply to the Final Approach Coding of all NDB based approach procedures. NDB based approach procedures include procedures using a NDB or Locator as the reference facility and procedures using a NDB or Locator and a DME (NDB + DME) as reference facilities. NDB approach procedures not requiring DME but using the DME for reduced minimums will be coded as NDB with DME required D in Qualifier Rule deleted by Supplement 23.Specific Reference Facility Rules The following rules apply to the Final Approach Coding of specific reference facility NDB based approach procedures Rule deleted by Supplement 23.NDB Final Approach Coding must include at least FAF and a runway fix or missed approach point fix a Rule deleted by Supplement Rule deleted by Supplement 23.NDB + DME Final Approach Coding must include an FAF and runway fix or missed approach point fix. The Final Approach Coding will include a FACF when one is required by Rule Rule deleted by Supplement 23.Final Approach Coding will be accomplished use IF and CF or TF legs through to the runway fix or missed approach point fix. The IF leg will be at the FAF or at the FACF when one is coded Rule deleted by Supplement 23.Recommended Navaid Requirements 16

118 a b Rule deleted by Supplement 23.On NDB Procedures Final Approach Coding, the recommended navaid information will be provided on the FACF (where coded), the FAF and the Missed Approach Fix record. It will be the procedure reference NDB or Locator. Theta and Rho information will not be provided on any sequence. Rule deleted by Supplement 23.On NDB + DME procedures Final Approach Coding, the recommended navaid information will be provided on all sequences. On the FACF (when coded) and FAF, this navaid will be the procedure reference NDB or Locator. On the runway fix or missed approach point fix, the recommended navaid will be the procedure reference DME. A procedure reference DME may be any navaid with DME, including unbiased ILSDMEs. The Theta and Rho information will not be provided in any sequence of the NDB + DME final approach except in the runway fix or missed approach point fix sequence. That sequence will include Rho information from the procedure reference DME Navaid Rule deleted by Supplement 23.Examples of NDB Coding Rule deleted by Supplement 23.Example of missed approach point before the runway threshold, refer to NDB coding example Rule deleted by Supplement 23.Example of missed approach point at the runway threshold, refer to NDB coding example Rule deleted by Supplement 23.Example of missed approach point beyond the runway threshold and the final course passes over the runway threshold, refer to NDB coding example Rule deleted by Supplement 23.Example of missed approach point beyond the runway threshold and the final approach course does not cross runway threshold, refer to NDB coding example Rule deleted by Supplement 23.RNAV Procedure Coding This section provides coding guidelines for RNAV Approach Procedures. The term RNAV Approach Procedure is defined as an approach procedure that was designed to provide lateral and vertical path guidance using criteria that do not rely on radial, bearing, arcs or glide paths from ground-based navaids. As such, a RNAV Approach Procedure will not include references to ground-based navaid associated information such as VOR radial, NDB bearings, DME distances, ILS course, MLS Azimuth and ILS or MLS glideslopes. Exceptions to this standard may be outlined in the rules that follow. Navaids may be referenced as waypoints in the coding of the RNAV Approach Procedures Rule deleted by Supplement 23.Recommended Navaids RNAV Approach Procedures do not require referencing a specific ground-based navaid. The exception to this rule is that in those cases where the official government source a specified a Path and Termination (leg type) that requires a Recommended Navaid (see Table 1.5, Leg Data Fields), the navaid will be included in the coding of the RNAV Approach Procedure as a Recommended Navaid. Including a Recommended Navaid does not imply that this navaid is required to be used in the navigation solution Rule deleted by Supplement 23.The Final Approach Coding must include a Final Approach Fix (FAF) and a Missed Approach Point fix (Runway Threshold or Missed Approach Point). The Final Approach Coding must include a Final 17

119 Approach Course Fix (FACF when such a fix is required by the rules in Section Rule deleted by Supplement 23.The Final Approach Coding of RNAV Approach Procedures covered by this Section 6.9 do not require a Recommended Navaid except as governed by other rules in this attachment Rule deleted by Supplement 23.RNAV Approach Procedures coded as GLS Procedure according to Section 5.7 must reference the GLS facility as a Recommended Navaid Rule deleted by Supplement 23.The track from the FACF (when coded) to the FAF and the FAF to MAP must be coded as TF or RF legs. The RF leg is not allowed as the first leg of the Final Approach Coding according to the Beginning/Ending Leg Table. The preferred coding when an approach starts with a precision arc is IF at the (FACF), followed by RF to the FAF Rule deleted by Supplement 23.Coding of Approach Procedures with Circle-To-Land Minimums Rule deleted by Supplement 23.Any source provided approach procedure with circle-to-land minimums may be coded, regardless of sensor type through correct application of Route Type and Qualifier, see Section 5.7 of this specification Rule deleted by Supplement 23.Approach Procedures with circle-to-land minimums may include the runway designation in the procedure identifier when the straight-in alignment criteria are met or may be a unique identifier indicating non-straight-in alignment of the final approach course. See Section 5.10 of this specification Rule deleted by Supplement 23.Approach Procedures with circle-to-land minimums that meet straight-in alignment criteria and include the runway designation in the procedure identifier are coded following the same rules sets found elsewhere in this attachment for the appropriate sensor type Rule deleted by Supplement 23.Approach Procedures with circle-to-land minimums that do not meet straight-in alignment criteria and use the unique procedure identifiers without runway designation will be coded using the rule set defined in Rule of this attachment Rule deleted by Supplement 23.If a runway is in alignment, the first altitude field in the missed approach point fix record will be coded as the LTP elevation + published TCH (if no procedure TCH is specified by source use 40 or 50 feet. See Section 5.67 of this specification Rule deleted by Supplement 23.Coding Rules, Approach Procedures, Circle- To-Land Minimums, Non-straight-in Alignment Rule deleted by Supplement 23.The final approach coding must include a FAF and a Missed Approach Point Fix Rule deleted by Supplement 23.If no runway is specified, the altitude 1 field in the missed approach point fix record will be coded with the airport elevation Rule deleted by Supplement 23.Altitude constraints and vertical angles will be coded as indicated in Section 8 of this attachment, specifically Rules 8.6.4, 8.9.3, and Rule deleted by Supplement 23.Final approach segment coding will use IF and CF or TF legs only. 18

120 6.11 Rule deleted by Supplement 23.Lateral Guidance Rules For FMS and GPS procedures, a missed approach point beyond the runway is not allowed, therefore Rules , , , c, d, and e do not apply Rule deleted by Supplement 23.The track from the FACF to the FAF, where an FACF exists, is coded with TF or RF legs. The RF leg is not allowed as the first leg of the approach coding according to the Beginning/Ending Leg Table. The preferred coding when an approach starts with a precision arc is IF at the FACF, followed by RF to the FAF Rule deleted by Supplement 23.The track from the FACF to the FAF, where an FACF exists, is coded with TF or RF legs. The RF leg is not allowed as the first leg of the approach coding according to the Beginning/Ending Leg Table. The preferred coding when an approach starts with a precision arc is IF at the FACF, followed by RF to the FAF. According to the rules on RF legs, this will require that a straight line, fix terminated approach transition to the FACF has been included. The track in the transition must be tangent to the arc and the fix at the end of the transition must be overflown. The rule also does not exclude the use of an RF leg in between FAF and the final TF leg of the approach. Such RF legs will be coded with the 4 th character of the Waypoint Description field blank Rule deleted by Supplement 23.Helicopter Procedure Coding The following rules apply to the Final Approach Coding of of all Helicopter Approach Procedure. These rules cover Helicopter Approach Procedures which may be coded to Airports and Runways included in Sub-sections PA and PG only Rule deleted by Supplement 23.Helicopter Approach Procedures will be coded using the rules in Section 6 of this attachment, appropriate to the type of sensor required for the procedure, such as VORDME or ILS or RNAV- Area Navigation. This includes rules for Recommended Navaid, FACF requirements and leg types Rule deleted by Supplement 23.The Lateral Path Rules for the sensor related procedure coding reference a runway fix as a missed approach point or a missed approach point. Those same rules apply to helicopter procedures. For procedures designed with a dedicated helipad as the missed approach point, a Terminal Waypoint will be established and used as the missed approach point fix Rule deleted by Supplement 23.The Vertical Path Rules in Section 6 apply without exception, using the rules appropriate for the sensor type Rule deleted by Supplement 23.Missed Approach code will be accomplished according to the rule in Section 7 of this attachment, appropriate for the sensor type. 19

121 APPROACH AND APPROACH TRANSITION CODING RULES 7.0 Precision Approach Procedure Coding 7.1 Final Approach Segment The following rules apply to the Final Approach Coding of full ILS Localizer based approach procedures. These procedures may include full ILS (localizer and GS), converging ILS, and those IGS (Instrument Guidance System) that are full ILS equivalent. These rules will be applied to the final approach coding of LDA and SDF procedures when those procedures include reference to an electronic glideslope, GLS and to all types of MLS Approach Procedures All such approach procedures must begin at the FACF. They must consist of a FACF, FAF and missed approach point fix and all step-down fixes published in the vertical path. The missed approach point will be a runway fix (landing threshold) unless otherwise indicated in government source documents. When a MAP is not provided by source and the published missed approach procedure requires a turn prior to the landing threshold, the missed approach point must be created on the glideslope at the highest published Decision Altitude For localizer based procedures, the FACF is defined as a fix located on the localizer beam center, 8NM or less from the FAF or within the reception range of the Localizer. This may be a source document provided fix or a fix created using these positioning rules The FACF is coded as an IF leg. An altitude will not be assigned to the FACF unless specified in government source documents. The FACF is coded as an IF leg with an altitude assigned, based on the source document or equal to the altitude of a procedure turn or the altitude of the last transition leg The track from the FACF to the FAF is coded as a CF or TF leg with altitude constraints as indicated for the specific procedure types below The recommended navaid must be the procedure reference localizer. Theta and Rho must be provided from that navaid for each sequence of the Final Approach Coding, including any step-down fixes, the runway or helipad fix and/or missed approach point The Outbound Magnetic Course field in all sequences must be equal to the localizer magnetic bearing or MLS course, derived from official government source For approach procedures with an electronic glideslope, the vertical angle must be coded in both the Final Approach Fix and the fix, which carries the missed approach point coding, except when the altitude 1 and altitude 2 at the FAF are identical, in which case the vertical angle is omitted on the FAF. The FAF record carries the Final Approach Fix waypoint description code of F in position four of that field. The missed approach point fix carries the waypoint description code of M in this position four. The vertical angle will be the published glideslope angle for the installation or procedure No precision approach procedure may include a Final End Point Fix (FEP). For this reason, the Rules , , c, d do not apply For full ILS procedures and GLS procedures, the glideslope intercept altitude must be coded in the altitude 2 field of the FAF record. 20

122 7.3 GLS Precision Approach Procedure Coding The rules for coding GLS Approach Procedures are understood to be identical to those of Localizer coding as found in Section 7.1 of this attachment with the exception listed below The Final Approach Coding of GLS Instrument Approach Procedures does not require the coding of a FACF waypoint The track from the FACF to the FAF, when a FACF is coded, will be coded as a TF leg with altitude constraints as indicated for the specific procedure types below The recommended navaid must be the procedure reference ground station The Outbound Magnetic Course field in all sequences must be equal to the course derived from official government source The lateral and vertical leg data coding from the FAF inbound will be in accordance with the data contained in the GLS Path Point Record. 7.4 MLS Approach Procedure Coding MLS Approach Procedure Code utilizing raw azimuth and elevation data is limited to those procedures that are designed as a localizer equivalent. If such a procedure is coded, the rules for the Final Approach Coding are to be identical with those stated in Rule 7.1 above. The Route Type of such approaches must be coded as M in column 20 of the primary approach record. Approach procedures predicated on the use of MLS Area Navigation (MLS/RNAV) must be coded with a W or Y in column 20 of the primary approach record. MLS/RNAV approaches are coded as described below. There are three types of MLS/RNAV approach, listed in increasing levels of complexity, computed lateral/raw vertical guidance, computed lateral and vertical guidance and curved path Approaches using computed lateral path and raw vertical path guidance, also referred to as Type A, will be used primarily where the MLS azimuth transmitter cannot be located on the extended runway centerline, but the elevation transmitter is sited normally abeam the touchdown point. All legs will be straight and aligned with the inbound course. They must be codes with Route Type W in column 20 of the primary approach record. Path definition will be the equivalent of a full ILS approach (Rule 6.4.2) with the exception that the leg from the PFAF inbound will be a TF leg, terminating at the runway or helipad waypoint, with the published final approach source in the Outbound Magnetic Course field. The PFAF will be coded as the Final Approach Fix in the Waypoint Description field and the first fix prior to the PFAF will be coded as the Final Approach Course Fix Approach using computed lateral and vertical guidance but no curved legs, also referred to as Type B, must be coded as Route Type Y in column 20 of the primary approach record. All legs will be straight and aligned with the inbound course. Path definition will be the equivalent of the full ILS approach (Rule 6.4.2) with the exception that the legs from the PFAF inbound will be a TF leg, with the published final approach course in the Outbound Magnetic Course field. The altitude of the PFAF and all waypoints inbound from it must be the glide path altitude at that point. The PFAF will be coded as the Final Approach Fix in Waypoint Description field and the first fix prior to the PFAF will be coded as the Final Approach Course Fix. 21

123 7.4.3 MLS/RNAV approaches using curved legs, also referred to as Type C, will be used for a variety of reasons, including parallel sidestep approaches, separation of different categories of aircraft, noise abatement, etc. These must always be precision approaches. They must be coded a with a Route type of Y in column 20 of the primary approach record. The following rules apply: The first leg of an MLS/RNAV approach with curved legs must be an IF/TF leg combination. All other straight legs must be coded as TF legs. All TF legs in an MLS/RNAV with curved legs procedure must have the published course included in the Outbound Magnetic Course field All curved legs will be code as RF legs. Every leg preceding or following the RF leg will be tangent to the RF leg at that point The initial portion of a MLS/RNAV approach with curved legs may be an IF/RF combination, provided a straight leg approach transition is coded to the point in the IF and Rule are complied with The PFAF will be coded as the Final Approach Fix in the Waypoint Description field and the first fix prior to the PFAF will be coded as the Final Approach Course Fix. If there is not a fix at the glide path intercept, then the first fix after the intercept will be the PFAF. There must be one and only one PFAF for each MLS/RNAV approach with curved legs The last leg of an approach transition prior to an MLS/RNAV approach must be one of the following types CF, CI, HF, PI, RF or TF, except as indicated in Rule If the leg type is CF, CI, RF or TF, then the Recommended Navaid must contain the identifier of the MLS used for the approach. If the leg type is PI or HF, then the Recommended Navaid must contain the VHF Navaid that defines the PI or HF leg If the last leg prior to the approach is a CI leg, the intercept angle will be 30 or less, and the intercept point must be between the first and second terminator fixes in the approach, but no closer that 2NM to the second fix The PFAF and the FACF altitudes must be coded according to Precision Approach Procedures Rule The PFAF will be used in precision MLS/RNAV approaches. It is defined as that fix along the lateral path where the published barometric altitude intercepts the glideslope. Prior to the PFAF, the aircraft is expected to fly barometric altitude to intercept the glide path. All waypoints up to the PFAF should be coded using the published barometric crossing altitude. The PFAF and all waypoints after it should be coded using the true altitude of the glide path at those points. 22

124 APPROACH AND APPROACH TRANSITION CODING RULES 8.0 Non-precision Approach Procedure Coding 8.1 General For approach procedures without an electronic glideslope, the Final Approach Fix will be that designated by government source. If no FAF is established in the government source, one will be computed according to Rule of this attachment. The fix, whether published or established, must carry the Final Approach Fix Waypoint Description code of F in position four of that code field. Note that only one record in a coded approach procedure can carry the F in position four of the Waypoint Description. Altitudes for this fix are coded in accordance with Rule of this attachment A vertical Angle must be coded in the Missed Approach Point, Runway Threshold or Final End Point, which ever occurs first, for each approach procedure. A Vertical Angle may be coded in the Final Approach Fix Segment for each approach that includes a FACF. Vertical Angles will be from official government source or computed. This Vertical Angle will only be repeated on all step-down fixes on the segment FAF to MAP. The government source Vertical Angle will also be repeated on fixes associated with an RF Leg as the start or end of the arc, when these fixes are not at procedure fix locations and the RF Leg is in the FAF to MAP portion of the final approach coding Missed Approach Point (MAP) Location. The MAP location will be as published on the non-precision approach procedure by the appropriate government authority. See also Rule 8.10 of this attachment. Note: If the source document states that the MAP and the LTP are not at the same location even if the distance is 0.1 mile or less, the MAP will not be placed at the LTP. 8.2 Final Approach Path Coding - Localizer-based Procedures The following rules apply to the Final Approach Coding of non-precision Localizer-based approach procedures. These procedures may include Localizer Only (LOC), Localizer Back Course (LOC BC), IGS (Instrument Guidance System (IGS) that are not full ILS equivalent, LDA, Localizer Directional Aid (LDA) without electronic glideslope and SDF (Simplified Directional Aid (SDF) without electronic glideslope procedures All such approach procedures must begin at the FACF. They must consist of a FACF, FAF, and missed approach point fix and all step-down fixes published in the vertical path The FACF is defined as a fix located on the localizer beam center, 8NM or less from the FAF or within the reception range of the Localizer. This may be a source document provided fix or a fix created using these positioning rules The FACF is coded as an IF leg with an altitude only when assigned by government source. The FACF is coded as an IF leg with an altitude assigned, based on the source document or equal to the altitude of a procedure turn or the altitude of the last transition leg The track from the FACF to the FAF is coded as a CF or TF leg with altitude constraints as indicated for the specific procedure types below. 23

125 8.2.5 The recommended navaid must be the procedure reference localizer. Theta and Rho must be provided from the localizer for each sequence of the Final Approach Coding, including any step-down fixes, the runway or helipad fix and/or missed approach point The Outbound Magnetic Course field in all sequences must be equal to the localizer magnetic bearing, derived from official government source No Localizer based approach procedure may include a Final End Point Fix (FEP). For this reason, the Rules , , c, d do not apply. 8.3 Final Approach Path Coding - VOR-based Procedures The following rules apply to the Final Approach Coding of non-precision VORbased approach procedures. These procedures may include VOR, VORDME, VORTAC, TACAN, and VOR/DME RNAV Area Navigation procedures Final Approach Coding must be coded using IF, and CF orand TF 1 legs only Final Approach Coding must include both a FAF and missed approach fix. The missed approach fix may be a runway or helipad fix or a designated missed approach point. Coding of a FACF is defined in Rule When the reference facility is VOR only or there is no DME collocated with VOR (see VOR coding examples 1, 3 and 8), the following applies: The recommended navaid must be the procedure reference VOR or TACAN. Theta values must be provided from that facility in all Final Approach Coding sequences, including any step-down fixes that are included When the reference facility is VORDME or VORTAC or TACAN (see VOR coding examples 2 and 6), the following applies: Rule deleted by Supplement 23.Final Approach Coding must be accomplished using IF and CF or TF 1 legs only Rule deleted by Supplement 23.Final Approach Coding must include a FAF and a missed approach point that may be a missed approach point fix, a runway fix or a helipad fix, and all step-down fixes published in the vertical path. The Final Approach Coding will include an FACF when one is required by Rule The recommended navaid must be the procedure reference VORDME or VORTAC or TACAN. Theta and Rho values must be provided from that facility in all Final Approach Coding sequences, including any step-down fixes that are included When the procedure reference is VOR/DME RNAV (VORDME), the following applies: Rule deleted by Supplement 23.Final Approach Coding must be accomplished using IF and CF or TF 1 legs only All VOR/DME RNAV- Area Navigation approach procedure missed approach points must be at or prior to a runway threshold or helipad alighting point. These points may be a source defined named waypoint. 1 In general CF legs are used in final approach coding. TF legs are used in FMS and GPS Approach Procedures, some types of MLS Procedures and in other procedure types where the determination has been made that a TF will work better than a CF. 24

126 The recommended navaid is not required unless specified by source or if required by the leg type. The recommended navaid must be the procedure reference VORDME or VORTAC. Theta and Rho values must be provided from that facility in all final approach sequences where the recommended navaid is coded, including any step-down fixes. The Recommended Navaid, Theta and Rho are never provided on fixes associated with the start and end of a precision arc (RF) leg used in the final approach coding sequences Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Examples of VOR Coding Example of missed approach point before the runway threshold, refer to VOR coding examples 7 and Example of missed approach point at the runway threshold, refer to VOR coding example 1 and Example of missed approach point beyond the runway threshold and the final course passes over the runway threshold, refer to VOR coding examples 3 and Example of missed approach point beyond the runway threshold and the final approach course does not cross runway threshold, refer to VOR coding examples 5 and Final Approach Path Coding - NDB-Based Procedures The following rules apply to the Final Approach Coding of all NDB based approach procedures. NDB based approach procedures include procedures using a NDB or Locator as the reference facility and procedures using a NDB or Locator and a DME (NDB + DME) as reference facilities. NDB approach procedures not requiring DME, but using the DME for reduced minimums, will be coded as NDB with DME required D in Qualifier NDB Final Approach Coding must include a FAF and a missed approach point that may be a missed approach point fix, a runway fix or a helipad fix, and all step-down fixes published in the vertical path. The Final Approach Coding must include a FACF when one is required by Rule Rule deleted by Supplement NDB + DME Final Approach Coding must include a FAF and runway or helipad fix or missed approach point fix and all step-down fixes published in the vertical path. The Final Approach Coding will include a FACF when one is required by Rule Coding must use IF and CF or TF 1 legs only through to the runway or helipad fix or missed approach point fix. The IF leg must be at the FAF (or at the optional FACF) for NDB procedures or at the FACF for NDB + DME procedures Recommended Navaid requirements 1 In general CF legs are used in final approach coding. TF legs are used in FMS and GPS Approach Procedures, some types of MLS Procedures and in other procedure types where the determination has been made that a TF will work better than a CF. 25

127 For NDB procedures Final Approach Coding, the recommended navaid must be the procedure reference NDB or Locator. Theta and Rho information will not be provided on any sequence For NDB + DME procedures Final Approach Coding, the recommended navaid must be the procedure reference NDB or Locator except on the missed approach point fix sequence, where the recommended navaid will be the procedure reference DME. A procedure reference DME may be any navaid with DME, including unbiased ILSDMEs. The Theta and Rho information will not be provided in any sequence of the NDB + DME final approach except on the missed approach point fix sequence. That sequence will include Rho information from the procedure reference DME Navaid Examples of NDB Coding Example of missed approach point before the runway threshold, refer to NDB coding example Example of missed approach point at the runway threshold, refer to NDB coding example Example of missed approach point beyond the runway threshold and the final course passes over the runway threshold, refer to NDB coding example Example of missed approach point beyond the runway threshold and the final approach course does not cross runway threshold, refer to NDB coding example Intentionally Left Blank 8.6 Final Approach Path Coding - Circle-to-Land Procedures Procedures that only have Circle-To-Land operating minimums may be included in the database. When they are included, they are identified with the Route Type (Section 5.7) appropriate to the reference facility and with the Route Type Qualifier Two set to C. The following rules apply to such approach procedures: The last segment in the Final Approach Coding must be the missed approach point fix For Circle-To-Land Procedures that are to a runway or helipad, or published missed approach point, all the rules listed above in Sections 6, 7 and 8 apply, as well as the rules for Missed Approach Procedure coding in Section For Circle-To-Land Procedures that are not to a runway or helipad, or published missed approach point, the missed Approach Point will be established at the center of the airport or heliport A Vertical Angle must be provided on the missed approach point fix, or, when the procedure meets the criteria specified in Rule , on the Final End Point fix when such as fix is coded for the approach. Vertical Angle information must be in accordance with the rules in Section 6, 7 and 8 of this attachment for the type of reference facility on which the procedure is based If no runway is specified, the altitude 1 field in the missed approach point fix record will be coded with the airport elevation. 8.7 Final Approach Path Coding RNAV Procedure 26

128 This section provides coding guidelines for RNAV Approach Procedures. The terman RNAV Approach Procedure is defined as an approach procedure that was designed to provide lateral and vertical path guidance withoutusing criteria that do not relying on radials, bearings, DME arcs or glide paths from ground-based navaids. As such, an RNAV Approach Procedure will not include references to ground-based navaid associated information such as VOR radials, NDB bearings, DME distances, ILS courses, MLS Azimuths and ILS or MLS glideslopes. These Approach Procedures are designated as PBN Navigation Specifications RNP APCH or RNP AR APCH, and typically are published using a title RNAV (GPS), RNAV (GNSS), RNAV (RNP) or RNP. Also approaches coded as GPS and FMS must follow these rules.exceptions to this standard may be outlined in the rules that follow. Navaids may be referenced as waypoints in the coding of the RNAV Approach Procedures The Final Approach Coding must include a Final Approach Fix (FAF) and a Missed Approach Point fix (Runway Threshold or Missed Approach Point). The Final Approach Coding must include a Final Approach Course Fix (FACF) when such a fix is required by Rule The FAF (or optional FACF) is coded as an IF leg with an altitude only when assigned by government source Final Approach Coding must be accomplished using IF, RF and TF legs only. When the final approach coding starts with a precision arc, use an IF leg at the FACF or FAF, followed by the RF leg. This ensures compliance with the Beginning/Ending Leg Table. According to RF leg rules, at least one fix terminated approach transition to the same fix used in the IF leg of the final approach coding must be included. The track in the transition(s) must be tangent to the arc.the track from the FACF (when coded) to the FAF is coded with TF or RF legs. The RF leg is not allowed as the first leg of the approach coding according to the Beginning/Ending Leg Table. The preferred coding when an approach starts with a precision arc is the use of an IF leg at the FACF or FAF, followed by RF to the FAF or MAP. According to the rules on RF legs, this must require that a straight line, fix terminated, approach transition to the FACF or FAF has been included. The track in the transition must be tangent to the arc and the fix at the end of the transition must be overflown. The rule also does not exclude the use of an RF leg in between FAF and the final TF leg to the missed approach point. Such RF legs must be coded with the 4th character of the Waypoint Description field blank The magnetic variation required to construct path terminators must be provided in the procedure design magnetic variation field either for the procedure or as a minimum for such legs (see and 5.291).The Final Approach Coding of RNAV Approach Procedures covered by this Section 8.7 do not require a Recommended Navaid except as governed by other rules in this attachment Rule deleted by Supplement 23.RNAV Approach Procedures coded as GLS Procedure according to Section 5.7 must reference the GLS facility as a Recommended Navaid A missed approach point beyond the runway is not allowed, therefore Rules , , , c, d, and e do not apply. 8.8 Final Approach Path Coding - Helicopter Approach Procedures 27

129 Helicopter Approach Procedures will be coding using the rules in Sections 6, 7, and 8 and 9 of this attachment, appropriate to the type of sensor required for the procedure, such as VORDME or ILS or RNAV or GNSS. This includes rules for Recommended Navaid, FACF requirements, beginning and ending leg types, etc. The Lateral Path Rules for the sensor related procedure coding reference a missed approach point fix, a runway fix or a helipad fix as the missed approach point. Those same rules apply to the coding of helicopter procedure. 28

130 8.9 Vertical Navigation Path (VNAV Path) or Descent Gradient Considerations If the government source provides, vertical path angle or other suitable information that can be used to determine a vertical path angle, it must be used. The only exception is when the source provides more than one angle for the Final Approach Coding segment FAF to MAP. If more than one angle is provided for this segment, the highest angle will be used. The following guidelines have been developed for the coding of the vertical angles on the Final Approach Coding when vertical path information is not provided by the government sources. Rule through applies to the FAF to MAP segment only. Rule applies to the FACF to FAF segment only The descent angle is to be calculated from Landing Threshold Point elevation plus the published procedure TCH (if no procedure TCH is specified by source use 40 or 50 feet [see Section 5.67 of this specification]) to the altitude at the Final Approach Fix (FAF). The curvature of the earth should not be used in the calculations of the descent angle. Refer to example 1, 7, and 8. The descent angle must always be rounded up to the nearest one hundredth of a degree. Examples of Rounding: = = The published TCH for a procedure used in these calculations is the procedure TCH (if no procedure TCH is specified by source use 40 or 50 feet). TCH is further defined in Chapter Five, Sections 5.67 and of this document The lateral distance used in the descent angle calculation is to be the along track distance of the path from the coded Final Approach Fix to the Landing Threshold Point. The distance resolution used in this calculation will be 0.1NM If the calculated angle is less than three degrees, it will be raised to a minimum of three degrees If a step-down fix is included in the Final Approach Coding segment to FAF and MAP and it is determined that the calculated descent angle will be above the step-down fix altitude, that calculated descent angle will be used. If it is determined that the step-down fix altitude is above the descent path, the descent angle will be calculated from the LTP plus TCH to the altitude at the step-down fix. Refer to Examples 3 and Deleted by Supplement If the final approach course does not cross over the runway threshold, a position abeam the landing threshold point on the final approach course will be calculated and coded as a Final End Point. The descent angle must be calculated using distances that start at the FEP fix and an altitude equal to the LTP elevation plus the published procedure TCH (if no procedure TCH is specified by source use 40 or 50 feet [see Section 5.67 of this specification]) to the altitude at the Final Approach Fix (FAF). Refer to Examples 6, 9, and If the missed approach point is prior to the runway threshold, the descent angle will be computed from the LTP elevation plus the published procedure TCH (if no procedure TCH is specified by source use 40 or 50 feet [see Section 5.67 of this specification]) to the altitude at the FAF. Altitude will be specified at the MAP fix and will be the altitude where the calculated descent angle passed through the MAP. Refer to Examples 7 and 8. 29

131 8.9.7 When circling-to-land minimums are the only landing minimums and the runway is in alignment with the Final Approach Coding segment FAF and MAP, a descent angle will be provided. The descent angle will be computed from the LTP elevation plus the published procedure TCH (if no procedure TCH is specified by source use 40 or 50 feet [see Section 5.67 of this specification]) to the altitude at the FAF. Refer to Examples 11 and When circling-to-land minimums are the only landing minimums and the runway is not in alignment with the Final Approach Coding segment FAF and MAP, a descent angle will be provided. The descent angle will be computed from a point on the final approach course Abeam the LTP of the nearest landing runway to the altitude at the FAF. Refer to Example If one or more step-down fixes are published in the official government source in the intermediate approach segment of the procedure, and the intermediate approach segment can be included in the final approach coding, the fixes and the appropriate altitudes will be included as part of the Final Approach Coding. A vertical angle will be coded on the FAF waypoint that will ensure that any stepdown fix altitude in the Final Approach Coding, FACF, to the FAF is cleared by that angle. Vertical angle information is not provided in Approach Transitions. However, any such fix will be included in the coding, along with the government source supplied altitudes If the Missed Approach Point (MAP) is at a Point-in-Space, the descent angle will be computed from the altitude at the MAP to the altitude at the Final Approach Fix (FAF) VNAV Coding of Non-Precision Approach Procedures With Missed Approach Points - Other Than Landing Threshold Coding standards for Non-Precision Approach Procedures that have a published missed approach beyond the Landing Threshold Point have been developed. These standards are included in the three VNAV coding scenarios in the following paragraphs. In these scenarios, the term final approach course crosses over the landing threshold is used as a qualification for the three scenarios. This attachment does not define with any precision what is meant by this qualification. The intent of this wording is that the published final approach course will lead to the landing threshold without course changes or corrections Missed Approach Point beyond the landing threshold and the published Final Approach Course crosses the landing threshold. The ARINC 424 rules for this case call for inserting the Landing Threshold Point as a fix in procedure coding. See VNAV Coding Example A Missed Approach Point beyond the landing threshold and the published Final Approach Course does not cross the landing threshold. The ARINC 424 rules for this case call for inserting a Final End Point as a fix in the procedure coding. See Coding Example B Missed Approach Point is a Navaid beyond the landing threshold. The published final approach course does not cross over the landing threshold but the navaid is located equal to or less than 0.1NM from that threshold. The ARINC 424 rules for this case call for coding the navaid as the missed approach point, no insertion of an additional fix. See Coding Example C. 30

132 APPROACH AND APPROACH TRANSITION CODING RULES 9.0 Missed Approach Procedure Rules Valid For All Procedure Types Missed Approach Procedure coding must be accomplished as an integral part of the Approach Procedure Coding and will be provided for each approach procedure contained in the database. Specific coding must be incorporated to facilitate identification of where the Missed Approach Coding starts within any given approach procedure. The structure of the procedure records included in this specification as defined in this attachment is such that multiple missed approach procedure paths may be coded for a single approach procedure. This will accommodate those procedures with alternative missed approach paths based on aircraft climb performance. Coding for multiple missed approach paths for a single approach procedure must commence at the same missed approach point. Identification of multiple missed approach procedures, when coded, will be accomplished through the coding of a specific Transition Identifier which closely aligns with published information. 9.1 Missed Approach Point All Approach Procedure coding must have a segment that identifies the Missed Approach Point Fix. Such a fix must be the published Missed Approach Point, either a IFR Landing Threshold or a Helipad Alighting Point or a dedicated Missed Approach Point (MAP Fix) Identification of the fix within a sequence of procedure records and the type of fix, must be accomplished through code in the Waypoint Description field (see Section 5.17) When the Missed Approach Point Fix is a Runway or Helipad Fix, Waypoint Description Position One, must carry a character G and the M in Position Four When the Missed Approach Point Fix is MAP Fix, Waypoint Description Position One will carry a code equal to the type of fix such a Navaid or waypoint and must carry a character M in Position Four. 9.2 First Leg of Missed Approach Procedure The first sequence of the Missed Approach Procedure must always be coded with the character M in Position Three of the Waypoint Description field Coding of the Missed Approach Procedure assumes that the procedure will be flown commencing at the Missed Approach Point Fix For Non-Precision Approach Procedures that have a published missed approach beyond the landing threshold (see rules in Section 8.10), and the procedure design intent is to overfly the published MAP (see Section ), a Y in position 2 of the waypoint description field must be coded in the coding sequence that contains the source provided missed approach fix. 9.3 Vertical Path of Missed Approach Procedure If the published Missed Approach Point Fix is a Runway fix or a Helipad Fix, then the following rules apply: The Altitude 1 value in the Missed Approach Point sequence must be equal to Runway Threshold or Helipad Alighting Point Elevation plus the published TCH. If no procedure TCH is specified by source use 40 or 50 feet [see Section 5.67 of this specification]. 31

133 The first leg of a Missed Approach Procedure will contain any government source provided altitude constraints. These altitudes may be provided as At, At or Above, At or Below, At or Below to At or Above, dependent on the government source documentation and coded in accordance with Section Five, Subsection 5.29 of this specification. Except as indicated below, if the government source does not provide an altitude constraint for the first leg of the Missed Approach Procedure, none will be coded In precision approach procedures such as Full ILS or GLS, the Decision Height (DH) value at which the Missed Approach Path would normally be commenced is not included as part of the Final Approach Coding. Other portions of this attachment define what altitude data is included in the coding of the procedure for the missed approach point and the first leg of the missed approach path In non-precision approach procedure, the Minimum Descent Altitude (MDA) value at which the missed approach decision would normally be made is not included as part of the Final Approach Coding.. Other portions of this attachment define what altitude data is included in the coding of the procedure for the missed approach point and the first leg of the missed approach path When an immediate turn is specified in an ILS, MLS, or GLS missed approach, or if the source describes a turn greater than 15 degrees from the final approach course, without an altitude specified before the turn, as the first leg of a missed approach, a course from or heading to an altitude (CA, FA, VA) leg must be coded as the first leg of the missed approach and must include a command to climb before the turning leg, using the final approach course for the leg heading or course. The altitude will be coded as a minimum altitude, at least 400 feet above the airport elevation and the leg will terminate at that altitude For a PinS approach procedure, a course from or heading to an altitude (CA, FA, VA) leg will be coded as the first leg of the missed approach only if required by source documentation. 9.4 Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Rule deleted by Supplement Other Missed Approach Procedure Considerations Opposite end runway or helipad fixes must not be used in the coding of missed approach procedures The procedure reference Navaid must be used as the Recommended Navaid when required, with the following exceptions: The first leg of a Missed Approach Procedure may be a CD, FD, or VD leg. For these legs a DME may be used as the Recommended Navaid, with the Theta field left blank and the DME distance entered in the Rho field Rule deleted by Supplement

134 The first leg of the Missed Approach Procedure may be a CR or a VR leg. For these legs, a VOR facility (without or without DME) may be used as the Recommended Navaid. When the facility has no DME, the Rho field is left blank and the VOR radial is entered in the Theta field When the first leg of a Missed Approach Procedure is coded as a HA or HM leg, the coding will also include a government source provided altitude. 33

135 Attachment 18 Attachment 18

136 ARINC 424 NDB Draft 1 of Supplement 23 Discussion/Proposal Location Gdansk, Poland October 9-11, 2018 DISCUSSION ABOUT CODING EXAMPLES V.1 Martin Zillig, Lufthansa Systems FlightNav SUMMARY Evaluate the rewriting of attachment 5, sections 6, 7, 8 and 9.

137 1.0 INTRODUCTION/ BACK GROUND During reviewing ARINC 424, and especially when removing duplicated rules, I noticed that some rules could not be moved to the most logical places, as the numberings were not available. 2.0 DISCUSSION and or ACTION I would like to ask the group, if the complete reorganization of approach coding rules in attachment 5, rules 6.x, 7.x, 8.x and 9.x would be supported. Regrouping and renumbering of all rules into clearer groups, leaving options to future changes and additions of rules. Also, the coding examples do not necessarily reflect the rules anymore, and there are many VOR coding examples, but no RNAV or LOC or transitions. 2

138 3.0 Changes as depicted (Track Changes is Helpful) 3

139 Attachment 19 Attachment 19

140 ARINC 424 NDB Draft 1 of Supplement 23 Proposal Location Gdansk, Poland October 9-11, 2018 TF OVER FC/CF V1.0 John Keeley, AeroNavData SUMMARY Attachment 5, rule specifies an FC/CF leg combination as preferred over a TF leg in certain cases. The FC/CF combination is potentially problematic when slaved variations differ between the associated recommended navaids. This paper proposes an adjustment to this preference.

141 1.0 INTRODUCTION Figure A5-6-1 in ARINC specifies that for precision approaches relying on an electronic glideslope, an FC/CF leg combination is preferred over a TF leg in cases where the leg distance to the FACF exceeds 8NM. A problem associated with an FC/CF leg combination is found in cases where the slaved variation differs between the recommended navaids associated with the FC and CF legs. A pilot may see a gap at the point where the FC terminates and the CF leg begins. In other words, due to differences in magnetic variation associated with each leg, the course that extends forward from the FC fix and the course that is projected back from the CF fix collectively do not represent a smooth track between the FC fix and the CF fix. Example: FAA chart for KJQF ILS OR LOC RWY 20, GSO transition Slaved variations: GSO VOR/DME: W0030 IJQF Localizer: W0060 2

142 2.0 BACK GROUND For reference, the following screenshots are intended to show the evolution of rule in ARINC 424, starting with the current section as it appears in : When a CF leg is used as the ending leg of a transition to a localizer-based procedure, the maximum leg distance will be within 8NM of the FACF or within the reception area of the localizer as depicted in Figure A Note: For precision approaches relying on an electronic glideslope, an FC/CF is preferred over a TF as illustrated in Figure A5-6-1 for those legs ending at a fix. 3

143 Next, see the following screenshot from ARINC At the time, rule C.1. prohibited a TF leg from serving as the last leg of an approach transition on an ILS approach procedure. Therefore, a preference for FC/CF over TF wasn t applicable since an approach transition-ending TF leg wasn t valid. Rule C.2.b called for an FC/CF combination instead of a CF in cases where the CF leg length would otherwise exceed 8 miles. 4

144 Next, see the following screenshot from ARINC , where a TF leg was added as an allowable ending leg of an approach transition on a localizer-based approach procedure ( ). The wording FC/CF is preferred over a TF is added to the note associated with Figure A Finally, see the following screenshot from ARINC where the wording in blue was adjusted to the current state as found in

145 3.0 DISCUSSION and or ACTION In the interest of mitigating the appearance of gaps caused by slaved variation differences between the recommended navaids associated with the FC and CF legs, please consider an adjustment to the note in Attachment 5, , figure A5-6-1, to remove wording that prioritizes the coding of an FC/CF combination over a TF leg. The great circle track implied by a TF leg isn t subject to slaved variation discrepancies applicable to the FC/CF combination. The changes proposed below would permit the data supplier to encode TF as the ending leg of localizer-based transitions without breaking a nominal preference for FC/CF coding. 4.0 Changes as depicted (Track Changes is Helpful) When a CF leg is used as the ending leg of a transition to a localizer-based procedure, the maximum leg distance will be within 8NM of the FACF or within the reception area of the localizer as depicted in Figure A Note: For precision approaches relying on an electronic glideslope, an TF FC/CF is preferred over a CF TF as illustrated in Figure A5-6-1 for those legs ending at a fix. 6

146 Attachment 20 Attachment 20

147 ARINC 424 NDB Draft 1 of Supplement 23 Proposal Location Gdansk, Poland October 9-11, 2018 ADDITION OF 5.46 TO HP RECORD V1.0 John Keeley, AeroNavData SUMMARY This paper proposes an update to the Helicopter Operations SBAS Path Point Record to allow the data supplier to provide a 5.46 value in columns 20 thru 24.

148 1.0 INTRODUCTION/ BACK GROUND The Helicopter Operations SBAS Path Point Primary Record (HP record) was added to the ARINC 424 specification in One difference between the HP record and the PP record (Airport SBAS Path Point Record ) is columns On an HP record these columns must represent a value, e.g., 05000, In the case of the PP record, columns may represent either a value or a Runway Identifier (5.46) value, e.g., RW05, RW21. The following example PP/HP record snippets illustrate the differences between and A 5.46 value is highlighted in the first row. A value is highlighted in the second row. The HP and PP record layouts both refer to RTCA DO229 to properly convert values and binary pack these fields for the CRC data wrap. One of the parameters specified in DO229D s CRC wrap is Runway Number. This parameter can be obtained from the PP record columns and depending on whether the PP record includes a 5.46 value or a value, these columns will either be a two-digit number (in the case of 5.46) or a zero (in the case of 5.300). 2

149 A zero Runway Number parameter is in line with DO229D, which designates the 0 value for heliport operations. The following screenshot shows the parameter definition of Runway Number from DO229D Appendix D 3.1: In the current successor to DO229D, that is DO229E (published December 15, 2016), the Runway Number parameter definition was changed. A value of 0, while still valid, is dubbed obsolete. The following screenshot shows the revised Runway Number parameter definition from DO229E, appendix D: Also, the screenshot above shows the revised Table D-1, Note 1 from DO229E. Note that zero no longer designates heliport operations in DO229E. As shown in the screenshot above, DO229E cites compatibility with FAA Order As expected, this FAA order defines a valid range of Runway values that does not include zero in accord with DO229E. For reference, see the following screenshot from FAA H Appendix K: 3

150 The following screenshots are provided within the scope of this working paper to illustrate pertinent source. The first screenshot shows a helicopter approach plate that serves a heliport and includes SBAS copter minima: 4