Sidestick Position
 

I have about equal experience in planes with yokes and sticks. I never seemed to have a problem in switching from the left seat to the right seat where yokes were involved. I can specifically remember flying an F-6A (F-4D) with a stick in the morning and an HU-16 (Grumman amphibian with a yoke and throttles in the middle) in the afternoon. However, the idea of a stick in my left hand seems awkward. Of course, you could get used to it. It's all in the training and experience.

Time To Impact
 

On the other AF 447 thread in R&N, there is an interesting Post # 377 by MFgeo. In this post there is a link to an author (Matthew Squair) where he has calculated the time to impact using information provided by the BEA in their Interim Report #1. With additional information provided by the BEA in Interim Report #2 he revised his figures accordingly.

Based on a terminal airspeed derived from the cabin pressure advisory message, the time to impact (tti) can be calculated as being 57 seconds after the cabin vertical speed advisory was generated (2:14:21).
This would result in a time of impact (toi) of 2:15:23.
But, these tti and toi are based upon the assumption of an average terminal vertical velocity in the last 57 seconds of flight that is the same as the average calculated for the preceding flight phase.
As a still flying aircraft would have transmitted the class 2 ADR 2 fault message before impact these two times can be used to revise the time to impact (tti) and correct the terminal velocity (vterm).
He previously calculated the altitude at which the safety valve opened (6,898.5 ft) and he believed that the valve opened at 2:14:26, 5 seconds before the advisory would have triggered and he calculated the terminal velocity associated with both ends of the transmission window as follows.
In the case of (time to impact) timp = 2:15:00:
tti (2:15:00) = 2:14:26 – 2:15:00 = 0:00:34 seconds.
Giving an average terminal velocity of:
vterm (2:15:00) = 6,898.5 ft / 34 sec = 12,173.9 ft / min.
In the case of timp = 2:15:14:
tti (2:15:14) = 2:14:26 – 2:15:14 = 0:00:48 seconds.
Giving an average terminal velocity of:
vterm (2:15:00) = 6,898.5 ft / 48 sec = 8,623.1 ft / min.
The corrected results. Given the transmission window for the ADR 2 fault message the average terminal velocity of AF 447 is in the range 8,623.1 to 12,173.9 ft / min.
His Conclusions. The increase in average vertical velocity from 6,718 ft/min to at a minimum 8,623.1 f/min indicates a sustained vertical acceleration of the aircraft.
This terminal vertical acceleration and high terminal vertical speed when combined with the positive attitude and low bank of the aircraft is strongly indicative of the aircraft having departed into a deep stall and possibly a subsequent flat spin.

If his theory is correct, it might explain the relative closeness of the found debris to the LNP.

He assumes that the airplane was at FL350 at 2:10:10, which is possible but not an established fact. He then goes on to assume that the rate of descent between 2:10:10 and 2:14:21 was constant, which is highly unlikely. (I recall that an earlier calculation was in error but didn't check whether that has been corrected. The matter was discussed quite some time ago on part 1 of this thread.).

PM is a euphemism. And whats the PF doing anyway?

This raises interesting questions about experience. What does it mean to have 10,000 hrs of experience if 7,500 or more of that time was spent staring at the computer flying the a/c. The reality of the modern flight deck may be closer to Pilot Staring and Pilot Doing Nothing. Talk about ennui. :rolleyes:

Deep stall and flat spin to the end, model
 

Just to remember: The conditions (mech. damages) of the debris recovered floating seems consistent with a flat spin "heading to RH" (CW as viewing from top)

Exception: Galley "good conditions".


Edited: Please don´t consider what is in blue: :confused:


Question 1): Supposing a flat spin til the end. Typically, how many degrees per second? :confused:If tail cone separated in flight:=, was at low height as showed by "concentration" in seabed.:confused:
Question 2): It´s possible (spinning to RH) hit the water slightly banking left? And if the VS detached before impact? LH would drop further?

Hi,

Always difficult to describe(evaluate) an experience comparing to a number of hours or age ...
A pilot can fly 10,000 hours very well (in full manual) and have little experience other than uneventful flight ... if no exeptional events (non-routine) occurs
In my job .. in one month (due exeptional events) I acquired more experience than I had been able to accumulate in 12 years ....

I think you said that backwards, or I understood it backwards.

If the aircraft is spinning CCW (and the aircraft is not inverted), its heading keeps changing to the left (being south of the equator would not change that :}). Put simply, if we mark the nose of the aircraft each time it passes through 360/North, it's heading will decrease during the next rotation until it arrives again at 360/North, and repeats the decrease on the next rotation.

If you spin/rotate CW, as viewed from above, (I have in my minds eye a fast moving, old fashioned compass card), as we pass through 360/North on each rotation, your heading will increase during the rotation. That's more of a right hand turn.

Wasn't that explained earlier as the airframe absorbing most/more of the impact? :confused: (Think "crumple zone" in a car collision).
It might be that Airbus never collected those data points in testing. :cool:
"Flat spin" will not by itself rule out a bit of roll along the longitudinal axis during the spin. The amount depends on aircraft type. The type I am familiar with had some (small) nose roll/oscillations in an erect spin. (Grateful I've never been in a flat spin, I understand it's a horror show.)

It also depends on the coupling between vertical stab and wings, which again would depend on a particular aircraft's unique characteristics.

I'll leave to those who are familiar with big jet/passenger jet spin and upset characteristics to explain in detail.

Spinning CW!
 

Lonewolf_50,

I´m sorry, CW!

It´s always good to put redundancy in the phrases.

OK, about roll oscillations, thanks. I asked because if she lost VS+assembly, some seconds before impact could "bank" left after losing it. Intuitive? It seems and could increase your "roll oscillation" factor.

Wall Street Journal, latest leak:

Preliminary Findings Suggest Pilot Error in Air France Crash - WSJ.com

The problem is that such a scenario contradicts all the physical evidence we have so far.

JD-EE
forget about the HF, when I had the dubious pleasure of using it one could go several hours without getting through.
Crossing the ITCZ especially in the middle of the night the important bit was finding our way through the cells.
Secondary was transmitting on VHF to let the other aircraft know where we were - same as over Africa and Asia.

We had the luxury of a double crew and occasionally we had the second captain watching as we transited the active zone. There was never ever an occasion when the working skipper was off the flight deck during the critical phase.

RR NDB, #2168
Ok, will will give it a shot and apologies to those who find this
oversimplified or even patronising:

Long before the days of software programmed microcomputers, there was a
need to be able to manage fixed sequences of events or 'states'. For
example, repetitive industrial processes.

For a trivial and incomplete example, consider the industrial bottle
filling line below. The state column defines valid states, while the
description defines actions, or what happens for each of those states.
For each state, an action is performed and a decision made as to which
state to move (transition) to next.

State Action / Transition
----- -------------------
0 Move next bottle to fill position
1 Open valve to fill bottle
2 If bottle not full, hold at state 2, else, goto state 3
3 close valve
4 if more bottles, goto step 0, else goto step 5
5 end, process complete

The key things to note here is that each defined state is associated with
an action and that only defined states are valid. Any other condition,
such as a broken or jammed bottle, is defined as an error. Errors may in
fact be handled by more states, after which the normal state sequence
would be restarted, but let's keep it simple. In the old days, such a
plant would have been implemented using electromechanical relays, pneumatics
and motors. To summarise then: The states, the action at each state and
transitions between states are designed to "encapsulate" the system functionality completely.

Finite state machines as we now understand the term were first (and are
still used) to implement complex digital logic functions in hardware.
If you like, programmed solutions for systems whare the the sequence of
data being processed and it's methods never change. They were widely used in
telecoms to decode and translate data streams between exchanges and
subscribers. Because of the speed limitations of early microcomputers,
such work could only be done in hardware, but later processors allow
this work to be done in software. In a way, it's still really all software
though, even when done in hardware http://images.ibsrv.net/ibsrv/res/sr...lies/smile.gif

For a more cutrrent example, we have to digress a little to communications
protocols. You can think of a protocol as an agreed language between one
or more systems that need to talk to each other. Such a language will be
transported in messages between one system and another. For a
trivial example, the wire between your home computer and printer carries a
defined message protocol to allow the two to talk to each other.

Messages are typically split into sections that describe, for example,
the start a new message (ie: phone off hook), control information, (ie, what
the message means) the data itself (ie: engine speed value), provide
error detection and signal the end of the message (phone hangup). Messages
are typically sent sequentially in time. That is, the overall message
is sent sequentially, one section after another.

Because of the agreed protocol and if the receiving node is keeping track
of parts already received, it knows which part of the message is coming next.
It can thus decode what each part of the message means without ambiguity.
So how do we keep track of where we are in the message?. We know that the
message has several sections and we know from the protocol spec the order in
which they should be received. We can thus define states that correspond to
each section, the actions that need to be performed and the transition to
the state that processes the next section of the message.

From a software engineering point of view, state machine based design
is a powerfull technique that allows a problem to to be broken down into
a number of small, well defined steps and can simply the generation of
demonstrably deterministic systems. Arguably the most socially significant
example is the internet, where the tcp/ip network stack is a state machine
based design.

This is a long post and hope it's not overdone. There's loads of info on
the web about state machine design that should fill in the gaps, or can
post a bit more if needed...

the "rest" of the story - F-16 FBW mods
 

Salute!

To avoid further dispersions as to why a few military would dare to tread amongst this august group of heavy pilots and experts, I'll conclude the story about our development of the first operational FBW system AFTER it was deployed and flown for a few years. My goal all along has been to provide some perspective concerning new concepts and their implementation with a first-person account.
++++++++++++++

Once we discovered that we could enter a deep stall and had no way to recover, things got serious.

- We transferred fuel forward shortly after takeoff. About 1200 pounds if memory serves. This helped our c.g., hurt our pitch rate, and led to some unintended consequences after landing if we forgot to "re-balance" on the way home.

- We added the pitch override switch to bypass angle of attack limits used by the computer..... well, almost. The switch was not active unless our AoA was above 29 degrees or so. Considering the deep stall was at 50 - 60 degrees AoA, no problem.

So we could control the horizontal tail surfaces "directly" in proportion to stick inputs.

- Developed a bigger tail. So we added a few square feet to the stabilators. This moved the aero center of pressure slightly aft, but most importantly, it gave the computers more control surface area to work with. Also gave we dumb pilots better control at slow speeds. We then quit transferring fuel, as the procedure was a kludge and had some unintended effects upon pumps and after-landing characteristics.

- We added a new control law called Category III. Named after our external loadout, which was impressive compared to the basic air-to-air configuration. The new law limited AoA and roll rate. This helped to avoid entering a departure induced by the inertia and aero effects of all that crapola hanging on an otherwise pretty jet.

Bottomline: Our engineers and USAF admitted that we all could have done better anticipating "upset" conditions or outright stupid moves. The system worked exactly as it was designed. Sound like a PR release or rumor from last week?

The flight test folks and GD came up with a great mod and it has served us well for 30 years.

we now return to our regularly scheduled hypothesis cacaphony.


Old fart with no airline experience
Familiar with many planes
Extremely familiar with early operational FBW systems
Extremely concerned with flying in a safe, well-engineered airliner
A.A.G.G.

The PI bug was almost unbelievable, but one suspects that internal politics,
project cost sensitivity issues etc were a factor in that one. Not something
that all software engineers would have experience of or be trained to recognise
at the time either. It's easy to be smug and there's plenty of info on the web on PI
now, but have yet to see a book that deals with it in depth and how to prevent it.

As for rtos, my (avionics) experience in that area is not current, but iirc,
there are at least two rtos's that are fully qualified to DO178 level, so it's
quite likely that they are being used. I would need to check what level
they are qualified to, but no company invests that amount of development
time and resource to such a project without the objective of making a lot of
money in return. You could check the Wind River site, or whatever they
are called now, for starters.

I don't see any problem with rtos, (treading carefully) and there may be
no alternative in that the business pressures, regulatory environment
and general competitive pressure mean that ever more complex solutions
are and will be needed to satisfy requirements. There's only so far that
you can go in simplifying a complex system and still have it work at all.

Of course, development processes and tools need to keep up with it all and
this is also cost driven to a degree http://images.ibsrv.net/ibsrv/res/sr...ilies/evil.gif (Again :-)...

WSJ: Air France's Black Boxes Point to Pilot Error
 

More:
Air France's Recorders Point to Pilot Error - WSJ.com

"Old fart with no airline experience
Familiar with many planes
Extremely familiar with early operational FBW systems
Extremely concerned with flying in a safe, well-engineered airliner
A.A.G.G."

...and what a rich life, that of yours.

First off I want to apologize to CogSim for my wording. I had no intention of wanting to make the discussion a Yoke vs SS or an A vs B discussion. Only a commentary on hand strength and the predilection to prefer one or the other for precision…without detracting from the AF447 discussion.

Smilin Ed's points are valid and I agree it’s all a matter of being trained, experienced and ultimately comfortable.

My experience includes flying various transport category aircraft with a yoke assembly (control wheel and column), from both the left side and right side; a transport category aircraft simulator with sidesticks, from both the left and right side; and fighter aircraft with both conventional center stick and FBW sidestick. I also flew the rams horn in the Hawker 800 aircraft from both the left and right seat.

I also flew different configurations, both aircraft and simulator, fighter and transport, on the same day from different chairs.

It indeed is not a strength or a handedness issue only a training and experience one. The A330 sidesticks in either seat are excellent pilot interface control devices. I personally use the armrest for both the control wheel and sidestick configurations in either seat. Some people don’t.

As to whether you need two hands on a yoke control wheel is a matter of technique and experience also. In the old days some aircraft didn’t have auto-throttles or auto-thrust and actual manual movement of the thrust levers (gasp) was often required. The control wheel was designed to accommodate two-handed flying, but did not necessitate it.

As an instructor in the B727 aircraft (prior to getting a simulator), I’ve flown manual reversion (flight control switches off) to the allowed aircraft training minimum of 300’ AGL on approaches from both the left and right seat. I can assure you that strength-wise it was equally difficult from either side.

DozyWannabe,

"The problem is that such a scenario contradicts all the physical evidence we have so far."

I made errors in expressing a model i was discussing here because i was in a hurry. And edited the post # 2199

Looking to the parts recovered first (floating) it seems matching a "flat spin" tail port (CW:)) Why not?

I had a "deep spin" trying to post some details we imagined:) here:confused:

But recovered:) and the model (of a flat spin until impact) is "stronger" now.

By the Wall Street Journal's account:

Sensory overload?

Question: How long would it take the captain at rest in the module -- and perhaps sensing that something is wrong around 2:10 or 2:11 -- to get to the cockpit, have a crew member open the secured door, and step inside?

At that point, at 2:12?, 2:13?, if the FOs are simultaneously trying to explain to him what is happening and fly the plane, is his appearance more hindrance than help?

CRM upside down
 

SaturnV asked

CRM also "stalling", :sad:

2:13:16 ~ 2:13:41 (Possible "Loss of Signal" with satellite) Unusual attitude

Capt. location? CVR will tell us:sad:

Software vs Man
 

syseng68k gave us a nice lecture on some IT stuff. Having spent of lot of time trying to make money in the IT world (there being no honorable way to make it in physics), I should point out the other side - IT abstractions always fail, most IT projects fail, period: on a team of 10 programmers, 1 is productive, 2 are helpful, 4 are a waste of office chairs, and 3 are probably faking it. and have a resume full of "exaggerations". No single discipline (such as it is) has generated so much hot air. The current programming idioms are byzantine beyond description, and have morphed eventually into "ends in themselves". Every problem of any sort is bent around the idiom, and bad performing bloatware is tolerated because "you can always throw more hardware at it". There are more IT fads than Paris fashions. Keep that in mind when you imagine a computer confusing your crew in a critical situation.

Seems like there is a controlled leak program in progress.

Easy to drop the power out of your scan when you weren't doing much of a scan to begin with.:rolleyes: When iron mike flies the aircraft, it can be real hard to stay in the loop, particularly when there isn't much happening.

Sounds like we are about to learn the necessity of getting some real stick time in, but as usual, we are learning the hard way.
The probable recommendation would be that more CRM training is required.:
Too many eyes on the same set of mouse holes, no one tending the others. Was anyone really flying the aircraft? Just too accustomed to a passive role.

Reminds me of a scary situation from my past. Two sets of eyes looking up at the formation above them while they flew into the water. The aftermath of that was what was scary for me.:eek: Have you ever seen a large formation breathe?

All this calls for a new kind of situational awareness. If I do get the airplane, what law is the system operating within, what configuration will it be in or going into? How will it behave in these modes? The old axiom of aviate first rings true but you have to know what the rules are first. Gone are the days when the chief pilot takes you up to show you "a few" of the nuances of an aircraft.

Let's be honest here. What you're saying is probably fair in many cases. But to compare the IT projects you're talking about with what goes into real-time aviation systems is like comparing regular army with Special Forces. And I say that as a vanilla software developer who hopes he falls into the first two categories you describe.

What usually causes consumer/business-level IT projects to fail tends to fall between unrealistic expectations on the part of management, poor specification on the part of the customer, and yes, occasionally programmers with padded CVs.

This, however, has about as much relevance to the discussion at hand as trying to determine why Wilbur Wright crashed the Flyer on his first attempt.

No harm. I possibly didn't phrase my thoughts too well. I am convinced that with training and experience, the position of sidestick will make very little difference, if any, in the vast majority of situations. I was just wondering about very high stress situations in which the mind "reverts", if you will, to a state that is not well understood. This reaction to acute stress actually triggers physiological changes in the brain. Call it sensory overload, acute stress reaction, or something else. There are studies that take into account behavior under stress when designing safety related equipment. A trivial example is the design of fire exits. People tend to push to get "out" even when they are trained to evacuate in an orderly fashion. It is considered unsafe to have fire exits that open inward. I was just wondering if our ability to coordinate movements with our "opposite" hand is effected under stress. Or does it take more effort (mental focus) to achieve the same level of coordination? (Try using your mouse with your left hand (if you are right-handed) and see what it does to your overall focus.) Will one hand perform better in this respect than the other? To be clear, this is different from panic. It has nothing to do with the strength of one hand over the other either. It was a poor choice of words to describe the hand as "strong".

DozyWan said

"Let's be honest here. What you're saying is probably fair in many cases. But to compare the IT projects you're talking about with what goes into real-time aviation systems is like comparing regular army with Special Forces. And I say that as a vanilla software developer who hopes he falls into the first two categories you describe. "

On the contrary, I started doing flat plate radar cross sections for the DoD on a project that turned out the be related to That Black Airplane. Remember Ada? Nope, gone down the ShopVac of IT ideas. I've seen BS across the board in IT, whose universal motto is "Failure is always an option. A stock option."

Back at post #2196 Turbine D made reference to a RoD calculation made by a Matthew Squair (an Australian engineer). HazelNuts39 has since mentioned that it was dealt with in Part 1 of this thread, and Squair's calculation was deemed to be incorrect due to a mathematical error.

At post #1900 in the same thread, I redid the calculation, and basically it is impossible to determine from it what the terminal RoD was, as depending at what time the Advisory happened, and allowing or not ACARS queue times, the outcome can be very much different.

My personal opinion is that Advisory happened after the final LOC and the aircraft was already approaching terminal RoD and the the flight ended very shortly after the receipt of the Cabin Vertical Speed advisory. In other words the calculated RoD could well be double that shown in post #1900

Would it also be just as likely to say the a/c was slowing, (vertically) as it developed the roughly "homogeneous" attitude at impact, from BEA??
Replacing what may have been purely vertical with (some) "flat" ? I'll hold onto this a bit longer. Who says because she hit not flying that the pilots were not attempting a recovery, and though only with 10.000 feet left, managed to bring the nose up and reload the wings a bit?

Errrr we are talking about the same Ada right? The programming language that pretty much all Airbus AND Boeing software is written in? The darling of safety critcial software design? Don't confuse IT with software engineering.
Who's Using Ada?

Bear,
Homogenous?
Don't you wish to imply a stable attitude?

I agree, very likely relatively stable at the end, but still somewhat dependent on actions of the crew who must have been desperate.
The way to life was not to bring the nose up however, but instead down. If they recognized a stall and had any experience with the subject, they should have instinctively known that.
The final impact bears too many similarities to D.P. Davies discussion about "Superstalls" to be anything different. I hope Friday we will know for sure.

BEA should be able to then tell us the general context of what the aircraft was doing on its way down although not the actual reasons in the final required detail.

Ada? Huh?
 

Salute!

From Wiki:

Not that Wiki is the end all authority, but I saw the reluctance of our software folks to embrace Ada back in late 80's and early 90's when developing systems for several military programs.

Granted, the compilers produced huge bytes of executable code. Tasking models by the compiler folks needed work to achieve the goals of the software engineers that developed Ada.

What I saw with DoD sfwe generally agrees with Wiki to some extent when I see the quoted text above.

The software folks couldn't get used to rigid definitions and typing. They did not like being handed a specification for an Ada package to be integrated in an existing system or a new one. We systems engineer folks said, "just do it", and we already have the overall sfwe for the project. They wanted "ownership".

Gums dons kevlar vest, looks for bomb shelter......

Loopholes allowed the "C" mafia to get into the process. So by early 90's, a lotta embedded computer sfwe stuff was not in Ada-compiled code.

Gotta tellya that it drove we systems engineers crazy in the "murder board" meetings. "lost pointers", huh? Case-sensitive variables and poorly designed calls to packages/subroutines, and the beat went on.

Fer chrissakes, all we wanted was modular and transportable code modules to get plug-and-play capability for basic aircraft avionics functions.

Sorry to rant, but sometimes I think a sfwe function coded in assembler would have been be easier to test and verify than the compiled code from "C++" or whatever.

back to my cave, now, as the press is now focusing upon "deep stall" and such. And my pea-brained background causes me to wonder how a system that works as advertised can allow ( maybe even cause) the confused aircrew to wind up in a loss of control accident. I thought all those control laws and sub-laws, and sub-sub-laws would help just a bit.

ion_berkeley, you can't be serious - people are still using that hermaphroditic monster? I'm stunned. Or is this just the page of some Ada booster (Lord do I remember those drones!)?

DozyWannabe, my recent experience is with a major aerospace firm and deSitter describes the software development process pretty well. There are (rare) modules that have to be expertly crafted to fit available constraints, but the bulk is produced as he described. No doubt for brevity he left out a bunch of nits, including that the process rewards happy rote-process-followers, depriving the project of the bright imaginative fellow who might've suggested a design for a thrust-and-attitude 'law'.

My usual apologies for treading where I don't belong....

gums
 

With this part of your message you have expressed what has come more and more as a nightmare to my mind. What, if the computers finished that flight off??
I believe Tim Vasquez with his exciting weather evaluation has already clearly worked out that weather was a or the primary cause of the crash. But the longer this discussion goes with very aducational - for me - contributions about the computers and programs background, the more I have come to the conclusion that another major hole of the "swiss cheese" might be computer generated.
If this assumption proofs correct, once the FDR and CVR data are published by BEA, I am sure some people at Toulouse might have a rough time.

Gosh - so none of the failed IT projects are anything to do with poorly defined user requirements and feature creep? In 30 years as an IT professional those are what I've found to be the biggest problem, along with salesmen more concerned about their bonus than anything else.

How embarrassing this thread is becoming!

Ada is alive, even if nowadays is typically confined to the high safety and integrity niche, where (if I'm not mistaken, and I'm not an insider) it is even growing. The earlier referenced Tokeneer project is done using a subset of Ada (Spark) with added facilities for automatic code verification.

The improvements brought in by the '95 standard were notable. I don't know to what extent the projects listed in that page use it though. Personally, I've settled on Ada (the modern versions) as the best compromise for error-free code in this crazy world of fads that IT is, as someone said, although my work has nothing to do with safety. But I went out of (an European) university latter than Ada fell into disgrace, so I was not exposed to the mandate and backslash that surrounded the origins of Ada. And even if I'm reassured thinking that the planes I use as SLF use Ada rather than C or C++, I'm sure there is much more (e.g. the whole development and certification process) involved than the particular language used in the end.

Hi Graybeard,
It seems that I missed your post here:
You should read again what I wrote and your question will be answered: when an ADR is declared faulty, an amber fault signal will pop up on the panel. Now, can you tell me how the hell one can only turn off the captain's pitot probes without turning off all the other chanels of ADR 1 (TAT, AoA, Static pressure, barometric altitude)?
There is only two separate parts: ADR & IR, as I said, and one may only turn off the complete Air data output from a faulty ADR.
http://takata1940.free.fr/ADIRS%280%29.jpg

http://takata1940.free.fr/ADIRS%281%29.jpg
http://takata1940.free.fr/ADIRS%282%29.jpg

I think that you may be the one confused here: what is then the purpose of sending cockpit effect messages without associated fault? Do you really think that "AUTO FLT AP OFF" or "AUTO FLT A/THR OFF" are only send because the tech will have to replace both autopilot and autothrust once landed?

Irrelevant as it is about A330 systems here: how its Air data are managed and integrated in flight and not about the general principles of ADIRs unit integrated in other flight systems.

No. Altitude values comes from the ADRs, via the transponder, but may not follow the same logic. In particular, the transponder may work without altitude imputs (which is not displayed in this case) while the TCAS is also feed with Radio Altitude and may need a valid and precise barometric altitude to continue to work without faulting. It is all about the internal functions of each particular system and its test boundaries. Moreover, the BEA is not supposed to explain all the details of every possible "no failure case sent" as it could lead to a never ending process. If Airbus told them that it was likely due to a TCAS altitude function failure (considering what elements they have on hand), then it is very likely the reason.

Annex14,
But the "Le Figaro" leak and the Airbus AIT 7 says there is no need for any immediate action on the A330 right now. This suggests that even if there were some computer bugs identified, they would be fixed by now. "Too bad for the 228 souls on AF447, but good for the future", one could say.

To my humble mind the recent leaks make this accident fit into the same category as what seems to be the current most common reason for aviation accidents:

Something unexpected happens, and the resulting corrective crew actions go haywire*.

Now the key issue looking forward is how to address that in order to improve on safety in the future. I see three scenarios:
1) add crew training to handle such "upset" situations in a safer way
2) add airplane automation to handle such situations
3) a "preventive system approach" to further minimize the risk of unexpected situations occurring. For example, speculating on the AF447 case, other routing and ATC options may have allowed the plane a safer routing around the bad weather zone. Or, a stricter AD regulation framework with quicker response to detected problems may have resulted in new pitot tubes being fitted before the accident flight.

Just my 2 cents.

*) Edit: this is, admittedly, coming from the GA side of aviation where crew training is arguably at a lower level. But it seems that a similar pattern is visible also on the commercial side.

@amos2

Tip: If you don't like it, don't read it....:mad: