Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF 447 Search to resume (part2)

Tech Log The very best in practical technical discussion on the web

AF 447 Search to resume (part2)

Old 24th May 2011, 01:44
  #2221 (permalink)  
 
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
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.
deSitter is offline  
Old 24th May 2011, 01:49
  #2222 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 78
Posts: 1,460
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.
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. 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?
Machinbird is offline  
Old 24th May 2011, 02:17
  #2223 (permalink)  
 
Join Date: Jul 2009
Location: Tranquility Base
Age: 65
Posts: 52
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.
Lazerdog is offline  
Old 24th May 2011, 02:22
  #2224 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,183
Originally Posted by deSitter View Post
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".
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.
DozyWannabe is offline  
Old 24th May 2011, 02:31
  #2225 (permalink)  
 
Join Date: Jul 2009
Location: Planet Earth
Posts: 91
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.
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".

Last edited by CogSim; 24th May 2011 at 02:43.
CogSim is offline  
Old 24th May 2011, 02:40
  #2226 (permalink)  
 
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
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."
deSitter is offline  
Old 24th May 2011, 02:59
  #2227 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 77
Posts: 1,330
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

Last edited by mm43; 24th May 2011 at 05:51.
mm43 is offline  
Old 24th May 2011, 03:43
  #2228 (permalink)  
bearfoil
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?

Last edited by bearfoil; 24th May 2011 at 04:01.
 
Old 24th May 2011, 04:17
  #2229 (permalink)  
 
Join Date: Feb 2008
Location: USA
Posts: 93
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."

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?
ion_berkley is offline  
Old 24th May 2011, 04:28
  #2230 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 78
Posts: 1,460
as it developed the roughly "homogeneous" attitude at impact,
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.
Machinbird is offline  
Old 24th May 2011, 05:02
  #2231 (permalink)  
Thread Starter
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,248
Ada? Huh?

Salute!

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.
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.
gums is offline  
Old 24th May 2011, 05:16
  #2232 (permalink)  
 
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
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!)?
deSitter is offline  
Old 24th May 2011, 07:20
  #2233 (permalink)  
 
Join Date: Jan 2008
Location: Los Angeles
Posts: 168
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....
poorjohn is offline  
Old 24th May 2011, 08:18
  #2234 (permalink)  
 
Join Date: Dec 2010
Location: S 51 N
Age: 80
Posts: 195
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.
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.
Annex14 is offline  
Old 24th May 2011, 08:30
  #2235 (permalink)  
 
Join Date: Jan 2008
Location: UK
Posts: 1,453
Originally Posted by deSitter View Post
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.
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.
cats_five is offline  
Old 24th May 2011, 09:20
  #2236 (permalink)  
 
Join Date: Mar 2002
Location: Wybacrik
Posts: 1,192
How embarrassing this thread is becoming!
amos2 is offline  
Old 24th May 2011, 09:27
  #2237 (permalink)  
 
Join Date: Jun 2009
Location: Spain
Posts: 13
Originally Posted by deSitter View Post
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!)?
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.
mosteo is offline  
Old 24th May 2011, 09:27
  #2238 (permalink)  
 
Join Date: Jun 2009
Location: Paris
Posts: 691
Hi Graybeard,
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.
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.





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.
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?

Originally Posted by Graybeard
Arinc 700 design was finalized in the late 1970s... bla bla bla.
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.

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.
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.
takata is offline  
Old 24th May 2011, 09:30
  #2239 (permalink)  
 
Join Date: Dec 2005
Location: Finland
Posts: 242
Annex14,
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.
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.

Last edited by snowfalcon2; 24th May 2011 at 09:40. Reason: footnote added
snowfalcon2 is offline  
Old 24th May 2011, 09:43
  #2240 (permalink)  
 
Join Date: Jun 2009
Location: Brussels
Age: 48
Posts: 2
@amos2

How embarrassing this thread is becoming!
Tip: If you don't like it, don't read it....
regularjo is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information -

Copyright © 2018 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.