PROCEDURE DESIGN MASTER CLASS

PROCEDURE DESIGN MASTER CLASS
James (Jim) W Gregory Civil Aviation Inspector and ATPL pilot with Transport Canada AIS and Airspace Standards Chair of ICAO OCP Participant at many RNAV related forums (RTCA SC-181, ATA FMS Task Force, FMS SID/STAR WG)

PROCEDURE DESIGN MASTER CLASS
History of RNAV History of ARINC 424 Problems related to existing procedures Reason for limited ARINC 424 set

HISTORY OF RNAV (According to Gregory!!)
Area Navigation (RNAV) a method of navigation that permits aircraft operation on any desired course within the coverage of station-referenced navigation signals or within the limits of a self contained system capability, or a combination of these.

RNAV developed to provide more lateral freedom Better use of airspace Route not tied to fly-over navigation aids Initially RNAV commonly meant VOR based rho-theta RNAV systems Expanded to also include INS/IRS, OMEGA, LORAN C, Doppler, DME/DME and GNSS

Use of RNAV began in late 1960’s Most were VOR/DME RNAV systems (for GA types; INS for large air carriers) 1st commercial RNAV system (course/track line computer) NARCO CLC-60 in mid 1968 System used waypoints based on radial/DME from VOR/DME facilities Maximum distance WP from facility was approximately 40 NM

Early VOR/DME RNAV system (KNS 80) track line computer

Rho-Theta RNAV Route Haines to Belgrade No database support required yet!

Other agencies began exploring RNAV systems KLM/SwissAir/SAS/UTA had a co-operative effort SwissAir became responsible for the development of a database to support this effort

1972 (?) LITTON INS had database of facilities June 1973, National Air DC-10 equipped with Collins ANS-70 conducted RNAV operation, including approaches in VMC, with database

HISTORY OF RNAV/ARINC (According to Gregory!!)
avionics manufacturer’s requirement for databases became more critical Each manufacturer had their own unique requirements for data Aug Jeppesen invites avionics manufacturers to meet Meeting described as cautious

Airlines Electronic Engineering Committee (AEEC) approached to broker industry standards for databases for navigation Sep AEEC Area Navigation Subcommittee established working group to standardize RNAV system reference data format and encoding characteristics

Committee noted: different RNAV manufacturers taking divergent paths with respect to reference data organization unless trend was halted, airline industry would face very high costs of supporting the production of data files in several different formats economic benefits would result if resolution could be established

WG met Jan 74 examined ways different manufacturers dealt with reference data organization meeting described as “interesting” as attendees were engineers whose interests were not specifically Aeronautical Information Services

Subsequent WG meetings in Mar and May 74 concentrated on defining characteristics for data elements AEEC RNAV subcommittee reviewed WG’s first draft “Project Paper 424” Sep 74 RNAV subcommittee endorsed principles established by WG RNAV subcommittee took on work itself and disbanded the WG

Second draft document developed in Jan 75 additional amendments constituted 3rd draft 3rd draft “Project Paper Area Navigation System Data Base Specification” approved by AEEC in Spring 75

ARINC Specification 424, adopted by AEEC, first published 21 May 75 Spec amended regularly each amendment following first publication identified as 424-1, 424-2, 424-3, etc information up to ARINC only included point-to-point-to-point navigation

ARINC 424-3, published 4 Nov 82, introduced concept of “path and terminator” “path and terminator” concept created by Sperry concept permits coding of terminal area procedures, SIDs, STARs and approaches

Concept established “rules” of coding Concept includes a set of defined codes known as “path terminators” or “leg type” Path Terminator “rules” contained in ARINC 424 Attachment 5 Currently there are 23 different “leg types”

Track to Fix (TF)

Initial Fix (IF)

Hold to Fix (HF), Hold to Altitude (HA), Hold to Manual termination (HM)

Direct to Fix (DF)

Fix to Altitude (FA)

Course to Fix (CF)

Procedure turn to Intercept (PI)

Course to Altitude (CA)

Course to Intercept (CI)

Course to DME termination (CD)

Course to Radial interception (CR)

Fix to distance on Course (FC)

Fix to DME termination (FD)

Fix to Manual termination (FM)

Arc to a Fix (AF)

Heading to DME distance (VD)

Heading to Altitude (VA)

Heading to Manual termination (VM)

Heading to next leg Intercept (VI)

Heading to Radial termination (VR)

Radius to a Fix (RF)

Certain path terminator assumptions are made to accommodate aircraft performance: speed K ground speed used to compute distance based upon 3.5 NM per min on course reversal - max distance of 4.3 NM used before turn inbound if no distance or time specified

Max 25 degree bank angle used to compute turn radius climb rate of 500 feet per NM used in computations intercept angles - no specified, 30 degrees for intercept of localizer based and degrees for all others

Path terminator concept developed to code existing conventional instrument procedures However, not all conventional procedures easily coded “conditional” procedures, easy for pilot to interpret, are difficult for computer to describe

Industry made representation to ICAO OCP RNAV WG in Jun 91 regarding problems with coding conventional procedures OCP 10 Nov 94 proposed amendment 9 to PANS-OPS Vol I regarding use of FMS/RNAV on conventional procedures:

“FMS/RNAV…may be used…provided: procedure is monitored using basic display normally associated with that procedure; and tolerances for flight using raw data on the basic display are complied with.” “Lead radials are for non-RNAV equipped aircraft and are not intended to restrict the use of turn anticipation by the FMS”

Furthermore, agreement to have FMS-equipped aircraft fly tracks instead of procedural headings provided heading not required for ATC separation Industry requesting that design of terminal area procedures be compatible with increasing number of FMS equipped aircraft

New criteria introduced into PANS-OPS to cater to the needs of the modern aircraft navigation databases VOR/DME RNAV (Chap 31) GNSS “basic receiver” criteria (Chap 33) DME/DME RNAV (Chap 32) RNP (Chap 35) BARO-VNAV (Chap 34)

When developing RNAV procedures, following path terminators accommodate all procedures: IF, TF, DF, FA, CF, HF, HA, and HM When developing RNP RNAV procedures, the following path terminators are only used: IF, TF, RF, (DF and FA -discouraged), (CF - to be phased out), HF, HA and HM

OCP 12 introduced material for PANS-OPS Vol II and Procedure Design Manual concerning path terminators, their definitions, and their application Encourage procedure designers to become more knowledgeable about path terminator

On a personal note: aircraft operation is becoming more reliant upon computer technology rather than pilot skill computers are smart - but cannot think - yet! the days of decision making with regard to navigation is being replaced by “monitoring” crowded skies dictate clearly defined airspace structure and procedures

Hence, the reason for procedure designers to clearly understand the airborne technology You are the people who have the greatest influence on the success (or failure) of RNAV and RNP RNAV implementation

QUESTIONS ? ? ? ? ? ?

PROCEDURE DESIGN MASTER CLASS

Similar presentations

Presentation on theme: "PROCEDURE DESIGN MASTER CLASS"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

PROCEDURE DESIGN MASTER CLASS

Similar presentations

Presentation on theme: "PROCEDURE DESIGN MASTER CLASS"— Presentation transcript:

Similar presentations

About project

Feedback