AF 447 Search to resume (part2)
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
The pilots of an Air France jet that crashed into the Atlantic Ocean two years ago apparently became distracted with faulty airspeed indicators and failed to properly deal with other vital systems, including adjusting engine thrust, according to people familiar with preliminary findings from the plane's recorders.
Easy to drop the power out of your scan when you weren't doing much of a scan to begin with.
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.
Have you ever seen a large formation breathe?
Join Date: Jul 2009
Location: Tranquility Base
Age: 68
Posts: 53
Received 0 Likes
on
0 Posts
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.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Jul 2009
Location: Planet Earth
Posts: 91
Likes: 0
Received 0 Likes
on
0 Posts
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.
Last edited by CogSim; 24th May 2011 at 01:43.
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
Likes: 0
Received 0 Likes
on
0 Posts
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."
"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."
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
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
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
Last edited by mm43; 24th May 2011 at 04:51.
Guest
Posts: n/a
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?
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?
Last edited by bearfoil; 24th May 2011 at 03:01.
Join Date: Feb 2008
Location: USA
Posts: 93
Likes: 0
Received 0 Likes
on
0 Posts
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."
Who's Using Ada?
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
as it developed the roughly "homogeneous" attitude at impact,
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.
Thread Starter
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.
From Wiki:
By the late 1980s and early 1990s, Ada compilers had improved in performance, but there were still barriers to full exploitation of Ada's abilities, including a tasking model that was different from what most real-time programmers were used to.[9]
The Department of Defense Ada mandate was effectively removed in 1997, as the DoD began to embrace COTS (commercial off-the-shelf) technology. Similar requirements existed in other NATO countries.
The Department of Defense Ada mandate was effectively removed in 1997, as the DoD began to embrace COTS (commercial off-the-shelf) technology. Similar requirements existed in other NATO countries.
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.
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
Likes: 0
Received 0 Likes
on
0 Posts
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!)?
Join Date: Jan 2008
Location: Los Angeles
Posts: 168
Likes: 0
Received 0 Likes
on
0 Posts
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....
My usual apologies for treading where I don't belong....
Join Date: Dec 2010
Location: S 51 N
Age: 84
Posts: 196
Likes: 0
Received 0 Likes
on
0 Posts
gums
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.
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.
Join Date: Jan 2008
Location: UK
Posts: 1,464
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Jun 2009
Location: Spain
Posts: 13
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi Graybeard,
It seems that I missed your post here:
Do you really know the fault logic of the ADIRU, Takata? You're saying that faulty airspeed is turns off all air data and AOA outputs from the ADR?
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.
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.
It seems that I missed your post here:
Originally Posted by Graybeard
Originally Posted by Graybeard
Airspeed and altitude are separate and unique functions within the ADR, except at low speeds, and their output data bus words are separate and unique. An ADR may flag or put out erroneous airspeed without affecting altitude output.
Takata replied:
Each ADIRU module is separated in two: ADR+IR. If you are turning OFF the faulty ADR part because of unreliable airspeed, you will also reject all the associated static and AoA probes. Hence, if all three are rejected, you are only left with your standby instruments.
Airspeed and altitude are separate and unique functions within the ADR, except at low speeds, and their output data bus words are separate and unique. An ADR may flag or put out erroneous airspeed without affecting altitude output.
Takata replied:
Each ADIRU module is separated in two: ADR+IR. If you are turning OFF the faulty ADR part because of unreliable airspeed, you will also reject all the associated static and AoA probes. Hence, if all three are rejected, you are only left with your standby instruments.
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.
Originally Posted by Graybeard
I think you have confused ACARS report with reality. The ACARS report is to aid the tech at destination in troubleshooting to the level of the offending LRU, Line Replaceable Unit.
Originally Posted by Graybeard
Arinc 700 design was finalized in the late 1970s... bla bla bla.
Originally Posted by Graybeard
BEA stated that the TCAS Fail on 447 was due to its internal monitoring of altitude. That altitude comes from the transponder. BEA doesn't explain why there wasn't also ATC Fail. There should have been, if the altitude it received from the ADR was faulty.
Yes, my knowledge and experience suggests BEA was mistaken on its assessment of the TCAS Fail.
Yes, my knowledge and experience suggests BEA was mistaken on its assessment of the TCAS Fail.
Join Date: Dec 2005
Location: At home
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
Last edited by snowfalcon2; 24th May 2011 at 08:40. Reason: footnote added
