SC-227 Meeting Minutes - RTCA

Minutes of 4 th RTCA SC-227 Meeting12-16 November 2012RTCA, Washington, DC, USARTCA Paper No. 009-13/SC227-008January 16, 2013Executive SummaryThe meeting was centered on discussing and updating proposed changes for the MASPS, and makingdecisions on what material would proceed into the first draft document. This required mostly plenarydiscussion with some breakouts that are addressed in the detailed minutes.Proposed changes from the September plenary meeting that are proceeding into the first draft: [M1-2a1] – Lateral Turn Performance (FRT) [M1-2b] – Speed-Altitude Constraints [M1 – 5] Continuous LNAV [M1-10b] – RNP Multiple Lines of Minima [M1-x03] – Acceptable Leg TypesProposed changes with either committee acceptance or conditional acceptance from this meeting: [M1 – 9a] Runway Alerto Final edits made to text during the meeting, and draft approved.[M1-2a] – Lateral Turn Performance (fly-by)o Equations from Brussels found to not bound the performance of fly-by turns, as it wasthought but were accepted as useable for the draft subject to FRAC processo A rationale for reversing the prior discussions and decisions of SC181 with regard to notchanging the fly-by turn transition area and the use of the new features fixed radiustransitions and radius to fix legs is still needed for this proposal to be retained.o Acknowledged that acceptance for the draft does not mean it’s considered acceptable as finalMASPS material or supported by all members.[M1-2c] – VNAV Performanceo Discussion converged to a conclusiono Action to resolve an out-dated regulatory reference.[M1-3] – Flexibility Windowso Included in TOAC [M1-x04][M1-8b] – Temperature Compensationo Current draft is back to two options• If temp comp is done, final segment temp comp always required.• Optional for pilot to apply temp comp to IAF and IF.o MITRE analysis of procedures shows that the problem is spread throughout all regions of theapproach, not just final.o Most agree that two options is not acceptable to the flight crew, but there seem to beshowstoppers from simplifying it down to one simple feature that is optional.o The committee agreed that the two option solution as good enough for draft MASPSrecognizing that there would still be more discussion and changes during FRACo Accepted for draft following editorial changes that were completed during the meeting andsubmitted to Cramer on 11/16[M1-10a] – Parallel Offsetso Discussion did not converge regarding FRT and RF for the offset route1

RTCA Paper No. 009-13/SC227-008January 16, 2013[M1-1] – Integration with approach ops – RNP to xLSo Not discussed.Papers withdrawn: [M1-11a] – GNSS Integration [M1-12b] – RF definition [M1-16d] – RNP Data BlockDatalink ReviewThe committee reviewed a set of issues related to FMS implementation of the datalink standard, sorted thelist by relevance to SC-227 specific nature, and commented on the relevant issues. A small group continuedthe discussion to review the rest of the issues identified.Action for Mike Jackson to collect the two sets of recommendations and prepare comment matrices and/orwhite papers for the SC214 plenary meeting in December.MOPS Overview and PlanningMOPS layout and structure was presented, and discussion started on the process that the committee will usein moving forward on developing the MOPS.WG2 will retain WG1 change numbering system to maintain consistency between change updates.The WG proposal was to develop the criteria based upon the 3 classes of capability that will be needed.(Tentative names for the 3 classes are 2D, 3D, and 4D.) The MOPS will proceed on this basis.Action on interested members to inform the WG chairs to be added to the WG2 member list.Jarrett Larrow recommended the group review AC 21-16F so there is a common understanding on equivalentlevel of safety considerations for prior environmental standards – Action on all MOPS interested parties.MASPS ScheduleDave N. pointed out that the time remaining for the MASPS activities is short; the next two meetings on thecalendar represent the time for committee work and any working group discussions that must take placeduring the February since the FRAC step is what leads to the April meeting. Final white papers due to Mike Cramer December 21 st MASPS Draft will be complete Jan 14 th Jan 30 th comments due Paper authors review comments and update drafts in preparation for meeting. Feb 11-15, 2013, MASPS draft complete, ready for review. Final general review and comment collection. Final Draft to group, February 22 nd FRAC comment response forms due March 22 nd . Organized comments and proposed dispositions, April 1st April 8-12, FRAC, final document complete on April 12 th . Final document submitted to RTCA June 13 th PMC meeting to approve document.3

Full Minutes of 4 th RTCA SC-227 MeetingRTCA Paper No. 009-13/SC227-008January 16, 2013Chairman:DFO:Secretary:Dave NakamuraJarrett LarrowMike JacksonDave Nakamura opened the fourth plenary session of RTCA SC-227 at 9:00 am on 12 November, 2012.The current scheduled PMC document approval for publication date is June 13 th , 2013 for the MASPS. TheMOPS will follow in 2014.The flow of the meeting discussions were as follows:EXECUTIVE SUMMARY .............................................................................................................................................. 1MONDAY, 11/12 .............................................................................................................................................................. 5ATTENDEES: ................................................................................................................................................................... 5REVIEW OF AGENDA ....................................................................................................................................................... 5REVIEW MINUTES AND ACTION ITEMS ........................................................................................................................... 5CHANGE PROPOSAL DISCUSSIONS .................................................................................................................................. 5[M1-2a] – Lateral Turn Performance (fly-by) ........................................................................................................... 5[M1 – 9a] Runway Alert ............................................................................................................................................ 6[M1-10a] – Parallel Offsets ...................................................................................................................................... 6MOPS overview / planning ........................................................................................................................................ 7Review of Change Candidate Discussion .................................................................................................................. 7TUESDAY, 11/13 .............................................................................................................................................................. 8[M1-2c] – VNAV Performance .................................................................................................................................. 8[M3-03] – Vert Dev Scaling ...................................................................................................................................... 8[M1-12c] – Mag Var ................................................................................................................................................. 8[M1-8b] – Temperature Compensation ..................................................................................................................... 8WEDNESDAY, 11/14 ......................................................................................................................................................10[M1-x04] – TOAC .....................................................................................................................................................10THURSDAY, 11/15..........................................................................................................................................................13[M1-x02] SC214 Interface – Dynamic PBN .............................................................................................................13SC214 CPDLC ISRA .................................................................................................................................................14SC214 Message Set Review ......................................................................................................................................14[M1-1] – Integration with approach ops – RNP to xLS ............................................................................................14[M1-3] – Flexibility Windows ...................................................................................................................................14[M1-x01] – 4D Trajectories, Additional Reqmts ......................................................................................................14Low RNP ...................................................................................................................................................................15RNP Terminology .....................................................................................................................................................15FRIDAY, 11/16 ................................................................................................................................................................15SC-186 Interface .......................................................................................................................................................15MASPS SCHEDULE ........................................................................................................................................................15MOPS OVERVIEW AND PLANNING: ...............................................................................................................................154

RTCA Paper No. 009-13/SC227-008January 16, 2013Monday, 11/12Attendees:See SC227 site.Note, the following participated by phone.Bob GaulPerry ClausenGreg McDonaldGarminSouthwest AirlinesAirServices AustraliaReview of AgendaAgenda approved.Review Minutes and Action ItemsMinutes reviewed. No corrections to minutes.Dave discussed the need for the minutes to be accurate so that we can use them during the FRAC tounderstand the rationale and discussion that went into the decisions made in the white papers.Change Proposal DiscussionsThe descriptions of the discussions that follow mix summary narratives with explicit statement fragmentsmade by individuals, as appropriate to the topic and material being addressed.[M1-2a] – Lateral Turn Performance (fly-by)Sets minimum and maximum transition area for lateral turns based on wind and true airspeed.Mike C. reviewed the current paper draft resulting from the telecon discussions.Guy Deker suggested raising the 25 degree limit to 30 degrees.Sylvain suggested that we don’t need to be this precise – why do we need this number in the standard? Juststate that the guidance system needs to have lateral guidance authority sufficient to track the computed lateralpath with some capability for rejection of tracking errors. It needs to be clear that the bank limit is for thepath definition, not the guidance.Dave N. This is definitely not for the IFPP – this deals with enroute airspace. We need to understand whothe customer is for this change and why this change rather than those created in the MASPS for repeatableand predictable performance, the FRT and RF. This needs to aim at the correct audience. Another point isthat this change is only about RNP, not RNAV. There may be a need to communicate that this applies toRNAV as well. Although, we do not have a mechanism to do so. Dave added a concern that it will be addexpense to document compliance with this changed requirement, even if does not require any change to thesystems to meet the requirement. We can expect resistance due to cost since there isn’t a rationale why thecurrent FRT and RF, added for this purpose, won’t be used.Pedro asks why we need this fly-by performance requirement – if an airspace designer needs a boundedrepeatable path they can use RF or FRT.Mike C. says the lack of FRT capability in the existing fleet and the large minimum RF radius for proceduredesign makes usage difficult, and motivates the need for this performance requirement.Geoff said it comes down to a cost benefit case (recertification vs. what are you going to gain from it givenmigration to RF and FRT). Difficult to justify if you’re going to have to re-examine all those existingsystems. Is there a way to pass these standards to air design community without making it a standard?Dick H. says the limits in the draft do not bound the performance of the Universal systems, and could violateboth the min and max limits.5

RTCA Paper No. 009-13/SC227-008January 16, 2013Sam says Boeing systems will comply, but the issue is documentation / certification.Erwan says the limits in the draft do not bound the performance of some Honeywell systems, and couldviolate the min limits.An informal poll of the group showed that there were supporters for both views.Action: The committee agreed that this can go into the draft for now; There are issues that need to beresolved. Mike C to perform editorial clean up and put the change into the draft MASPS.[M1 – 9a] Runway AlertSam M. reviewed the paper. Text moved to section 3.7.2.1.1.1. of the MASPS – it fits better there.Several raised concern that the description was too FMS-centric – the group edited the text in real time toaddress this concern.Action: Committee agreement reached that this can go into the draft.[M1-10a] – Parallel OffsetsMike C. reviewed the paper status.Michael GS: these requirements will impact the datalink definition of messages.SC214 can support offset start point, but not end point. Needs coordination.Erwan: what is driving the need for 0.1nm offsets? Specifically the minimum offset size, not the resolution.What does it mean to have a 30 degree intercept to such a small lateral offset? This is not flyable.Mike C. the need was established at a CNS Task force meeting by FAA Nick Tallman, Jim Arrighi, others.Applications near Atlanta where 0.2nm offset was needed when adjacent military airspace goes active.FRT/RF discussion – several people raised concern that we deleted in Brussels the requirement to maintainFRT and RF on an offset route.Russ and Dave N. suggested that we include this in the standard as optional – if you do this, do it this way.Erwan expressed concern about offsetting RF to the inside of the turn – can get too steep.Mike C. said this can be handled by controller procedures and avionics UNABLE functionality.Dave Z. suggested we put FRT back in as a minimum requirement but make RF optional.Dave N. proposed that we will put FRT and RF back in as minimum requirements, with the recognition thatthe FRT description is a clarification of what was intended in the original standard, but that the RFrequirement is a new requirement. Add a note to remind that offsets of fly-by turns are not necessarilyparallel or of the same radius as the original path.Objections raised by various parties (Honeywell, Airbus) that offset of RF legs will add too muchcomplexity.Mike C. proposed a note to explain the limitations of offset to the inside of an RF leg, and that avionics becapable of producing an “UNABLE” if the offset radius becomes unmanageable. It also will be incumbentupon ATC to develop a tool that would allow controllers to know the limits on offsets that shrink the radiusof the turn, which will be added in the note.David DS asked why maintain the turn center for RF legs.Mike C: Refer to the supporting paper. For very large track angle changes, approaching 180 degree coursereversals to the runway, you cannot maintain the radius and achieve the offset – you must reduce the turnradius.More discussion too place in a breakout session, and the decision was to include both the FRT and RFalong with clarifying support material.Action: Jarrett and Mike J. to coordinate with SC214 the datalink requirements related to offsets.Action for Mike C. to describe RF issue in assumptions section.Action for Mike C. to make background paper available. (Done.)6

RTCA Paper No. 009-13/SC227-008January 16, 2013MOPS overview / planningMichael GS presented a powerpoint overview of the MOPS layout and structure, and areas of the documentthat need changes. Michael discussed MOPS dependency upon the MASPS, and the associated conflictbetween need to get started on MOPS because there is a lot of work to do, but also need for wait untilMASPS are stable before writing the derived requirements in the MOPS. Michael showed 10 pages of draftexamples of how the MASPS white papers will affect specific sections of the MOPS.WG2 will retain WG1 change numbering system to maintain consistency between change updates.There is a challenge to represent the requirements related to future capabilities that we don’t intend to flowdown to existing systems thus forcing retrofits. As options – invoking regulations can include them as requirements as needed. No options – include the future features in MOPS and regulators will exclude these features fromTSO until they are needed. Not included – leave future features out of MOPS until they are ready to be invoked by the TSO.Jarrett made it clear that the FAA doesn’t want optional features in the MOPS – it makes the TSO unclear.The purpose of the MOPS is to define the future system requirements. If you aren’t ready to put thesefeatures in to your box, you don’t use the new TSO.Group discussion around and around to understand the subtleties of this issue.Jarrett presented a tutorial on the TSO process.Action on interested members to inform Michael GS and/or Chris Shehi to add you to the WG2 memberlist.Breakout summaryAgreement reached that classes of capability will provide a means of determining what requirements areassociated with a capability, leaving implementers and applicant to make their choices accordingly.Proposed classes:2D 3D (2D+) 4D (3D+)Current LNAV Current VNAV (App H) 4D TrajectoriesLateral turn performance Speed / alt constraints TOACContinuous LNAV VNAV Performance SC-214Runway alerting Temp comp Flex windows (time)Parallel offsetsRNP multiple lines of minimuMag VarVDEV scalingLeg typesFlex windows (altitude)EnvironmentalRNP ARVPPL examples presented. Based on the assumptions and allocations presented, the conclusion was that thevertical performance requirements can’t always be met, and it’s not clear how to fix this.Telecon(s) to be planned to continue the discussion and draft preparation.In consideration for updates to the required environmental section of the MOPS, Jarrett recommended thegroup review AC 21-16F so there is a common understanding on equivalent level of safety considerations forprior environmental standards.Review of Change Candidate DiscussionDave N. led a review of the topics considered for change papers during meeting 1 in March to ensure that thegroup is not ignoring any important topics, nothing falling through the cracks. Dave took notes in thespreadsheet. Notes have been added to the status matrix for the WG1 activity for tracking. The purpose wasto be sure the committee understands what is in work and what is not, with regard to the MASPS update.7

Tuesday, 11/13RTCA Paper No. 009-13/SC227-008January 16, 2013[M1-2c] – VNAV PerformanceDave N. reviewed the paper.General agreement was reached to put this into draft document. Editorial work is needed to resolve an out ofdate regulatory reference in a note.[M3-03] – Vert Dev ScalingWaldo reviewed the “VNAV DEV Scaling” paperBob Gaul objected to the linear display of vertical deviation instead of angular display – all of Garmin’sapproach modes always display angular deviation.Pedro expressed concerns from a pilot training standpoint that the deviation displays should be consistent oneach aircraft between different modes. The main need is for the pilot to determine if they are meeting theapproach requirements, or trending towards them – that can be met either by an analog display or a digitaldisplay.Geoff supported what Bob advocated, different requirement. This text provides linear requirement, angularrequirement is something else.Sylvain described Airbus displays as 200 foot with no scale markings, and expressed concerns about havingdifferent scaling for different modes. Why is the value of the scaling a minimum requirement?Waldo described the need for a standard – there are a variety of implementations with a variety of scalingsup to 500 feet that make it difficult to [develop procedures?].Mike C: Scaling requirement is aimed at the minimum requirement for crew to be able to detect nonstandardbehavior. Are we trying to standardize the method of detection?Pedro: As a pilot, need to be able to determine when we’re coming into tolerance.Dave N. pointed out that a large deviation range, say 1000 feet, can be acceptable if the display size is verylarge, as long as the range is marked sufficiently so that the pilot can determine the small deviationsaccurately enough to meet the requirements.Sylvain: Still not sure if this is a minimum requirement.Dave N: May be able to address some of Sylvain’s concerns, allow some flexibility, through the next roundof edits. Left up to implementers to determine what’s appropriate for their equipment and operations.Agreement was reached to include in draft MASPS after Waldo updated the document per discussion.Updated document was received during the meeting.[M1-12c] – Mag VarSteve J. related events from PARC mag var meeting last week. Some progress toward convergence, butthey are not there yet. Probably will end up with CAT II/III operations requiring 1 degree accuracy.Pedro related a recent discussion with John Hillier “The PARC thinks SC227 is working this issue, andSC227 thinks the PARC is working it.”Dave N. related that the PARC group does expect some work from SC227.Action for Pedro to continue side discussions with John to converge on a recommendation to SC227.[M1-8b] – Temperature CompensationWaldo reviewed the paper.Dave N. notes that the section 1.5.6.2 material is in the assumptions section, yet it doesn’t really describetemp comp assumptions.Several comments that section 3.2.8.6 is too long, and takes too long to get to the “shall”.Need description of roles and responsibilities for actors outside the aircraft.Geoff If ATC doesn’t make accommodations for mixed compensated/uncompensated, how will this work?Presents a risk of loss of separation.Pedro points out that we already have established regulations and procedures for when to use temp comp andthe coordination needed between flight crew and ATC. All we are doing is adding automation of the task.8

RTCA Paper No. 009-13/SC227-008January 16, 2013Dave N: Past practice – even though we create these assumptions, we have parties engaged so that theyknow we’re making these assumptions.Waldo This assumption has caught the attention of ICAO ATC folks, this is an issue that they do need tofollow up on.Sylvain Is temperature compensation provided for vectoring?Waldo ATC needs to clearly understand what the aircraft does, system should not correct what is alreadycorrected, ATC needs to know what they need to compensate vs. what the aircraft needs to compensate.Several comments to also trim the appendix, for example removing the last paragraph of section H.1.Agreement for section H.2.2 that all altitudes shall be compensated – for simplicity reasons and because notdoing so will create altitude separation issues.QFE discussion to be moved to a note.Paragraph on resolution is confusing. Needs to be clear which resolutions are acceptable and when roundingis needed. Do we even need this paragraph at all? Pedro recommends deleting the whole paragraph.Agreement to delete the paragraph.Need for Figure H-4 to be reworked to address comments.Agreement that we will proceed with temp comp. in the standard, with the bulk of the material in theappendix.Action on Waldo and Jeff to continue to edit the text per the comments received.DoneSummary of Thursday breakoutCurrent draft still contains options. Added assumptions section in appendix.Removed repetition and unnecessary detail where possible. Terminology made consistent: above-ISA,below-ISA. Clarified how temperature affects altimetry, avoided path definition error.Text detail that specified solutions, such as FPA, FAF, was removed. (Expect some detail to re-appear inMOPS, though.)Current draft is back to two options again.If temp comp is done, final segment temp comp always required.Optional for pilot to apply temp comp to IAF and IF.Still need to study full vs. simplified solutions and make sure those are described appropriately.Further discussion on FridayMike C. wants this option removed – if any temp comp is done it must all be done. Mike shared an analysisof procedures with temperature issues, and the terrain risk ranges equally across all segments of theprocedures, Initial, Intermediate, Final, Missed.Barry advocates the two options structure due to practical issues related to transitioning equipment andoperational procedures towards the full capability. Lack of a standard ops concept for using temp comp ishard to regulate. If you just apply temp comp to FAF it avoids air traffic problems. Practical operationconsideration, in a busy airport, ATC may not let you turn temp comp on. Supports leaving options in therefor now. Needs worldwide harmony before we say all-on.Geoff asked if these issues are on legacy procedures. Only reservation about the proposal as it stands is thecomplexity. On/off would be something more desirable but understands what Barry is saying. Still evenbetter if you correct the altimetry.Mike C If someone wants to go into airport on one of these procedures, at below minimum temperature, willneed to temp-comp correct entire procedure. Standard going forward should be that you correct the entireapproach, do the corrections or do not.9

RTCA Paper No. 009-13/SC227-008January 16, 2013Waldo and Pedro advocate one option for simplicity – difficult for pilot to know when to apply it to thissegment or that segment, and it adds confusion. Pedro goes as far to say that the two-option concept it is acrew training nightmare to the point that airlines will avoid purchasing the feature just for this reason.Pedro concerned that correcting IAF and IF segments corrected on warm days is a problem – pilots will beflying below the altitudes on the approach procedures, which has regulatory implications, and that tempcomp on cold days will push aircraft up closer to aircraft crossing above.Dave doesn’t see a clear single answer yet. Outside the room, not too many people engaged in this though.Maybe we need to retain the solutions that were discussed, but with some notes that this will make thingsvery messy in the operational world and implementation world. No initiative to drive this solution, from theoutside. Not in favor of the multiple solutions, but maybe for the purposes of the draft we need to go forwardthat way.Waldo says that having a standard is very important, even if it is the two-option solution, so that controllersknow what the aircraft capabilities are and can develop operational procedures to work with them. It willsimplify the issues.Sylvain agrees with others that two options on the aircraft is not workable. We should be taking the secondoption in what feature we put on the aircraft, not asking the pilot to make this decision.Barry said it’s a really tough operational environment, and suggested we try to take the issue to panels atICAO. When temp-comp goes into the MOPS, either you do it as an option or you don’t- equivalent to baroweightingfor GNSS installation. FAA is not in position to say that you need temp-comp on vs. off for entireapproach.Geoff: it would be nice to have only on/off, but still question in mind about hot temp-comp scenario, whichmay cause some issues. Does final include missed? If we’re really concerned about the intermediate, if weput in Pedro’s no climb requirement, would that resolve issues for the intermediate segment?Sylvain: At least in the draft, we should make the distinction that one of the two options will providebenefits, (i.e. only correcting FAF would not provide benefits of providing correction for the entire path). Wecould state this without creating an option. If you correct the whole thing, provides benefit.Waldo We have put this in already, it mentions that we get the benefit from correcting all. Second,assumptions will require accommodation from ATC. Squishyness goes away, this context is mentioned in theassumptions. Hot temp is an operational issue – note that flight crew will know what the compensation is. Ifflight crew chooses to fly the published altitudes, they can do this knowing that they are safe. Hot temp is nota huge problem operationally, because you can choose not to fly that correction.Dave Z Options create cockpit confusion. No safety issue on the intermediate and initial segments in hotweather. Only problem comes in for correcting final path when it’s hot out. Putting a lot on the pilots duringa critical time.Waldo: Not that complex, can be addressed with pilot training. Experience in Canada shows this can bedone.Dave N: Not hearing us converge. Suggest we take the text from the discussions and put it in the draft forcomments.Waldo We have something that does work, has more complexity than we would like, maybe as we go on wecan simplify.Dave N Closing out for now, for now we will include the material in the draft update.Wednesday, 11/14[M1-x04] – TOACSylvain presented of status of the change proposal and a summary of recent changes.Section 2.4 generated discussion on the ETA computation time requirement of 30 seconds. Commentsincluded: 100 points is too many. 100 points is too few.“points” should instead be “fixes”Computation time is not driven just by lateral fixes but vertical complexity, altitude and speedchanges, optimizations, etc.10

This level of detail should only be in the MOPSRTCA Paper No. 009-13/SC227-008January 16, 2013Section 2.5.1Jeff : Concern that tying the 30/10 second accuracy to “cruise” vs. “descent” flight phase may be arbitrary –what is the requirement for an RTA at top-of-descent or slightly before or after?Sylvain suggested that meeting WINDOW constraints with 95% reliability not be a minimum requirement,and perhaps also the AT-OR-BEFORE and AT-OR-AFTER. Lots of discussion, not just about theperformance requirement but about the existence of the functionalities.Sylvain suggested that the specification of the accuracy be part of the functional description, section 3.5, andthat section 2.5 just state that the specified accuracy be met with 95% probability.Sylvain suggested that the behavior of RTA in the presence of speed constraints be reconsidered, that thetime constraint be considered higher priority and that the presence of the time constraint allows the FMS toviolate the speed constraint by 10-15 knots.Pedro didn’t like considering the time constraint higher priority than the speed constraint – don’t mix timeand speed constraints.Sherrie agrees with Pedro – controllers expect speed control or time control. We will only slow aircraftdown from the procedure speeds. We may need to adjust the procedures to remove constraints where timeconstraints are expected.Mike C. suggested that when a time constraint is issued that the speed constraints prior to that point bewaived.Mike J raised concern that the FMS behavior required to meet a time constraint in the presence of an AT-OR-BELOW speed constraint, using a speed “pad” on the constraint speed, will produce operational issues -the RTA aircraft fly a higher speed before the constraint and lower speed after the constraint than non-RTAaircraft and this will reduce the separation. (2009 DASC conference paper on the topic.)Sylvain made a drawing on the white board describing the AT-or-BELOW speed scenario and the AT speedscenario.Chris W. asked why not treat the AT-or-GREATER speed scenario similar to AT-or-BELOW speed.Group agreed on the following (in breakout session): we must obey speed constraints, speed constraints are higher priority we can provide reliability on AT-OR-BELOW speed constrained regions using a speed pad strategyin the TOAC function. The speed pad strategy needs to be described so that vendors can design similar systems.Dave N. said we need to move the requirements out of notes.Dave N said that note 4 (application of 95% in approach) should not be a note if it is a requirement.Dave Z: what does it mean to have a time constraint with no performance requirement?Dave N said that note 6 (RTA reliability duration limit of 40 minutes) needs to be clear that the flight timerequirement is regarding the time between the issuance of the time constraint and the time constraintwaypoint.Discussion on the nature of this issue – that wind errors with non-zero mean over long durations can makemeeting a time constraint difficult. Q: where did 40 miles come from? A: based on operational concept forhow Initial4D will be used – we need the TOAC system to meet a 10 second accuracy over about 200 milerange, so this is what we asked for.Section 2.5.2Dave N: “ETA min/max” – we need better terminology that can be used by flight crews and controllers, andthat even we ourselves understand.Mike C: proposed the “earliest” and “latest” arrival time11

RTCA Paper No. 009-13/SC227-008January 16, 2013Sylvain clarified that this is a “reliable” window, not just maximum / minimum achievable – we can meetthese times with 95% reliability. “Earliest / latest reliable times” is acceptable.Action for breakout session to determine better terminologyNote 3 (applicability of 95% reliability to at/before, at/after constraints) needs to be simplified. This is easierif we remove window time constraints.Q: does a time constraint still apply to an offset path?(answer?)Section 3.5 TOAC Functional requirementsPedro suggests that the capability for pilot to enter a min/max RTA speed be a minimum requirement, toaddress considerations of turbulence and speed restrictions.Chris W. we did run into these issues in Seattle, because the FMS treated the speed constraint as at AT-or-BELOW, and they didn’t want RTA speeds below the constraint speed.Mike J. said that once we implement AT speed constraints properly, we won’t need the RTA speed min/maxto address the speed restriction issue. We should not use that as a justification for the functionality.Erwan challenged the need for this capability and for it to be tied specifically to the RTA functionality. Itmay be appropriate to apply the min/max speed to ECON mode.Guy D. also challenged the need for this as a minimum capability because there are some low performanceaircraft that won’t need it.Pedro maintains that there is operational need to prevent the RTA system from using full authority betweenthe min and max performance limits.More discussion needed. Action for breakout group to word it.Breakout discussion agreed that this is not a minimum requirement. It will be described as an operationalconsideration or note.Accuracy discussion, 10 vs. 30, selectable value, etc.Dave Z suggests that we consider TOAC accuracy requirement like RNP value – we have a default value byflight phase.Comment made that the discussion of TOAC behavior in lateral steering mode does not go far enough.Besides stating that we do not delete the time constraint we should consider describing desired behavior bythe TOAC system during this situation. Currently some FMSs freeze the speed target sent to the autothrottle,while other systems continue to adjust the speed target to absorb the increased path distance. This variabilitycreates additional workload for controller and pilot to coordinate desired behavior in this situation.Group agreed to specify that the speed will be maintained in lateral steering mode and the TOAC speedtracking will resume when lateral steering is re-engaged. (Later discussion clarified that the TOAC speedsent to the guidance system will be frozen, but the speed target may still change due to other considerationssuch as flight envelope, speed constraints, speed limits, etc.)Comment that the last sentence in section 3.5.2, on flight crew awareness of TOAC mode, belongs in section3.6. Agreed.Summary of agreementsWindow constraints are not a minimum requirementReliability only required on at-or-below speed constraints up-path of RTA constraint.Reliability now required on at-or-before and at-or-after.Consolidated functional description in section 3.5Moved requirements in notes out of the notes.Min/max RTA speed page is optionalTOAC behavior in heading mode specifiedETA 1% requirement details removed.12

RTCA Paper No. 009-13/SC227-008January 16, 2013Open itemsWording for flight phasesCleanup related to moving requirements out of notesRequirements if any of TOAC on offset pathsTerminology discussion needed for ETA min/max.Section 3.6Mike J. if the system allows display and entry of TOAC accuracy requirement, then the resolution of thisfield should appear in table 3-4. Agreed by group.Section 3.7Jarrett – terminology on annunciation is not consistent.Section 4.2.3 ETA performanceMike J. the wind model error discussion focuses on altitude variation of wind, but does not discuss lateralwind modeling. Group agreed that the discussion should include lateral aspects of wind model.Mike J. pointed out that the wind model error discussion, “this error shall be evaluated using simulationswith different types of wind/temperature profiles” might be a big deal if this is interpreted as a requirement.If the environment contains a large wind gradient, it can be very challenging to prove meeting a 1% ETAaccuracy in these situations. Do we need this level of detail as a minimum requirement?Dave N. suggested that this detail should be moved to the MOPS or means of compliance.Sylvain confirmed that this text was intended as a clarifying example, not a requirement.Group agreed to remove the wind model example from this section.Action for Chris W. to assess meteorological assumptions of the appendix.Action for Mike C to review for editorial cleanup prior to draft MASPS inclusion.Thursday, 11/15[M1-x02] SC214 Interface – Dynamic PBNJarrett used a PowerPoint to lead the discussion.Brussels discussion points: Parts of concept may be feasible – datalink of transition type and RNP valueSafety concerns over use in approach regionLeg types dropped from the proposal – safety concerns over transmission of leg type without chartcross-check.ISRA process started to provide official backing for recommendations for SC214.4 CPDLC messages have the capability to send up route clearances based on the RouteClearance variable,which can contain arbitrary waypoint strings or can invoke published route segments (airways andprocedures).Issue is that ATC does not have ability to specify navigation performance requirements on the waypointstring type of clearance, so they have to allocate more airspace for aircraft on this type of clearance.Proposal is to add RNP value and transition type as optional fields on each waypoint in the clearance.Some members (Sylvain) expressed concern that this will be an expensive change on the avionics and thatthe operational use is not ready to support the use of the functionality. So it would result in large cost withno benefit.Mike J Using this kind of capability for approaches violates SC214 assumptions in their safety assessment ofwhat kinds of bad things can happen. Using dynamic approaches breaks their safety assessment. Suggest westay away from proposing that.Dick concern that FRTs will be difficult to evaluate if they are flyable, both for the ATC system, the FMS,and the pilot.13

RTCA Paper No. 009-13/SC227-008January 16, 2013Point raised that the datalink standard is a maximum standard, and this feature could be optional in thedatalink standard. But, this would put us in the position of recommending a feature that we don’t plan to usein the near term. Jarrett suggests that this may still be appropriate, given the expected lifespan of the datalinkstandard.Barry supported RNP in tenths of a NM increments.Dave N requested that Mike C, Sylvain, Jarrett, Mike J to take a go at rewording the introduction to makemore direct.Geoff requested more international perspective of benefits to broaden appeal. He offered to assist in addingcontent.Dave N Change terminology: navigation performance to RNP for international audience. Also, noted thatthe described capabilities are already in the MASPS as well as general guidance on datalink as a means ofexercising the system capability.The ISRA for SC214 will reflect our views to have the datalink interface support the existing MASPScriteria which are being retained for the update.SC214 CPDLC ISRAA breakout session worked on the ISRA draft and backup paper.The group is still struggling to get consensus on what we want SC214 to publish.Concern was expressed that we don’t want to take a position that endorses the operational concept that usesdynamic PBN. Two options proposed to proceed.Jarettt proposed a stronger ISRA, but falling short of endorsing the ops concept.Dave N Developed alternative version, does not comment on ops concept but just responding to the pointsthat there is a top level need and requirements for what is in the MASPS today and needs to be supported bydatalink. We did our assigned task in identifying a gap.Group showed a general preference for Dave’s version - just responding to message requirements.Dave’s revision posted with action to the full committee to comment by November 23.SC214 Message Set ReviewMike Jackson led a review of a PowerPoint summary of issues raised where the datalink standard beingdeveloped needs to be coordinated with SC227. The issues collected were categorized as follows:1) SC227 relevant – These issues were discussed in plenary and recommendations will be provided toSC214 from SC227.2) Not-SC227 relevant – These issues were still discussed by interested parties, but in a smaller group.The comments resulting from this discussion will still be provided to SC214, but not officially fromSC227.Action for Mike Jackson to convert the Powerpoint presentation with notes from the discussion into a twocomment matrices and/or white papers and submit for SC214 plenary meeting in December.[M1-1] – Integration with approach ops – RNP to xLSNot discussed.[M1-3] – Flexibility WindowsSince only the time window will be required this proposal was merged with the TOAC [M1-x04] changeproposal.[M1-x01] – 4D Trajectories, Additional ReqmtsNot discussed14

Low RNPNot discussed.RTCA Paper No. 009-13/SC227-008January 16, 2013RNP TerminologyNot discussed.Friday, 11/16Full group review of the breakout sessions. Notes included in respective sections above.SC-186 InterfaceThis area is still lagging and more effort is needed.Jarrett has tried to initiated discussions, but not much coordination has occurred yet.Cursory review says I don’t know that we need to make any changes in respect to SC186.Jarrett Two concepts of operation, some consideration of how they might use PBN for navigation.Dave N Multiple concepts for ADS-B, all hinge on trajectory. We have to figure out what does PBN bring,by having more path information. PBN related changes to the interface and data above what is alreadyidentified, may not be necessary or appropriate.Jarrett and Dave N. to continue to work connections with SC-186 to determine what level of coordinationis appropriate. No ISRA is planned at this time.MASPS Schedule Final white papers due to Mike Cramer December 21 st MASPS Draft will be complete Jan 14 th Jan 30 th comments due Paper authors review comments and update drafts in preparation for meeting. Feb 11-15, 2013 Plenary at Brussels Final review and comment collection. Final Draft to group, February 22 nd FRAC comment response forms due March 22 nd . Organized comments and proposed dispositions, April 1 st April 8-12, FRAC, final document complete on April 12 th . Final document submitted to RTCA June 13 th PMC meeting to approve document.MOPS Overview and Planning:MOPS layout and structure was presented, and discussion started on the process that the committee will usein moving forward on developing the MOPS.WG2 will retain WG1 change numbering system to maintain consistency between change updates.Agreement reached that 3 classes of capability will be needed.Tentative names for the 3 classes are 2D, 3D, and 4D.Note that 2D class represents minimal changes from current MOPS (DO-283A) and TSO-C115c. – . Actionon interested members to inform Michael GS and/or Chris Shehi to add you to the WG2 member list.Jarrett recommended the group review AC 21-16F so there is a common understanding on equivalent level ofsafety considerations for prior environmental standards – Action on all MOPS interested parties.Jarrett – Request day for identifying what we’re trying to change to MOPS.Dave N. – Need to publicize among any MOPS stakeholders, make sure they’re aware.15