comments to guidance material 15 sept 2011 meetings seminars and worksho… · comments to icao...

Comments to ICAO document reference: “PBNTF5 WP05 Rev 1 Guidance Material RNP APCH Updated August 2011.doc”

Last update: 03/11/2011 by EUROCONTROL

1/34

# Comment originator

document/ Section/Page

Comment / question Response Status (closed/Open)

1. AENA (R.

Pecos)

Whole doc I have been reading with the highest

interest in such document and I would like

to suggest a couple of comments for your

consideration, provided that it would be

possible. Generally speaking, it is a good

guidance material. I think it gives an

explanatory and “friendly” picture of all the

“new” concepts derived from RNP

approaches. Congratulations for that good

work.

N/A Closed

2. IATA (A.

Van Der

Velt)

Whole doc Comment 1: The document provides mainly

guidelines for States and ANSPs whilst it is

assumed that the Operator has the

equipment on board and is approved to

execute Baro-VNAV procedures. The latter

being still an "EASA obstacle" for airlines

that did not receive approval based on AMC

20-27's too stringent operational

requirements compared with FAA AC 20-

129. This has created a non level playing

field. It should be sufficient to be approved

based on FAA AC 20-129 as an alternative

means of compliance. The situation is

detrimental to proliferation of PBN Baro-

VNAV operations.

Not a comment on the guidance – something

directed at EASA.

Closed

3. Eurocontr

ol (G.

Berz)

Table of

content

It seems to me the table of contents

doesn't match the document?

fixed



2/34




4. AENA (R.

Pecos)

Glossary of

The Main

Terms

Taking advantage from the very last

proposals for amendment to some ICAO

documents, those are: PANS-OPS, vol II

(doc. 8168); Annex 14, vol I; Annex 6, part

I; and Annex 10 vol I; what are very

consolidated and mature, I would put the

new definitions (or re-definitions), related

to the RNP APCHs, in the part “Glossary

of The Main Terms”, including definitions

for types of approaches, types of runways

and OCA/H and DA/H, MDA/H, despite they

are explained at the body of the document.

Not accepted.

The Definitions are still evolving and are not

yet stable. We should stay with the

currently published definitions until they are

formally changed in ICAO documents

Closed

5. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

Definition of APV to be updated in order to

be compliant with the definition in PANS-

OPS:

“An instrument procedure which utilizes

lateral and vertical guidance but does not

meet the requirements established for

precision approach and landing operations.”

Accepted

Although this definition is expected to

change in the near future.

Closed

6. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

“APV Baro” to be replaced by “APV Baro-

VNAV” in order to comply with Doc 8169 p.

III 3.4.1

This comment applies to the whole

document.

Accepted

Closed

7. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

“Baro-VNAV”: Why not using the definition

used by Doc8168 :

“Barometric vertical navigation (Baro-

Accepted

Closed



3/34




VNAV) is a navigation system that presents

to the pilot computed vertical guidance

referenced to a specified vertical path angle

(VPA), nominally 3°. The computer-

resolved vertical guidance is based on

barometric altitude and is specified as a

vertical path angle from reference datum

height (RDH).”

8. Jeppesen

(S.

Onitiu)

Glossary of

The Main

Terms

Suggests adding definitions for CRC,

EGNOS SoL, FAS DB

Accepted

Closed

9. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

Definition of ABAS to be added Accepted

Closed

10. Jeppesen

(S.

Onitiu)

Glossary of

The Main

Terms

Suggest adding MSAS and GAGAN in the

GNSS definition

Accepted

Closed

11. Jeppesen

(S.

Onitiu)

Glossary of

The Main

Terms

In LNAV, LPV, LNAV/VNAV and LP

definitions: Actually LNAV, LNAV/VNAV, etc

are defined as Level of Service (ARINC 424)

or Mode of Operations (ICAO). The term

‘minima line’ is reflecting only the charting

aspect. Therefore, I suggest to add above

industry/ICAO terms.

Accepted

Closed

12. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

Proposed some small modification in the

definition for “LNAV, LNAV/VNAV, LPV and

LP” “… distinguish the various the minima

Accepted

Closed



4/34




lines on the RNAV(GNSS)chart.”

13. EBAA (P.

Vincente

Azua)

$ 2.13: Is AMC 20-27 really equivalent to FAA AC

20-129?

No there are known differences. EASA are

planning to publish a memo explaining how

to treat aircraft with AC 20 129 approvals.

The text has been modified to remove

reference to AC 20-129

closed

14. Jeppesen

(S.

Onitiu)

Glossary of

The Main

Terms

In LNAV/VNAV definition: The SBAS

receiver has also the ability to provide

vertical guidance beside supporting APVs

thru FAS data block ‘guidance’. Therefore

the VNAV mode of LNAV/VNAV is provided

thru two on-board capabilities namely

Barometric altimeter or SBAS VNAV

functionality. Suggest adding to the

explanation of the term LNAV/VNAV.

Accepted

closed

15. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

Amended LNAV/VNAV definition: “the

minima line based on Baro-VNAV system

performances and can be used by aircraft

approved according to AMC 20-27 or

equivalent (for example FAA AC 20-129).

LNAV/VNAV minima can also be used by

aircraft computing SBAS information for

positioning. “

Accepted

Closed

16. Jeppesen

(S.

Onitiu)

Glossary of

The Main

Terms

In LPV definition, add in full text “Localizer

Performance with Vertical Guidance”

Accepted

17. DSNA/DTI

(C.

Glossary of

The Main

Amended LPV definition: “the minima line

based on SBAS performances and can be

Accepted



5/34




Bousquet) Terms used by aircraft approved according to AMC

20-28 or equivalent.”

18. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

LP definition: replace “minima line to be

flown” by “to be used”.

Accepted

19. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

LP definition: about “due to obstacles,

terrain, airport infrastructure limitations”. Is

fair to let it without more explanation?

Accepted. Further text has been added.

20. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

PBN definition: remove “availability” from

the definition

Accepted

21. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

RNAV approach definition: replace “to

ground-based navigation aids” by “to/from”

Accepted

22. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

RNAV approach definition: replace last

sentence by “RNP APCH navigation

specification is synonym of RNAV

approach.”

Accepted

23. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

RNP AR APCH definition: complement last

sentence with “in particular environments

rich in terrain and dense terminal areas”

Accepted

24. DSNA/DTI

(C.

Bousquet)

Glossary of

The Main

Terms

SBAS definition: replace “used for the

augmentation of GNSS signals” by “used for

the augmentation of core constellation

GNSS signals”

Accepted

25. AENA (R. $ 2.19 - About “LP” and its associated note: “Not Accepted



6/34




Pecos)

and Pildo

Labs (S.

Soley)

Figure 1 planned in Europe”, I do not know the

rationale supporting that, but could be a

constraint for the implementation of SBAS

operations. We have not explored the

suitability of LP procedures, but for our

orography and, bearing in mind the EGNOS

area coverage, maybe LP operations could

be something appropriate or advantageous

for some Spanish scenarios (South

Peninsula and Canary Islands). Maybe, it

would be good having a short explanation

of the rational for such note or probably

eliminate it.

The note has been removed.

26. EBAA (P.

Vincente

Azua)

$ 2.19 -

Figure 1

Why is LP excluded from Europe planning?

In some circumstances, LP can be a

solution (e.g. requirement of a high descent

angle). I understand and approve Europe's

concern to reduce unstable approaches by

encouraging CDFA. Encouragement in this

respect must be done by providing no

operational benefit when flying a LNAV or

LP without applying the CDFA technique.

But this must not lead to the exclusion of

possibilities. It is the safety case at each

airport that must rationalize the choice.

Accepted.

The note has been removed.

27. DSNA/DTI

(C.

Bousquet)

$ 2.19 -

Figure 1

About LP: needs to be investigated before

stating “Not planned in Europe”.

Accepted



7/34




28. EBAA (P.

Vincente

Azua)

$ 2.19 -

Figure 1

+ $ 4.1.2

The distinction between linear deviation(s)

(LNAV and LNAV/VNAV) and angular

deviation(s) (LP and LPV) must be

highlighted as a criterion required for

precision approaches. The safety benefit of

stable approaches does not end at the

published minimum, but reliable guidance

information provided by precision

approaches down to the flare (50ft AGL)

helps the pilot to maintain stable

approaches until the touchdown (reducing

the chance of "too" short/long landings).

Agreed.

However, it is difficult to modify the text to

address the comment directly as the

difference is not so clear. For example,

there are LNAV and LNAV/VNAV systems

that provide angular guidance.

All four approaches in the figure are RNP

APCH according to PBN and they will be

published on a chart with the title RNAV

(GNSS).

The debate over what is, or is not a precision

approach is still under debate in ICAO. The

ICAO ACTF discusses approach classification

and we must wait until they come to a

conclusion on the subject.

Closed

29. Jeppesen

(S.

Onitiu)

$ 2.19 -

Figure 1

Add “SBAS VNAV” below “APV Baro” Not agreed. This figure is high level and

should not be over complicated. Yes the

LNAV/VNAV procedure can be flown with

SBAS (under certain circumstances) but this

is explained in the text. (Definitions)

30. DSNA/DTI

(C.

Bousquet)

$ 4.1.1 Replace “has made it possible to use RNAV”

by “to use area navigation”

Accepted.

31. EBAA (P.

Vincente

Azua)

$ 4.1.2 EBAA believes LPV should not be considered

anymore as part of the RNP approach. LPV

are considered by both FAA and EASA as

precision approaches and therefore should

Not Accepted

This comment cannot be taken onboard by

this guidance document. Today LPV is

defined in ICAO as an RNAV approach and



8/34




be included in this paragraph. complies with RNP APCH navigation

specifications in the PBN Manual. The ICAO

ACTF discusses approach classification and

we must wait until they come to a conclusion

on the subject before adopting any new

terms.

32. DSNA/DTI

(C.

Bousquet)

$ 4.1.2 In “PA” and “NPA” definition add “uses for

the final approach segment” …

Accepted

33. DSNA/DTI

(C.

Bousquet)

$ 4.1.2 In PA definition, replace “bring the aircraft

to a point where the runway is in view and

a visual landing can be performed” by “and

provide only lateral guidance along the final

approach segment”

Accepted

34. DSNA/DTI

(C.

Bousquet)

$ 4.1.3 Replace the last sentence by “The RNAV

system can be used for approach phase of

flight, provided RNAV approach procedures

are designed and published. RNAV

approach are described by a series of

waypoints, legs, altitude and speed

constraints published and stored in the

onboard navigation database.

Accepted

35. DSNA/DTI

(C.

Bousquet)

$ 4.1.4 Remove “called GPS NPA”

Complement the sentence by “as with

conventional NPA procedures, which is

indicated as the LNAV minima line on the

RNAV(GNSS)chart.

Accepted



9/34




Remove the last sentence from “Although”

to “are currently based on GPS”.

36. DSNA/DTI

(C.

Bousquet)

$ 4.1.5 Replace “to implement RNP APCH” by “to

use RNP APCH”

Accepted

37. Jeppesen

(S.

Onitiu)

$ 4.1.6 Replace 1st sentence by “The step-down

level-off or dive and drive descent

technique for flying NPAs containing step-

down fixes, which is prone to error, can

also be removed.”

Accepted

38. DSNA/DTI

(C.

Bousquet)

$ 4.1.6 Replace first sentence by “The step-down

descent technique used along conventional

final approach segment in NPA procedures,

which is prone to error, can also be

removed from RNAV final approach

segment.”

Accepted.

39. DSNA/DTI

(C.

Bousquet)

$ 4.1.6 Shouldn’t the “can also be removed” be

replaced by a “should”?

Accepted

40. DSNA/DTI

(C.

Bousquet)

$ 4.1.6 About “Operators are being encouraged”

add the following foot note: “This is even

mandatory for public transport and general

aviation (heavy aircraft only)”

Accepted

41. DSNA/DTI

(C.

$ 4.1.6 Remove “where a continuous descent

vertical path is followed”.

Accepted



10/34




Bousquet)

42. DSNA/DTI

(C.

Bousquet)

$ 4.1.6 Replace “the design of Non Precision

Approach” by “NPA procedure”

Accepted

43. DSNA/DTI

(C.

Bousquet)

$ 4.1.6 Replace “nominal descent angle” by

“gradient”

Accepted

44. DSNA/DTI

(C.

Bousquet)

$ 4.2.1 Add “with a constant rate of descent based

on the Barometric altimeter, or on GPS

augmented SBAS position”

Accepted

45. DSNA/DTI

(C.

Bousquet)

$ 4.2.2 Add at the end of the paragraph “The

vertical guidance is provided only along the

final segment whatever onboard system is

used”

Accepted

46. DSNA/DTI

(C.

Bousquet)

$ 4.2.4 Replace “are flown to the LPV minima line”

by “are flown to a Decision Altitude/Height

indicated in the LPV minima line

Accepted

47. DSNA/DTI

(C.

Bousquet)

$ 4.3.2 Replace paragraph by “For intermediate,

final approach, initial and intermediate

phases of missed approach, the ICAO PBN

Manual specifies RNP APCH navigation

specifications which are to be found on

PBN, Volume II, Part C, Chapter 5 [1].

Initial approach segment and final missed

approach segments can be supported either

by RNP APCH or by RNAV1.” (only add-ons)

Accepted



11/34




48. DSNA/DTI

(C.

Bousquet)

$ 4.3.3 Replace paragraph by “APCH procedures

are published on charts with the title

RNAV(GNSS) RWY XX. That is the reason

why they are referred to so far as RNAV

approaches. These approach charts can

have several minima lines depending on the

type of final segment defined with the RNP

APCH operation to be flown. The table

below provides cross reference between

RNAV PANS-OPS and PBN terminology.

Accepted

49. DSNA/DTI

(C.

Bousquet)

$ 4.3.3 –

Table 1

Replace beginning of the first column of

the table by:

PANS-OPS terminology

NPA GPS

APV Baro VNAV

Accepted

50. Jeppesen

(S.

Onitiu)

$4.3.3 -

Table 1

Change the last column with:

Basic GNSS,

Basic GNSS + Baro VNAV/SBAS VNAV

SBAS

SBAS

Table amended to say “minimum sensor”

The statement that SBAS/VNAV can be used

to fly the LNAV/VNAV minima line is clearly

in the text.

51. EBAA (P.

Vincente

Azua)

$ 4.3.3 –

Table 1

RNP APCH down to LNAV/VNAV can be

flown with SBAS sensor (see $ 4.2.3).

Table amended to say “minimum sensor”

52. DSNA/DTI

(C.

$ 4.3.5 Complement the sentence in the paragraph

with “navigation performance is expressed

OK – needs to be considered with comment



12/34




Bousquet) as an RNP value for NPA and APV Baro-

VNAV.”

below.

53. Thales (P.

Bouniol)

$ 4.3.5 We think that you should not mention “and

navigation performance is expressed as an

RNP value”. One of the characteristics of

RNP-APCH is that there is not a single RNP

value (values for initial/intermediate and

final segment are different)

Accepted

54. DSNA/DTI

(C.

Bousquet)

$ 4.3.6 Remove in the paragraph “despite the use

of different terminology, the RNP APCH …3

Accepted

55. DSNA/DTI

(C.

Bousquet)

$ 4.4.1 Amend first sentence by “An The important

distinction between the different types …”

Accepted

56. DSNA/DTI

(C.

Bousquet)

$ 4.4.2 Replace “… for the different flavours of RNP

…” by “for the different RNP APCH

operations”

Accepted

57. DSNA/DTI

(C.

Bousquet)

$ 4.4.3 Replace “The vertical path angle is usually

defined between 50ft above the runway

threshold and a final capture point (for

example the FAF)” by

“The vertical path angle is computed

between 50ft above the runway threshold

and a final capture point which corresponds

to the location of the FAF associated with

the NPA RNP APCH even though the WP

associated with the FAF of the NPA RNP

Accepted



13/34




APCH is never used on board to start the

final descent for the APV BaroVNAV. The

final path starts when the aircraft intersects

the vertical final guidance. But this point of

intersection is very close to FAF of NPA RNP

APCH.”

58. DSNA/DTI

(C.

Bousquet)

$ 4.4.3 Replace the last sentence of the $ by “. The

final descent is also influenced by

temperature: temperature limits are

published on the chart.”

with the following foot note: “Currently only

the lower temperature value is published on

the chart”

Accepted

59. Jeppesen

(S.

Onitiu)

$4.4.4 According to State Letter B2.1 ‘Navigation

Infrastructure’, replace 1st sentence by

“RNP APCH to LPV minima is based on

augmented GNSS and (SBAS).”

Accepted (see comment below)

60. DSNA/DTI

(C.

Bousquet)

$ 4.4.4 Amend 1st sentence with “…based on GNSS

core constellation and SBAS.

Accepted

61. DSNA/DTI

(C.

Bousquet)

$ 4.4.4 Add the following sentence before the last

sentence: “The vertical path angle is

defined (not computed) and published in

degree (mainly 3°).”

Accepted

62. DSNA/DTI

(C.

Bousquet)

$ 5.2.2.2.1 Amend $ by “… LNAV minima as an

acceptable alternative to APV in places

where APV implementation is not possible

Accepted



14/34




or does not make sense as no aircraft are

suitably equipped for APV operations”.

63. EBAA (P.

Vincente

Azua)

$ 5.2.2.2.2 We are surprised to see that aircraft below

5,700 kg MTOW are excluded from APV and

LPV. This does not reflect what is currently

done by EASA and FAA.

This is a quote from the ICAO Assembly

Resolution. States are recommended to

implement APV at runway ends serving

aircraft with a maximum certificated take-off

mass of 5 700 kg or more. For aircraft

below that weight there is no

recommendation.

64. DSNA/DTI

(C.

Bousquet)

$ 5.2.2.3.1 Typo “Non Precision Approaches” Accepted

65. DSNA/DTI

(C.

Bousquet)

$ 5.2.2.3.1 Replace “better” by “APV operation” in the

text in bracket: “(APV operation back-up

solution in case of ILS outages)”

Accepted

66. DSNA/DTI

(C.

Bousquet)

$ 5.2.2.8.1

and 5.2.2.8.2

Replace “APV” by “RNP APCH” (3

occurrences).

Accepted

67. Jeppesen

(S.

Onitiu)

$ 5.2.5.3 Recommend to remove end of the

paragraph (“such as an NPA”) as not

necessary (redundant)

Accepted

68. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.2.2 Typo replace “PANS OPS” by PANS-OPS” Accepted

69. DSNA/DTI

(C.

Bousquet

$ 5.2.6.2.2 In the two bullet points, DA/H must be

replaced by DH

Accepted



15/34




& R.

Guleac)

70. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.4.1 Is the following sentence correct: “GPS is

the only fully operational core GNSS

available”

Maybe not 100%. The text has been

removed.

71. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.4.1 Add “All NPA RNP APCH …” in 2nd sentence. Not agreed. All types of RNP APCH rely on

the use of GPS. This is true. Baro VNAV and

SBAS users also rely on GPS.

72. Jeppesen

(S.

Onitiu)

$ 5.2.6.4.3 Propose to add a sentence at the end of the

paragraph: “The EGNOS Safety of Life

(SoL) service commissioning took place on

2 March 2011. The EGNOS SoL is provided

free of direct user charges.”

Accepted

73. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.4.6 Is the word “refers” correct in the

sentence: “(For the EU States EC

Regulation No 550-2004 Article 10 refers)”

Accepted - propose to replace by “applies”

74. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.4.7 Replace “coverage” by “service” in “if

suitable EGNOS coverage is available”

Accepted

75. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.4.9 Delete the end of the paragraph: “and ATC

prefers not to be provided with this data.”

Accepted

76. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.4.10 Amend the paragraph as follows:

“(approach clearance is according to

approach name – RNAV(GNSS) – and not to

the type of minima). An aircraft will follow

the same lateral path whether performing

Accepted



16/34




an approach down to LNAV, LNAV/VNAV or

LPV minima available on the same chart.”

77. Eurocontr

ol (G.

Berz)

$ 5.2.6.4.11 The stuff about GNSS monitoring is mostly

on Annex 10 (not so much in 8071 as far as

I remember) and the GNSS Manual treats

the subject as well. While I understand you

wanting to make clear that there is no strict

requirement I personally still consider it a

useful activity, especially for the detection

of RFI.

Agreed. Refer to Annex 10.

78. DSNA/DTI

(C.

Bousquet)

$ 5.2.6.5.1 Replace paragraph by “RNP APCH

operations are based upon GNSS including

missed approach segment. Nevertheless, if

required by the local safety assessment,

some conventional navaids (VOR, DME,

NDB) can be locally maintained.

Accepted

79. Jeppesen

(S.

Onitiu)

$ 5.2.6.5.4 My suggestion is to split the statements in

order to differentiate between a clear

requirement in PANS-OPS for Baro-VNAVs

i.e. procedure is not authorized with remote

QNH and a statement for LPVs which is

under consideration. “Remote QNH is

acceptable in the case of RNP APCH to

LNAV. and LPV minima (TBC). This is

accounted for in the procedure design.

Remote QNH for APV procedures down to

LPV minima is under consideration..”

Accepted

80. DSNA/DTI $ 5.2.6.5.4 TBC is the following sentence needs Confirmed. TBC has been removed.



17/34




(C.

Bousquet)

urgently to be confirmed before the

publication of the document: “Remote QNH

is acceptable in the case of RNP APCH to

LNAV and LPV minima (TBC).”

81. Thales (P.

Bouniol)

§ 5.2.6.5.4 You mention that remote QNH might be

acceptable for LPV. Even if the descent

profile following is based on the GPS/SBAS

altitude, the DA estimation is based on

Zbaro. A local QNH should be thus required

instead of a remote.

This is still under discussion at IFPP.

82. DSNA/DTI

(C.

Bousquet)

$ 5.2.7.2.4 Amend the 3rd bullet with “Does the aircraft

have an RNAV or RNP capability onboard?

For what phase of flight?”

Accepted

83. DSNA/DTI

(C.

Bousquet)

$ 5.2.7.2.4 Amend the 6th bullet with “Does the aircraft

operator …” and propose to highlight in bold

the word “airworthiness”

It is the aircraft which is certified, so it is

proposed to replace “operator” by “aircraft”.

The two words “airworthiness approval” are

proposed to be highlighted.

84. DSNA/DTI

(C.

Bousquet)

$ 5.2.7.2.4 In 7th bullet highlight in bold the word

“operational”

Accepted. propose to highlight “operational

approval”

85. DSNA/DTI

(C.

Bousquet)

$ 5.2.7.2.4 What does 8th bullet brings in addition to

the bullets before?

Nothing. Propose to remove.

86. DSNA/DTI

(C.

Bousquet)

$ 5.2.8.2 Do you think the PANS-ATM (doc 4444)

provides enough information?

Yes. For the moment we do not have

anything better to propose. I expect this will

be revisited in the light of experience.



18/34




87. DSNA/DTI

(C.

Bousquet)

$ 5.2.8.5 It is more than necessary to provide an

example at least to support the following

paragraph: “In line with Amendment 1,

aircraft navigation equipment and capability

for PBN applications, including RNP APCH,

are catered for through the application of

dedicated indicators in items 10 and 18 of

the flight plan. Entries made under Items

10 and 18 of the FPL will indicate the

equipment level and capabilities of the

aircraft. ATS automated systems need to be

upgraded to be able to extract this

information from the FPL and it would need

to be agreed what information to display on

ATC working positions. However, ATC do

not require detailed information about the

PBN equipment on board an aircraft

requesting to carry out an RNAV approach.”

The operational concept for the use of the

new flight plan parameters has not yet been

developed. It is impossible to provide a

concrete example at this time. What we

wanted to indicate is that this is not required

today for the implementation of RNP APCH.

88. DSNA/DTI

(C.

Bousquet)

$ 5.2.8.7 Replace “(for LPV)” by “(for APV SBAS)” Accepted

89. AENA (R.

Pecos)

$ 5.2.9 -

Activity 8

Regarding to “5.2.9. Activity 8: Benefits

and costs for RNP APCH implementation”,

there are other benefits: Deployment of

some conventional navaids (maintenance,

calibration flights, etc.), and even, jointly to

that, the possibility to have less building

constraints in the aerodrome, bearing in

mind obstacle limitation surfaces related to

Accepted



19/34




the navaids that limit the construction of

hangars, TWRs, aprons, etc. -> possibility

to develop more the aerodrome, and

improve services. I am not sure how to put

all that in the text.

90. Jeppesen

(S.

Onitiu)

$ 5.2.9.2.2 3rd bullet : Replace “step” by “activity” Accepted

91. Jeppesen

(S.

Onitiu)

$ 5.2.9.2.3 Add “navaid” in sentence: “ground navaid

infrastructure”

Accepted

92. AENA (P.

Haro)

$ 5.2.10.1 –

Table 2

In Table 2, it is stated that the best

achievable minima for APV SBAS is 200 ft.

However, according to Appendix 1 (New) to

OPS 1.430 ‘Aerodrome operating minima’

(page 72) for APV the DH is not lower than

250 ft and the RVR is not less than 600 m

unless approved by the Authority. I suggest

to refer to the same DH figure than the one

mentioned in the OPS 1.430 and also to

include the RVR value.

Accepted. The best achievable minima for

APV SBAS is defined in PANS-OPS as being

250 ft. We can also add a reference to EU

OPS (which replaces OPS 1.430) and RVR

values.

But – we would like to think that EGNOS will

be able to support 200ft DH one day.

We think that this table adds little value and

raises a lot of questions. Propose to delete

the table.

93. EBAA (P.

Vincente

Azua)

$ 5.2.10.1 –

Table 2

Note that the Table 2 recognizes a best

theoretical achievable minimum of 200ft for

LPVs.

see response to comment 92 above from

AENA.

94. DSNA/DTI $ 5.2.10.1 – About “200 ft” add the following foot note: See response to comment 92 above from



20/34




(C.

Bousquet)

Table 2 “To be expected after 2015” AENA.

95. Jeppesen

(S.

Onitiu)

$ 5.2.10.1 –

Table 2

Two lines proposed to be added to table 2:

Authorization for remote QNH setting: - /+

Database requirements (FAS DB, procedure

extract/package): +/-

Agree with 1st point but not with 2nd.

It’s difficult to say whether the need for a

FAS DB is an argument in favour of APV

SBAS rather than of APV Baro-VNAV. Maybe

this is more complex to code, but on the

other hand this secures the intent from the

designer. We agree having the FAS DB

means that more data are to be checked by

data packers (and this may even be more

“effort demanding” when it is encoded in a

binary file) but again, the definition of path

in space is probably better defined like this.

96. DSNA/DTI

(C.

Bousquet)

$ 5.2.10.1 –

Table 2

About “The airport elevation is higher than

5000 ft AMSL”, this statement shall be

supported by a paragraph providing

rationale”.

Accepted

97. IATA (A.

Van Der

Velt)

$ 5.2.10.1 –

Table 2

Comment 2: Table 2: shows Guidance

Material for States and ANSPs to choose

between APV Baro or APV SBAS

procedures, especially the airport elevation

height of > 5000 ft AMSL.

First of all this airport height of > 5000 ft

AMSL is wrong. Meant is t the FAF altitude

at > 5000 ft and not the airport height,

which translates in an airport height of >

3000 ft (1000 m) and with the aircraft at

This is an IFPP issue and cannot be

addressed in the guidance.



21/34




the FAF at 2000 ft above the airport

Secondly, it is obvious that the criteria of

the FAF height of > 5000 ft AMSL has a

detrimental effect on Baro-VNAV

applications, as there are many airports

that are located at a height AMSL of 3000 ft

(1000m) and above

The practical im plication of this criteria will

be that Baro-VNAV procedures are not

permitted at airports that have an elevation

of 3000 ft and above and will lead to

marginally offering of Baro-VNAV

procedures globally by States/ANSPs and

consequently will hamper PBN proliferation

severely.

We strongly recommend that the criteria be

cancelled from the table until after the new

design for APV Baro are available. In this

sense, the subject is being worked on by an

ICAO APV Baro-VNAV drafting group that

will deliver its findings to the ICAO IFPP

that is reporting to the ICAO PBN Steering

Group for its consent

98. EBAA (P.

Vincente

Azua)

$ 5.2.10.3 To facilitate the process to publish multiple

RNP APCH minimas at once, it would make

sense to identify which steps are generic for

all RNP APCH minimas, and which steps

must be done separately for each approach

We agree with this comment, but these

clarifications should be provided into PANS-

OPS not in the guidance material. A

proposal for IFPP.



22/34




minima.

99. Jeppesen

(S.

Onitiu)

$ 5.2.10.3 Propose to reformulate 3rd bullet by: “‘Note

that all three level of services of RNP APCH

can be published on a single chart only in

case the procedure design solution for

LNAV mode does not utilize step-down fix

within the final approach segment. In this

case, it is recommended that RNP APCH

(LNAV mode) and RNP APCH (LNAV/VNAV

and/or LPV modes) should be published on

separate charts respectively. The

application of ICAO duplicate procedure

identification concept i.e. usage of a single

letter suffix may also be considered.”

Accepted.

100. Jeppesen

(S.

Onitiu)

$ 5.2.10.3 I would recommend replacing the term

‘type of’ RNP APCH with ‘level of service’ or

‘mode of operation’ of RNP APCH... (to be

changed: “all three types of RNP APCH

procedures”)

Maybe. It depends where you look at it from.

The word “Type” has been removed.

101. DSNA/DTI

(C.

Bousquet)

$ 5.2.10.3 Amend 3rd bullet with “…type of RNP APCH

(with minima LNAV, LNAV/VNAV and/or

LPV)”

addressed together with comment 98 above.

102. Jeppesen

(S.

Onitiu)

$ 5.3.2.1 Propose to add the following at the end of

the paragraph: “Special consideration

should be given when designing an LNAV

RNP APCH procedure using step-down fix

method. The usage of step-down fix is a

valid design criteria permitting additional

Accepted



23/34




descent within a segment by identifying a

point at which a controlling obstacle has

been safely over-flown. However, due to

the fact that RNP APCH procedures are

relying on navigation databases and Flight

Management Systems (FMS) it has been

recognized that there are some avionics

limitation in handling coded step-down fixes

(SDF) within final segment. It is also clear

that some State regulators would not

accept SDFs in the final segment coded into

the navigation database under any

circumstances. In that case, the States

regulator which does not accept SDF

coding, should advise thru official letter

sent to navigation data-houses for clearly

indicating under which conditions the

published SDFs (identified as named or not

named fixes) are to be captured or not into

on-board databases.”

103. DSNA/DTI

(C.

Bousquet)

$ 5.3.2.2 This is to be stressed that this document

(doc 8168 vol II) does not provide today all

answers to procedure designers.

Accepted. Text has been miodified and a

reference to 9906 has been added.

104. DSNA/DTI

(C.

Bousquet)

$ 5.3.2.5 Remove paragraph Accepted

105. Jeppesen

(S.

$ 5.3.6.2 Replace “to verify” by “verifying” Accepted



24/34




Onitiu)

106. DSNA/DTI

(C.

Bousquet)

$ 5.3.2.7 and

$ 5.3.2.8

Amend paragraph as follows:

5.3.2.6. The criteria for RNP APCH

with vertical guidance based on Baro VNAV

(APV BaroVNAV) design are described in

ICAO PANS OPS Volume II, Part III, Section

3, Chapter 4.

5.3.2.7. The criteria for RNP APCH

with vertical guidance based on SBAS (APV

SBAS) criteria are provided in ICAO PANS

OPS Volume II, Part III, Section 3, Chapter

5.

Accepted

107. DSNA/DTI

(C.

Bousquet)

$ 5.3.4 Add the following text before the two

existing sub-chapter: “Local safety case

shall start as soon as possible because the

analysis can have effect on the design or on

the charting of the procedure”

Accepted

108. DSNA/DTI

(C.

Bousquet)

$ 5.3.6.1 Amend $ by “The objective of procedure

validation is to verify all obstacles”

Accepted

109. DSNA/DTI

(C.

Bousquet)

$ 5.3.6.1 What about detection of interference? This would not be under procedure validation

it would be under local site survey.

110. DSNA/DTI

(C.

Bousquet)

$ 5.3.6.3 Add the following paragraph after the first 2

paragraphs: “5.3.6.3. Before

implementation of the procedure based on

GNSS information, a flight inspection shall

We think that doc 8071 is out of date and

doc 9906 replaces the procedures validation

elements. 8071 should focus on signal-in-

space validation and today no flight



25/34




be conducted in compliance with Doc 8171

Manual on Testing of Radionavigation Aids

Vol II

inspection is required to validate the SIS. It

might be wise to check for signal reception

issues along the procedure but it is not

mandatory.

In doc 9906 Vol 1 Section 7.8. “Ground validation must always be undertaken. When the State can verify, by ground validation, the accuracy and completeness of all obstacle and navigation data considered in the procedure design, and any other factors normally considered in the flight validation, then the flight validation requirement may be dispensed with.”

111. Eurocontr

ol (G.

Berz)

$ 5.3.6.3 I thought the stuff about procedure

validation was going to be in Vol 5 or 6 of

the Quality Manual, not Vol 1. But I am not

sure what the current status is.

See above

112. DSNA/DTI

(C.

Bousquet)

$ 5.3.7 Maybe this activity should be moved before

“procedure design” (activity 10), or should

be renamed?

Have renamed the section.

113. Jeppesen

(S.

Onitiu)

$ 5.3.7.2 the RNP APCH is usually designed (and not

“are”)

Accepted

114. DSNA/DTI

(C.

Bousquet)

$ 5.3.7.2 Replace paragraph by “5.3.7.2. RNP

APCH procedures providing a vertical

guidance may be published either as

backup for precision approaches or as sole

approaches when there is no ILS/MLS..”

Not accepted The idea from the second

sentence is not captured in the proposal.

115. EBAA (P.

Vincente

$ 5.3.7.3 Replace "All procedures should include a

LNAV minima..." by "All procedures shall

Accepted, However, Sometimes publication

of LNAV minima on the same chart is not



26/34




Azua) include a LNAV minima..." In accordance

with ICAO resolution A37-11 pt 2. / a) / 2)

& 3).

possible or is not adequate so we cannot

change the “should” in “shall”.

116. DSNA/DTI

(C.

Bousquet)

$ 5.3.7.3 Replace 1st sentence of the $ by “5.3.7.3.

When the only approach available is

an RNP APCH procedure is published, it is

possible that not all the three minima lines

are available on the chart.”

Accepted

117. DSNA/DTI

(C.

Bousquet)

$ 5.3.7.4 To explain what is “mixed mode

operations”; propose between brackets

“(conventional navigation versus area

navigation)”

Agreed. An explanation of mixed-mode has

been added to the para above where mixed

mode is first introduced.

118. DSNA/DTI

(C.

Bousquet)

$ 5.3.7.4 Replace last sentence by “Conventional

navigation aids may be needed to support

operators’ contingency procedure in case of

GNSS outage.”

Accepted

119. DSNA/DTI

(C.

Bousquet)

$ 5.3.8.1.2 Replace last sentence by: “Using a suffix is

a common rule not specific to RNP APCH

procedures.”

Accepted

120. Jeppesen

(S.

Onitiu)

$ 5.3.8.1.2 Suggest to delete this sentence as not

really necessary i.e. according to

Introduction the RNP AR APCH is out of

scope of this guidance material. “Also,

those suffixes are applicable to both RNP

APCH and RNP AR APCH types of

operations.”

See response to comment 119 above from

DSNA/DTI. Reference to RNP AR has been

deleted.

121. Jeppesen $ 5.3.8.1.3 Propose to add “All procedures must be Accepted



27/34




(S.

Onitiu)

based upon WGS-84 coordinates.”

122. Jeppesen

(S.

Onitiu)

$ 5.3.8.1.4 Propose to add the following paragraph:

“5.3.8.1.4. The State AIP should clearly

indicate that the navigation application is

RNP APCH. The navigation data published in

the State AIP for the procedures and

supporting navigation aids must meet the

charting requirements of Annex 4

‘Aeronautical Charts’, Chapter 11,

paragraph 11.10.9 and Annex 15 ‘AIS’ (as

appropriate), The RNP APCH procedures

shall be published in tabular form or a

formal textual description on the verso of

the chart or a separate, properly referenced

sheet. “

Agreed. But last sentence has been clarified.

What needs to be published on the back of

the chart? – a coding table giving the

coordinates of all the waypoints (and Fixes)

used in the procedure.

123. DSNA/DTI

(C.

Bousquet)

$ 5.3.8.1.4 About “an agreed format”. Is it acceptable

to speak about some “agreed format” and

not being able to tell where or how this

format is ? At least one should mention if

this agreement is to be settled between

national AIS and data houses. As long as no

ICAO document is provided to standardize

the format.

There is no agreed format. Text has been

clarified.

124. AENA (R.

Pecos)

$ 5.3.8.1.5 Is it recommended to publish the SBAS FAS

DB in the AIP?

Accepted. See comment 126 below.

125. DSNA/DTI

(C.

$ 5.3.8.1.5 Is “Electronic form” the binary format? Not necessarily. It could be hexadecimal,

ASCII



28/34




Bousquet)

126. Jeppesen

(S.

Onitiu)

$ 5.3.8.1.6 Propose to replace paragraph with “In the

case of LPV, data transfer includes a FAS

DB, which contains an 8-character

hexadecimal representation of the

calculated remainder bits called CRC

remainder. The CRC reminder is used to

determine the integrity of the FAS DB data

during transmission and storage and it is

computed electronically with use of FAS

data block software tool. The FAS Data

Block content is addressed in detail in Doc.

8168, Vol. II, Part III, Section 2, Chapter 6.

However, there is no statement in PANS-

OPS or other ICAO document where the

FAS DB information should be promulgated.

Presently, there is a proposition to ICAP IFP

Panel for the specification of the minimum

information to be published in the AIP

which is recommending that FAS DB -

represented as a textual description -

should be published on the verso of the

chart in order to ensure that the procedure

is correctly coded in the navigation

databases.”

Accepted

127. Jeppesen

(S.

Onitiu)

$ 5.3.8.1.7 Propose to add: “Generally, FAS DB tools

also generate a Data Block representation

as hexadecimal string, the recommendation

is that the textual description only together

Accepted



29/34




with the CRC remainder value should be

made available on the verso of the chart.

“

128. Jeppesen

(S.

Onitiu)

$ 5.3.8.1.9 Propose to add: “The SBAS channel number

is a five digit number that must be

regionally unique and shall be in the range

of 40,000 to 99,999. Channel number

assignments are required for LPV and LP

procedures and shall be promulgated on

the SBAS LPV and LP approach chart

respectively. To be noted that SBAS final

approach segment (FAS) data blocks are

different for LPV and LP, even though these

procedures have the same lateral approach

geometry to the same runway end.

Therefore, they are to be charted

separately with different channel numbers

and different reference path identifiers

(RPI).

Accepted, However - the point we need to

capture here is that there will never be an LP

and an LPV procedure to the same runway.

An LP procedure is only published if the LPV

is not possible.

129. Jeppesen

(S.

Onitiu)

$ 5.3.8.1.10 Propose new paragraph:

“The information regarding the

establishment of new RNP APCH

procedure(s) shall be provided in

accordance with AIRAC system. It is

recommended that new RNP APCH

procedures should be considered by States

AIS as ‘major changes’ in respect of

circumstances listed in Appendix 4, Part 3

of ICAO Annex 15 (guidance on what

Accepted



30/34




constitutes a ‘major change’ is included in

Doc. 8126 ‘AIS Manual’). Therefore, it is

recommended that new RNP APCH

information should be distributed by the

AIS unit at least 56 days in advance of the

planned effective date.”

130. Jeppesen

(S.

Onitiu)

$ 5.3.8.2.1 Propose to add: “Both type of avionics i.e.

basic GNSS and augmented GNSS (SBAS)

support all phases of flight from departure

through precision approach. GNSS-related

elements providing the navigation service

for en-route purposes shall be published in

the State AIP ENR 4 section. When the

same aid i.e. GNSS and/or SBAS is used for

both en-route and aerodrome purposes, a

description must also be given in AIP AD 2

and/or (if appropriate) AD 3 sections.”

+ Recommend insertion of new paragraph

Activity 16 ‘Navigation database’ as in PBN

Manual. In case accepted, please re-

sequence the next paragraph & Activity

numbers.

Accepted

131. Jeppesen

(S.

Onitiu)

Propose a new activity 16 (see text below

the table)

Accepted

132. DSNA/DTI

(C.

Bousquet)

$ 5.3.9.1.1 About the bullet list, refer to or reproduce

the syllabus provided in PBN Manual. It is

more comprehensive.

Accepted



31/34




133. DSNA/DTI

(C.

Bousquet)

$ 5.3.9.1.1 Add the following sentence after the bullet

points: “Some item of the training are

general, local consideration may be added

as result from the safety assessment.”

Accepted

134. Jeppesen

(S.

Onitiu)

Annex 1 What is the meaning of colours? Suggest a

Legend for colour codes

Accepted

135. Eurocontr

ol (G.

Berz)

Annex 1 Diagram in Annex Step 13b you talk about

flight inspection but it seems in the doc you

only talk about flight validation (which is

probably right) - the inspection part (SiS

for RFI) could be done on the ground.

There are different views here - general RFI

monitoring practice is to measure for a

week and then you can be reasonably

confident that even intermittent

transmissions have been detected - if I had

to pick between one flight in the air and

one week on the ground I would prefer the

ground check. Always good to add the flight

check but the validation flight would notice

either way.

Step 13b is from the ICAO PBN Manual

process. The Activities in this guidance are

being mapped across to this process.

Linked to other comments (109/110).

136. UK CAA

(G.

Burtensha

w)

5.3.4 to provide a set of generic hazards to be

addressed as part of preparation of the

local safety case

We have been working on this for a long

time and have not been able to find an

agreement yet. It is therefore considered

premature to include such a list here.



32/34

Proposed Activity 16 by Jeppesen (comment 131):

5.3.9 Activity 16: Navigation Database

5.3.9.1 The navigation database should be obtained from a supplier that complies with RTCA 200A/EUROCAE ED-76A

‘Standards for Processing Aeronautical Data. A Letter of Acceptance (LoA) type 1 granted by the appropriate regulatory authority shall

demonstrate data house compliancy with the above mentioned standard requirement.

Virtually all aeronautical databases are loaded according to the specifications in the Aeronautical Radio, Incorporated (ARINC) 424

standard ‘Navigation System Data Base’. While the ARINC 424 specification covers a large percentage of the aeronautical requirements, it

is impossible to write a specification that wraps up every combination of factors used to design and fly instrument procedures.

Many of the differences between charts and databases are because there can be no standard implemented to have the information in

both places depicted in exactly the same way. It is recognized that the basic design for most aeronautical information contained in

instrument procedures i.e. conventional ones has been created for the analogue world. The art of entering data into an aeronautical

database i.e. translation of the textual & graphical description of a procedure with the help of Path and Terminator (P/T) codes is one that

balances the intent of the original procedure designer and the requirements of FMC systems. With the implementation of RNAV and RNP

type of applications, a high degree of standardization and harmonization chart – database information has been reached due to following

reasons:

• RNAV approach procedure standard shape ‘Y’ or ‘T’;

• Mostly straight segments (TF leg);

• Small sub-set of P/Ts compatible for RNAV procedure coding;

• ICAO requirement for formal or tabular procedure description on chart verso which significantly diminished the miss-interpretation

of procedures by coders;

However, there are many different types of avionics equipment utilizing the same baseline database. The same database information may

be presented differently on certain types of airborne equipment even being manufactured by the same FMS vendor. In addition, some

equipment may be limited to specific types of database information, omitting other database information.

For nearly two decades data-house experts have been working with all avionics vendors to achieve as much standardization of flying

RNAV procedures as possible.



33/34

Consequently, it is strongly recommended that in certain cases, alternative coding (such as path terminators, speed and altitude

restrictions) may be used to enable specific RNAV systems to better follow the intended track – such actions should be approved by the

associated State Regulator and are within the purview of the data coder and the avionics manufacturer.

5.3.9.2 Within an ARINC 424 output file for an SBAS LPV procedure, the FAS DB data is carried in a dedicated type of record

called Path Point (PP) file. The PP Primary record description contains all FAS data fields (twenty-one fields including the CRC remainder

field) as required for the data wrap for CRC calculations. The specific order and coding of the twenty-one fields shall be followed

rigorously when computing the CRC to ensure avionics compatibility. When ‘un-wrapping ‘the FAS Data Block, the data-house and

avionics must compare the resulting CRC remainder i.e. representing integrity field with the value provided by the procedure designer. If

the values do not match, the FAS Data Block cannot be validated and extracted from database.

Additionally, the Path Point record has been further extended following industry requirements with a continuation record. The PP

Continuation record containing fields lsuch as LTP and FPAP orthometric heights, FPAP ellipsoid height, SBAS channel number, etc.

Therefore, States are also required to provide these parameters to the data houses in addition to the FAS DB.

In conclusion, RNP APCH procedures authorized for SBAS navigation demand a complex work-process for generation and extraction of the

complete set of records by the navigation database supplier. There are three record types simultaneously extracted as follows:

1. Airport Approach Primary Record – carrying coding legs (P/Ts) and supporting data elements;

2. Path Point Primary/Continuation Records – carrying twenty-one FAS Data Block fields and some non-FAS DB (needed)

information;

3. Procedure Data Continuation Record – provides the Level of Service (LPV, LNAV/VNAV and LNAV) authorized for SBAS and

respective Name of the Service.

Also, from data quality and integrity level stand point, some elements of FAS DB are classified as critical data requiring the highest

possible resolution for latitude/longitude & elevation (hundredth of sec and 1 foot respectively).

Therefore, attention should be paid throughout the entire chain of involved actors i.e. procedure designer – AIS expert - data ware-house

specialist – avionics representative in order that the high demanding navigation database requirements for RNP APCH should be closely

coordinated as well as it would be a collaborative process.

5.3.9.3 From a database perspective, special consideration should also be given when designing an LNAV RNP APCH

procedure using step-down fix (SDF) method (for SDF procedure design consideration, see paragraph 5.3.2.1).

Generally, if the procedure design solution is employing final and/or intermediate segment SDFs, the respective fix(es) will be captured in

the navigation database according to the coding rules stated in the ARINC 424 industry standard.



34/34

Since many years, industry and database providers have anticipated the application of VNAV function included into FMS/RNAV system in

support of continuous descent final approach operations. An FMS usually ‘builds’ a profile backwards from a point 50ft above the runway

threshold to the initial constraints – normally, an altitude restriction at the FAF. Therefore, a vertical angle is always included as a vertical

path coding element within all straight-in type of procedures including RNAVs. For NPAs and LNAV RNAV, the vertical angle is calculated

by the database supplier from LTP elevation + published TCH/50ft to the altitude of the FAF.

If final segment SDF(s) are published, a single value for vertical angle will be calculated in order to clear each SDF associated x-cross

altitude and it will be repeated on all step-down fixes.

Last but not least: It has to be emphasized that MDA and DA values are not part of the approach coding solution and the altitude at

missed approach fix (MAP) fix is not any of procedure MDA or DA. The associated altitude at MAP is a computed by database coder

(mandatory) value based on the final profile and implicitly, based on the calculated vertical angle. If, for example, one RNAV APCH chart

is including LNAV and LNAV/VNAV minima, this RNAV APCH procedure can be coded only once irrespective of different minima values.

With other words, if the approach has LNAV/VNAV minima then it only requires FAF and MAP with VPA, but will always show SDFs if they

are coded. Therefore, it is recommended that States accepting SDFs coding on final, they should apply the ICAO duplicate procedure

identification i.e. adding suffix letter to approach identifiers for LNAV only with coded SDFs chart and allocating a different letter for

LNAV/VNAV without any SDFs chart. This will ensure a consistent, correct and harmonized application of design and charting principles on

one side with coding rule and specifications on the other side.

comments to guidance material 15 sept 2011 meetings seminars and worksho… · comments to icao...

Documents