RAAF AERONAUTICAL INFORMATION SERVICE

RAAF AERONAUTICAL INFORMATION SERVICEComments on the DAFIF Terminal Procedure Coding

for the Australian Airspace

Mission Statement of RAAF AISTo provide the Australian Defence Force

with tailored, accurate and current aeronautical information.

The Vision Statement of RAAF AISExcellence in the provision of

aeronauticalinformation services.

RAAF AIS role in the ADF

2. PURPOSE AND SCOPE.

B. The DAFIF database is designed to contain flight information detailing Airports, Heliports, Navigational Aids, Air Traffic Service (ATS) Routes, Airspace Boundaries, Terminal Procedures,……...

The database may be used for (but is not limited to):(1) Automated Flight Planning Systems(2) Flight Simulators(3) Flight Management Computer Systems (Mission Computers)

3. COMPLIANCE/IMPLEMENTATION DOCUMENTATION. (10) Standards for Processing Aeronautical Data, RTCA DO200A, or current version.

(11) ARINC –424 –XX (Terminal Instrument Procedures, Path Codes)

FOREWORD (as per DAFIF)

Current Airframes & Systems using the DAFIF files. C130J (Flight Management System) E3 AWACS (Flight Management System) VC10 (Flight Management System) Sea King Helicopter (Flight Management System) Orion P3 (Flight Simulator) C17 Globemaster 111 (Flight Management System) Nimrod (Flight Management System) Bombardier BD-700 Global Express (Flight Management System)

Proposed Airframes & Systems to use the DAFIF files. B737 BBJ & AWACS (Flight Management System) A330 Air - Air Refueler (Flight Management System) Orion P3 (Flight Management System)

USERS of DAFIF

Comments on Procedure coding

Background:- The following Plots were done by using Smiths Industries Procedure Design Tool.


Within the DAFIF rules Procedure Turns are normally coded using an “PI - CF” combination.

However in checking Procedures coded in the AS area no Procedure Turns are coded in this combination. Instead they are generally coded using TF legs to “Analyst Generated” Fixes.

Over use of Analyst Generated Fixes limits available Fix Idents, adds to Cockpit confusion, and reduces limited Flight Management System Memory.

The coding could lead to the Aircraft not flying the designed Path.

For Example…

ISSUE:- PROCEDURE TURNS

Comments on Procedure codingPROCEDURE TURNS

Source Chart for Airport YBAS RWY12 ILS

Comments on Procedure codingExample of an FMS interpretation of a DAFIF Procedure Turn coding vs. Standard PI CF legs

The FMS translation using the DAFIF coding using TF, VM, DF, AF & CF legs.

VM LEG (manual heading leg to ?)

DF LEG AF LEG

CF LEG

The FMS translation of the standard coding using PI CF legs.

YBAS RWY12 ILS


Within the DAFIF rules the FD leg (Course from a Fix to DME Distance) is one of the leg types available to the Analyst. This Leg type is ideal in most cases for TEAR DROP coding.

However, no Tear Drop Procedures coded in the AS area are coded using this leg type. Instead they are generally coded using TF legs to “Analyst Generated” Fixes.

ISSUE:- TEAR DROP PROCEDURES

Comments on Procedure codingTEAR DROP PROCEDURES con’t.

Source Chart for Airport YBAS RWY12 VOR/DME


The FMS translation using standard coding of IF FD CF legs.

TEAR DROP PROCEDURES con’t.

FD LEG

TEMP. FMS COMPUTED FIX

CF LEG

The FMS translation using the DAFIF coding using IF TF, TF, TF legs

TF LEG

(causing a Route Discontinuity)

TF LEG

TF LEG

YBAS RWY12 VOR/DME


RCTA DO-201A recommends that the Procedure Identifier is the Identifier of the FIX or Navaid that the Procedure is going to.

However in several locations in the DAFIF database the SID/STAR IDENTIFIER has been filled with data other than the FIX IDENTIFIER.

Example: For the Melbourne (ML) 3 Departure at AVALON Airport the DAFIF database has called this SID MELBN3 when it should be called ML3 as per source. (ML being the ident of the Melbourne VOR/DME.)

ISSUE:- PROCEDURES NAMES NOT MATCHING SOURCE


When grouping together several SID/STARS Procedures a key part of the Procedure Identifier can be overlooked, the “ROUTE VALIDITY INDICATOR”. This Indicator is required by RCTA DO201A & ICAO Annex 11 , Appendix 3 to indicate to Flight Crews the currency of the Procedure.

Example: For the Brisbane (YBBN) Departures the DAFIF database has called the SIDs to the South “RW191” with transitions to SCOTT, LARAVALE(LAV), WIZZA.

Ideally these should be coded as 3 different SIDs called :- SCOTT3, LAV6, WIZZA2 as per source.

ISSUE:- PROCEDURES NAMES NOT MATCHING SOURCE


The grouping of two or more SIDs under the one Procedure Identifier and then breaking up the Procedure into type 1 & 2 can cause the coding of the Procedure not to follow the Path designed by the Source.

Example:- For the Avalon (YMAV) Departures to Melbourne the DAFIF database has combined both SIDs as one. (MELNN3), but in this case there is no common part between the two SIDs. Therefore to combine the two SIDs together a common point has been “made up” and not existing in source.

For Example..

ISSUE:- PROCEDURE CODING NOT MATCHING SOURCE



The FMS translation using standard coding

DAFIF coding of the same SID

The two sets of coding overlaid.

YMAV RWY 18 ML3 SID

2 NM Lateral offset between paths

Fix AV027 not in source



The FMS translation using standard coding

DAFIF coding of the same Sid

The two sets of coding overlaid.

YMAV RWY 36 ML3 SID

1/2 NM Lateral offset due to “CR” Leg


CR and VR legs have been used in place of CI or VI legs. The general intention of CR/VR legs is to code “a Course or Heading to cross ABC Radial at XYZ Altitude”. When used to code legs meant to intercept a Course/Heading, a unintented “dog leg” will be introduced to the path which is not as per the procedure designer intend and could place the Aircraft well outside designed path as per PANSOP/TERPS/RNP. Example YBTL RW01 ROM1 SID

ISSUE:- PROCEDURE CODING IMPROVEMENTS

The FMS translation using standard intercept coding.

Sample of DAFIF coding where a CR leg has been used to intercept a CF

Two Sets of coding overlaid

5.5 NM Lateral offset due to “CR” Leg

What if there was terrain here ?


Throughout the database there are several examples of data being out of date. One of the worst cases were Approach Transitions in YPPH (Perth) Airport where the database was referring to charts that had been superseded over seven (7) years ago.

The data for the Australian region and indeed most of the world (outside USA) is far from complete, with major Approaches, Approach Transitions, SIDs and STARs missing from major Civilian and Military Airports.

There are cases where an Approach has been coded twice to facilitate two different Transitions. For example, the ILS approach into YPEA (Pearce) has been coded with I18L-A (with a transition from PEA92) & I18L-B ILS (with a transition from PEA04) when all that was required was a I18L ILS Approach with two Transitions, one from PEA92 & other from PEA04, as per source.

There is no need to break a Procedure into Type 1 & 2 if there is no common part other than a single IF leg. Example: The SIDs out of YMML (Melbourne). (NB - several years out of date)

VOR/NDB only Approaches cannot have DME Arcs. See YCIN RWY S29.



Some examples of coding in the HAWAIIAN Airspace

JEPPESEN CHART for HILO (PHTO)

Correct coding flying Runway Heading to intercept the CF to “SAPDE” as per Source

DAFIF coding using a CA then CR leg to intercept the CF to the fix “SAPDE”

However the CR will give a “dog leg” path not matching source.

PARIS 2 SID for RWY03

2.3 NM Lateral offset due to “CR” Leg




JEPPESEN CHART

Correct coding as per Source

DAFIF coding using a “CR” leg. Again the CR leg gives a “dog leg” path not matching source.

AMERY 2 for RWY17

The Runway Bearing for this RWY is 1740 but the DAFIF data has been coded as a “CA” leg of 1700




JEPPESEN CHART Correct coding as per Source

DAFIF coding using a CR leg. Again the CR leg gives a “dog leg” path not matching source. It also would cause a route discontinuity. AMERY 2 for RWY35

1. When the Source specifies a Course or Heading to intercept the Radial and then Track to a Fix, use a CI or VI leg instead of CR or VR legs. Refer to RTCA DO -201A for details.

2. Commercial Off the Shelf Flight Management Systems require some types of Path Termination Legs (eg CF legs ) to reference a VOR/DME or VOR/TAC even if this is maybe irrelevant to the Procedures as the recommended Nav Aid. In order to make the DAFIF data useable in these systems, and where this is not possible, consider other Leg types or Combinations of legs eg CI IF TF.

3. Use the given source name of Fixes and Procedures. See RCTA 201A (Members of the RTCA Committee included NIMA and USAF & U.S.N)

4. Use of better naming convections for Analyst Generated Fixes would reduce any possible confusion for Flight Crews. (Refer to standard as used by most COT Flight Management Systems, Arinc424 attachment 7 Naming Conventions). The introduction of a Terminal Waypoint Record would give more flexible approach to the Naming of Fixes.

Coding RecommendationsKey Points

Coding Recommendations

5. Include all details of the Procedure Identifier in the coding. i.e. Basic Indicator, Validity Identifier, and where required a Route Indicator. As per ICAO Annex 11, Appendix 3 & RTCA DO201A .

6. Computer based systems anticipate the turn after the DME ARC, Therefore there is no requirement to use a CR/VR leg. If necessary use CI/VI legs.

7. Don’t code VOR only or NDB only approaches with DME Arc Transitions.

8. Don’t code the same Procedure twice when an additional Transition will do.

9. Don’t try and join Procedures when there is no common part of the Procedure.

10. Increasingly some Government Agencies are specifying the Path Termination Legs types to be coded. The FAA is an example with its Form 8260. When this data is available and not used could lead to RCTA DO201A issues.

Key Points

Coding Recommendations

11. There is no need to create a type 2 record for SIDs for a single record when record is a “IF” leg.

12. Use PI CF legs for Procedure Turns wherever possible.

13. Use FD CF (or IF, FD, CF if required due to Altitude requirements) legs for Tear Drop Procedures.

14. Procedure data is the most safety critical of any in the database. Where data has been NOTAM’d out for several years, with no prospect of being corrected in the foreseeable future, then it is potentially far too dangerous to continue to republish it cycle after cycle.

10.

Key Points


Background:- Turns and Radius based on a Boeing 737 (same as RAAF BBJ & Project Wedge Tail)

A Spreadsheet is available listing all (Cycle 200407) DAFIF Terminal Procedures in Australia and comments regarding the coding used.

Sample coding and presentation done by David Owens a RAAF AIS staff member with 11 years experience in Coding for COT Flight Management Systems including Terminal Procedures (used by B737, B747, B767 & A320 aircraft.)

RAAF AERONAUTICAL INFORMATION SERVICE

Documents

Transcript of RAAF AERONAUTICAL INFORMATION SERVICE