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