Pilot Commands TOGA; A320 lands anyway

[Flight Safety]

It sounds like the track/fpa function relies on an INS reference (or GPS reference) for ground track information instead of flying a beacon. Is that why managed non-precision approaches are restricted?

[This message has been edited by Flight Safety (edited 24 June 2001).]

[Diesel8]

I think restrictions on managed non precision approaches has to do with individual company SOP's. The company I fly for allows managed nav approaches, as long as accuracy is high.

[Pontius' Pilot]

Our company received the following from Honeywell. (Not verbatim) Coding of certain non-precision approach (NPA) procedures within the A340 FM navigation database could result in an unanticipated vertical profile construction. Specifically NPA's with the MAP beyond the runway could result in the constructed FM vertical profile passing the FAF BELOW the Jeppesen published FAF altitude.

Known NPA procedures which are affected are HSSS VOR 18, VABB VOR 27, YMML VOR 34, FMEE VOR 30. Because 3 of the four are destinations in our airline, and the remaining one an enroute alternate our company has also made it SOP to do all NPA's in selected mode. Guess they are erring on the safe side.

The A340 FCOM 3 also has background info which elaborates a little more on the subject. FCOM 3: BULLETIN #12/1 dated OCT/00.

Personally I have had no problem with the use of the TRACK/FPA during these procedures even in high varying cross wind conditions. Admittedly it does increase pilot workload.

[Frederic]

In my company there is a list of airports and approaches where APP NAV managed approaches are allowed. It seems strange to me that some companies ban them altogether. I think they're much better than conventional non precisions. Oh yeah, Max Angle: In Track/FPA the aircraft flies the selected track. So if there is a xwind gust, although the aircraft will try to maintain the track, there is always a delay in it doing so. So although your track will return to the selected value, you will fly a parrallel track after a gust. Very much the same thing happens in roll and FPA: the FBW does not try to keep the aircrafts wing LEVEL. Instead it tries to keep the rollrate at 0 (stick-free). So if there is gust pushing one of the wings up, the FBW will counter the rollrate with aileron/spoilers untill it is 0. But by the time it has done that the aircraft will already have banked by a couple of degrees. Same thing in pitch The FBW will try to maintain 1G, but by the time it has done that after e.g. a gust, it will already have reached a different FPA.

PS: Stickyb: very good point you're making, but in this case I do not believe there was a software fault as such. There are, in each Flight Control Computer in AI aircraft, two channels using two different programmes written in two different languages. The COM and the MON channels both calculate the same thing and compare the result of their demand through feedback from the flight controls position. If they dissagree I think the computer gets a fault and disconnects from the system. So if there is a software fault that demands a rediculous control position, it will be declared "mad", and will be disregarded. In this case, however my guess is that the overshoot and reaction time values for angle of attack protection weren't right in the whole system. So I don't think there ever was a software "fault" as such. But then I'm not on the investigation board and I'm not an aeronautical engineer, so I don't really know. Nodody really knows untill AI gives us some more info...

[This message has been edited by Frederic (edited 24 June 2001).]