This is not a bizarre failure. If your primary onboard oxygen system fails, you have to activate emergency oxygen, it's the same in all modern fighter planes, really. This is not bizarre, it's a known failure mode, and they train F-22 pilots to deal with it. The real question is why was the pilot unable to activate emergency oxygen.
It's a normal event that they train for and are expected to survive. It was a pilot error. Sorry. The poor ergonomics of the emergency oxygen system activation mechanism notwithstanding -- that stupid detail has to be fixed, of course.
Sigh. Mistake upon mistake in those comments. The computer didn't detect any oxygen leaks. It detected a leak of hot air (bleed air) that is used to power various things, including oxygen generator (OBOGS). Since an uncontained leak of bleed air is likely to start a fire, the bleed air was automatically cut off by closing isolation valves at the engines. Thus it was no more powering the oxygen generator. The pilot fumbled for about 30s trying to activate emergency oxygen, eventually failing to do so, but while he was fumbling he bumped the control stick and rudder pedals, sending the aircraft on an uncontrolled inverted dive.
The bleed air is really hot -- between 1200F to 2000F (650C to 1000C). PHX (primary heat exchanger) then cools it down to 400F (200C).
There was some maintenance done in the previous months that required disconnecting the bleed air ducts, the accident investigators didn't think that anything went wrong there.
The bleed air leak was survivable, but somehow the pilot couldn't get emergency oxygen going, and lost situational awareness. When he tried to recover from the dive, it was too late.
That's semi-wrong. It was a failure of where the air was bleeding. The bleed air isolation valves closed because there was a leak in the bleed air duct. Since bleed air is hot, a leak in a wrong place is likely to cause a fire, thus the fire control system's leak detection triggered the environmental control system (ECS) to stop bleed air from the engines from reaching the things it normally feeds, including the oxygen generator.
You've mixed things up, it makes no sense. I've read the report. Here's what happened:
1. The fire control system (FCS) detected a bleed air duct leak and has closed the isolation valves, cutting off engine bleed air from reaching the bleed air manifold (or duct). Bleed air is hot air from the compressor, used to power other systems. This triggers the "C BLEED HOT" caution.
2. Loss of bleed air made the following systems inoperational: environmental control system (ECS), forced air cooling for avionics et al (ACS), oxygen generator (OBOGS), inert gas generator (OBIGGS), cabin pressurization.
3. About 5 seconds after the bleed air was cut off, a new caution appeared: "OBOGS FAIL". This means the oxygen generator is out and you have to activate emergency oxygen generator on your seat - soon. That one is on your seat because it has to supply you with oxygen when you eject.
4. About 14 seconds later, a sensor picks up loss of oxygen pressure to the mask (from failed OBOGS).
That's all there's to it. Apparently the pilot never managed to activate emergency oxygen, and while fumbling with that he also bumped the control stick and rudder, causing the aircraft to fly a "random" trajectory. The cabin is cramped, and with extra cold weather gear it's nigh impossible to activate that emergency oxygen without bumping into things. That is a design issue, as well as the awkward way of activating that emergency oxygen system (you have to pull a ring from a hip level about 2 in. forward (away from you) with 40lb or more of force.
I'm thinking of manual agility. I don't know how much cadaver time one normally gets, but from what I've seen it's pretty limited. There is a reason why students practice stitching on chickens, pieces of cloth, etc. As for anatomical differences -- they are fairly minor, on the grand scale of things. If you want to do reconstruction on small blood vessels, a frog is as good as anything -- the scale of larger vessels in a frog will be similar to what you'd have, say, in a severed human finger.
Heck, I'd almost like to call history a mostly non-science, because it has no theories to explain much if anything. It only applies science to fact gathering, and that's it. Psychology, psychiatry, physiology and economics are the major providers of theory here, because ultimately history is study of human behavior.
It always worries me when people try to pass psychology for history -- what else is so basic that they have such a poor grasp of? History repeats itself because people are people, still. There's nothing enlightening about study of history if you have prior psychology background. It's downright boring, like reading similar case reports over and over. I think that history is highly overrated. Medical education in any field will have you exposed to plenty of cases, clinical psychology and psychiatry is no different, except that you not only have a bunch of anecdotes to rely on, but also an understanding (however feeble it may be) of underlying causes. History has little to no tools to explain why people did what they did. It's horribly lacking in that fundamental department. Saying "ah, it happened like so in year X" is hardly an explanation. It's a cargo cult.
As far as I can tell, you'd find several very similar pictures from anywhere behind the iron curtain. Probably the store was only accessible to those holding sufficient party credentials. My dad studied in former Soviet Union, and as a top-grading foreign student on a scholarship, no less, he had access to a store catering to diplomats and other dignitaries. A whole different experience it was, he says.
The idea that the only indicator of a scientists' value is some measure of "scientific productivity" is fundamentally braindead. I'd say their value may well be in guiding their young team, providing sage advice, and otherwise mediating things where the young ones may lack the social or political skill. There's no way to measure it only looking at the published output, and quite likely no way to quantify it at all without conducting extensive interviews with people who actually work under/next to those old "farts".
If you're ever going to be a surgeon, there's no replacing dissection. Sorry. They are living on some cloud nine. This is a big snafu in the making. My bet is that the people who made this decision were not practicing surgeons, or perhaps they were some very poor ones better fit for a bureaucratic job rather than an OR job.
The only thing that's of concern is if all air-sensor and inertial reference inputs are bad yet they agree and pass sanity checks. That's the only failure mode, however unlikely, where an "OVRD DIRECT LAW" pushbutton would be of help -- that way the flight controls' computers wouldn't be using any sensors beyond stick/pedal position sensors and feedback from the actuators. It's about the only thing that I'd like to see on FBW aircraft that's missing at least on Airbus models. I haven't read yet any accident/incident report where lack of such a button was a hindrance, though, so for now I'd say their design is fundamentally OK. I dislike not having actuators in the stick and throttles so that the human could be kept in the loop. That's a big human factors snafu in Airbus's cockpit design, and the only major thing I'd urge them to change.
Example: with both radar altimeters dead (breakers pulled), the computer selects direct law automatically when you deploy the gears. If you're brave and would kill the primary ADIRU, then you'd probably also immediately get the direct law activated, although don't quote me on that.
The flight control computers implement all control laws, so you're not disabling any computers at all. Let's talk about, say A330. There is a set of three primary control computers (PRIM) that produce data for the control surface actuators, and a set of two secondary computers (SEC). SEC only implements the direct law, PRIM implements all control laws (normal, alternate 1/2, direct, with mode modifications for flare and ground).
The control law downgrading can only be handled automatically. You pretty much have to pull circuit breakers to change it manually. If there's a "catastrophic computer error", say all PRIM computers down due to overheating (has happened at least once due to air conditioning failure) the downgrading or selection of SEC computers will happen automatically, the pilot isn't expected to have to handle that.
I don't think there's any reason for the computers to permanently "crash" preventing direct law from working. You'd need to physically break some hardware for that. As in taking a flak from an AA battery, etc. I don't believe this has ever been attributed to any crash, and I don't know if it has ever happened at all in a commercial FBW aircraft.
I think that there is absolutely no reason to blame FBW concept itself on anything. It has never failed so as to prevent control of the plane, I doubt it ever will, and is a convenient scapegoat. The reliability people have done their job on that one, it was beaten to death and brought back, so to speak, precisely because everyone worried so much you'd have a "perfectly flyable" plane with dead computers crash due to lack of control. Your hypothetical scenario is even more hypothetical than all hydraulic circuits failing (it did happen at least once that I'm aware of).
Those are glaring human factors mistakes, agreed, but the use of computers is not to blame. The stick and the levers should be actuated, and the sticks should be mirroring each other's position. The throttle levers should be mirroring the current setpoint (follow autothrottle, flare on autoland, etc). I didn't know the stupid things were not designed that way.
My best bet at this point is that it was a known issue with airspeed sensors, and the pilots were not properly trained how to deal with it. That particular plane can be flown quite well without any airspeed data -- you pretty much set the throttles by looking it up in the table, based on air pressure and desired airspeed. What most likely killed them was that the pilots were unaware that the airspeed data was wrong, so they were flying the plane on wrong (most likely low) airspeed indication. There was nothing particularly computer-related in the whole incident so far. Good old wetware issue.
I can't help wondering just how a piece of code, which presumably didn't test its input data for validity before acting on it, could become part of a modern jet's onboard software suite
Here's how: high reliability software engineering may be slowly turning into a cargo cult, where certain artifacts become part of the ritual without much understanding what they are for. There's a certain process that has to be followed to get the software past certification bodies, and there are expensive (think $150k per seat and up) and inexpensive (bound notebook with numbered pages + a pencil) tools that can be used to help you follow the process in various ways (by offering mathematical proofs that various pre/post conditions are fulfilled, by tracking specifications, requirements and test coverage, etc). Those artifacts are not a substitute for thinking and understanding how what you're coding fits into the system, and that the requirements and specs may need to be amended. Either the spec/reqs were bad, or the implementation didn't quite follow them, and somehow it slipped under the radar. If it were on the space shuttle software team, they'd dig deep to understand how their process had failed, and would fix the process first. Whoever maintains that software probably simply issued a bugfix, filed requisite paperwork somewhere, and promptly forgot the whole thing.
To shoot oneself in the foot?! I just don't get it. Wouldn't Oracle want to have their platform deployed as widely as possible? Someone's asleep at the helm. Just like at the media companies. Seems some big corporations these days are like chicken running around headless...
I agree with you as to teaching more advanced ideas, so I don't quite get the name calling. Perhaps if you could have said what you mean and all that instead of making me guess and getting upset that I don't read your mind...
Nope. It is the MS linker problem. It's not about memory usage, it's about stupidly memmapping ALL of the input files during startup. So it's very simple to check if you may have a problem: add up the size of all the.obj files. If it's above 1-1.5G or so, it won't fit as linker needs address space for its own transient data and you need to boot with the/3g switch. If it's above 2G or so, then even the/3g switch won't help you -- you need a 64 bit host.
Slashdot Mirror
This is not a bizarre failure. If your primary onboard oxygen system fails, you have to activate emergency oxygen, it's the same in all modern fighter planes, really. This is not bizarre, it's a known failure mode, and they train F-22 pilots to deal with it. The real question is why was the pilot unable to activate emergency oxygen.
It's a normal event that they train for and are expected to survive. It was a pilot error. Sorry. The poor ergonomics of the emergency oxygen system activation mechanism notwithstanding -- that stupid detail has to be fixed, of course.
Bingo.
Sigh. Mistake upon mistake in those comments. The computer didn't detect any oxygen leaks. It detected a leak of hot air (bleed air) that is used to power various things, including oxygen generator (OBOGS). Since an uncontained leak of bleed air is likely to start a fire, the bleed air was automatically cut off by closing isolation valves at the engines. Thus it was no more powering the oxygen generator. The pilot fumbled for about 30s trying to activate emergency oxygen, eventually failing to do so, but while he was fumbling he bumped the control stick and rudder pedals, sending the aircraft on an uncontrolled inverted dive.
The bleed air is really hot -- between 1200F to 2000F (650C to 1000C). PHX (primary heat exchanger) then cools it down to 400F (200C).
There was some maintenance done in the previous months that required disconnecting the bleed air ducts, the accident investigators didn't think that anything went wrong there.
The bleed air leak was survivable, but somehow the pilot couldn't get emergency oxygen going, and lost situational awareness. When he tried to recover from the dive, it was too late.
That's semi-wrong. It was a failure of where the air was bleeding. The bleed air isolation valves closed because there was a leak in the bleed air duct. Since bleed air is hot, a leak in a wrong place is likely to cause a fire, thus the fire control system's leak detection triggered the environmental control system (ECS) to stop bleed air from the engines from reaching the things it normally feeds, including the oxygen generator.
There is one attached to the seat. The thing you linked to is useless if you're wearing a cold weather flight suit, a helmet, and an oxygen mask.
You've mixed things up, it makes no sense. I've read the report. Here's what happened:
1. The fire control system (FCS) detected a bleed air duct leak and has closed the isolation valves, cutting off engine bleed air from reaching the bleed air manifold (or duct). Bleed air is hot air from the compressor, used to power other systems. This triggers the "C BLEED HOT" caution.
2. Loss of bleed air made the following systems inoperational: environmental control system (ECS), forced air cooling for avionics et al (ACS), oxygen generator (OBOGS), inert gas generator (OBIGGS), cabin pressurization.
3. About 5 seconds after the bleed air was cut off, a new caution appeared: "OBOGS FAIL". This means the oxygen generator is out and you have to activate emergency oxygen generator on your seat - soon. That one is on your seat because it has to supply you with oxygen when you eject.
4. About 14 seconds later, a sensor picks up loss of oxygen pressure to the mask (from failed OBOGS).
That's all there's to it. Apparently the pilot never managed to activate emergency oxygen, and while fumbling with that he also bumped the control stick and rudder, causing the aircraft to fly a "random" trajectory. The cabin is cramped, and with extra cold weather gear it's nigh impossible to activate that emergency oxygen without bumping into things. That is a design issue, as well as the awkward way of activating that emergency oxygen system (you have to pull a ring from a hip level about 2 in. forward (away from you) with 40lb or more of force.
The report is here.
I'm thinking of manual agility. I don't know how much cadaver time one normally gets, but from what I've seen it's pretty limited. There is a reason why students practice stitching on chickens, pieces of cloth, etc. As for anatomical differences -- they are fairly minor, on the grand scale of things. If you want to do reconstruction on small blood vessels, a frog is as good as anything -- the scale of larger vessels in a frog will be similar to what you'd have, say, in a severed human finger.
Heck, I'd almost like to call history a mostly non-science, because it has no theories to explain much if anything. It only applies science to fact gathering, and that's it. Psychology, psychiatry, physiology and economics are the major providers of theory here, because ultimately history is study of human behavior.
It always worries me when people try to pass psychology for history -- what else is so basic that they have such a poor grasp of? History repeats itself because people are people, still. There's nothing enlightening about study of history if you have prior psychology background. It's downright boring, like reading similar case reports over and over. I think that history is highly overrated. Medical education in any field will have you exposed to plenty of cases, clinical psychology and psychiatry is no different, except that you not only have a bunch of anecdotes to rely on, but also an understanding (however feeble it may be) of underlying causes. History has little to no tools to explain why people did what they did. It's horribly lacking in that fundamental department. Saying "ah, it happened like so in year X" is hardly an explanation. It's a cargo cult.
As far as I can tell, you'd find several very similar pictures from anywhere behind the iron curtain. Probably the store was only accessible to those holding sufficient party credentials. My dad studied in former Soviet Union, and as a top-grading foreign student on a scholarship, no less, he had access to a store catering to diplomats and other dignitaries. A whole different experience it was, he says.
The idea that the only indicator of a scientists' value is some measure of "scientific productivity" is fundamentally braindead. I'd say their value may well be in guiding their young team, providing sage advice, and otherwise mediating things where the young ones may lack the social or political skill. There's no way to measure it only looking at the published output, and quite likely no way to quantify it at all without conducting extensive interviews with people who actually work under/next to those old "farts".
If you're ever going to be a surgeon, there's no replacing dissection. Sorry. They are living on some cloud nine. This is a big snafu in the making. My bet is that the people who made this decision were not practicing surgeons, or perhaps they were some very poor ones better fit for a bureaucratic job rather than an OR job.
The only thing that's of concern is if all air-sensor and inertial reference inputs are bad yet they agree and pass sanity checks. That's the only failure mode, however unlikely, where an "OVRD DIRECT LAW" pushbutton would be of help -- that way the flight controls' computers wouldn't be using any sensors beyond stick/pedal position sensors and feedback from the actuators. It's about the only thing that I'd like to see on FBW aircraft that's missing at least on Airbus models. I haven't read yet any accident/incident report where lack of such a button was a hindrance, though, so for now I'd say their design is fundamentally OK. I dislike not having actuators in the stick and throttles so that the human could be kept in the loop. That's a big human factors snafu in Airbus's cockpit design, and the only major thing I'd urge them to change.
Sorry, that would be flare law, close enough to a direct law :)
Example: with both radar altimeters dead (breakers pulled), the computer selects direct law automatically when you deploy the gears. If you're brave and would kill the primary ADIRU, then you'd probably also immediately get the direct law activated, although don't quote me on that.
The flight control computers implement all control laws, so you're not disabling any computers at all. Let's talk about, say A330. There is a set of three primary control computers (PRIM) that produce data for the control surface actuators, and a set of two secondary computers (SEC). SEC only implements the direct law, PRIM implements all control laws (normal, alternate 1/2, direct, with mode modifications for flare and ground).
The control law downgrading can only be handled automatically. You pretty much have to pull circuit breakers to change it manually. If there's a "catastrophic computer error", say all PRIM computers down due to overheating (has happened at least once due to air conditioning failure) the downgrading or selection of SEC computers will happen automatically, the pilot isn't expected to have to handle that.
I don't think there's any reason for the computers to permanently "crash" preventing direct law from working. You'd need to physically break some hardware for that. As in taking a flak from an AA battery, etc. I don't believe this has ever been attributed to any crash, and I don't know if it has ever happened at all in a commercial FBW aircraft.
I think that there is absolutely no reason to blame FBW concept itself on anything. It has never failed so as to prevent control of the plane, I doubt it ever will, and is a convenient scapegoat. The reliability people have done their job on that one, it was beaten to death and brought back, so to speak, precisely because everyone worried so much you'd have a "perfectly flyable" plane with dead computers crash due to lack of control. Your hypothetical scenario is even more hypothetical than all hydraulic circuits failing (it did happen at least once that I'm aware of).
Those are glaring human factors mistakes, agreed, but the use of computers is not to blame. The stick and the levers should be actuated, and the sticks should be mirroring each other's position. The throttle levers should be mirroring the current setpoint (follow autothrottle, flare on autoland, etc). I didn't know the stupid things were not designed that way.
Well said. And I own no aerospace stocks and have nothing to gain by siding with you.
My best bet at this point is that it was a known issue with airspeed sensors, and the pilots were not properly trained how to deal with it. That particular plane can be flown quite well without any airspeed data -- you pretty much set the throttles by looking it up in the table, based on air pressure and desired airspeed. What most likely killed them was that the pilots were unaware that the airspeed data was wrong, so they were flying the plane on wrong (most likely low) airspeed indication. There was nothing particularly computer-related in the whole incident so far. Good old wetware issue.
I can't help wondering just how a piece of code, which presumably didn't test its input data for validity before acting on it, could become part of a modern jet's onboard software suite
Here's how: high reliability software engineering may be slowly turning into a cargo cult, where certain artifacts become part of the ritual without much understanding what they are for. There's a certain process that has to be followed to get the software past certification bodies, and there are expensive (think $150k per seat and up) and inexpensive (bound notebook with numbered pages + a pencil) tools that can be used to help you follow the process in various ways (by offering mathematical proofs that various pre/post conditions are fulfilled, by tracking specifications, requirements and test coverage, etc). Those artifacts are not a substitute for thinking and understanding how what you're coding fits into the system, and that the requirements and specs may need to be amended. Either the spec/reqs were bad, or the implementation didn't quite follow them, and somehow it slipped under the radar. If it were on the space shuttle software team, they'd dig deep to understand how their process had failed, and would fix the process first. Whoever maintains that software probably simply issued a bugfix, filed requisite paperwork somewhere, and promptly forgot the whole thing.
To shoot oneself in the foot?! I just don't get it. Wouldn't Oracle want to have their platform deployed as widely as possible? Someone's asleep at the helm. Just like at the media companies. Seems some big corporations these days are like chicken running around headless...
I agree with you as to teaching more advanced ideas, so I don't quite get the name calling. Perhaps if you could have said what you mean and all that instead of making me guess and getting upset that I don't read your mind...
Nope. It is the MS linker problem. It's not about memory usage, it's about stupidly memmapping ALL of the input files during startup. So it's very simple to check if you may have a problem: add up the size of all the .obj files. If it's above 1-1.5G or so, it won't fit as linker needs address space for its own transient data and you need to boot with the /3g switch. If it's above 2G or so, then even the /3g switch won't help you -- you need a 64 bit host.