We do this too, it is procedure, but I guess not coming from Airbus FCOM, it is just a company SOP for both crew members. We also have to compare the QNH given by approach control when descending to an altitude with an alternative source, typically ATIS. On non-precision approaches we again have to confirm QNH with tower.

I still think the machine should do this automatically by comparing QNH on the perf approach page with the QNH set on the FCU once on QNH.

That’s the issue with PBN approaches and incorrect QNH settings, it all looks good. It’s frightening that people flying these approaches don’t understand this risk.

I stand geographically corrected.

This is a typical case study of QNH blunder error where an SOP such as pre-setting the METAR/ATIS QNH prior to TOD could have prevented the incident. Many operators use this procedure as a safety net and it does work well indeed to trap errors both from the crew side and ATC. I believe that after this event more and more operators will include it in their procedures.

Mode C is not, however a strange quirk of Airbus avionics suite sends the last used before setting the STD through the downlink S mode.

The extended squitter seems to have a data filed for selected Baro ref, however the last value is retained for transmission instead of STD when the crew changes to that.

Which brings us to another unexpected conclusion. Mode S must have been transmitting Q1011 after this almost doomed crew accepted the wrong instruction.

​​​​​​Hmm, some opportunities there!
​​​​

Indeed. All in French. All you need is a French level 4.

See UK CAA Safety Notice SN2019-001 (Mar 19)
 

https://cimg1.ibsrv.net/gimg/pprune....8624af6f4a.png
https://cimg6.ibsrv.net/gimg/pprune....79accceb0a.png

Did this happen at an airshow?

AFAIK, baro pressure setting isn't part of the ADS-B extended squitter, but is only sent as part of Mode S EHS, if and when interrogated by SSR.

I don't know whether the CDG controllers typically see it on their screens (either fulltime or as an option) or not.

Point being made, would it not be a useful feature of the ATC kit to automatically track and alert for any selected Baro REF discrepancies of the arriving aircraft?

Surely that was the idea behind having it in the dataset.

Every cheese has holes
 

This procedure was used by my outfit when we operated Airbus and worked well. However one pitfall ( and this happened on a flight ) is the setting of QNH and forgetting to switch back to STD.
This crew ( PF ) set the QNH but forgot to switch back to STD and was cleared descent to a Flight Level. A Level bust occurred using QNH instead of STD.

(Apparently I need to add words to a quote to be able to hit post)

The Preliminary Report contains the following Safety Recommendation

which strongly implies that CDG has no current safety-net involving automated detection of incorrect QNH setting.

The BEA makes no reference to the solution adopted by NATS, though it's anybody's guess whether it is simply avoiding being prescriptive as to the solution that it is recommending CDG should adopt, or whether they are unaware of how other ANSPs tackle the issue.

That was exactly my point. Trying to fix one point of failure by introducing another point of failure is not airmanship, it is called cultural SOP. With QNH and RNAV approaches, awareness of what the QNH should be from the TAF and comparing it with the ATIS is the best defense. Of course sitting there and just accepting information without cross checking it is certainly not airmanship. Introducing procedures into a flightdeck as a workaround is also not airmanship.

We do that at my outfit. We’ll set the QNH while doing the perf app page, about an hour out. What you described shouldn’t happen in an Airbus, as I believe it’ll eventually start flashing at you.

Some people set the destination QNH when climbing through TA on the sid.

Both methods are only technique though.

DaveReidUK : It is the second option. afaik.

When we sit in our aircraft, we have in front of us 120 year old pressure displayed instruments.... we also have a display that gives our geometric altitude, and a synthetic view of the world in front, including terrain alerting and obstacles. Operating into an airfield that is 6,000' up and -30C makes it desirable to actually know what your physical separation from bad days are. In this event, the crew would have received an alert that they were landing in a paddock, outside of the passengers preferred arrival location, and they would see a FPV that was aiming 1nm short of the runway threshold, the display would show the threshold moving away from the FPV at an ever increasing rate until it gets rowdy.

Point is, our safety is predicated on a weak system of communications, mon dieu, and placing the fix at the same side that is already showing problems with task saturation and process maintenance seems to be less than optimal. The people with the vested interest in arrival at the correct place in space if not time are the drivers.

At cruise, the difference is a curiosity, geometric altitude is normally around 1500' higher than the FL, but it remains quite stable for periods dependent on the airmass, on an approach, the PA and geometric altitude converge, and at around 3000' PA there is normally not more than 20' error at ISA, but as per cold temp correction factors, there is considerable difference to the uncorrected PA altitude... If the corrections are correctly applied, or the G/S is a valid (geometric) track, then the FPA sits on the end of the runway. There is no cognitive load to looking at a happy map of the world in front, and this display is specifically not corrected to PA for the very reason that we want to see real world, not someones communicated information on the local airmass characteristics.

It happens to display on an iPad, it can display on an iPhone... Could it be added as a display to any aircraft? of course, but there is no current TSO standard that would be relevant to such a display, as we are firmly committed to the 18th century in technology.


https://cimg2.ibsrv.net/gimg/pprune....f92922dcfe.png

I suspect 99% of the replies on here have missed the overriding law in aviation.

Its referred to as 'tombstone safety'. Nothing changes until there are deaths and it costs more in insurance payouts than to fix the problem.

How much would it cost, apart from the dint in nationalistic pride, for it to be compulsory for English to be used at one of the busiest airports in Europe. Let's remember standard RT phraseology does not mean having to be fluent. Indeed if you said 'QNH' to a typical Englishman you might as well be talking Mandarin. How hard can it be?

Fortunately, for this situation, the third one got the correct QNH in French instead of the wrong one in English. Otherwise, that aircraft might have created a real smoking hole.

I did not see an explanation/assumption in the report, why the ATC got it wrong in English.

fdr I agree with your writing, though my issue is, that this "tool" still is the (admittedly much better) primary driver for the flight path.

What we are missing is the "independent and automated verification" of what flight path the flight crew creates/follows with the tools they have available (or should have available in the ideal situation). The verifier is the one that saves the lives, when the flight crew screws up, for whatever reason.

Harder than you might think, in my view.

Various suggestions have been made about how the initial incorrect value could or should have been caught, irrespective of how that incorrect value came to be communicated by ATC. They are way outside my area of expertise, but language use isn't, and my conviction, informed by professional and personal experience, is that requiring people who share a native language to communicate in a non-native language is a recipe for poor communication and potentially just as great a problem as any due to the use of multiple languages.

There is considerable focus on the human aspects of this incident, but consider the technologies supposed to catch human error; why didn't they work.

I think a few flights into or out of CDG when it is busy and thunderstorms are about would concentrate your mind on if the use of French and English is a serious problem.

Eutychus. I think all the aviators on here see where you’re coming from. However….. consider my own airline which is by no means unique. Until recently with 20 odd nationalities on the flight deck operating in pretty much every country in Europe plus a few others every day. Much as I’d love to have level 4 or better in multiple languages, it’s not going to happen. Picture our Italian/Spanish flight deck into Cdg speaking French, or (just as bad) Scandi/German going to Spanish speaking Madrid or indeed any European flight deck going to native speaking China.

I guess in specific cases (probably regional airports) operating national airline only, native language could work but otherwise I can’t see how anything other than a common language could be safe. Fortunately for linguistically lazy Brits that language happens to be English.

Language Barriers
 

I recall many many years ago, as a Mil Controller on the rather 'interesting' Clacton Sector, handling a 4-ship of Italian F-104s heading for home. Only the lead seemed to speak English, and he thus translated everything I said into Italian for the benefit of the rest of the formation. Mercifully neither I, nor the frequency, were particularly busy.

As much as I think there's bigger galaxy-class cruisers to fry on this one compared to the dual language at CDG (which bites different ways)

​​​​​​.
.
​​​​​​.

Did the French not file a variation? Instead of spelling the Kweu-enh-aich they verbalise Quebec-November-Hotel?

Thanks for your response. I think you slightly misunderstand where I'm coming from.
I have absolutely no problem with there being a standard aviation language and there are plenty of arguments in favour of it being English.
I would also expect ATC at any international airport (as well as pilots!) to have a sufficient command of it.
The point I'm trying to make is that no matter how good the respective parties' English may be, it's never going to be as fluid as them using a shared native language if they do share one.
And it's with that in mind that I'm disputing the notion that making CDG English-speaking only would make it a safer airport considering the number of parties talking to each other whose mutually shared native language is French.

Anecdote: Calling my internet provider helpline, I once happened on a tech support guy here in France whose native language was audibly English. Both their French and mine were excellent (my basis for this claim on my part is that I make a living out of being fluent in both), but I can't tell you how frustrating it was trying to troubleshoot the problem in what was not our non-native language because his company policy required it.

Many many posts referencing language difficulties but.....

QNH is a very simple datum

What prevents HAL being responsible for this?

Give me an altitude, a speed, a heading a QNH and a runway...Thats wall we need.

SLF noted :-)
There are no grounds for clearing an aircraft for take off with FOD/suspected FOD on a runway. Procedure should be to check the report even if it incurs delays to arrival or departures.

That was kind of my point. The root problem in the FOD incident referred to is not which language was being used but why suspected FOD didn't lead to a runway check. In my SLF view over-fixation on the language issue here may lead to other more serious problems being overlooked.

Isn't that what precisely the aircraft in the incident in your original post got, in English? (Or at least thought it got?). How would *mandating* the use of English have prevented this incident?

? I would have thought that conversing in 'not your non-native language' would have improved things, but then again if you used a lot of double-negatives I can see how it would get frustrating :} !

But look how easy it is to clear up the misunderstanding between native speakers :}

Always amazed to see how the language issue is alawys coming back here to the French , and CDG as if it was the only country and only airport in the world using dual language.
This acident is not a language issue. Actually you could turn this argument around, if English had been mandated for all aircrfaft in CDG that day , the QNH passed to the AF would most likely been 1011 as well., so in fact decreasing significantly the overall saftey by increasing the risk to other aircraft. .
I always was and still am all for a single global language in the R/T , but I also know that there is absolutely zero chance of having this pass any ICAO meeting., even more today than in 1944 with nationalsim on the rise everywhere. Language is cultural and part of a State Sovereingty and a change is never going to happen , Same as having the US adopting the metric system ( which is the international ICAO standard btw) . So we all have learned to live with these and mitigate the shortcomings.

The TWR controller "did not notice" the circled '16' annotation on the strip. Just over two minutes after the transfer to listen out on TWR, with the 737 having meanwhile landed and passed in front of the SD330 waiting on taxiway 16 before clearing the runway, TWR cleared the MD83 (in French) for take-off. Five seconds after this, the SD330 was instructed by TWR (in English) to "line up runway 27 and wait, number 2". On receipt of this clearance, its crew then began to taxi onto the runway "whilst looking for the Number 1"

It doesn't seem the comms in French and English was a major factor. The SD330 knew there was an A/C on the runway as they were looking for it. It seems the root cause was clearing the A/C onto the runway into the path of another A/C already rolling as the TWR controller thought it was behind the MD. No2 implies there is an A/C to depart before you. Of course, hearing "Clear for Take-off" in English just before you are cleared to Line up and wait No2, may have provoked a different reaction but it equally may have made no difference. To say the language difference was the cause, I don't think is backed up by the facts.

So he would have lined up if he had just heard an aircraft that had not yet passed him was cleared to take off?

I’m sure that if everyone on the frequency is given 1001 and you’re given 1011, you’ll be suspicious and query it. Furthermore, if the ATC is constantly giving out 1001, the odds on them giving you 1011, will be greatly reduced.

I get that, but say trying to fly in Paris, Bhutan, or around Mongolia, Kunming, South Korea in winter, and the error is easily greater than the 10mb in this case. Had a crew do an autoland once before they got to minima... Using PA below about FL180 is a technical backwardness. The system isn't going to change anytime soon, but in the interim, the next panel upgrade I'm doing to my jets includes space for an iPad as the EFB, and for general "SA" benefits. It already interfaces with the APFD and C145 nav systems. Geometric altitude is where there be dragons, that's the info I find nice to have on hand.

On a GPS based 3d source, if the aiming point is 3 degrees below the horizon, that is where you are going if you are flying your 3 degree path.

I speak a few languages, and English is by far the simplest one. Seriously, the most complicated thing in English is spelling, which is irrelevant for phraseology. It's a very good choice for an international language.