Summary of the First Meeting Special Committee 227 ... - RTCA

Summary of the First Meeting
Special Committee 227
Standards of Navigation Performance
RTCA Paper No. 074-12/SC227-002
March 12, 2012
The first meeting of SC-227 was held on 7 – 9 March 2012 at RTCA Headquarters,
1150 18 th Street, N.W., Suite 910, Washington, D.C. 20036. The attendees were the following:
Dave Nakamura (Chairman)
Mike Jackson (Secretary)
Raghavendra Achanta
Frank Alexander
Ken Alexander
Pete Branower
Kevin Bridges
Geoff Burtenshaw
Alexandre Capodicasa
Perry Clausen
Michael Cramer
David De Smedt
Bruce DeCleene
Guy Deker
Steve Fulton
Bob Gaul
Tim Geels
Michael Gordon-Smith
Marc Henegar
John Hillier
Larry Hills
Barry Irwin
Steven Jackson
Don Jansky
David Jaquith
Terry Jones
Greg Joyner
Tom Kramer
Jarrett Larrow
Erwin Lassooij
The Boeing Company
Honeywell International, Inc.
Tetra Tech
International Air Transport Association
Federal Aviation Administration
Consultant
Federal Aviation Administration
UK - Civil Aviation Authority
Esterline CMC Electronics
Southwest Airlines
The MITRE Corporation
EUROCONTROL
FAA
Thales Avionics
GE Aviation
Garmin
Rockwell Collins, Inc.
CMC Electronics an Esterline Company
Air Line Pilots Association
Honeywell International, Inc.
Federal Express Corporation
The MITRE Corporation
Federal Aviation Administration
Jansky-Barmat Telecommunications
GE Aviation
Federal Express Corporation
Federal Aviation Administration
Aircraft Owners and Pilots Association
Federal Aviation Administration
International Civil Aviation Organization
1

Gary Livack
Wendy Ljungren
Catherine Majauskas
Pierre Marchi
Paul McGraw
Jeff Meyers
Barry Miller
Sam Miller
John Moore
Harold Moses
Laurence Mutuel
James Nicholls
Russell Ramaker
Sylvain Raynaud
Ron Renk
Jeff Robinson
Jim Savage
Les Schroeppel
Marissa Singleton
Peter Skaves
Ted Urda
Stephen Van Trees
Kenneth Wise
Chris Wynnyk
David Zeitouni
Federal Aviation Administration
GE Aviation
Federal Aviation Administration
EMBRAER
Air Transport Association of America
Federal Aviation Administration
Federal Aviation Administration
The MITRE Corporation
Federal Aviation Administration
RTCA, Inc.
Thales
Honeywell International, Inc.
GE Aviation
Airbus Americas, Inc.
United Airlines, Inc.
CNI Aviation LLC
Innovative Solutions International, Inc.
SAIC
The Boeing Company
Federal Aviation Administration
Federal Aviation Administration
Federal Aviation Administration
Innovative Solutions International, Inc.
The MITRE Corporation
The Boeing Company
**************************************************************************
In accordance with the Federal Aviation Advisory Committee Act, Jarrett Larrow, Federal
Aviation Administration (FAA), was the designated Federal Employee for this meeting.
**************************************************************************
Dave Nakamura opened the first plenary session of RTCA SC-227 at 9:00 am on March 7, 2012. After
brief introductions, Dave reviewed the agenda. He noted that the agenda was now more detailed than the
general announcement, and pointed out that the expectation was that work would commence this week,
noting the current scheduled due date of June 13 , 2013 for the committee deliverables.
No changes were made to the agenda and it was approved by the committee. During the meeting session,
adjustments were made to stay in plenary, rather than the planned breakouts, to get a group understanding
of the issues, plans of actions and next steps. The flow of the meeting discussions were as follows:
TUESDAY, 3/6 ............................................................................................................................................................. 3
ATTENDEES ................................................................................................................................................................ 3
OVERVIEW: RTCA, FAA, COMMITTEE – HAL MOSES, JARRETT LARROW AND DAVE NAKAMURA .......................... 3
PBN, NEXTGEN, AND THE RELATIONSHIP TO NAVIGATION STANDARDS – MARK STEINBICKER ............................... 3
2

NEXTGEN IMPLEMENTATION PLAN (NGIP) - BRUCE DECLEENE .............................................................................. 5
WG85 ACTIVITIES - SYLVAIN RAYNAUD ................................................................................................................... 7
STANDARDS OF NAVIGATION PERFORMANCE – GEOFF BURTENSHAW....................................................................... 8
SC181 HISTORY PERSPECTIVE AND NEED FOR FMS STANDARDS – FRANK ALEXANDER ........................................ 10
SC181 HISTORY PERSPECTIVE AND THOUGHTS FOR SC227 – JOHN HILLIER .......................................................... 10
WEDNESDAY, 3/7 .................................................................................................................................................... 12
FMS STANDARDIZATION – MIKE CRAMER .............................................................................................................. 12
WALK THROUGH OF DO-236B MASPS .................................................................................................................. 14
THURSDAY, 3/8 ........................................................................................................................................................ 18
MEETING SCHEDULE AND SCOPE ............................................................................................................................. 18
SCHEDULE DISCUSSION REGARDING MOPS UPDATE............................................................................................... 20
WALK THROUGH OF DO-283A MOPS .................................................................................................................... 20
PRIORITIZATION AND SCOPE OF UPDATES TO BE MADE ........................................................................................... 21
Tuesday, 3/6
Attendees
Hal Moses agreed to distribute the attendee list... (listed above)
Overview: RTCA, FAA, Committee – Hal Moses, Jarrett Larrow and
Dave Nakamura
Powerpoint: “SC-227 New Committee - RTCA Briefing - mjhem.pptx , SC227-FAA Involvement.pptx and
SC227 Meeting 1 Agenda and Work Plan R1”
Hal gave a brief overview of RTCA, the general processes and the committee workspace.
Jarrett provided a brief overview of the FAA groups whose activities and expertise were relevant to this
group. He touched on the Aircraft Certification Directorate (AIR), Flight Standards (AFS), and Air
Traffic Organization’s PBN Integration (AJV) and Navigation Services (AJW) groups. Additional,
NextGen support is expected to be as needed from the advanced concepts and technology development
(ANG-C) with regard to their 4DFMS research and Wind/TBO projects.
Dave reviewed the meeting plan and noted that it would be adjusted as we go along. The primary
objective was to get a better bound on the scope of issues, the steps the committee would take and the
TOR schedule and deliverables. The big challenge besides producing a MASPS and MOPS, was to get a
clear picture of the updates needed to the document and the scope of any new material that will be added.
In producing the updated documents, the efficient use of committee time in its efforts will matter. Dave
indicated that this means that committee expertise will be focused on the key issues and that nominal
editorial changes will be undertaken separately. Given this approach the committee will still have a say
on all aspects of the document contents.
PBN, NextGen, and the Relationship to Navigation Standards – Mark
Steinbicker
Powerpoint: “3 ef NextGen Perspective.ppt”
Mark is the manager of AFS-470 – operational implementation of PBN in flight deck. Mark Steinbicker
is also the US lead to ICAO PBN study group. Mark summarized some of the historical and context
aspects of PBN. He started by illustrating the broad array of applications of RNAV and RNP in the
3

2000’s and earlier and the expanding needs globally in the future. He pointed out that one of the steps
taken was through ICAO. Specifically the formation of the ICAO RNP Special Operational
Requirements Study Group (RNPSORSG) around 2004 and its successor the Performance Based
Navigation Study Group (PBN SG) from 2008 until the present was an effort to increase the
understandability of RNAV and RNP, though greater harmonization and consistency in the types of
RNAV and RNP criteria for aircraft qualification, operational approval and implementation
considerations. This effort represented the creation of and transition to PBN and the development of the
PBN Manual, ICAO Doc 9613. Mark pointed out that one of the key aspects of PBN was the
differentiation between RNAV and RNP. While both have performance requirements, RNP has on-board
performance monitoring and alerting (OBPMA). It is OBPMA where the greater assurance of RNP
system performance is provided. Mark also highlighted with examples that there is still room and a need
for more improvement to reduce the operational variability in aircraft flight path performance.
Bruce DeCleene is the manager of the Aircraft Certification group, AIR-130. Bruce started out by setting
a number of considerations as SC227 goes forward. Specifically, he pointed out folding in lessons
learned such as
pilot awareness of sensor inputs,
speed/altitude,
wrong runway entry
global harmonization through linkage to the ICAO navigation specifications, and raising the bar on
performance and capability where it’s appropriate such as
pilot and air traffic expectations,
turn performance, including fixed radius and
support of TSE monitoring and alerting.
JohnH: Is there regulatory basis on the PBN manual document Were the same experts as here involved
in writing the PBN manual
MarkS (PBN Study Group, US Member): The PBN manual was meant to embrace existing equipment.
It was not meant as a certification document.
DaveN (Chair of PBN Study Group and ICCAIA Member): The PBN manual has not been used
consistently in the way we expected. It is being used as a regulatory document by some states without the
appropriate considerations that must be made and as spelled out in the manual itself.
GeoffB (PBN Study Group, UK Member): There was a proliferation of standards that needed to be
focused. That harmonization is focused at the regulatory level. The problem is that the linkage with
MASPS and MOPS has been lost. The MASPS and MOPS didn’t have any force into usage in service.
As a result we have had a proliferation of standards and applications. The challenge is to bring it all back
together. The only way to have airspace development is to have interoperability and aircraft meeting a
standard.
BruceDC(RNP SORSG, FAA Member): SC181 did a good job laying a foundation. What has happened
since is taking that and turning it into practice. It has not been simple with RNP, RNAV, and RNP
RNAV. The need is to reestablish the connection between the operational side developed since SC181
back into the equipment standards.
JH: Is there a comment period for the new PBN manual
Erwin (PBN Study Group, ICAO Secretariat, and PBN Program Manager): There is sort of a comment
process but it must be through attendee members.
MarkS: There is also no intent to create specs that distinguish between GA and AT. Please provide
feedback through me. We try to minimize differences between expectations of how FAA and EASA will
use of the manual.
4

NextGen Implementation Plan (NGIP) - Bruce DeCleene
Powerpoint: “3 ef NextGen Perspective.ppt”
What should be included in the next round of equipment
Bruce pointed out that the NGIP includes the operations concept for 2018. One appendix relates the
concepts to the aircraft equipment required. The NGIP is updated every year to reflect progress and
budgets. The 2012 document should be released at any moment.
Bruce also stated that the 2025 TBO vision is contained in the JPDO NextGen Avionics Roadmap, v2.0
Sept 2011, an effort led by Steve VanTrees and Frank Alexander. In particular, Appendix 1 talks about
Trajectory Operations.
Trajectory Operations is a transformation that reflects specific steps:
1. Now: procedural control – pre-radar, shrimp boats
2. Next: surveillance based control – radar-based
3. Future: trajectory based control – where there is knowledge of a future trajectory, not just
prediction. It will be based on RNP, ADS-B, and DataComm
The Mid-term objective is to turn the automation / human interaction picture inside out. Instead of
humans at the center supported by automation, we want automation at the center supported by humans.
Automation systems will be connected via data links with human supervision and management
The Unifying concepts for this future are:
performance and windows for lateral, vertical and temporal aspects of trajectories.
phases of trajectory operations will have different enablers:
o pre-negotiation (over SWIM)
o negotiation (over SWIM)
o agreement (over Data Comm.)
o execution (via ADS-B and Data Comm.)
Implementation of Trajectory Ops will depend on a number of factors.
use ICAO PBN manual, but move forward with Advanced RNP for NextGen.
an updated MASPS will serve as the basis for FAA policy for implementation though:
o 20-series AC
o 90-series AC for equipment and operational guidance
An updated MOPS will be invoked by TSO for forward-fit only.
As we write the new standard, will we need to debate how far forward do we reach with new capability
Bruce suggested that we should consider that a standard that we write as forward fit only, or mandate for
retrofit. We should avoid optional capabilities – we have learned over and over again that ANSPs need a
homogenous fleet. Optional capabilities will not be usable. The PBN SG does not need the result of this
group to move forward – SC227 should focus on new capability going forward. The FAA expectation is
that we focus on forward fit, and the retrofit decisions will be made regionally based on when it becomes
appropriate to mandate to all aircraft.
GeoffB: any looking forward is a risk that when it comes time to implement/deploy that the environment
will be changed and our original vision and standard will not be what we actually want to implement as
the operational concept has evolved. We need to be aware of this risk.
BruceD: fundamental risk is in the new product development, that we develop new products that do not
provide benefit down the road. That is why we develop a standard – everyone starts developing similar
products at the same time to make providing benefits more feasible. We need to determine what new
capability is required, with a high probability of becoming real, and focus the standard on that.
JohnH: Question on TSO. Is this a new TSO How does this work
5

BruceD: When we keep the same number with a new letter, 115b over 115a, it stops new design approval
with the old standard (after a grace period). This group will need to provide guidance on whether new
MOPS replaces DO283 or is a separate MOPS / TSO.
The term “intended function” is used in regulatory publications. We should avoid using this term in our
standards as it is not our role to define that.
Need for updating navigation standards
There are a number of updates that need to be considered.
PBN enhancements
o Turn performance (operators want tighter radius turns, achieving IMC ops like VMC ops
is huge)
o Path repeatability under stress (sharp angles, climbing faster than expected, accelerating,
etc.)
Performance
o Reconcile GNSS and PBN monitor requirements (eg. ICAO PBN manual)
o Review containment integrity and continuity
Time of arrival control
o Tolerance (manual or autothrottle FTE)
o Required wind data
o One or more time constraints
o Integration with relative time of arrival control (ads-b based)
Vertical navigation
o Temperature compensation, including transition between with and without compensation
and managing separation
o Complex paths (multiple constraints), tighter tolerance as in RNP AR VEB
o Do we need vertical RNP
Lateral navigation
o Aircraft-defined path stretching Bracket allowable changes.
Alignment/Integration with Data Comm, SC214
This is one of the key activities for the committee. We need to ensure that the navigation aspects of the
assumed operations, data and data interfaces are right. The gaps and changes need to be identified to
SC214 quickly.
ATN-B2 defined by SC-214/WG78, to be complete in 2013
CPDLC, ADS-C, DFIS (wind data)
Requires standardized set of navigation abilities
Issue: uplinked routes don’t allow specification of leg types
o Lack of RF legs
o Lack of names for created waypoints to facilitate crew/controller voice
Validate SC214 products from navigation perspective
o ETA min/max assumptions
Provide new implementation requirements as appropriate
o E.g. display of proposed route clearance prior to acceptance
Alignment/Integration with ADS-B, SC186
The same holds true for SC186 in terms of navigation and the part it plays in applications for interval
management and separation standards.
Interval management
o assigns spacing to other aircraft
o from navigation perspective, many common issues to TOAC
6

• flight deck display of speed cues
• evaluating feasibility of making constraints while following another aircraft
• FET allocation and winds
Improving separation standards with ADS-B and Navigation
o Need accurate nav and surveillance combined to provide benefit
o Use surveillance to “cut the tails off” the navigation errors.
Regarding interval management vs. 4D TBO, Bruce advocated implementing both technologies and using
them regionally as appropriate.
Additional Considerations
Bruce also pointed out other possible areas of change in the updates.
position estimation
o need our standard to not depend upon GNSS specifics, because these will change.
integration with approach operations
o e.g. transition between RNP route and ILS is not defined
o dynamic RF-leg trombone called by controller (over data comm.)
alignment with stand-alone navigator – SC159
o SC159 dumbed down SC181 result to create a GA product, but it has become a headache
to maintain two nav standards.
WG85 Activities - Sylvain Raynaud
Sylvain Raynaud, Airbus FMS Engineer, Eurocae WG85 Chairman
Powerpoint: “WG 85 activities presentation.ppt”
Sylvain stated that the WG85 efforts started in Oct 2009, and that there have been 5 meetings, and 19
webexes to date. The ED75 addendum containing updated requirements for ETA and Time of Arrival
Control has been drafted. The current draft is as of June, 2011.
Validation activities that are supporting their efforts are:
Prior experiments – Cassis, NUP II
Seattle RTA trials
SESAR Initial 4D validation
The WG85 publication target is mid 2013.
This ensures coordination with WG78/SC214
It supports certification of Initial4D-capable certified systems to meet SESAR timetable
Their operational assumptions are based on SESAR and the WG78 4DTRAD OSEDs. Sylvain provided
a high level overview of the concept of operations with emphasis on the trajectory , aircraft/ground
exchanges and expected benefits.
The ED75 addendum draft criteria that support the 4D aspects of the operations are:
TOAC remains optional
ETA in open loop operations characterized
Meteo error assumptions created
RTA 95% reliability defined
ETA min/max function defined for 95% confidence
RTA precision down to 10 seconds in terminal airspace or en-route airspace
Means of compliance updated/created
7

White papers supporting the addendum changes are:
Distance reduction analysis, open and closed loop
what is ETA minmax
ETA uncertainty 95% envelope model in open and closed loop
Meteo error analysis
WG85 input to WG78 (in work)
o Clarify any unclear aspect concerning about functional content of the 4D trajectory (EPP)
o Propose updates for potential missing info
o Underline EPP requirements with significant impact on nav systems without clear
associated need.
RTA 95% accuracy demonstration methodology
Sylvain indicated that the WG85 addendum and papers would be shared with SC227.
The SESAR Initial4D validation is a phased approach with three steps planned.
Initial4D airborne prototypes available now by Honeywell and Thales for demonstration aircraft.
Improved RTA performance in descent: +/- 10 seconds with 95% reliability
Improved weather modeling – additional wind and temperature levels available
ETA min/max computed in FMS and reported over new ADS-C report
Datalink draft standard implemented – CPDLC and ADS-C updates per WG78
Initial4D ground function prototypes are also available now
By Maastrict (Enroute) and NORACON (TMA)
Datalink per WG78 draft standard
Controller working position using new generation HMI
(more on slide 21)
AMAN functionality expanded
A Flight test was conducted in late 2011
Coupled and non-coupled simulators in development for ground-based testing of integrated system
Coupled = aircraft simulated at Airbus connected over internet to ATM simulation
Objective of simulations is to model operational performance issues and benefits
Proposed way forward with SC227 – Sylvain that he was just presenting the EUROCAE position.
EUROCAE is interested in keeping ED75 & DO236 a common document
But, WG85 scope is not as wide as SC227
EUROCAE want only one EUROCAE WG to impact ED75 at a time, and WG85 already existed,
so WG85 scope will expand to cover additional RNP aspects
Proposed to have joint WG85/SC227 activities starting now for RNP and GNSS, but not Initial4D
Concerning keeping Initial4D efforts on track, the following ideas were offered.
o Create a dedicated sub-group in WG85 and SC227
o Start with coordinated (not joined) activities to secure the output of a final ED75
addendum in mid-2013 by WG85 subgroup
o After mid-2013, transition to joined activities on I4D scope
WG85 scope will grow to match the scope of SC227.
WG85 TOR to be updated and new call for participation for wider participation to cover RNP and GNSS.
Hal Moses (RTCA) indicated that due to the complicated and slow process for joint committees, the best
way to go forward for now is to just work together until the formalities can be worked out.
Standards of Navigation Performance – Geoff Burtenshaw
Geoff Burtenshaw, UK CAA, former Co-Chair of Joint SC181/WG-13
8

Powerpoint: “3a Standards of Navigation Performance GB 20120306.pptx”
Review of SC181/WG13 products and intended applications
Geoff pointed out the importance and value of standards.
interoperability
o without interoperability, every route or instrument procedure and airspace would have to
account for different aircraft capability
o precludes efficiency, capacity, and environmental improvements
cost of certification
non-optimized airspace design, since every variation must be considered.
Scope of standards
not just the airborne nav system is standardized
terminology
aeronautical data
procedure design affected by nav standards
charting
SC181 products and adoption thereof
Do236B/ED75B MASPS for RNP
o Intended/Used as a toolbox, implemented piecemeal by regulators
DO200A/ED76 Standards for processing aeronautical data
DO201A/ED77 standards for aeronautical information
DO283A MOPS for RNP for RNAV
o No ED equivalent
o TSO-C115c, FMS using multi-sensor inputs 2012
DO257A, MOPS
Adoption has been affected adversely by
GPS standards, DO-229
SC159 and SC181 which worked in parallel and were never brought together
Slow and fragmented airspace development
o Lack of harmonized operational requirements
Future for navigation performance standards
PBN is now the ‘must-have’
GPS standards are insufficient on their own
Considerations for SC227
Recognition of PBN concept, but keep RNP RNAV distinct as DO236/ED75 is only one means
to define an aircraft/system that spans multiple applications.
Functional definitions insufficient to support implementation. Changes are needed for:
o fixed radius transition
o tactical parallel offset
o use of speed and altitude constraints in path definition
VNAV mess since there has been little convergence on a standard.
o AC20-138B is 1980’s definition
o EASA AMC 20-27 (FTE and altitude limitation)
o AC 90-110a / AMC 20-26 Vertical Error Budget
o Do-236B / ED75b VNAV
Current PANS Ops Baro-VNAV design criteria needs a harmonized standard.
Inconsistency with lateral RNP RNAV – do we need a vertical RNP RNAV rather than just a
99.7% accuracy
4D trajectories
9

o Are the ATM operational concepts well enough defined
o Clear that there is some relationship between ground and air systems
Coordination with SC214 / WG78 data comm. standards is needed.
Interim steps to 4D that need to be considered.
o Enhanced time-based flow mgmt
o Use of target time of arrival
o Part of an AMAN/DMAN + collaborative ATM
o Need to provide adequate intent information to the ground systems
Perhaps the CNS section in DO236 needs to better explain the interrelations to other systems
Help define clearer requirements for 4D requirements and operations
Harmonization with WG85
Need to bring SC214/WG78 into line or accept there may need to be rework
Data quality – DO-200A is a bit dated, perhaps needs to be updated
Summary
Need all stakeholders, especially controllers, participating.
SC181 History Perspective and Need for FMS Standards – Frank
Alexander
Frank Alexander, IATA, former Co-Chair of Joint SC181/WG13.
Powerpoints: “3b SC-227 History Presentation.pptx “ & “3b FMS standardization presentation.ppt”
Early 1990s observed need for FMSs from disparate suppliers and OEMs to have similar behavior.
December, 1993 was the first SC181 meeting. In early 1994, SC181 joined with WG13.
Frank stated that we must try to look forward 20 years to what the requirements will be so that we can
define the system once now, since upgrade opportunities for airplanes happen seldom. Today’s technical
standards do not incorporate the requirements that are needed to insure consistent performance across all
lines of FMC.
The main concerns, and areas of differences are:
Turn performance variation
Phase of flight transitions – variations affect
o roll rates, speeds, default RNP values, display scaling
Dissimilar VNAV path construction
RTA differences
o What are the performance numbers
o Acceptable tolerances for ATM
o How is it achieved
o Availability of intent
Database coding
o Offsets, dep/app procedures, speed constraints
Holding
o Wide variation in paths for holding patterns
Sylvain: common performance requirements will not allow manufacturers to optimize their aircraft
performance.
SC181 History Perspective and Thoughts for SC227 – John Hillier
John Hillier, Honeywell
Powerpoint: “3c SC 227 KOM - Honeywell.ppt”
John led the SC-181 path definition subgroup, co-chaired with Airbus’s Gilles DeCevin
John pointed out that RNP RNAV certification now is painful and we need to fix this!
10

Sharing of common flight plan between air and ground (ADS-C EPP) is the key to TBO.
Datalink is the enabler.
RTA is one piece of the puzzle, but there are concerns about different solutions affecting separation.
Deterministic LNAV and VNAV is required.
Lessons learned
Not being tied out with SC159 really hurt
o SC214 is strikingly similar situation, is data link driving nav/guidance
o Security, this is more than data, it’s the expanding scope of security into operations.
o ADS-B impact to navigation is another area.
Nav world was and still is split between GPS/WAAS and RNP SC’s
o Not close to being harmonized
o Full time RNP vs. RNP RNAV
o AR RNP vs. non-AR RNP
We should have dealt more with classic procedures and use of the RNP concept
Need to tie out CAAs
We need to make it so pilots can understand this stuff
Problematic areas in SC181, still need to be addressed
o Offsets
o Temp Comp
o VNAV
o Fixed radius transitions
• Started simple – name of airway indicated
o RNP holds
o Integrity
o Accuracy models
o Flight deck annunciations
How things evolved
Evolve existing concept of RNAV into RNP RNAV
Wanted to avoid sensor-based procedures
Break into logical pieces
o UI
o Performance
o
o
Path definition / path guidance
Spin-offs
• DO200, DO 201, VNAV, TOAC, DO -283
What’s the same
Nakamura still trying to maintain order
Classic procedures (VOR, etc.) cause 99% of the problems for FMS
The transition period will always be there – mixed equipage
It still costs more to change the airside than the ground side
The editing process is painful – get draft sections out early and often
o 10% do 90% of the work, and attend the meetings
o The rest will send comments only after the draft is out
What’s different
Data link!
Vertical situation displays
RTA trials
SESAR / NextGen
Integrated cockpits are the norm now
o SVS, TAWS, ADS-B
11

SBAS is here, GBAS and new constellations are coming
Future of SC227
We need to fix the broken pieces, at least the ones that matter
o Cert remains painful
o Radio nav and integrity issues need to be closed out
o Availability vs. integrity
o CDI/VDI display issues need resolution, including dual aspects
o Classic procedures in an RNP flight deck
o Offsets, RNP holds, fixed radius turns
o Temp comp – debate about what to do here
o Users need better information presented… pilots, controllers
o Charts/FMS/Database harmonization
• RNP minima vs. RNP by leg, RNP by leg not on the chart
o MOPS need to be tightened up in support of TSO C-115c
We need to refine the features with value and try to jettison the rest
Time constrained waypoints
o Performance requirements – keep it simple – what matters
Don’t forget security – it’s coming
Related functions – FMS is the info hub of the flight deck
Wednesday, 3/7
FMS Standardization – Mike Cramer
Mike Cramer, MITRE
Mike also leads the FMS Standardization working group (of the CNS task force), that led to a number of
ATA task force recommendations.
FMS Standardization Issue, FMS Runway Alert, dated Dec 8, 2011
Ref: “FMS Standardization - Runway Alert Recommendation Final.pdf”
This paper attempts to describe from the user/ATC side, the issue of departure operations from the wrong
runway, differences in system detection methods and alerts, and the needed for improved/new solutions.
Main recommendation: The FMF should identify and alert pilots of a discrepancy between loaded and
actual departure runway when takeoff power is added.
FMS Standardization Issue #27 Speed and Altitude constraints
Ref: “FMS Standardization Spd Alt Constraints Recommendation Final.pdf”
This paper points out that constraints are not handled the same in different systems. Some can be worked
around with procedure changes to account for the differences. Speed-only constraints require ‘fake’
altitude constraints on some systems. Some procedures need AT or At-or-Above speed constraints, and
the FMSs aren’t designed for this. Sequencing of speed and altitude constraints differ on some systems –
sequencing either the altitude or speed can cause early sequence of the other.
Recommendations:
1. speed-only constraints should be allowed on FMSs.
2. when associated with an altitude constraint, the speed constraint should remain active until the
waypoint is sequenced or deleted.
3. FMSs should provide auto-throttle or appropriate commands so that airspace does not deviate
more than 10 knots (0.02 Mach)
4. FMSs should support all four types of speed constraints (at, at/below, at/above, between)
12

Q: what is the impact on economy of flight with these speed constraint changes
Mike: There is 3D-PAM study on this. If procedure is done well there is not much impact.
Issue Lateral Offset Operation
Ref: “FMS Standardization of Lateral Offset Operation FINAL RECOMMENDATION.pdf and
FMS Standardization - Lateral Offset and FRT.pdf”
The first paper indicates that FMS treatment of lateral offsets differ to the point that ATC cannot easily
use it as a tool. Entry and exit treated as a straight path, but the intercept angle varies between 30 and 45
degrees, but some aircraft allow specification of the angle in the AMI and some systems allow the pilot to
enter the angle. Most perform a flyby transition from parent path to intercept path. Some systems display
offset path and intercept track, others don’t. Some systems allow 0.1nm increments, others only 1.0nm.
Some systems allow specification of the lateral offset start and end points, some don’t – they only allow
immediate engagement and disengagement of the offset.
This variation makes it difficult for ATC to use it because the result of the clearance varies. ATC use of
this is desired, and ATC automation tools are being developed that could make use of this capability if its
response were consistent.
Desired operations:
1. all aircraft should respond in a consistent and predicable manner to lateral offset clearances.
2. all aircraft should be capable of offsets up to 99nm in 0.1nm increments.
3. offset types should handle optional specification of begin and end fixes.
Recommendations:
1. intercept angle default is 30 degrees.
2. flight deck selectable intercept angle from 10-50 degrees to use as needed
3. start and end waypoints should be specifiable
a. automatic initiation and cessation at these points
b. the intercepts should be flown with fly-by transitions
4. offset distances specifiable by 0.1nm
5. common requirement for which ARINC path terminator types that should be offsetable.
a. Fixed radius transitions should be preserved for the offset by offsetting the turn center
along the bisector
b. For RF path terminators the radius should be changed by the amount of the offset
6. terminators that automatically terminate
a. no system should allow offsets to be applied in approach or missed approach segments
i. offsets should automatically terminate at first approach waypoint
ii. do not propagate across route discontinuities or unreasonable geometries.
7. provide data to support the map display
8. do not need to support multiple pre-planned offsets
9. provide output of intent on ADS-B and ADS-C
A table of current behavior across different FMSs was also presented in the second paper.
From a timetable standpoint, ATC automation tools will start coming along around 2015.
Frank: concern about lateral offset terminating at FAF.
Mark: a clearance like this should not be issued.
There was general agreement that it should still be fixed in the document
13

David DS: why change turn radius for RF leg, but turn center for FRT
MikeC: when you change the turn center for an FRT meeting the offset in the inbound and outbound
legs, the actual offset to the FRT varies as you make the turn (increasing then decreasing), for a 120
degree turn, the center of the FRT is offset by twice the offset of the inbound and outbound legs. This is
unacceptable for RF in the terminal area, so the radius needs to change, keeping the turn center, to make
the offset constant through the turn
Dave N: is the different treatment between the two types really merited, considering the added complexity
we are talking about
Geoff B: these 3 examples talk to FMS standardization. MASPS does have operational considerations.
There needs to also be guidance for how these systems are applied to procedure and airspace design and
use by ATC.
The was vehement agreement by others.
DaveN: it will take time for these changes to trickle into the fleet to reach a critical mass for 15-20 years.
Lacking a mandate, do we have a responsibility to provide guidance for how these functions can be used
in the meantime Otherwise we’d be asking customers to buy a feature that cannot be used for 15-20
years.
MikeC: we can show that the lateral offset changes will have a positive cost benefit.
MarkS: CAS is kicking off some activities to analyze runway disagree issue as well.
JohnH: I have not bought in to offsets being useful. Pieces make sense. Regarding RF leg – we can’t
even fly these without special approval (AR). It may have good value, but we can’t even use it in
practice.
Erwin/others: RF legs are showing up in more approaches than just AR.
SamM: the FMS response is preventing these procedures from being used.
John H: we can do these procedures today by manually controlling the intercepts by switching to heading
mode manually.
Mark H (ALPA): need to make sure the crew has the tools they need to do the procedures needed.
Sylvain: why not just uplink a new flight plan for path stretching instead of using the lateral offset
mechanism The corners in the new route could just be waypoints in a new route. Is the lateral offset
functionality really needed
Dave N: The ICAO PBN study group operations include parallel offsets as a useful tool for passing.
Ron (United pilot): We have tried to implement offsets in Houston for passing, but the unpredictability
of the response made it unworkable.
Geoff: there is a difference between harmonizing existing functionality versus adding new functionality
like handling offsets on FRT and RF.
David J (GE): want to reinforce that we have an obligation for supplementary guidance.
Dave N: our operational considerations section may well need to include procedure design and ATC use,
to prevent it being used in the wrong way and creating new problems.
Walk Through of DO-236B MASPS
The walk through was led by Mike Cramer who will also lead the effort in updating the MASPS.
Ref: “DO-236B Organization.pdf”
The purpose of the walk through is to level set this group with regard to the contents and clarify the intent
of the MASPS.
Question about integrity: are you talking about integrity at the aircraft level Are we correctly capturing
the GNSS integrity relation to this
Mike: the MASPS used the term containment integrity very specifically to indicate that the total aircraft
navigation error cannot exceed 2x RNP more than 10^-5. This is all aircraft systems combined.
14

Section 1.1 para 3 is significant.
DaveN: We need to consider how we add discussion about the new context of updates we will make.
System overview, section 1.2, has four key sections that divide the main content going forward in the
document (same as in chapter 3 – functional requirements)
1. Position estimation
2. Path definition: lateral and vertical
3. Path steering: lateral and vertical, and time of arrival
4. User interface
DaveN: We originally wanted many aspects as requirements that had to be downgraded to optional
because it would not be feasible for everyone to implement it. We need to consider going forward how
we want to deal with this, considering that optional requirements have significantly reduced value
operationally.
Vertical containment is not treated the same as lateral – based on 99.7% reliability like prior standards.
Sections 1.3.3 – 1.3.5 may need to be updated to reflect current environment such as NextGen, SESAR,
ICAO block upgrades, etc.
FrankH: Consider changing to TBO and revising RNP RNAV to RNP
Aside: We are lacking an procedure design standard that defines how to use the RNP capabilities
appropriately in procedures and airspace design.
Section 1.4 defines RNP. Consistent use of terminology is key here. We need to be careful how we use
RNP and RNP RNAV terms to be clear what the containment, continuity, and integrity characteristics are
associated with those terms.
RNP type does not reflect just required navigation accuracy now, we also use it to reflect integrity and
continuity requirements, so we will sometimes used required navigation accuracy to be precise instead of
RNP-type.
Erwin: section 1.4 will need to updated to be consistent with the new PBN manual
JohnH: discussion of how use of RNP-10, RNP-2, RNP-1 relate to this discussion
RNP RNAV applicability range table is causing issues. Discussion about whether or not this can be
removed.
Note that section 1.4.6 allows for TOAC with lateral and vertical path adjustments, though no system yet
uses lateral adjustments to achieve a time it is technically allowed.
Frank: RNP Tables – pull out
Frank: With VNAV what is the truth line that you measure against
Section 1.5 assumptions
MarkS: 2x accuracy up against rock and airspace gets into AR issues.
Dave N: we are providing a navigation system with 2xRNP capability. How it is used will affect process
of approval.
Steve: how do we take credit for the fact that the actual performance is better than the requirement We
should recommend that RNP is 2x. If someone uses 2x plus buffer, then they can’t call it RNP. Another
point is that if we truly contain with 2x, why are people adding buffers to this
Dave N: We need to focus on the fact that we are doing a MASPS, not dealing with application of RNP
capability outside this document. We can’t solve those problems here. Detailed work on application of
this standard is not our purview. We can put pointers in to indicate where issues may be, but we cannot
15

solve the issues. We should consider following through and making sure that someone else will pick up
the ball and cover that aspect. We can provide recommendations for how our material is used, but we
cannot make anyone do anything in that respect.
MikeC: to some extent that is what this assumptions section is for.
JohnH: we can expect discussions of how RNP 2x is used to achieve separation. We need to also know
who is making the decisions on how this capability is used for separation and procedure design, so that
we can participate in those forums.
MikeC: SASP separation panel in particular debated between a Gaussian and double exponential
distribution, and call into question the assumptions we make about what 2x RNP really means and how
they can trust it. It is for reasons like this that they are adding buffers.
JohnH: we should consider adding a “lessons learned” section in the MASPS as background material to
help people understand what can go wrong and prevent it going forward in applications of these
capabilities.
JohnH: RE section 1.5.5, what about non-WGS84 areas what if we fly to countries that to not use
WGS84
Unknown: There is another AC that allows for equivalence.
Section 1.5.6.2 – some countries accommodate temperature compensation in procedure design, others
assume the flight crew will deal with this.
Steve J: there are issues in using temperature compensation in procedure design that can make a
procedure less usable e.g. Hot temperature instead of cold temperature.
Frank: 1.5.2 should we add the term procedure
1.5.7.1 paragraph on fly-overs needs to be updated.
1.5.7.2 vertical transitions are fly-bys
1.7 definitions
RNP = required navigation performance accuracy
RNP RNAV = meets all requirements of this document, including integrity, containment
Frank: need to update figure 1-2 to have an aircraft graphic that doesn’t look like a DC9
The term containment is used different in this document than ICAO. They use it as a 95% containment.
Section 1.7.3 lateral containment
JohnH: regarding P(E2), P(E3), this area assumes the airspace infrastructure supports the intended RNP
level (e.g. no loss of GPS). The assumption is stated elsewhere, but we need it again here to be clear.
Section 2.1
JohnH: Table 2-1 column headings are notoriously misunderstood and have caused problems. They date
back to 1984. We need to fix these misunderstandings.
Section 2.3
Frank: 2.3.2 Continuity requirements for VNAV
Frank: 2.3.4 Continuity requirements for TOAC
Frank: 2.3.5 We should consider addressing wind input requirements here
Section 2.5
16

David DS: network and flow management in Europe desires to start using TOAC for airspace boundary
crossings in a more basic form than captured currently. For enroute operation, we may sometimes need
10 second accuracy instead of 30.
MikeJ: data comm. standard allows for tolerance to be flight phase independent, not 30 or 10 seconds
tied to flight phase but given as part of the RTA clearance.
David DS: for some enroute ops, if there is a high quality ETA this may be sufficient to support
operations.
Chapter 3
Section 3.2.1 lists the allowable leg types.
We didn’t want this list as long as this. Perhaps we can try again to reduce the list.
Vector legs sometimes get used when nav accuracy is not needed.
Some may try to make the list longer again.
We will need to discuss this again.
Add a note that other leg types may be applied if nav accuracy is not a concern.
RF leg. Do we need turn center definition It turns out now that we should not need this. Turn center is
implied by prior fix, RF fix, and radius. Turn center is redundant information and we will need to deal
with situations where it is inconsistent (wrong) and the FMS needs to decide which data to use.
Steve J: Need to look at new 424 definition. They have taken out the tangent requirement.
Bob G (Garmin): Procedure designer rules are usually more restrictive than what the boxes can do.
Section 3.2.4.1
MikeJ: Holding patterns define a maximum size. But, we learned yesterday that controllers / airspace
designers don’t like to see all this variability in how airplanes fly the hold. So, how do we want these
holds to be flown
MikeC: There are also inconsistencies between how the AIM describes how holds are to be flown and
how we are defining holding patterns in the nav standard.
SamM: there is a better description in PANS OPS now, and we think it will be coming to the AIM soon.
DaveN: the fly-by entry is also an aspect that needs to be described.
Section 3.2.4.3
MikeC: Figure 3-7 needs to be drawn better to use curves.
Section 3.2.5.2
JohnH: CF leg – inbound course is mag, which causes issues. We used airport mag var to convert
procedure mag course. New procedures use new mag var, old procedures use old mag var. Flying an old
course with new mag var from the airport in navdb doesn’t work. So, we started using nearest VOR mag
var for the procedures, but the VORs are going away soon. We had to do all this because Arinc 424 did
not support mag var on the procedures. The new Arinc 424 does include this, but it will require box
upgrades to be able to use this
MikeC: the hierarchy of which mag vars to be used is different in practice than that discussed in the
document. We will need to revisit this.
Section 3.2.8.5 – vnav path transitions
James N: vertical fly-bys cause confusion. Table 3-3. we’ve had conflicts with regulators in the past
with this material.
JohnH: this section gives numbers but no requirement. It’s just info for procedure designers.
Section 3.2.8.6 – temperature compensation
17

Sylvain: if we currently have temperature compensation, we have no way to take credit for this.
MarkS: there is a note on some procedures that temperature compensation does not apply to systems that
have compensation.
Section 3.5 TOAC
MikeJ: ETA min/max description is currently min/max speed, whereas SESAR / WG85 propose a 95%
reliable definition. This area needs study to harmonize.
Section 3.6 user interface
MikeC / JohnH: Table 3-4 needs to be revisited
Times to seconds, Altitudes, etc.
Section 3.7.2.1.2
Frank: we need to put something about user defined fixes in approaches and missed approaches, that this
is not intended. We need this to be clear that this is not allowed. User defined fixes prohibited on
instrument approaches and limited in use for departure procedures where obstacles or environment is an
issue
Frank: we should discuss a minimum requirement for automatic sequencing for missed approach
transition, from TOGA to LNAV.
Section 3.7.3 navigation aid selection
JohnH: there are parts of the navaid selection that needs fixing.
Section 3.7.8 TOAC
Frank: we will want to add discussion of single vs. multiple time constraint, and en-route vs. terminal.
Sylvain: what does it mean to minimize throttle activity
MarkH: we need to be careful commanding speeds near the edges of the envelope.
Sylvain: we can have pilot entry of min/max RTA speeds to keep the RTA speeds away from the edges of
the envelope.
MarkH: we may need to communicate these limitations to ATC before we get cleared for something we
can’t do. This should get done from dispatch time onwards.
MikeJ: the ETA min/max capability is intended to cover this once the aircraft is airborne, to prevent the
issuance of clearances that cannot be complied with.
MarkH: we should consider supporting two time constraints, one en-route, one terminal.
Frank: we should tie the RTA tolerance to the flight phase.
Sylvain: no we should not
Frank: there are issues with details of speed control that affect how the aircraft meet the time constraints.
Section 4.2.3 TOAC performance
Sylvain: wind modeling errors affects achievable performance
Thursday, 3/8
Meeting Schedule and Scope
Dave presented two possible meeting schedules, 3 month or 2 month cycle and opened discussion related
to picking meeting dates.
The considerations raised:
18

concern that we don’t have momentum yet and think a 2 nd meeting soon is appropriate before we
go to a 3 month cycle. (JamesN) (General agreement that this is a good suggestion.)
concern that Europe may need some time to get new scope added to WG85 to support joint
activities. (Sylvain)
SC214 Plenary meetings this year are June 4-8 and Dec 10-14. (MikeJ)
Meeting a 15 month cycle will be a lot of work. This is our big chance to open up the box and fix
it, and we don’t want to miss the chance. Mark H suggested the committee go to 5 day meetings.
The end date is chosen mainly to allow interaction and influence to the other active standards, in
particular SC214 and SC186. The nav standard publication may be able to be delayed some, but
we must work to ensure the collaboration with SC214 and SC186 occurs before they publish.
(Jarrett)
The committee agreed to 5 day meetings to support the current document due dates. In light of the plan to
have a harmonized activity with a re-tasked WG85, meetings will also be planned in European venues.
When this will take place will depend on the speed in which EUROCAE changes to the WG85 terms of
reference are approved and navigation system specialists and experts can be found to participate in
WG85.
2 nd meeting May 7-11, after that a three month interval as well as meetings in Europe is likely.
3 rd meeting July 30 – Aug 3, tentatively, possibly Toulouse.
Part of our charter from the ATMAC/NAC is to find and resolve gaps in the other activities. We need to
study the operational concepts they are working towards and buy in to them or take issue with them. The
TOps Concept of Use contained in the JPDO Aircraft WG’s Avionics Roadmap will be used on the US
side.
Dave re stated that the committee has 2 main tasks, fixing what is there, and adding new capabilities (4D
TBO). But, we need to be careful about splitting into sub-groups to ensure that we keep a critical mass of
expertise working on both aspects. For now we will plan to stay as one group. How this affects the
current Terms of Reference is not clear. However, what is clear is that for now the June 13 date is firm
for the efforts for trajectory operations with regard to navigation function, data and interfaces associated
with SC214 and SC186. The MASPS update/fix effort remains consistent with the terms of reference as
well and will continue. The magnitude of updates may lead to a different end date. However, until we
know better, i.e. at the next meeting, it is hard to say what it will be. The committee agreed that we will
stay with the current TORs for now.
A question was raised with regard to FMS specification efforts at AEEC for ARINC 702A. It was
pointed out that the ARINC characteristic contains a lot of installation and interface oriented guidance
and requirements. And there are areas that appear to set design/implementation that overlap what is
contained in the MASPS. For now the focus is with the MASPS/MOPS and coordination with AEEC
will follow as appropriate.
Sam: SAI has deferred opening up ARINC 702 because it was too much to be done to do now. Their
focus will be on 660A.
A number of the committee members commented on the need for broader subject matter expertise for this
activity, which proved to be part of the reason for the success and acceptance of the SC-181/WG-13
MASPS. In particular, air traffic control was mentioned. Jarrett L will coordinate in the FAA to
identify experts who will participate and support this effort. There will be outreach to other areas as well.
19

During the course of the meeting discussions, a number of issues related to aeronautical information and
databases were raised e.g. changes in RF, FRT, displays, etc. Dave pointed out that in the committee
planning he had raised such issues and documents DO-200A and DO-201A. However, it was felt that the
scope was too large for the committee schedule. With the committee discussions, it was apparent that all
the pieces for addressing lessons learned and new additions need to be worked in order to achieve success
in implementation. It was pointed out that RTCA was considering expanding the scope of SC-217,
Terrain and Airport Databases to add navigation. A number of the committee including the chair
expressed concern that splitting off the effort might make sense from a functional standpoint but by being
tackled by a group with a totally different perspective and goals, could also lead to divergent solutions
and increased complexity for SC-227 standards. Dave pointed out that this adds the need for close
coordination with this committee as well as SC-214 and SC-186 in moving forward. Dave will make
these points known to RTCA.
Schedule Discussion regarding MOPS Update
Do we need the MOPS done at the same time as the MASPS
It may be a long process after the completion of the MOPS for it to go into the TSO, so it should be okay
if the MOPS are delayed until after the MASPS are complete. We can start MOPS activity before the
MASPS are complete, but we may not be able to focus the full group attention on the MOPS until the
MASPS are complete.
JohnH: we can start fixing the text of the MOPS right away. We need the fixes made, and this can be
done before the MASPS are done. The new stuff will need to wait, but not the fixes.
Walk Through of DO-283A MOPS
Dave pointed out that he was leading this discussion only because a lead had not been found by the time
of the meeting. He stated that as an aircraft and systems person, it would be more appropriate to have an
equipment manufacturer with experience in MOPS, TSO’s and related regulatory approvals in front of
this effort. Until then, and for this session only Dave quickly skimmed over the content of the MOPS and
discussed how it adds specificity to the MASPS and leaves out background rationale information that is
not needed to describe the requirements.
Dave mentioned a number of areas that may require changes including:
RNP Scalability: the current MOPS provides specific criteria for set RNP values but also provides
guidance with regard to the applicability to other RNP values and especially for the lateral
deviations. However, more may be required with regard to factors such as acceptability of
current discrete alerting levels or what mitigations will work
VOR/DME is included as with the MASPS. However the MASPS goes, so will the MOPS.
Currently the MOPS is only 2D. What becomes the minimum set of requirements e.g. VNAV
and TOAC needs to be discussed and determined.
The test sections may need updating for DO-160, as well as additional test scenarios for functions
and performance for sequential RF turns, datacom, data outputs , etc.
Hardware/Software compliance
Relevant electronic display features/performance for the installed system
All MASPS changes that correspond to a MOPS requirement.
Dave also mentioned that more may be appropriate but will require the knowledge and perspective of
those who actually need and use the MOPS as a basis for equipment development and approvals.
Regarding holding – we may need to address lessons learned regarding disconnects between expectations
and content.
20

Prioritization and Scope of Updates to be Made
Dave presented a list of areas that we expect to need to make updates to the MASPS and MOPS and
solicited input. In order to quickly order the discussion, the group ‘multi-voted’ for their priorities to get
to an ordered, prioritized list.
The group looked at the higher priority items in the list and discussed what needs to happen in those
areas. Dave’s notes are contained in “DO236B_Update Issues Matrix.docx” that is posted to the
Workspace.
Action Required for All. Dave requested participants to develop issue white papers for items in the list,
presenting their position for what needs to be changed and how to change it. The assignments are
contained in the posted document. It is expected that the papers will be available via the workspace three
weeks prior to the next meeting. It is recognized that this is a challenge with the 2 month interval and
everyone was urged to make their best efforts to make this work.
-S-
Mike Jackson
Secretary
CERTIFIED as a true and accurate summary of the meeting.
-S-
Dave Nakamura
Chairman
21