ATM Requirements - ICAO...ARINC 424 is not a “charting standard “ file structure (it maybe...

Practical Experiences & ATM Workshop

ATM Requirements

Setting the Scene ……

2 Issue

• Many Issues (and many solutions) • This Forum’s central theme

MIXED MODE One of the thorniest problems to solve

ATM Requirements Forum - INTRO

3 What is mixed mode?

• In PBN, mixed mode refers to an ATM environment where procedures designed and operations permitted accommodate more than one kind of navigation qualification

• Examples include: – RNAV 1 SIDs/STARs + Conventional SIDs/STARs – RNAV 5 + Conventional ATS Routes – RNP AR APCH procedures + ILS – RNP APCH Baro procedures + GLS


4 The Implementation Challenge

Mandates of Airborne equipment are the favoured option for efficient ATM …

But can be costly for Airspace users

(if the mandate Is too demanding.)

Phased Implementation is a more popular solution

with airspace users but creates mixed mode.

Currently very difficult for ATC to manage effectively

Mixed Mode

Everyone must be the same Differences allowed


5 Why have mixed mode?

• € - $ – Even if fleet can be retrofitted, it may cost too

much

• Physical limitations of older aircraft • Physical/Cost limitations of other aircraft

– E.g. military – E.g. bizjets – E.g. GA


6 Why’s it a challenge?

• Specific routes to accommodate different performance

• Which route spacing? • How does ATC know which clearance to issue?

– The ATC FPL is key….

• How can it be managed from a procedure design perspective?

• What about the data base coding and retrieval?


7 This Forum – ATM Requirements 14h35 – 17h05

• 14h35-14h45: Intro x Forum Champion • 14h45 – 14h55: Airspace Design • 14h55- 15h10: IFP • 15h10 – 15h25: AIM & Charting COFFEE • 15h50 – 1605: Practical PBN Example • 16h05-16h20: ATC Operating Procedures • 16h20- 16h55: Questions • 16h55 – 1705: Summary & Closing

+ Geoff + Aline

(Franca)

(Franca)

(Noppadol)

(Sorin)

(Doug)

(Walter)

(David)

(Franca & David)


8

Airspace Design

ATM Requirements Franca Pavličević

Head of Navigation & CNS Research Unit (EUROCONTROL/DSR) In cooperation with FINAVIA

MIXED MODE

9 Helsinki, Finland – 2000 – First thoughts

• Vantaa had two runways (X) • Parallel Runway to be added to 04/22 • TMA re-design needed

ATM Requirements Forum – Airspace Design

10 Helsinki, Finland – 2000 – Principles


11 Helsinki, Finland – 2000 – Airspace Concept


12

• RNAV 1 needed (pre-PBN P-RNAV in Europe) • Early adopter => lack of guidance material /

specs • Knowing which aircraft are RNAV 1 approved

– Only approx. 50% of operations in the beginning => mixed mode operations only option

Helsinki, Finland – 2002 - Challenge


13

• RNAV 1* STAR’s designed in 2000 using vectored tracks of A/C as a basis => Same track miles to all (RNAV 1/non-RNAV 1)

• Implemented despite low RNAV 1 approval rates • At first, ATCOs had to know which A/C were

approved: Easy to learn due limited A/C variety • A/C informed EFHK APP on initial contact if

following RNAV 1 STAR or if on heading • Currently RNAV 1 approval indicated by system,

based on FPL data

Actions


14 Helsinki, Finland – Implemented routes


15

• RNAV 1 SID’s introduced in 2003 – Less than 50% of operations capable of flying them – A/C departed on headings => problems with noise =>

reverted back to conventional SID’s

• Currently RNAV 1 SID’s in use – Reduced noise impact – A/C shall inform ATC if unable to follow RNAV 1 SID =>

will be given an initial heading as part of clearance

Actions


16

• Benefits – Shorter tracks inside TMA – CDO – Noise impact reduced – AMAN – Reduced workload in HK – Increased efficiency in airspace use

• Glider areas • Danger areas

Results


17

• Operating in mixed mode operations in EFHK not difficult and does not increase ATC load – Since STAR’s are based on actual tracks used when

vectoring, mixed mode operations not a problem • Benefits outweigh risks/challenges • Introduction of RNAV 1 SID’s/STAR’s has helped in

reducing noise impact • RNAV 1 SID’s should not be implemented before

sufficient A/C approval rate is achieved

Lessons Learned


18

Procedure Design

Noppadol Pringvanich Manager, ICAO APAC Flight Procedure

Programme 17 October 2012

MIXED MODE

19

• In mixed traffic environment, different aircraft may have different equipment and PBN approvals.

• Some GNSS equipped aircraft are capable of RNP AR. Some only are capable of RNP APCH.

• Non-GNSS equipped aircraft are still in operation. – ILS is still required for their operations and often ILS

approaches have lower operating minima than RNAV(GNSS)

• Having different aircraft flying different flight paths increase ATC workload and may result in increased safety risks.

Challenges

ATM Requirements Forum – Procedure Design

20

How can we design terminal area procedures to support aircrafts with different equipmentsand PBN

approvals, while harmonizing traffic pattern and controlling ATC workload?

Challenges


21

• Airport with VOR and ILS • Conventional ATS routes connecting to the VOR • Current operation RADAR vector to intercept ILS • All aircrafts have VOR and ILS • 80% of aircrafts are approved for RNAV 1 or RNP 1 • 60% are approved for RNP APCH • 10% are approved for RNP AR

Typical Scenario


22 Typical Scenario


23

• Proper design of RNAV 1 or RNP 1 SID/STAR – Consider proper altitude for crossing points between

ARR/DEP

• Common IAFs of VOR/ILS/RNAV (GNSS) approaches – As much as practicable

• Common IFs of VOR/ILS/RNAV (GNSS) approaches – As much as practicable

• Consistent Missed Approach Procedures and Holdings

Design Considerations


24 Segregating ARR/DEP


25 Linking to VOR approach


26 Linking to ILS approach


27 Linking to RNAV(GNSS) approach


28 How about RNP AR?


29 Overall Mixed Operations


30 Suggestions for ICAO PANS-OPS

• Design criteria and practical examples for joining RNAV-1/RNP-1 with ILS or VOR approaches?

• Reduced Area-semi width for GNSS-based procedure?

• RNP 0.3 for Intermediate and Missed Approach Segment for RNAV(GNSS) procedures?


31

Database Coding and Publication

Sorin-Dan Onitiu Jeppesen

17 October 2012

An inter-disciplinary overview of PBN design, coding and charting

MIXED MODE

32

Generally, basic procedure design has been created for the ‘analog world’;

The art of ‘procedure coding’ is one that balances the intent of design and the FMS requirements

No common standard implemented to have same information charts vs. database

Virtually all the aeronautical databases are loaded according to ARINC 424 standard which specs cover

a large percentage of aeronautical requirements, but not all combinations

Issue: Chart, Database, and Avionics Harmonization

33

Ground-Navaid, Complicated, Rigid paths, Non-standard, Manually flow:

Analog World

Satellite, Simple, Flexible paths, Standard shape, database-driven:

Digital World

Challenge: Role of database & evolution of PD criteria

34

32

Results: Charts & Procedure coding

35 Approach Coding & Design

Route Type concept – includes a ‘primary route type’ and up to two ‘route type qualifiers’ Q1& Q2;

Description: a) Approach Transition (Route Type ‘A’); b) Final Approach Transition (Route Type ‘R’ = APV, ‘H’ = RNP PBN

or ‘J’ = GLS) c) Missed Approach Transition (Route Type ‘Z’);

35 ATM Requirements Forum – Database Coding & Publication

36 Approach Coding Structure

Fixes associated with approach coding

ARINC 424 PANS-OPS

Approach Transition IAF – FACF* Initial Segment IAF - IF

Final Transition FACF* – MAP

Intermediate and Final Segments

IF – FAF - MAPt

Missed Approach Transition MAP – MAHP or end of MA

Initial/Intermediate/ Final MA Segments

MAPt – end of MA phase

* FACF (ARINC) = IF (PANS-OPS)

Final Approach Transition: As a minimum, the coding of final segment must include a fix for the FAF and MAP. A third fix called FACF has to be always included when ‘design’ IF is published.

ATM Requirements Forum – Database Coding & Publication

37 PBN design/charting & coding considerations

Mixed mode (RNAV/Conventional) coding

Primary/Secondary Missed Approach

37

MIXED MODE




Conventional Initial Departure of RNAV 1 SID

MIXED MODE

39

Coding

✈ Vertical Angle for NPA is always included in all straight-in NPA coding solution;

✈ An FMS usually ‘builds’ a profile backwards from a point 50ft above the threshold to the initial (FAF and/or SDF);

MDA and DA are NOT part of the approach coding solution!

✈ Altitude at MAP fix is NOT any of procedure MDA, but it’s a computed mandatory value;

PBN design/charting & coding considerations



Coding of speed restrictions

Speed/Altitude restrictions applied at the waypoint: general situation like ‘Below FL100/IAS 250KT’ has no procedure coding solution;

For approaches, speed limit in FMS will be applied forward throughout the procedure until superseded by another speed limit.

Speed limitation depicted ‘somewhere’ during a turn shall be associated with a waypoint.



Coding of altitude constraints

Altitude constraints have to be clearly associated to a fix; No appropriate coding solution for

minimum segment altitude or MEA’s.

‘Expect altitude’, “Recommended’, “Tactical” procedure altitude cannot be translated appropriately in FMS box language;



Charted Information not provided in NavData database

42

43

43 Database Coding & Publication

Lessons Learned/Summary

Collaboration of all team players is highly recommended!

✈ ARINC 424 is the encoding standard for navigational database consumed by FMS;

✈ For the data houses, ARINC 424 provides the measure of standardization

they can apply; ✈ However: “All things are not equal” in the world of FMS & how they execute a procedure

defined with Path & Terminator legs; Most of limitations are coming from the FMS execution logic and not procedure

design constraints; ARINC 424 is not a “charting standard “ file structure (it maybe addressed by the NDB

industry group; Challenges DB/Publication , specifically for “Mixed –Mode” operations (cannot

properly be reflected in the FMS);

43

44

Air Traffic Control Operating Procedures

Walter White ICAO PBN Technical Officer

17 October 2012

MIXED MODE

45 Issue/Challenge

ATM Requirements Forum – ATC Operating Procedures

i1 – ATC is a key component in a successful PBN implementation.

i2 – ATC operating procedures to accommodate PBN. •Integrated Design •Phraseology •Education

i3 – PBN sequencing and transitional environments.

46 Overview

ATM Requirements Forum – ATC Operating Procedures

• We make successful what we want to do

• Simplify – we tend to make this more complicated than it is

• Watch your assumptions

• The devil is in the details – good design vs. poor design

• We must change our work habits to take advantage of new technologies

• We have managed change before

47

47

Why PBN?

48

48

ATC key component in successful PBN implementation.

•Buy in - Benefits described in terms of ATC • Reduced radio transmissions • Increased track predictability • Increased safety • ATM vs AT Vectors

•ATC is sometimes an afterthought in the PBN design process • Good design enables ATC participation • Include ATC early in a collaborative design process • Consider existing VA tracks for RNAV(RNP) • Guided Visual Approach • Transition plan implemented

49

49

ATC operating procedures to accommodate PBN.

• Design in updated techniques

• CDO • CCO

• Education

• Concept of operations • ATC benefits • Phraseology • Clear responsibilities defined

• START

50

50

PBN sequencing and transitional environments.

• Point merge

• Structured decision points

• Defined Interval

• Required Time of Arrival

Managed by design, education and technique

DI Target Level of Safety

51

Practical Experiences and

Air Traffic Management

Doug Marek FAA Operations Manager,

17 October 2012

Greener Skies over Seattle

MIXED MODE

52 Issue/Challenge

i1 –Design/Implement PBN instrument procedures into a complex airspace, with a mixed fleet, all while providing an environment for research.

i2 - Evaluate concepts, research alternatives and establish requirements resulting in full implementation of PBN technologies within SEA/BFI airspace and NAS-wide.

i3 - Implementation of new procedure, rule making, and TFM/training.

ATM Requirements Forum – Practical Experiences & ATM

53

53 Collaboratively Innovating and Implementing PBN – Greener Skies over Seattle

Actions

Connect RNAV STARs with all RNAV, RNP, RVFP,

and ILS Approaches.

Keys to Success: ATC/Pilot use

Repeatable in all WX TFM

54

54 Collaboratively Innovating and Implementing PBN – Greener Skies over Seattle

Connecting RNAV STARs with RNP, RVFP,

and ILS Approaches

55 RNAV vs. Conventional

STAR Build speeds and altitudes

into procedures

56 Results

Collaboratively Innovating and Implementing PBN – Greener Skies over Seattle

•Predictable tracks, speeds, and reduced radio communications

•Allows ATC to clear aircraft on any instrument approach procedure to all runways •Overlay different types of PBN IFP, covering all weather conditions, keeping ATC/flight deck/TFM simple

57 Lessons Learned

Collaboratively Innovating and Implementing PBN – Greener Skies over Seattle

• Integrate new PBN flight procedures alongside conventional routes in collaboration with all stakeholders

• Connect STARs to all approaches and runways • Build in speeds to allow for ATM/TFM predictability

58

Question Time

THE FLOOR IS YOURS

ATM Requirements - ICAO...ARINC 424 is not a “charting standard “ file structure (it maybe...

Documents

Transcript of ATM Requirements - ICAO...ARINC 424 is not a “charting standard “ file structure (it maybe...