Read NPA 2011-03, p. 60 "CS.1324" (all new), and p. 75 "Appendix P" (all new).
Many thanks, HN. I've skip-read it and will read it again, even if it is not quite my field. But at first sight, I've not seen an unequivocal requirement for re-defining the pitot tube certification requirements.
It seems almost ridiculous the fact the aviation industry is still today using sub heated Pitot's.
A very simple device, so important, an essential input to the A/C complex IT Systems, seems to be not advancing to a "changing environment".
And clearly, the trigger of a serious accident where the System and the crew were not capable to deal with the consequences of it's VERY BRIEF failure in presenting consistent output.
Another almost ridiculous fact was a DESIGN FLAW that allowed Garbage In generate Garbage Out affecting an essential System output, the aural Stall alarm. An essential input to a crew facing an unprecedented situation.
This first issue IMO should be addressed earlier by Airbus SAS and the patent filed (of a l@ser based sensor) shows a tentative to face the problem.
And the 30+ UAS incidents shows the (previous) vulnerability.
These companies no longer invest in R&D? And the bureaucrats do not rely on the TECHNICAL experts or not pay attention to the REGISTERED incidents?
What I was saying is that, so far, I've not yet seen any reports of substantial research into the 'unusual' pitot icing leading to UAS events, or any 'proposals for rule making' based on such research.
Remember the patent filed by Airbus SAS using OPTICAL approach.
As an engineer, I design to specs.
The problem is above Engineering level, you know. The HIGH ROCKS failed and probably are still failing to solve the problem.
And the short duration of the "inconsistent output" of current probes suggest we are near the required electric power.
IMHO this is a typical INERTIA of bureaucrats. It seems lack of diligent Technical experts in order to KILL the problem.
Analog devices are no longer "attractive"? The Engineers are losing the ESSENTIAL feeling due the "Digital revolution"?
Like pilots under the FANTASTIC digital paraphernalia losing the basic ability to fly safely when they need it most?
A design that put triple redundancy to deal with (sensor) failures that OBVIOUSLY will occur SIMULTANEOUSLY is RIDICULOUS, IMHO.
And after all, not train adequately the crew to operate these A/C is
Organfreak, The human machine interface (during crisis) has not a place in your list? The fact that the entire crew failed to even understand timely what was occurring is not important?
Yes, of course, and you're right that I was careless when I assumed that was taken into account in point seven (quoted below), as well as my remarks about poor training. Point seven:
7. Deficiencies in the Airbus instrumentation and control design in terms of stall warning behavior, angle-of-attack display, auto-trim, and the list is long.....
Guess I was thinking that the above deficiencies, IMO of course, were a part and parcel of their lack of situational awareness. Anyway, nothing meant to be definitive about what I wrote, just the musings of a bystander trying to make sense of it all. When the final report comes in summer, it'll be none too soon, eh?
An aircraft upset can be defined as an airplane unintentionally exceeding the parameters normally experienced in line operations. This may concern unusual attitudes (large pitch or bank attitudes), and also inappropriate airspeeds which may result in stall of the airplane. Because the normal response of the airplane to pilot input may be altered during an upset, it is important to train pilots to adopt alternate control strategies to sustain or regain controlled flight. To do this effectively in a flight simulator, the simulator should realistically reflect the aircraft behaviour in upset conditions. However, current flight simulator technology is incapable of reproducing upset conditions, and aviation professionals are conservative in advocating the use of simulators for upset recovery training because the risk of negative transfer-of-training. The SUPRA project is aiming at developing simulator technologies that allow for better upset recovery training. The project will last for three years and will result in guidelines on simulator requirements (aerodynamic modelling and motion cueing) to be presented at an international workshop which will be organized in August 2012.
Leonardo da Vinci: Simplicity is the ultimate sophistication.
Antagonic factors poses important challenges to the design of the “interface" in complex Systems.
CRM, developed after DC8-61 flight 173 in Portland is IMO closely related to the interface design challenge:
1) What is happening? (relatively simple to present) 2) Which are the priorities (a complex task for the interface and the crew)
The crew always should be helped to deal with the issues.
Based in what we learned (not so much) on AF447 we may say the crew barely understood what was happening. And only realized (partially) in the final moments of their plunge.
This is a very important fact. We may say the System failed, at least in three important points:
1) In order to deal with, and present fast and precise information on the SIMPLE (and BRIEF) failure of an important "input" (AS data) to the STABILITY of the plane System. AS probes with a previous history of problems. (Simultaneous "failures")
2) In order to present CLEARLY and with all necessary methods, the REAL EMERGENCY: Plane plunging near TERMINAL SPEED. With ETA to sea level in just 4 minutes.
3) In order to provide "automated" resources to allow the crew fly the plane.
Actually the crew never learned the trigger factor and the short duration of the sensors failure.
And they never elected the top priority, very probable due current deficiencies in the human machine interface.
The silent move of THS made things worse instead to help the crew with useful output to facilitate the urgent need to "make the plane fly again".
The probable "pilot error" in the end, IMO could be applicable during sections of 350 to 380 climb. To PF (absurdly) not trained for hand flying at cruise level.
During the descent, the many facts we learned, suggests important deficiencies in an essential sub System, the man-machine interface.
Thus compromising the ability and the performance of the entire crew. IMO, the human machine interface must be improved urgently and a complex R&D is required for.
Antoine de Saint Exupéry's "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away".
to present what the a/c did right, and what the pilots (obviuousy, not even
Frustrating. All along, here, I have noticed a tendency for many to present what the a/c did right, and what the pilots bitched up. Odd, since there is ample fuel to go around both ways. I appreciate your take on the matter at hand. I recall that the UAS here, was the 33rd in a recorded sequence, and yet there seems a lack of urgency on the part of the line and the airframe side to give it proper credence.
No awareness of the cause of the a/p drop is apparent in the CVR. Yet wouldn't both pilots be quite aware of the progress of the flightpath and attendant parameters? "What's with the speeds"? "G is constant, noise level is ok, wtf?"
Hamburt says the a/c was in ALII immediately, yet the pilot makes no mention of the degradation in Law, merely, "I have the controls." Something so important, along with a notice of fluctuating IAS deserves not a mention? No discussion of the handling differences twixt NL and ALII? "Watch your lateral, remember the bank is touchy in this regime". No Protection, etc. Only, "Lost the speeds, Alternate Law". And that many seconds after the PF has started hand flying?
What about the several seconds prior to a/p drop? Would the a/c, in autoflight, not react to ADR with "corrections" noticeable on the flight deck? No flight path changes? Nothing untoward due faulty sensors, just a cavalry charge instant? And wouldn't these excursions produce a heightened sense of awareness in our pilots?
It is so hard to imagine such a quiet, passive, and reactive flight deck. It only starts to appear real when the a/c is already in dire trouble, banking to and fro, climbing way too quickly, etc. Something is missing here, if only a completely lacking CRM. Reading for on toward three years about this has not lessened my sense of a very incomplete story presented by the authority.
Ultimately, not even BEA will present "This is what happened".
(And my favorite. "Less is more." Mies van der rohe)
Hate to say it but I think it is time to put this crash to rest
You are right .. put all this into hibernation and set the alarm clock to the release date of the final report of the BEA. We have time to take a well deserved rest as the report will be published in a few months Although for those who are impatient and curious .. they can certainly have the final report by reading everything that was posted in this forum. The key is to choose the right things .. but certainly the analysis and recommendations to be made by the BEA are already written in this forum Some may say "I told you so"
First, when the autopilot disengaged there should have been an explicit message that it did so because of air speed indication anomalies.
The speed/mach flag was shown on the PFD. How many clues are required?
This tragedy wasn't caused by the UAS but by the reaction upon.
Second, clearly the stall warning should continue regardless of airspeed except in specific circumstances ie if you are airborn at significant altitude there really is no reason for the stall warning to be discontinued...
Said it before but will say it again, there was no input from ADIRU to the SW logic inside FWC. The ADIRU output design needs to be considered not the SW logic, as AIB did with offering the BUSS option. (AoA input available to SW logic supplied through IR output)
AF (Pilot organisation) didn't opt for the BUSS enhancement, Why?
The BEA is absolutely on the right track with the Human Factors workgroup, 'all' visual and audible clues have been missed without any sign of CRM or TEM.
I don't know for sure whether or not the following has been linked here (I did a search and the search returned a null) but I found the following Aviation Week article 'High-Altitude Upset Recovery" most informative. There are even some comments by Captain C.B "Sully" Sullenberger.
Reading so many opinions over the past year about this unfortunate crash, it seems to me that the majority are picking up the story in the middle of the book. Most comments begin after the airspeed, auto pilot and auto thrust disconnect. For me, that is not where the story begins. It begins when the crew enter the flight dispatch/operations office in Rio. These 3 pilots about to take a flight at night over the ocean must have been given a weather briefing, weather maps and had to know what type of weather to expect in the ITCZ. Next, they must have checked the fuel uplift for the flight including fuel to circumnavigate the bad weather. In the CVR there doesn't seem to be any mention of the weather by anyone, neither any plan to skirt the CBs. When the captain left the flight deck, did he say anything about the ITCZ ? As the aircraft reached TOC, was the radar checked and set for inflight operation in cruise? You see, this is where the story begins. This is the beginning of the book. I will forever hold that this accident would never have happened if they had gone around the storm. That is where they screwed up royally. All the other stuff that has been discussed for the past year has nothing to do with what really caused this crash. They flew a perfectly good airplane into CBs that iced up the pitot tubes causing the loss of control. As for the heated pitot tubes, have you ever made the mistake of touching one on the ramp check? It will give you a really bad burn if the switch is in the on position. Don't forget that after lift-off they go to high power and get much hotter for flight. I will say again for the 10th time, you don't fly an airplane into CBs when close to the coffin corner.
I only hope that everyone has learnt the lessons from this accident and will not repeat them. Thanks..
I take your point, but I think you go back a bit too far. Captain did caution the two remaining pilots to expect turbulence greater than they had experienced, and the crew discussed deviating "a bit left". Bonin even briefed the cabin (Maryann?) in regard the expected turb. Your conclusion that ice caused the IAS problem is not ironclad, the pitots failed simultaneously, and that speaks to other than blockage/ICE.
I rue the lack of CVR discussion, but unlike you, I do not conclude that the flightdeck was silent. I believe the bare minimum was released, and whether or not it was by the wish to slow public suspicion of a/c problems or for "discretion", we have a most incomplete and premature picture.
The speeds were odd, but not so unusual as to eliminate Windshear. TCAS and WINDSHEAR were present on ACARS, and remain unexplained; the actual speeds are after the fact, and a lack of comment initially by the Pilot flying might show that they indeed were not "crazy speeds" , except to say that the speeds may have given him the notion of overspeed, ("we have some crazy speed") not extremely low, as would be expected with pitot blockages. He has become pre-occupied with overspeed, is this in response to IAS? Surely not, unless he has sussed UAS, which most doubters refuse to alow him, due his "lack of training".
Smokin' Eddie, are you sure? That is not what I have found, and remain convinced the first evidence WE have is of PM annunciating "Lost the speeds, ALTERNATE LAW". This was at I think :16, eleven seconds post a/p loss. No?
organfreak. "Dollars to doughnut......" Hmm. Right, that is not speculation, that is an accusation. We should be better than gratuitously making wagers on a dead man's training. I still get chills when I put myself there.
See, here's the thing: UAS was not in the line quiver, it was poorly understood, and even after the wreck, AB was issuing..."DON"T re-select A/P, the a/c may CLIMB unexpectedly......." No one had conclusively decided whether or not to trust the STALLSTALL !! respect