Summary of the First Meeting Special Committee 227 ... - RTCA
Summary of the First Meeting Special Committee 227 ... - RTCA
Summary of the First Meeting Special Committee 227 ... - RTCA
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Summary</strong> <strong>of</strong> <strong>the</strong> <strong>First</strong> <strong>Meeting</strong><br />
<strong>Special</strong> <strong>Committee</strong> <strong>227</strong><br />
Standards <strong>of</strong> Navigation Performance<br />
<strong>RTCA</strong> Paper No. 074-12/SC<strong>227</strong>-002<br />
March 12, 2012<br />
The first meeting <strong>of</strong> SC-<strong>227</strong> was held on 7 – 9 March 2012 at <strong>RTCA</strong> Headquarters,<br />
1150 18 th Street, N.W., Suite 910, Washington, D.C. 20036. The attendees were <strong>the</strong> following:<br />
Dave Nakamura (Chairman)<br />
Mike Jackson (Secretary)<br />
Raghavendra Achanta<br />
Frank Alexander<br />
Ken Alexander<br />
Pete Branower<br />
Kevin Bridges<br />
Ge<strong>of</strong>f Burtenshaw<br />
Alexandre Capodicasa<br />
Perry Clausen<br />
Michael Cramer<br />
David De Smedt<br />
Bruce DeCleene<br />
Guy Deker<br />
Steve Fulton<br />
Bob Gaul<br />
Tim Geels<br />
Michael Gordon-Smith<br />
Marc Henegar<br />
John Hillier<br />
Larry Hills<br />
Barry Irwin<br />
Steven Jackson<br />
Don Jansky<br />
David Jaquith<br />
Terry Jones<br />
Greg Joyner<br />
Tom Kramer<br />
Jarrett Larrow<br />
Erwin Lassooij<br />
The Boeing Company<br />
Honeywell International, Inc.<br />
Tetra Tech<br />
International Air Transport Association<br />
Federal Aviation Administration<br />
Consultant<br />
Federal Aviation Administration<br />
UK - Civil Aviation Authority<br />
Esterline CMC Electronics<br />
Southwest Airlines<br />
The MITRE Corporation<br />
EUROCONTROL<br />
FAA<br />
Thales Avionics<br />
GE Aviation<br />
Garmin<br />
Rockwell Collins, Inc.<br />
CMC Electronics an Esterline Company<br />
Air Line Pilots Association<br />
Honeywell International, Inc.<br />
Federal Express Corporation<br />
The MITRE Corporation<br />
Federal Aviation Administration<br />
Jansky-Barmat Telecommunications<br />
GE Aviation<br />
Federal Express Corporation<br />
Federal Aviation Administration<br />
Aircraft Owners and Pilots Association<br />
Federal Aviation Administration<br />
International Civil Aviation Organization<br />
1
Gary Livack<br />
Wendy Ljungren<br />
Ca<strong>the</strong>rine Majauskas<br />
Pierre Marchi<br />
Paul McGraw<br />
Jeff Meyers<br />
Barry Miller<br />
Sam Miller<br />
John Moore<br />
Harold Moses<br />
Laurence Mutuel<br />
James Nicholls<br />
Russell Ramaker<br />
Sylvain Raynaud<br />
Ron Renk<br />
Jeff Robinson<br />
Jim Savage<br />
Les Schroeppel<br />
Marissa Singleton<br />
Peter Skaves<br />
Ted Urda<br />
Stephen Van Trees<br />
Kenneth Wise<br />
Chris Wynnyk<br />
David Zeitouni<br />
Federal Aviation Administration<br />
GE Aviation<br />
Federal Aviation Administration<br />
EMBRAER<br />
Air Transport Association <strong>of</strong> America<br />
Federal Aviation Administration<br />
Federal Aviation Administration<br />
The MITRE Corporation<br />
Federal Aviation Administration<br />
<strong>RTCA</strong>, Inc.<br />
Thales<br />
Honeywell International, Inc.<br />
GE Aviation<br />
Airbus Americas, Inc.<br />
United Airlines, Inc.<br />
CNI Aviation LLC<br />
Innovative Solutions International, Inc.<br />
SAIC<br />
The Boeing Company<br />
Federal Aviation Administration<br />
Federal Aviation Administration<br />
Federal Aviation Administration<br />
Innovative Solutions International, Inc.<br />
The MITRE Corporation<br />
The Boeing Company<br />
**************************************************************************<br />
In accordance with <strong>the</strong> Federal Aviation Advisory <strong>Committee</strong> Act, Jarrett Larrow, Federal<br />
Aviation Administration (FAA), was <strong>the</strong> designated Federal Employee for this meeting.<br />
**************************************************************************<br />
Dave Nakamura opened <strong>the</strong> first plenary session <strong>of</strong> <strong>RTCA</strong> SC-<strong>227</strong> at 9:00 am on March 7, 2012. After<br />
brief introductions, Dave reviewed <strong>the</strong> agenda. He noted that <strong>the</strong> agenda was now more detailed than <strong>the</strong><br />
general announcement, and pointed out that <strong>the</strong> expectation was that work would commence this week,<br />
noting <strong>the</strong> current scheduled due date <strong>of</strong> June 13 , 2013 for <strong>the</strong> committee deliverables.<br />
No changes were made to <strong>the</strong> agenda and it was approved by <strong>the</strong> committee. During <strong>the</strong> meeting session,<br />
adjustments were made to stay in plenary, ra<strong>the</strong>r than <strong>the</strong> planned breakouts, to get a group understanding<br />
<strong>of</strong> <strong>the</strong> issues, plans <strong>of</strong> actions and next steps. The flow <strong>of</strong> <strong>the</strong> meeting discussions were as follows:<br />
TUESDAY, 3/6 ............................................................................................................................................................. 3<br />
ATTENDEES ................................................................................................................................................................ 3<br />
OVERVIEW: <strong>RTCA</strong>, FAA, COMMITTEE – HAL MOSES, JARRETT LARROW AND DAVE NAKAMURA .......................... 3<br />
PBN, NEXTGEN, AND THE RELATIONSHIP TO NAVIGATION STANDARDS – MARK STEINBICKER ............................... 3<br />
2
NEXTGEN IMPLEMENTATION PLAN (NGIP) - BRUCE DECLEENE .............................................................................. 5<br />
WG85 ACTIVITIES - SYLVAIN RAYNAUD ................................................................................................................... 7<br />
STANDARDS OF NAVIGATION PERFORMANCE – GEOFF BURTENSHAW....................................................................... 8<br />
SC181 HISTORY PERSPECTIVE AND NEED FOR FMS STANDARDS – FRANK ALEXANDER ........................................ 10<br />
SC181 HISTORY PERSPECTIVE AND THOUGHTS FOR SC<strong>227</strong> – JOHN HILLIER .......................................................... 10<br />
WEDNESDAY, 3/7 .................................................................................................................................................... 12<br />
FMS STANDARDIZATION – MIKE CRAMER .............................................................................................................. 12<br />
WALK THROUGH OF DO-236B MASPS .................................................................................................................. 14<br />
THURSDAY, 3/8 ........................................................................................................................................................ 18<br />
MEETING SCHEDULE AND SCOPE ............................................................................................................................. 18<br />
SCHEDULE DISCUSSION REGARDING MOPS UPDATE............................................................................................... 20<br />
WALK THROUGH OF DO-283A MOPS .................................................................................................................... 20<br />
PRIORITIZATION AND SCOPE OF UPDATES TO BE MADE ........................................................................................... 21<br />
Tuesday, 3/6<br />
Attendees<br />
Hal Moses agreed to distribute <strong>the</strong> attendee list... (listed above)<br />
Overview: <strong>RTCA</strong>, FAA, <strong>Committee</strong> – Hal Moses, Jarrett Larrow and<br />
Dave Nakamura<br />
Powerpoint: “SC-<strong>227</strong> New <strong>Committee</strong> - <strong>RTCA</strong> Briefing - mjhem.pptx , SC<strong>227</strong>-FAA Involvement.pptx and<br />
SC<strong>227</strong> <strong>Meeting</strong> 1 Agenda and Work Plan R1”<br />
Hal gave a brief overview <strong>of</strong> <strong>RTCA</strong>, <strong>the</strong> general processes and <strong>the</strong> committee workspace.<br />
Jarrett provided a brief overview <strong>of</strong> <strong>the</strong> FAA groups whose activities and expertise were relevant to this<br />
group. He touched on <strong>the</strong> Aircraft Certification Directorate (AIR), Flight Standards (AFS), and Air<br />
Traffic Organization’s PBN Integration (AJV) and Navigation Services (AJW) groups. Additional,<br />
NextGen support is expected to be as needed from <strong>the</strong> advanced concepts and technology development<br />
(ANG-C) with regard to <strong>the</strong>ir 4DFMS research and Wind/TBO projects.<br />
Dave reviewed <strong>the</strong> meeting plan and noted that it would be adjusted as we go along. The primary<br />
objective was to get a better bound on <strong>the</strong> scope <strong>of</strong> issues, <strong>the</strong> steps <strong>the</strong> committee would take and <strong>the</strong><br />
TOR schedule and deliverables. The big challenge besides producing a MASPS and MOPS, was to get a<br />
clear picture <strong>of</strong> <strong>the</strong> updates needed to <strong>the</strong> document and <strong>the</strong> scope <strong>of</strong> any new material that will be added.<br />
In producing <strong>the</strong> updated documents, <strong>the</strong> efficient use <strong>of</strong> committee time in its efforts will matter. Dave<br />
indicated that this means that committee expertise will be focused on <strong>the</strong> key issues and that nominal<br />
editorial changes will be undertaken separately. Given this approach <strong>the</strong> committee will still have a say<br />
on all aspects <strong>of</strong> <strong>the</strong> document contents.<br />
PBN, NextGen, and <strong>the</strong> Relationship to Navigation Standards – Mark<br />
Steinbicker<br />
Powerpoint: “3 ef NextGen Perspective.ppt”<br />
Mark is <strong>the</strong> manager <strong>of</strong> AFS-470 – operational implementation <strong>of</strong> PBN in flight deck. Mark Steinbicker<br />
is also <strong>the</strong> US lead to ICAO PBN study group. Mark summarized some <strong>of</strong> <strong>the</strong> historical and context<br />
aspects <strong>of</strong> PBN. He started by illustrating <strong>the</strong> broad array <strong>of</strong> applications <strong>of</strong> RNAV and RNP in <strong>the</strong><br />
3
2000’s and earlier and <strong>the</strong> expanding needs globally in <strong>the</strong> future. He pointed out that one <strong>of</strong> <strong>the</strong> steps<br />
taken was through ICAO. Specifically <strong>the</strong> formation <strong>of</strong> <strong>the</strong> ICAO RNP <strong>Special</strong> Operational<br />
Requirements Study Group (RNPSORSG) around 2004 and its successor <strong>the</strong> Performance Based<br />
Navigation Study Group (PBN SG) from 2008 until <strong>the</strong> present was an effort to increase <strong>the</strong><br />
understandability <strong>of</strong> RNAV and RNP, though greater harmonization and consistency in <strong>the</strong> types <strong>of</strong><br />
RNAV and RNP criteria for aircraft qualification, operational approval and implementation<br />
considerations. This effort represented <strong>the</strong> creation <strong>of</strong> and transition to PBN and <strong>the</strong> development <strong>of</strong> <strong>the</strong><br />
PBN Manual, ICAO Doc 9613. Mark pointed out that one <strong>of</strong> <strong>the</strong> key aspects <strong>of</strong> PBN was <strong>the</strong><br />
differentiation between RNAV and RNP. While both have performance requirements, RNP has on-board<br />
performance monitoring and alerting (OBPMA). It is OBPMA where <strong>the</strong> greater assurance <strong>of</strong> RNP<br />
system performance is provided. Mark also highlighted with examples that <strong>the</strong>re is still room and a need<br />
for more improvement to reduce <strong>the</strong> operational variability in aircraft flight path performance.<br />
Bruce DeCleene is <strong>the</strong> manager <strong>of</strong> <strong>the</strong> Aircraft Certification group, AIR-130. Bruce started out by setting<br />
a number <strong>of</strong> considerations as SC<strong>227</strong> goes forward. Specifically, he pointed out folding in lessons<br />
learned such as<br />
pilot awareness <strong>of</strong> sensor inputs,<br />
speed/altitude,<br />
wrong runway entry<br />
global harmonization through linkage to <strong>the</strong> ICAO navigation specifications, and raising <strong>the</strong> bar on<br />
performance and capability where it’s appropriate such as<br />
pilot and air traffic expectations,<br />
turn performance, including fixed radius and<br />
support <strong>of</strong> TSE monitoring and alerting.<br />
JohnH: Is <strong>the</strong>re regulatory basis on <strong>the</strong> PBN manual document Were <strong>the</strong> same experts as here involved<br />
in writing <strong>the</strong> PBN manual<br />
MarkS (PBN Study Group, US Member): The PBN manual was meant to embrace existing equipment.<br />
It was not meant as a certification document.<br />
DaveN (Chair <strong>of</strong> PBN Study Group and ICCAIA Member): The PBN manual has not been used<br />
consistently in <strong>the</strong> way we expected. It is being used as a regulatory document by some states without <strong>the</strong><br />
appropriate considerations that must be made and as spelled out in <strong>the</strong> manual itself.<br />
Ge<strong>of</strong>fB (PBN Study Group, UK Member): There was a proliferation <strong>of</strong> standards that needed to be<br />
focused. That harmonization is focused at <strong>the</strong> regulatory level. The problem is that <strong>the</strong> linkage with<br />
MASPS and MOPS has been lost. The MASPS and MOPS didn’t have any force into usage in service.<br />
As a result we have had a proliferation <strong>of</strong> standards and applications. The challenge is to bring it all back<br />
toge<strong>the</strong>r. The only way to have airspace development is to have interoperability and aircraft meeting a<br />
standard.<br />
BruceDC(RNP SORSG, FAA Member): SC181 did a good job laying a foundation. What has happened<br />
since is taking that and turning it into practice. It has not been simple with RNP, RNAV, and RNP<br />
RNAV. The need is to reestablish <strong>the</strong> connection between <strong>the</strong> operational side developed since SC181<br />
back into <strong>the</strong> equipment standards.<br />
JH: Is <strong>the</strong>re a comment period for <strong>the</strong> new PBN manual<br />
Erwin (PBN Study Group, ICAO Secretariat, and PBN Program Manager): There is sort <strong>of</strong> a comment<br />
process but it must be through attendee members.<br />
MarkS: There is also no intent to create specs that distinguish between GA and AT. Please provide<br />
feedback through me. We try to minimize differences between expectations <strong>of</strong> how FAA and EASA will<br />
use <strong>of</strong> <strong>the</strong> manual.<br />
4
NextGen Implementation Plan (NGIP) - Bruce DeCleene<br />
Powerpoint: “3 ef NextGen Perspective.ppt”<br />
What should be included in <strong>the</strong> next round <strong>of</strong> equipment<br />
Bruce pointed out that <strong>the</strong> NGIP includes <strong>the</strong> operations concept for 2018. One appendix relates <strong>the</strong><br />
concepts to <strong>the</strong> aircraft equipment required. The NGIP is updated every year to reflect progress and<br />
budgets. The 2012 document should be released at any moment.<br />
Bruce also stated that <strong>the</strong> 2025 TBO vision is contained in <strong>the</strong> JPDO NextGen Avionics Roadmap, v2.0<br />
Sept 2011, an effort led by Steve VanTrees and Frank Alexander. In particular, Appendix 1 talks about<br />
Trajectory Operations.<br />
Trajectory Operations is a transformation that reflects specific steps:<br />
1. Now: procedural control – pre-radar, shrimp boats<br />
2. Next: surveillance based control – radar-based<br />
3. Future: trajectory based control – where <strong>the</strong>re is knowledge <strong>of</strong> a future trajectory, not just<br />
prediction. It will be based on RNP, ADS-B, and DataComm<br />
The Mid-term objective is to turn <strong>the</strong> automation / human interaction picture inside out. Instead <strong>of</strong><br />
humans at <strong>the</strong> center supported by automation, we want automation at <strong>the</strong> center supported by humans.<br />
Automation systems will be connected via data links with human supervision and management<br />
The Unifying concepts for this future are:<br />
performance and windows for lateral, vertical and temporal aspects <strong>of</strong> trajectories.<br />
phases <strong>of</strong> trajectory operations will have different enablers:<br />
o pre-negotiation (over SWIM)<br />
o negotiation (over SWIM)<br />
o agreement (over Data Comm.)<br />
o execution (via ADS-B and Data Comm.)<br />
Implementation <strong>of</strong> Trajectory Ops will depend on a number <strong>of</strong> factors.<br />
use ICAO PBN manual, but move forward with Advanced RNP for NextGen.<br />
an updated MASPS will serve as <strong>the</strong> basis for FAA policy for implementation though:<br />
o 20-series AC<br />
o 90-series AC for equipment and operational guidance<br />
An updated MOPS will be invoked by TSO for forward-fit only.<br />
As we write <strong>the</strong> new standard, will we need to debate how far forward do we reach with new capability<br />
Bruce suggested that we should consider that a standard that we write as forward fit only, or mandate for<br />
retr<strong>of</strong>it. We should avoid optional capabilities – we have learned over and over again that ANSPs need a<br />
homogenous fleet. Optional capabilities will not be usable. The PBN SG does not need <strong>the</strong> result <strong>of</strong> this<br />
group to move forward – SC<strong>227</strong> should focus on new capability going forward. The FAA expectation is<br />
that we focus on forward fit, and <strong>the</strong> retr<strong>of</strong>it decisions will be made regionally based on when it becomes<br />
appropriate to mandate to all aircraft.<br />
Ge<strong>of</strong>fB: any looking forward is a risk that when it comes time to implement/deploy that <strong>the</strong> environment<br />
will be changed and our original vision and standard will not be what we actually want to implement as<br />
<strong>the</strong> operational concept has evolved. We need to be aware <strong>of</strong> this risk.<br />
BruceD: fundamental risk is in <strong>the</strong> new product development, that we develop new products that do not<br />
provide benefit down <strong>the</strong> road. That is why we develop a standard – everyone starts developing similar<br />
products at <strong>the</strong> same time to make providing benefits more feasible. We need to determine what new<br />
capability is required, with a high probability <strong>of</strong> becoming real, and focus <strong>the</strong> standard on that.<br />
JohnH: Question on TSO. Is this a new TSO How does this work<br />
5
BruceD: When we keep <strong>the</strong> same number with a new letter, 115b over 115a, it stops new design approval<br />
with <strong>the</strong> old standard (after a grace period). This group will need to provide guidance on whe<strong>the</strong>r new<br />
MOPS replaces DO283 or is a separate MOPS / TSO.<br />
The term “intended function” is used in regulatory publications. We should avoid using this term in our<br />
standards as it is not our role to define that.<br />
Need for updating navigation standards<br />
There are a number <strong>of</strong> updates that need to be considered.<br />
PBN enhancements<br />
o Turn performance (operators want tighter radius turns, achieving IMC ops like VMC ops<br />
is huge)<br />
o Path repeatability under stress (sharp angles, climbing faster than expected, accelerating,<br />
etc.)<br />
Performance<br />
o Reconcile GNSS and PBN monitor requirements (eg. ICAO PBN manual)<br />
o Review containment integrity and continuity<br />
Time <strong>of</strong> arrival control<br />
o Tolerance (manual or autothrottle FTE)<br />
o Required wind data<br />
o One or more time constraints<br />
o Integration with relative time <strong>of</strong> arrival control (ads-b based)<br />
Vertical navigation<br />
o Temperature compensation, including transition between with and without compensation<br />
and managing separation<br />
o Complex paths (multiple constraints), tighter tolerance as in RNP AR VEB<br />
o Do we need vertical RNP<br />
Lateral navigation<br />
o Aircraft-defined path stretching Bracket allowable changes.<br />
Alignment/Integration with Data Comm, SC214<br />
This is one <strong>of</strong> <strong>the</strong> key activities for <strong>the</strong> committee. We need to ensure that <strong>the</strong> navigation aspects <strong>of</strong> <strong>the</strong><br />
assumed operations, data and data interfaces are right. The gaps and changes need to be identified to<br />
SC214 quickly.<br />
ATN-B2 defined by SC-214/WG78, to be complete in 2013<br />
CPDLC, ADS-C, DFIS (wind data)<br />
Requires standardized set <strong>of</strong> navigation abilities<br />
Issue: uplinked routes don’t allow specification <strong>of</strong> leg types<br />
o Lack <strong>of</strong> RF legs<br />
o Lack <strong>of</strong> names for created waypoints to facilitate crew/controller voice<br />
Validate SC214 products from navigation perspective<br />
o ETA min/max assumptions<br />
Provide new implementation requirements as appropriate<br />
o E.g. display <strong>of</strong> proposed route clearance prior to acceptance<br />
Alignment/Integration with ADS-B, SC186<br />
The same holds true for SC186 in terms <strong>of</strong> navigation and <strong>the</strong> part it plays in applications for interval<br />
management and separation standards.<br />
Interval management<br />
o assigns spacing to o<strong>the</strong>r aircraft<br />
o from navigation perspective, many common issues to TOAC<br />
6
• flight deck display <strong>of</strong> speed cues<br />
• evaluating feasibility <strong>of</strong> making constraints while following ano<strong>the</strong>r aircraft<br />
• FET allocation and winds<br />
Improving separation standards with ADS-B and Navigation<br />
o Need accurate nav and surveillance combined to provide benefit<br />
o Use surveillance to “cut <strong>the</strong> tails <strong>of</strong>f” <strong>the</strong> navigation errors.<br />
Regarding interval management vs. 4D TBO, Bruce advocated implementing both technologies and using<br />
<strong>the</strong>m regionally as appropriate.<br />
Additional Considerations<br />
Bruce also pointed out o<strong>the</strong>r possible areas <strong>of</strong> change in <strong>the</strong> updates.<br />
position estimation<br />
o need our standard to not depend upon GNSS specifics, because <strong>the</strong>se will change.<br />
integration with approach operations<br />
o e.g. transition between RNP route and ILS is not defined<br />
o dynamic RF-leg trombone called by controller (over data comm.)<br />
alignment with stand-alone navigator – SC159<br />
o SC159 dumbed down SC181 result to create a GA product, but it has become a headache<br />
to maintain two nav standards.<br />
WG85 Activities - Sylvain Raynaud<br />
Sylvain Raynaud, Airbus FMS Engineer, Eurocae WG85 Chairman<br />
Powerpoint: “WG 85 activities presentation.ppt”<br />
Sylvain stated that <strong>the</strong> WG85 efforts started in Oct 2009, and that <strong>the</strong>re have been 5 meetings, and 19<br />
webexes to date. The ED75 addendum containing updated requirements for ETA and Time <strong>of</strong> Arrival<br />
Control has been drafted. The current draft is as <strong>of</strong> June, 2011.<br />
Validation activities that are supporting <strong>the</strong>ir efforts are:<br />
Prior experiments – Cassis, NUP II<br />
Seattle RTA trials<br />
SESAR Initial 4D validation<br />
The WG85 publication target is mid 2013.<br />
This ensures coordination with WG78/SC214<br />
It supports certification <strong>of</strong> Initial4D-capable certified systems to meet SESAR timetable<br />
Their operational assumptions are based on SESAR and <strong>the</strong> WG78 4DTRAD OSEDs. Sylvain provided<br />
a high level overview <strong>of</strong> <strong>the</strong> concept <strong>of</strong> operations with emphasis on <strong>the</strong> trajectory , aircraft/ground<br />
exchanges and expected benefits.<br />
The ED75 addendum draft criteria that support <strong>the</strong> 4D aspects <strong>of</strong> <strong>the</strong> operations are:<br />
TOAC remains optional<br />
ETA in open loop operations characterized<br />
Meteo error assumptions created<br />
RTA 95% reliability defined<br />
ETA min/max function defined for 95% confidence<br />
RTA precision down to 10 seconds in terminal airspace or en-route airspace<br />
Means <strong>of</strong> compliance updated/created<br />
7
White papers supporting <strong>the</strong> addendum changes are:<br />
Distance reduction analysis, open and closed loop<br />
what is ETA minmax<br />
ETA uncertainty 95% envelope model in open and closed loop<br />
Meteo error analysis<br />
WG85 input to WG78 (in work)<br />
o Clarify any unclear aspect concerning about functional content <strong>of</strong> <strong>the</strong> 4D trajectory (EPP)<br />
o Propose updates for potential missing info<br />
o Underline EPP requirements with significant impact on nav systems without clear<br />
associated need.<br />
RTA 95% accuracy demonstration methodology<br />
Sylvain indicated that <strong>the</strong> WG85 addendum and papers would be shared with SC<strong>227</strong>.<br />
The SESAR Initial4D validation is a phased approach with three steps planned.<br />
Initial4D airborne prototypes available now by Honeywell and Thales for demonstration aircraft.<br />
Improved RTA performance in descent: +/- 10 seconds with 95% reliability<br />
Improved wea<strong>the</strong>r modeling – additional wind and temperature levels available<br />
ETA min/max computed in FMS and reported over new ADS-C report<br />
Datalink draft standard implemented – CPDLC and ADS-C updates per WG78<br />
Initial4D ground function prototypes are also available now<br />
By Maastrict (Enroute) and NORACON (TMA)<br />
Datalink per WG78 draft standard<br />
Controller working position using new generation HMI<br />
(more on slide 21)<br />
AMAN functionality expanded<br />
A Flight test was conducted in late 2011<br />
Coupled and non-coupled simulators in development for ground-based testing <strong>of</strong> integrated system<br />
Coupled = aircraft simulated at Airbus connected over internet to ATM simulation<br />
Objective <strong>of</strong> simulations is to model operational performance issues and benefits<br />
Proposed way forward with SC<strong>227</strong> – Sylvain that he was just presenting <strong>the</strong> EUROCAE position.<br />
EUROCAE is interested in keeping ED75 & DO236 a common document<br />
But, WG85 scope is not as wide as SC<strong>227</strong><br />
EUROCAE want only one EUROCAE WG to impact ED75 at a time, and WG85 already existed,<br />
so WG85 scope will expand to cover additional RNP aspects<br />
Proposed to have joint WG85/SC<strong>227</strong> activities starting now for RNP and GNSS, but not Initial4D<br />
Concerning keeping Initial4D efforts on track, <strong>the</strong> following ideas were <strong>of</strong>fered.<br />
o Create a dedicated sub-group in WG85 and SC<strong>227</strong><br />
o Start with coordinated (not joined) activities to secure <strong>the</strong> output <strong>of</strong> a final ED75<br />
addendum in mid-2013 by WG85 subgroup<br />
o After mid-2013, transition to joined activities on I4D scope<br />
WG85 scope will grow to match <strong>the</strong> scope <strong>of</strong> SC<strong>227</strong>.<br />
WG85 TOR to be updated and new call for participation for wider participation to cover RNP and GNSS.<br />
Hal Moses (<strong>RTCA</strong>) indicated that due to <strong>the</strong> complicated and slow process for joint committees, <strong>the</strong> best<br />
way to go forward for now is to just work toge<strong>the</strong>r until <strong>the</strong> formalities can be worked out.<br />
Standards <strong>of</strong> Navigation Performance – Ge<strong>of</strong>f Burtenshaw<br />
Ge<strong>of</strong>f Burtenshaw, UK CAA, former Co-Chair <strong>of</strong> Joint SC181/WG-13<br />
8
Powerpoint: “3a Standards <strong>of</strong> Navigation Performance GB 20120306.pptx”<br />
Review <strong>of</strong> SC181/WG13 products and intended applications<br />
Ge<strong>of</strong>f pointed out <strong>the</strong> importance and value <strong>of</strong> standards.<br />
interoperability<br />
o without interoperability, every route or instrument procedure and airspace would have to<br />
account for different aircraft capability<br />
o precludes efficiency, capacity, and environmental improvements<br />
cost <strong>of</strong> certification<br />
non-optimized airspace design, since every variation must be considered.<br />
Scope <strong>of</strong> standards<br />
not just <strong>the</strong> airborne nav system is standardized<br />
terminology<br />
aeronautical data<br />
procedure design affected by nav standards<br />
charting<br />
SC181 products and adoption <strong>the</strong>re<strong>of</strong><br />
Do236B/ED75B MASPS for RNP<br />
o Intended/Used as a toolbox, implemented piecemeal by regulators<br />
DO200A/ED76 Standards for processing aeronautical data<br />
DO201A/ED77 standards for aeronautical information<br />
DO283A MOPS for RNP for RNAV<br />
o No ED equivalent<br />
o TSO-C115c, FMS using multi-sensor inputs 2012<br />
DO257A, MOPS<br />
Adoption has been affected adversely by<br />
GPS standards, DO-229<br />
SC159 and SC181 which worked in parallel and were never brought toge<strong>the</strong>r<br />
Slow and fragmented airspace development<br />
o Lack <strong>of</strong> harmonized operational requirements<br />
Future for navigation performance standards<br />
PBN is now <strong>the</strong> ‘must-have’<br />
GPS standards are insufficient on <strong>the</strong>ir own<br />
Considerations for SC<strong>227</strong><br />
Recognition <strong>of</strong> PBN concept, but keep RNP RNAV distinct as DO236/ED75 is only one means<br />
to define an aircraft/system that spans multiple applications.<br />
Functional definitions insufficient to support implementation. Changes are needed for:<br />
o fixed radius transition<br />
o tactical parallel <strong>of</strong>fset<br />
o use <strong>of</strong> speed and altitude constraints in path definition<br />
VNAV mess since <strong>the</strong>re has been little convergence on a standard.<br />
o AC20-138B is 1980’s definition<br />
o EASA AMC 20-27 (FTE and altitude limitation)<br />
o AC 90-110a / AMC 20-26 Vertical Error Budget<br />
o Do-236B / ED75b VNAV<br />
Current PANS Ops Baro-VNAV design criteria needs a harmonized standard.<br />
Inconsistency with lateral RNP RNAV – do we need a vertical RNP RNAV ra<strong>the</strong>r than just a<br />
99.7% accuracy<br />
4D trajectories<br />
9
o Are <strong>the</strong> ATM operational concepts well enough defined<br />
o Clear that <strong>the</strong>re is some relationship between ground and air systems<br />
Coordination with SC214 / WG78 data comm. standards is needed.<br />
Interim steps to 4D that need to be considered.<br />
o Enhanced time-based flow mgmt<br />
o Use <strong>of</strong> target time <strong>of</strong> arrival<br />
o Part <strong>of</strong> an AMAN/DMAN + collaborative ATM<br />
o Need to provide adequate intent information to <strong>the</strong> ground systems<br />
Perhaps <strong>the</strong> CNS section in DO236 needs to better explain <strong>the</strong> interrelations to o<strong>the</strong>r systems<br />
Help define clearer requirements for 4D requirements and operations<br />
Harmonization with WG85<br />
Need to bring SC214/WG78 into line or accept <strong>the</strong>re may need to be rework<br />
Data quality – DO-200A is a bit dated, perhaps needs to be updated<br />
<strong>Summary</strong><br />
Need all stakeholders, especially controllers, participating.<br />
SC181 History Perspective and Need for FMS Standards – Frank<br />
Alexander<br />
Frank Alexander, IATA, former Co-Chair <strong>of</strong> Joint SC181/WG13.<br />
Powerpoints: “3b SC-<strong>227</strong> History Presentation.pptx “ & “3b FMS standardization presentation.ppt”<br />
Early 1990s observed need for FMSs from disparate suppliers and OEMs to have similar behavior.<br />
December, 1993 was <strong>the</strong> first SC181 meeting. In early 1994, SC181 joined with WG13.<br />
Frank stated that we must try to look forward 20 years to what <strong>the</strong> requirements will be so that we can<br />
define <strong>the</strong> system once now, since upgrade opportunities for airplanes happen seldom. Today’s technical<br />
standards do not incorporate <strong>the</strong> requirements that are needed to insure consistent performance across all<br />
lines <strong>of</strong> FMC.<br />
The main concerns, and areas <strong>of</strong> differences are:<br />
Turn performance variation<br />
Phase <strong>of</strong> flight transitions – variations affect<br />
o roll rates, speeds, default RNP values, display scaling<br />
Dissimilar VNAV path construction<br />
RTA differences<br />
o What are <strong>the</strong> performance numbers<br />
o Acceptable tolerances for ATM<br />
o How is it achieved<br />
o Availability <strong>of</strong> intent<br />
Database coding<br />
o Offsets, dep/app procedures, speed constraints<br />
Holding<br />
o Wide variation in paths for holding patterns<br />
Sylvain: common performance requirements will not allow manufacturers to optimize <strong>the</strong>ir aircraft<br />
performance.<br />
SC181 History Perspective and Thoughts for SC<strong>227</strong> – John Hillier<br />
John Hillier, Honeywell<br />
Powerpoint: “3c SC <strong>227</strong> KOM - Honeywell.ppt”<br />
John led <strong>the</strong> SC-181 path definition subgroup, co-chaired with Airbus’s Gilles DeCevin<br />
John pointed out that RNP RNAV certification now is painful and we need to fix this!<br />
10
Sharing <strong>of</strong> common flight plan between air and ground (ADS-C EPP) is <strong>the</strong> key to TBO.<br />
Datalink is <strong>the</strong> enabler.<br />
RTA is one piece <strong>of</strong> <strong>the</strong> puzzle, but <strong>the</strong>re are concerns about different solutions affecting separation.<br />
Deterministic LNAV and VNAV is required.<br />
Lessons learned<br />
Not being tied out with SC159 really hurt<br />
o SC214 is strikingly similar situation, is data link driving nav/guidance<br />
o Security, this is more than data, it’s <strong>the</strong> expanding scope <strong>of</strong> security into operations.<br />
o ADS-B impact to navigation is ano<strong>the</strong>r area.<br />
Nav world was and still is split between GPS/WAAS and RNP SC’s<br />
o Not close to being harmonized<br />
o Full time RNP vs. RNP RNAV<br />
o AR RNP vs. non-AR RNP<br />
We should have dealt more with classic procedures and use <strong>of</strong> <strong>the</strong> RNP concept<br />
Need to tie out CAAs<br />
We need to make it so pilots can understand this stuff<br />
Problematic areas in SC181, still need to be addressed<br />
o Offsets<br />
o Temp Comp<br />
o VNAV<br />
o Fixed radius transitions<br />
• Started simple – name <strong>of</strong> airway indicated<br />
o RNP holds<br />
o Integrity<br />
o Accuracy models<br />
o Flight deck annunciations<br />
How things evolved<br />
Evolve existing concept <strong>of</strong> RNAV into RNP RNAV<br />
Wanted to avoid sensor-based procedures<br />
Break into logical pieces<br />
o UI<br />
o Performance<br />
o<br />
o<br />
Path definition / path guidance<br />
Spin-<strong>of</strong>fs<br />
• DO200, DO 201, VNAV, TOAC, DO -283<br />
What’s <strong>the</strong> same<br />
Nakamura still trying to maintain order<br />
Classic procedures (VOR, etc.) cause 99% <strong>of</strong> <strong>the</strong> problems for FMS<br />
The transition period will always be <strong>the</strong>re – mixed equipage<br />
It still costs more to change <strong>the</strong> airside than <strong>the</strong> ground side<br />
The editing process is painful – get draft sections out early and <strong>of</strong>ten<br />
o 10% do 90% <strong>of</strong> <strong>the</strong> work, and attend <strong>the</strong> meetings<br />
o The rest will send comments only after <strong>the</strong> draft is out<br />
What’s different<br />
Data link!<br />
Vertical situation displays<br />
RTA trials<br />
SESAR / NextGen<br />
Integrated cockpits are <strong>the</strong> norm now<br />
o SVS, TAWS, ADS-B<br />
11
SBAS is here, GBAS and new constellations are coming<br />
Future <strong>of</strong> SC<strong>227</strong><br />
We need to fix <strong>the</strong> broken pieces, at least <strong>the</strong> ones that matter<br />
o Cert remains painful<br />
o Radio nav and integrity issues need to be closed out<br />
o Availability vs. integrity<br />
o CDI/VDI display issues need resolution, including dual aspects<br />
o Classic procedures in an RNP flight deck<br />
o Offsets, RNP holds, fixed radius turns<br />
o Temp comp – debate about what to do here<br />
o Users need better information presented… pilots, controllers<br />
o Charts/FMS/Database harmonization<br />
• RNP minima vs. RNP by leg, RNP by leg not on <strong>the</strong> chart<br />
o MOPS need to be tightened up in support <strong>of</strong> TSO C-115c<br />
We need to refine <strong>the</strong> features with value and try to jettison <strong>the</strong> rest<br />
Time constrained waypoints<br />
o Performance requirements – keep it simple – what matters<br />
Don’t forget security – it’s coming<br />
Related functions – FMS is <strong>the</strong> info hub <strong>of</strong> <strong>the</strong> flight deck<br />
Wednesday, 3/7<br />
FMS Standardization – Mike Cramer<br />
Mike Cramer, MITRE<br />
Mike also leads <strong>the</strong> FMS Standardization working group (<strong>of</strong> <strong>the</strong> CNS task force), that led to a number <strong>of</strong><br />
ATA task force recommendations.<br />
FMS Standardization Issue, FMS Runway Alert, dated Dec 8, 2011<br />
Ref: “FMS Standardization - Runway Alert Recommendation Final.pdf”<br />
This paper attempts to describe from <strong>the</strong> user/ATC side, <strong>the</strong> issue <strong>of</strong> departure operations from <strong>the</strong> wrong<br />
runway, differences in system detection methods and alerts, and <strong>the</strong> needed for improved/new solutions.<br />
Main recommendation: The FMF should identify and alert pilots <strong>of</strong> a discrepancy between loaded and<br />
actual departure runway when take<strong>of</strong>f power is added.<br />
FMS Standardization Issue #27 Speed and Altitude constraints<br />
Ref: “FMS Standardization Spd Alt Constraints Recommendation Final.pdf”<br />
This paper points out that constraints are not handled <strong>the</strong> same in different systems. Some can be worked<br />
around with procedure changes to account for <strong>the</strong> differences. Speed-only constraints require ‘fake’<br />
altitude constraints on some systems. Some procedures need AT or At-or-Above speed constraints, and<br />
<strong>the</strong> FMSs aren’t designed for this. Sequencing <strong>of</strong> speed and altitude constraints differ on some systems –<br />
sequencing ei<strong>the</strong>r <strong>the</strong> altitude or speed can cause early sequence <strong>of</strong> <strong>the</strong> o<strong>the</strong>r.<br />
Recommendations:<br />
1. speed-only constraints should be allowed on FMSs.<br />
2. when associated with an altitude constraint, <strong>the</strong> speed constraint should remain active until <strong>the</strong><br />
waypoint is sequenced or deleted.<br />
3. FMSs should provide auto-throttle or appropriate commands so that airspace does not deviate<br />
more than 10 knots (0.02 Mach)<br />
4. FMSs should support all four types <strong>of</strong> speed constraints (at, at/below, at/above, between)<br />
12
Q: what is <strong>the</strong> impact on economy <strong>of</strong> flight with <strong>the</strong>se speed constraint changes<br />
Mike: There is 3D-PAM study on this. If procedure is done well <strong>the</strong>re is not much impact.<br />
Issue Lateral Offset Operation<br />
Ref: “FMS Standardization <strong>of</strong> Lateral Offset Operation FINAL RECOMMENDATION.pdf and<br />
FMS Standardization - Lateral Offset and FRT.pdf”<br />
The first paper indicates that FMS treatment <strong>of</strong> lateral <strong>of</strong>fsets differ to <strong>the</strong> point that ATC cannot easily<br />
use it as a tool. Entry and exit treated as a straight path, but <strong>the</strong> intercept angle varies between 30 and 45<br />
degrees, but some aircraft allow specification <strong>of</strong> <strong>the</strong> angle in <strong>the</strong> AMI and some systems allow <strong>the</strong> pilot to<br />
enter <strong>the</strong> angle. Most perform a flyby transition from parent path to intercept path. Some systems display<br />
<strong>of</strong>fset path and intercept track, o<strong>the</strong>rs don’t. Some systems allow 0.1nm increments, o<strong>the</strong>rs only 1.0nm.<br />
Some systems allow specification <strong>of</strong> <strong>the</strong> lateral <strong>of</strong>fset start and end points, some don’t – <strong>the</strong>y only allow<br />
immediate engagement and disengagement <strong>of</strong> <strong>the</strong> <strong>of</strong>fset.<br />
This variation makes it difficult for ATC to use it because <strong>the</strong> result <strong>of</strong> <strong>the</strong> clearance varies. ATC use <strong>of</strong><br />
this is desired, and ATC automation tools are being developed that could make use <strong>of</strong> this capability if its<br />
response were consistent.<br />
Desired operations:<br />
1. all aircraft should respond in a consistent and predicable manner to lateral <strong>of</strong>fset clearances.<br />
2. all aircraft should be capable <strong>of</strong> <strong>of</strong>fsets up to 99nm in 0.1nm increments.<br />
3. <strong>of</strong>fset types should handle optional specification <strong>of</strong> begin and end fixes.<br />
Recommendations:<br />
1. intercept angle default is 30 degrees.<br />
2. flight deck selectable intercept angle from 10-50 degrees to use as needed<br />
3. start and end waypoints should be specifiable<br />
a. automatic initiation and cessation at <strong>the</strong>se points<br />
b. <strong>the</strong> intercepts should be flown with fly-by transitions<br />
4. <strong>of</strong>fset distances specifiable by 0.1nm<br />
5. common requirement for which ARINC path terminator types that should be <strong>of</strong>fsetable.<br />
a. Fixed radius transitions should be preserved for <strong>the</strong> <strong>of</strong>fset by <strong>of</strong>fsetting <strong>the</strong> turn center<br />
along <strong>the</strong> bisector<br />
b. For RF path terminators <strong>the</strong> radius should be changed by <strong>the</strong> amount <strong>of</strong> <strong>the</strong> <strong>of</strong>fset<br />
6. terminators that automatically terminate<br />
a. no system should allow <strong>of</strong>fsets to be applied in approach or missed approach segments<br />
i. <strong>of</strong>fsets should automatically terminate at first approach waypoint<br />
ii. do not propagate across route discontinuities or unreasonable geometries.<br />
7. provide data to support <strong>the</strong> map display<br />
8. do not need to support multiple pre-planned <strong>of</strong>fsets<br />
9. provide output <strong>of</strong> intent on ADS-B and ADS-C<br />
A table <strong>of</strong> current behavior across different FMSs was also presented in <strong>the</strong> second paper.<br />
From a timetable standpoint, ATC automation tools will start coming along around 2015.<br />
Frank: concern about lateral <strong>of</strong>fset terminating at FAF.<br />
Mark: a clearance like this should not be issued.<br />
There was general agreement that it should still be fixed in <strong>the</strong> document<br />
13
David DS: why change turn radius for RF leg, but turn center for FRT<br />
MikeC: when you change <strong>the</strong> turn center for an FRT meeting <strong>the</strong> <strong>of</strong>fset in <strong>the</strong> inbound and outbound<br />
legs, <strong>the</strong> actual <strong>of</strong>fset to <strong>the</strong> FRT varies as you make <strong>the</strong> turn (increasing <strong>the</strong>n decreasing), for a 120<br />
degree turn, <strong>the</strong> center <strong>of</strong> <strong>the</strong> FRT is <strong>of</strong>fset by twice <strong>the</strong> <strong>of</strong>fset <strong>of</strong> <strong>the</strong> inbound and outbound legs. This is<br />
unacceptable for RF in <strong>the</strong> terminal area, so <strong>the</strong> radius needs to change, keeping <strong>the</strong> turn center, to make<br />
<strong>the</strong> <strong>of</strong>fset constant through <strong>the</strong> turn<br />
Dave N: is <strong>the</strong> different treatment between <strong>the</strong> two types really merited, considering <strong>the</strong> added complexity<br />
we are talking about<br />
Ge<strong>of</strong>f B: <strong>the</strong>se 3 examples talk to FMS standardization. MASPS does have operational considerations.<br />
There needs to also be guidance for how <strong>the</strong>se systems are applied to procedure and airspace design and<br />
use by ATC.<br />
The was vehement agreement by o<strong>the</strong>rs.<br />
DaveN: it will take time for <strong>the</strong>se changes to trickle into <strong>the</strong> fleet to reach a critical mass for 15-20 years.<br />
Lacking a mandate, do we have a responsibility to provide guidance for how <strong>the</strong>se functions can be used<br />
in <strong>the</strong> meantime O<strong>the</strong>rwise we’d be asking customers to buy a feature that cannot be used for 15-20<br />
years.<br />
MikeC: we can show that <strong>the</strong> lateral <strong>of</strong>fset changes will have a positive cost benefit.<br />
MarkS: CAS is kicking <strong>of</strong>f some activities to analyze runway disagree issue as well.<br />
JohnH: I have not bought in to <strong>of</strong>fsets being useful. Pieces make sense. Regarding RF leg – we can’t<br />
even fly <strong>the</strong>se without special approval (AR). It may have good value, but we can’t even use it in<br />
practice.<br />
Erwin/o<strong>the</strong>rs: RF legs are showing up in more approaches than just AR.<br />
SamM: <strong>the</strong> FMS response is preventing <strong>the</strong>se procedures from being used.<br />
John H: we can do <strong>the</strong>se procedures today by manually controlling <strong>the</strong> intercepts by switching to heading<br />
mode manually.<br />
Mark H (ALPA): need to make sure <strong>the</strong> crew has <strong>the</strong> tools <strong>the</strong>y need to do <strong>the</strong> procedures needed.<br />
Sylvain: why not just uplink a new flight plan for path stretching instead <strong>of</strong> using <strong>the</strong> lateral <strong>of</strong>fset<br />
mechanism The corners in <strong>the</strong> new route could just be waypoints in a new route. Is <strong>the</strong> lateral <strong>of</strong>fset<br />
functionality really needed<br />
Dave N: The ICAO PBN study group operations include parallel <strong>of</strong>fsets as a useful tool for passing.<br />
Ron (United pilot): We have tried to implement <strong>of</strong>fsets in Houston for passing, but <strong>the</strong> unpredictability<br />
<strong>of</strong> <strong>the</strong> response made it unworkable.<br />
Ge<strong>of</strong>f: <strong>the</strong>re is a difference between harmonizing existing functionality versus adding new functionality<br />
like handling <strong>of</strong>fsets on FRT and RF.<br />
David J (GE): want to reinforce that we have an obligation for supplementary guidance.<br />
Dave N: our operational considerations section may well need to include procedure design and ATC use,<br />
to prevent it being used in <strong>the</strong> wrong way and creating new problems.<br />
Walk Through <strong>of</strong> DO-236B MASPS<br />
The walk through was led by Mike Cramer who will also lead <strong>the</strong> effort in updating <strong>the</strong> MASPS.<br />
Ref: “DO-236B Organization.pdf”<br />
The purpose <strong>of</strong> <strong>the</strong> walk through is to level set this group with regard to <strong>the</strong> contents and clarify <strong>the</strong> intent<br />
<strong>of</strong> <strong>the</strong> MASPS.<br />
Question about integrity: are you talking about integrity at <strong>the</strong> aircraft level Are we correctly capturing<br />
<strong>the</strong> GNSS integrity relation to this<br />
Mike: <strong>the</strong> MASPS used <strong>the</strong> term containment integrity very specifically to indicate that <strong>the</strong> total aircraft<br />
navigation error cannot exceed 2x RNP more than 10^-5. This is all aircraft systems combined.<br />
14
Section 1.1 para 3 is significant.<br />
DaveN: We need to consider how we add discussion about <strong>the</strong> new context <strong>of</strong> updates we will make.<br />
System overview, section 1.2, has four key sections that divide <strong>the</strong> main content going forward in <strong>the</strong><br />
document (same as in chapter 3 – functional requirements)<br />
1. Position estimation<br />
2. Path definition: lateral and vertical<br />
3. Path steering: lateral and vertical, and time <strong>of</strong> arrival<br />
4. User interface<br />
DaveN: We originally wanted many aspects as requirements that had to be downgraded to optional<br />
because it would not be feasible for everyone to implement it. We need to consider going forward how<br />
we want to deal with this, considering that optional requirements have significantly reduced value<br />
operationally.<br />
Vertical containment is not treated <strong>the</strong> same as lateral – based on 99.7% reliability like prior standards.<br />
Sections 1.3.3 – 1.3.5 may need to be updated to reflect current environment such as NextGen, SESAR,<br />
ICAO block upgrades, etc.<br />
FrankH: Consider changing to TBO and revising RNP RNAV to RNP<br />
Aside: We are lacking an procedure design standard that defines how to use <strong>the</strong> RNP capabilities<br />
appropriately in procedures and airspace design.<br />
Section 1.4 defines RNP. Consistent use <strong>of</strong> terminology is key here. We need to be careful how we use<br />
RNP and RNP RNAV terms to be clear what <strong>the</strong> containment, continuity, and integrity characteristics are<br />
associated with those terms.<br />
RNP type does not reflect just required navigation accuracy now, we also use it to reflect integrity and<br />
continuity requirements, so we will sometimes used required navigation accuracy to be precise instead <strong>of</strong><br />
RNP-type.<br />
Erwin: section 1.4 will need to updated to be consistent with <strong>the</strong> new PBN manual<br />
JohnH: discussion <strong>of</strong> how use <strong>of</strong> RNP-10, RNP-2, RNP-1 relate to this discussion<br />
RNP RNAV applicability range table is causing issues. Discussion about whe<strong>the</strong>r or not this can be<br />
removed.<br />
Note that section 1.4.6 allows for TOAC with lateral and vertical path adjustments, though no system yet<br />
uses lateral adjustments to achieve a time it is technically allowed.<br />
Frank: RNP Tables – pull out<br />
Frank: With VNAV what is <strong>the</strong> truth line that you measure against<br />
Section 1.5 assumptions<br />
MarkS: 2x accuracy up against rock and airspace gets into AR issues.<br />
Dave N: we are providing a navigation system with 2xRNP capability. How it is used will affect process<br />
<strong>of</strong> approval.<br />
Steve: how do we take credit for <strong>the</strong> fact that <strong>the</strong> actual performance is better than <strong>the</strong> requirement We<br />
should recommend that RNP is 2x. If someone uses 2x plus buffer, <strong>the</strong>n <strong>the</strong>y can’t call it RNP. Ano<strong>the</strong>r<br />
point is that if we truly contain with 2x, why are people adding buffers to this<br />
Dave N: We need to focus on <strong>the</strong> fact that we are doing a MASPS, not dealing with application <strong>of</strong> RNP<br />
capability outside this document. We can’t solve those problems here. Detailed work on application <strong>of</strong><br />
this standard is not our purview. We can put pointers in to indicate where issues may be, but we cannot<br />
15
solve <strong>the</strong> issues. We should consider following through and making sure that someone else will pick up<br />
<strong>the</strong> ball and cover that aspect. We can provide recommendations for how our material is used, but we<br />
cannot make anyone do anything in that respect.<br />
MikeC: to some extent that is what this assumptions section is for.<br />
JohnH: we can expect discussions <strong>of</strong> how RNP 2x is used to achieve separation. We need to also know<br />
who is making <strong>the</strong> decisions on how this capability is used for separation and procedure design, so that<br />
we can participate in those forums.<br />
MikeC: SASP separation panel in particular debated between a Gaussian and double exponential<br />
distribution, and call into question <strong>the</strong> assumptions we make about what 2x RNP really means and how<br />
<strong>the</strong>y can trust it. It is for reasons like this that <strong>the</strong>y are adding buffers.<br />
JohnH: we should consider adding a “lessons learned” section in <strong>the</strong> MASPS as background material to<br />
help people understand what can go wrong and prevent it going forward in applications <strong>of</strong> <strong>the</strong>se<br />
capabilities.<br />
JohnH: RE section 1.5.5, what about non-WGS84 areas what if we fly to countries that to not use<br />
WGS84<br />
Unknown: There is ano<strong>the</strong>r AC that allows for equivalence.<br />
Section 1.5.6.2 – some countries accommodate temperature compensation in procedure design, o<strong>the</strong>rs<br />
assume <strong>the</strong> flight crew will deal with this.<br />
Steve J: <strong>the</strong>re are issues in using temperature compensation in procedure design that can make a<br />
procedure less usable e.g. Hot temperature instead <strong>of</strong> cold temperature.<br />
Frank: 1.5.2 should we add <strong>the</strong> term procedure<br />
1.5.7.1 paragraph on fly-overs needs to be updated.<br />
1.5.7.2 vertical transitions are fly-bys<br />
1.7 definitions<br />
RNP = required navigation performance accuracy<br />
RNP RNAV = meets all requirements <strong>of</strong> this document, including integrity, containment<br />
Frank: need to update figure 1-2 to have an aircraft graphic that doesn’t look like a DC9<br />
The term containment is used different in this document than ICAO. They use it as a 95% containment.<br />
Section 1.7.3 lateral containment<br />
JohnH: regarding P(E2), P(E3), this area assumes <strong>the</strong> airspace infrastructure supports <strong>the</strong> intended RNP<br />
level (e.g. no loss <strong>of</strong> GPS). The assumption is stated elsewhere, but we need it again here to be clear.<br />
Section 2.1<br />
JohnH: Table 2-1 column headings are notoriously misunderstood and have caused problems. They date<br />
back to 1984. We need to fix <strong>the</strong>se misunderstandings.<br />
Section 2.3<br />
Frank: 2.3.2 Continuity requirements for VNAV<br />
Frank: 2.3.4 Continuity requirements for TOAC<br />
Frank: 2.3.5 We should consider addressing wind input requirements here<br />
Section 2.5<br />
16
David DS: network and flow management in Europe desires to start using TOAC for airspace boundary<br />
crossings in a more basic form than captured currently. For enroute operation, we may sometimes need<br />
10 second accuracy instead <strong>of</strong> 30.<br />
MikeJ: data comm. standard allows for tolerance to be flight phase independent, not 30 or 10 seconds<br />
tied to flight phase but given as part <strong>of</strong> <strong>the</strong> RTA clearance.<br />
David DS: for some enroute ops, if <strong>the</strong>re is a high quality ETA this may be sufficient to support<br />
operations.<br />
Chapter 3<br />
Section 3.2.1 lists <strong>the</strong> allowable leg types.<br />
We didn’t want this list as long as this. Perhaps we can try again to reduce <strong>the</strong> list.<br />
Vector legs sometimes get used when nav accuracy is not needed.<br />
Some may try to make <strong>the</strong> list longer again.<br />
We will need to discuss this again.<br />
Add a note that o<strong>the</strong>r leg types may be applied if nav accuracy is not a concern.<br />
RF leg. Do we need turn center definition It turns out now that we should not need this. Turn center is<br />
implied by prior fix, RF fix, and radius. Turn center is redundant information and we will need to deal<br />
with situations where it is inconsistent (wrong) and <strong>the</strong> FMS needs to decide which data to use.<br />
Steve J: Need to look at new 424 definition. They have taken out <strong>the</strong> tangent requirement.<br />
Bob G (Garmin): Procedure designer rules are usually more restrictive than what <strong>the</strong> boxes can do.<br />
Section 3.2.4.1<br />
MikeJ: Holding patterns define a maximum size. But, we learned yesterday that controllers / airspace<br />
designers don’t like to see all this variability in how airplanes fly <strong>the</strong> hold. So, how do we want <strong>the</strong>se<br />
holds to be flown<br />
MikeC: There are also inconsistencies between how <strong>the</strong> AIM describes how holds are to be flown and<br />
how we are defining holding patterns in <strong>the</strong> nav standard.<br />
SamM: <strong>the</strong>re is a better description in PANS OPS now, and we think it will be coming to <strong>the</strong> AIM soon.<br />
DaveN: <strong>the</strong> fly-by entry is also an aspect that needs to be described.<br />
Section 3.2.4.3<br />
MikeC: Figure 3-7 needs to be drawn better to use curves.<br />
Section 3.2.5.2<br />
JohnH: CF leg – inbound course is mag, which causes issues. We used airport mag var to convert<br />
procedure mag course. New procedures use new mag var, old procedures use old mag var. Flying an old<br />
course with new mag var from <strong>the</strong> airport in navdb doesn’t work. So, we started using nearest VOR mag<br />
var for <strong>the</strong> procedures, but <strong>the</strong> VORs are going away soon. We had to do all this because Arinc 424 did<br />
not support mag var on <strong>the</strong> procedures. The new Arinc 424 does include this, but it will require box<br />
upgrades to be able to use this<br />
MikeC: <strong>the</strong> hierarchy <strong>of</strong> which mag vars to be used is different in practice than that discussed in <strong>the</strong><br />
document. We will need to revisit this.<br />
Section 3.2.8.5 – vnav path transitions<br />
James N: vertical fly-bys cause confusion. Table 3-3. we’ve had conflicts with regulators in <strong>the</strong> past<br />
with this material.<br />
JohnH: this section gives numbers but no requirement. It’s just info for procedure designers.<br />
Section 3.2.8.6 – temperature compensation<br />
17
Sylvain: if we currently have temperature compensation, we have no way to take credit for this.<br />
MarkS: <strong>the</strong>re is a note on some procedures that temperature compensation does not apply to systems that<br />
have compensation.<br />
Section 3.5 TOAC<br />
MikeJ: ETA min/max description is currently min/max speed, whereas SESAR / WG85 propose a 95%<br />
reliable definition. This area needs study to harmonize.<br />
Section 3.6 user interface<br />
MikeC / JohnH: Table 3-4 needs to be revisited<br />
Times to seconds, Altitudes, etc.<br />
Section 3.7.2.1.2<br />
Frank: we need to put something about user defined fixes in approaches and missed approaches, that this<br />
is not intended. We need this to be clear that this is not allowed. User defined fixes prohibited on<br />
instrument approaches and limited in use for departure procedures where obstacles or environment is an<br />
issue<br />
Frank: we should discuss a minimum requirement for automatic sequencing for missed approach<br />
transition, from TOGA to LNAV.<br />
Section 3.7.3 navigation aid selection<br />
JohnH: <strong>the</strong>re are parts <strong>of</strong> <strong>the</strong> navaid selection that needs fixing.<br />
Section 3.7.8 TOAC<br />
Frank: we will want to add discussion <strong>of</strong> single vs. multiple time constraint, and en-route vs. terminal.<br />
Sylvain: what does it mean to minimize throttle activity<br />
MarkH: we need to be careful commanding speeds near <strong>the</strong> edges <strong>of</strong> <strong>the</strong> envelope.<br />
Sylvain: we can have pilot entry <strong>of</strong> min/max RTA speeds to keep <strong>the</strong> RTA speeds away from <strong>the</strong> edges <strong>of</strong><br />
<strong>the</strong> envelope.<br />
MarkH: we may need to communicate <strong>the</strong>se limitations to ATC before we get cleared for something we<br />
can’t do. This should get done from dispatch time onwards.<br />
MikeJ: <strong>the</strong> ETA min/max capability is intended to cover this once <strong>the</strong> aircraft is airborne, to prevent <strong>the</strong><br />
issuance <strong>of</strong> clearances that cannot be complied with.<br />
MarkH: we should consider supporting two time constraints, one en-route, one terminal.<br />
Frank: we should tie <strong>the</strong> RTA tolerance to <strong>the</strong> flight phase.<br />
Sylvain: no we should not<br />
Frank: <strong>the</strong>re are issues with details <strong>of</strong> speed control that affect how <strong>the</strong> aircraft meet <strong>the</strong> time constraints.<br />
Section 4.2.3 TOAC performance<br />
Sylvain: wind modeling errors affects achievable performance<br />
Thursday, 3/8<br />
<strong>Meeting</strong> Schedule and Scope<br />
Dave presented two possible meeting schedules, 3 month or 2 month cycle and opened discussion related<br />
to picking meeting dates.<br />
The considerations raised:<br />
18
concern that we don’t have momentum yet and think a 2 nd meeting soon is appropriate before we<br />
go to a 3 month cycle. (JamesN) (General agreement that this is a good suggestion.)<br />
concern that Europe may need some time to get new scope added to WG85 to support joint<br />
activities. (Sylvain)<br />
SC214 Plenary meetings this year are June 4-8 and Dec 10-14. (MikeJ)<br />
<strong>Meeting</strong> a 15 month cycle will be a lot <strong>of</strong> work. This is our big chance to open up <strong>the</strong> box and fix<br />
it, and we don’t want to miss <strong>the</strong> chance. Mark H suggested <strong>the</strong> committee go to 5 day meetings.<br />
The end date is chosen mainly to allow interaction and influence to <strong>the</strong> o<strong>the</strong>r active standards, in<br />
particular SC214 and SC186. The nav standard publication may be able to be delayed some, but<br />
we must work to ensure <strong>the</strong> collaboration with SC214 and SC186 occurs before <strong>the</strong>y publish.<br />
(Jarrett)<br />
The committee agreed to 5 day meetings to support <strong>the</strong> current document due dates. In light <strong>of</strong> <strong>the</strong> plan to<br />
have a harmonized activity with a re-tasked WG85, meetings will also be planned in European venues.<br />
When this will take place will depend on <strong>the</strong> speed in which EUROCAE changes to <strong>the</strong> WG85 terms <strong>of</strong><br />
reference are approved and navigation system specialists and experts can be found to participate in<br />
WG85.<br />
2 nd meeting May 7-11, after that a three month interval as well as meetings in Europe is likely.<br />
3 rd meeting July 30 – Aug 3, tentatively, possibly Toulouse.<br />
Part <strong>of</strong> our charter from <strong>the</strong> ATMAC/NAC is to find and resolve gaps in <strong>the</strong> o<strong>the</strong>r activities. We need to<br />
study <strong>the</strong> operational concepts <strong>the</strong>y are working towards and buy in to <strong>the</strong>m or take issue with <strong>the</strong>m. The<br />
TOps Concept <strong>of</strong> Use contained in <strong>the</strong> JPDO Aircraft WG’s Avionics Roadmap will be used on <strong>the</strong> US<br />
side.<br />
Dave re stated that <strong>the</strong> committee has 2 main tasks, fixing what is <strong>the</strong>re, and adding new capabilities (4D<br />
TBO). But, we need to be careful about splitting into sub-groups to ensure that we keep a critical mass <strong>of</strong><br />
expertise working on both aspects. For now we will plan to stay as one group. How this affects <strong>the</strong><br />
current Terms <strong>of</strong> Reference is not clear. However, what is clear is that for now <strong>the</strong> June 13 date is firm<br />
for <strong>the</strong> efforts for trajectory operations with regard to navigation function, data and interfaces associated<br />
with SC214 and SC186. The MASPS update/fix effort remains consistent with <strong>the</strong> terms <strong>of</strong> reference as<br />
well and will continue. The magnitude <strong>of</strong> updates may lead to a different end date. However, until we<br />
know better, i.e. at <strong>the</strong> next meeting, it is hard to say what it will be. The committee agreed that we will<br />
stay with <strong>the</strong> current TORs for now.<br />
A question was raised with regard to FMS specification efforts at AEEC for ARINC 702A. It was<br />
pointed out that <strong>the</strong> ARINC characteristic contains a lot <strong>of</strong> installation and interface oriented guidance<br />
and requirements. And <strong>the</strong>re are areas that appear to set design/implementation that overlap what is<br />
contained in <strong>the</strong> MASPS. For now <strong>the</strong> focus is with <strong>the</strong> MASPS/MOPS and coordination with AEEC<br />
will follow as appropriate.<br />
Sam: SAI has deferred opening up ARINC 702 because it was too much to be done to do now. Their<br />
focus will be on 660A.<br />
A number <strong>of</strong> <strong>the</strong> committee members commented on <strong>the</strong> need for broader subject matter expertise for this<br />
activity, which proved to be part <strong>of</strong> <strong>the</strong> reason for <strong>the</strong> success and acceptance <strong>of</strong> <strong>the</strong> SC-181/WG-13<br />
MASPS. In particular, air traffic control was mentioned. Jarrett L will coordinate in <strong>the</strong> FAA to<br />
identify experts who will participate and support this effort. There will be outreach to o<strong>the</strong>r areas as well.<br />
19
During <strong>the</strong> course <strong>of</strong> <strong>the</strong> meeting discussions, a number <strong>of</strong> issues related to aeronautical information and<br />
databases were raised e.g. changes in RF, FRT, displays, etc. Dave pointed out that in <strong>the</strong> committee<br />
planning he had raised such issues and documents DO-200A and DO-201A. However, it was felt that <strong>the</strong><br />
scope was too large for <strong>the</strong> committee schedule. With <strong>the</strong> committee discussions, it was apparent that all<br />
<strong>the</strong> pieces for addressing lessons learned and new additions need to be worked in order to achieve success<br />
in implementation. It was pointed out that <strong>RTCA</strong> was considering expanding <strong>the</strong> scope <strong>of</strong> SC-217,<br />
Terrain and Airport Databases to add navigation. A number <strong>of</strong> <strong>the</strong> committee including <strong>the</strong> chair<br />
expressed concern that splitting <strong>of</strong>f <strong>the</strong> effort might make sense from a functional standpoint but by being<br />
tackled by a group with a totally different perspective and goals, could also lead to divergent solutions<br />
and increased complexity for SC-<strong>227</strong> standards. Dave pointed out that this adds <strong>the</strong> need for close<br />
coordination with this committee as well as SC-214 and SC-186 in moving forward. Dave will make<br />
<strong>the</strong>se points known to <strong>RTCA</strong>.<br />
Schedule Discussion regarding MOPS Update<br />
Do we need <strong>the</strong> MOPS done at <strong>the</strong> same time as <strong>the</strong> MASPS<br />
It may be a long process after <strong>the</strong> completion <strong>of</strong> <strong>the</strong> MOPS for it to go into <strong>the</strong> TSO, so it should be okay<br />
if <strong>the</strong> MOPS are delayed until after <strong>the</strong> MASPS are complete. We can start MOPS activity before <strong>the</strong><br />
MASPS are complete, but we may not be able to focus <strong>the</strong> full group attention on <strong>the</strong> MOPS until <strong>the</strong><br />
MASPS are complete.<br />
JohnH: we can start fixing <strong>the</strong> text <strong>of</strong> <strong>the</strong> MOPS right away. We need <strong>the</strong> fixes made, and this can be<br />
done before <strong>the</strong> MASPS are done. The new stuff will need to wait, but not <strong>the</strong> fixes.<br />
Walk Through <strong>of</strong> DO-283A MOPS<br />
Dave pointed out that he was leading this discussion only because a lead had not been found by <strong>the</strong> time<br />
<strong>of</strong> <strong>the</strong> meeting. He stated that as an aircraft and systems person, it would be more appropriate to have an<br />
equipment manufacturer with experience in MOPS, TSO’s and related regulatory approvals in front <strong>of</strong><br />
this effort. Until <strong>the</strong>n, and for this session only Dave quickly skimmed over <strong>the</strong> content <strong>of</strong> <strong>the</strong> MOPS and<br />
discussed how it adds specificity to <strong>the</strong> MASPS and leaves out background rationale information that is<br />
not needed to describe <strong>the</strong> requirements.<br />
Dave mentioned a number <strong>of</strong> areas that may require changes including:<br />
RNP Scalability: <strong>the</strong> current MOPS provides specific criteria for set RNP values but also provides<br />
guidance with regard to <strong>the</strong> applicability to o<strong>the</strong>r RNP values and especially for <strong>the</strong> lateral<br />
deviations. However, more may be required with regard to factors such as acceptability <strong>of</strong><br />
current discrete alerting levels or what mitigations will work<br />
VOR/DME is included as with <strong>the</strong> MASPS. However <strong>the</strong> MASPS goes, so will <strong>the</strong> MOPS.<br />
Currently <strong>the</strong> MOPS is only 2D. What becomes <strong>the</strong> minimum set <strong>of</strong> requirements e.g. VNAV<br />
and TOAC needs to be discussed and determined.<br />
The test sections may need updating for DO-160, as well as additional test scenarios for functions<br />
and performance for sequential RF turns, datacom, data outputs , etc.<br />
Hardware/S<strong>of</strong>tware compliance<br />
Relevant electronic display features/performance for <strong>the</strong> installed system<br />
All MASPS changes that correspond to a MOPS requirement.<br />
Dave also mentioned that more may be appropriate but will require <strong>the</strong> knowledge and perspective <strong>of</strong><br />
those who actually need and use <strong>the</strong> MOPS as a basis for equipment development and approvals.<br />
Regarding holding – we may need to address lessons learned regarding disconnects between expectations<br />
and content.<br />
20
Prioritization and Scope <strong>of</strong> Updates to be Made<br />
Dave presented a list <strong>of</strong> areas that we expect to need to make updates to <strong>the</strong> MASPS and MOPS and<br />
solicited input. In order to quickly order <strong>the</strong> discussion, <strong>the</strong> group ‘multi-voted’ for <strong>the</strong>ir priorities to get<br />
to an ordered, prioritized list.<br />
The group looked at <strong>the</strong> higher priority items in <strong>the</strong> list and discussed what needs to happen in those<br />
areas. Dave’s notes are contained in “DO236B_Update Issues Matrix.docx” that is posted to <strong>the</strong><br />
Workspace.<br />
Action Required for All. Dave requested participants to develop issue white papers for items in <strong>the</strong> list,<br />
presenting <strong>the</strong>ir position for what needs to be changed and how to change it. The assignments are<br />
contained in <strong>the</strong> posted document. It is expected that <strong>the</strong> papers will be available via <strong>the</strong> workspace three<br />
weeks prior to <strong>the</strong> next meeting. It is recognized that this is a challenge with <strong>the</strong> 2 month interval and<br />
everyone was urged to make <strong>the</strong>ir best efforts to make this work.<br />
-S-<br />
Mike Jackson<br />
Secretary<br />
CERTIFIED as a true and accurate summary <strong>of</strong> <strong>the</strong> meeting.<br />
-S-<br />
Dave Nakamura<br />
Chairman<br />
21