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.
|
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.: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.
|
Originally Posted by deSitter
(Post 6469370)
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".
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. |
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. |
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? |
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? |
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. |
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. 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
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. |
Originally Posted by deSitter
(Post 6469370)
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.
|
How embarrassing this thread is becoming!
|
Originally Posted by deSitter
(Post 6469516)
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!)?
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:
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. 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
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. |
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. 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
How embarrassing this thread is becoming! |
All times are GMT. The time now is 17:16. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.