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