Slashdot Mirror
Flight Data Recorders, Decades Out of Date
Tisha_AH writes "For the past fifty years the technology behind aircraft flight data recorders has remained stagnant. Some of the advances of cloud computing, mesh radio networks, real-time position reporting and satellite communications are held back by a combination of aircraft manufacturers, pilots unions and the slow gears of government bureaucracy. Many recent aircraft loss incidents remain unexplained, with black boxes lost on the bottom of the Atlantic Ocean, buried under the wreckage of the World Trade Centers or with critical information suppressed by government secrecy or aircraft manufacturers. Many devices still rely upon tape recorders for voice and data that only record a very small sampling of aircraft dynamics, flight and engine systems or crew behaviors. Technologically simple solutions like battery backup, continual telemetry feeds by satellite and hundreds of I/O points, monitoring many systems should be within easy reach. Pilot unions have objected to the collection and sharing of detailed accident data, citing privacy concerns of the flight crew. Accidents may be due to human error, process problems or design flaws. Unless we can fully evaluate all factors involved in transportation accidents, it will be difficult to improve the safety record. Recommendations by the NTSB to the FAA have gone unheeded for many years. With all of the technological advancements that we work with in the IT field, what sort of best practices could be brought forward in transit safety?"
Trying to take that a bit literally, are we?
fp?
well, they can run in parallel. as far as i know, nobody says you can't have a backup flight data recorder using mesh cloud pie-in-the-sky technology...
So the one place where there would be a benefit to all this nifty surveillance technology that keeps popping up everywhere else and for once, with no civil rights issues ... and they let it go decades out of date. Doing something useful must not be as fun as circumventing the Constitution for politicians.
Really if this were a private Internet connection with an expectation of privacy they'd have come up with 20 different ways to monitor it, 5 of which wouldn't require a warrant due to bad precedent. A flight data recorder has no concerns about privacy and such so it just isn't a priority. Nice. Real nice.
Tape is one of the best long term and reliable storage methods. As long as it doesn't burn (which kills any memory type), it's more stable in most situations than the modern memory devices. Remember, it has be stable in salt water, in high impact, humid environments, dry environments, wide temperature ranges, take electrical shock, etc.
People just think it sucks b/c it's old school and clunky.
They work, don't they? Yeah more bells and whistles might be nice, but as Scotty said "the more you overthink the plumbing, the easier it is to stop up the drain."
Not only that but the article conflates two different issues.
1. technology that COULD be improved (complete with buzz-words).
2. government/corporation control of data.
meh
Cloud computing? Conflation of data not being recorded and the choice to be secret about what's recorded? Technologically simple solutions with "hundreds of I/O points"?
Rather than hand-waving over every single modern technology which might be remotely relevant to the flight recorder, how about writing down, point by point, each improvement you feel should be made and why you feel it would be beneficial. Mention deployments to flying aircraft as well as destruction testing which has been done. IOW, what that is broken are you able to fix?
And, yes, pilot privacy is a concern because certain well-known air crashes have involved the airline and/or even government falsifying data to put the blame on the pilots (cue fingers wagged at France).
Why would a black box need to use cloud computing or mesh networks?
Just because new technologies have emerged doesn't mean they are necessarily applicable in all areas of computing. My knowledge in this field is limited, but I just don't see the point of a twittering black box, or whatever web 2.0 meme is the flavor of the day.
Jesus had a UNIX beard.
"Many recent aircraft loss incidents remain unexplained, ....., buried under the wreckage of the World Trade Centers" - This has to be the dumbest statement of all time. I think everyone knows what happened to the planes THAT WERE FLOWN INTO THE WTC BY MUSLIM TERRORISTS. Fail.
Conservative, mod down for violating
The rabid tone of the summary is completely unsupported by the article itself. Does the submitter have any evidence that advancements are held back by unions, bureaucracy and privacy concerns? The article does not claim anything like that.
They are just proposing a replacement technology with a catchy name. The submitter is a massive troll.
...citing privacy concerns of the flight crew.
Not only are you on the job (which means your privacy is significantly reduced by default), you're job involves being responsible for hundreds of lives. I'm sorry that you're worried about people potentially overhearing you and the co-pilot talking about that hot piece of new flight attendant, but recording flight data is just a bit more important.
Pompous assholes.
Living With a Nerd
The simple fact is that you can't take ordinary hardware, put it in a box, and say that it's ready to be a flight data recorder. The simple example is storage: even though you can get a 2-TB harddrive into your computer, it'd never pass muster for flight data. Even once you find ultra-ruggedized hardware that you're happy with, you then need to subject it to a few years of excruciatingly brutal tests to make sure that, in the event of a crash, you have a reasonable chance of getting useful information back.
Because the pipeline is so long, the FAA ought to, years ago, have put a development program in place. They should model it along the lines of a DARPA program: one- or two-year commitments with substantial deliverables. Want to play again next year? Better deliver this year. When the contract's up, the money's done. They ought to pit competing factions against each other: have development teams one year become destructive testers of someone else's hardware the next year.
A direct telemetry feed to ground stations or via satellite could be a very interesting way to monitor the airplanes and give crucial information in the even of a crash, but could not replace an on-board logging device. In the even of catastrophic malfunction, on-board recorders are most likely more reliable than networked data. But in the even the on-board recorder is lost, the telemetry feed could give most of the required information on the systems leading and the events leading to the malfunction.
To some extent, these systems already exist and are used by maintenance crew to schedule maintenance and get early warnings on possible problems with the airplane.
Having a global system that is not company-based, but centralized and international could give not only make incident reconstitution easier, but might also improve transparency on aircraft maintenance on less "serious" airlines and provide real time information (wetter radar feed, wind shear data, turbulence, etc.) to air traffic control and weather forecasters to improve safety overall.
The major technical issue that this would bring is a problem of bandwidth. There are a lot of aircraft in the air and it would generate huge amounts of data. Transmission, storage and analysis would all be challenge.
One important thing to point out, is that when the aircraft attitude is so messed up that the sat link is no longer reliable, the crucial events that lead to the crash already occurred. We don't really need to now how the plane crashed into the ground, we need to know why and what lead to it. Nevertheless, on board recoding should not be replaced by telemetry.
As for the value of such a system, if its only used for analysis in the event of a crash, I think its a waste of money. But if its used for more than that, It may become a damned good way to further improve air safety.
Its my understanding the tape hasn't been used in new flight recorders for quite some time. I think they're all solid state now.
Yeh, I'll get off your lawn.
Still, the summary is atrocious buzz-word bingo. The article is better written but the 'glass box' basically amounts to broadcasting the black box data on the go. Hardly a revolutionary idea, with a sugar coating. If it doesn't exist currently there is probably a reason - technical (bandwidth requirements) or otherwise (cost) - that is not outweighed by the proposed benefits. Rather than address this we get hand waving and straw man rambles about union conspiracies.
Yawn.
Python coder | PyQt Applications | Writer
Umm, no. You're almost a century out of touch with reality. What you say was true in 1930s.
Today, when an airplane crashes, the human has failed. Pretty much always. Technical issues that lead to crashes are very, very rare. If you were to place monetary bets, a winning strategy is to bet for human failure.
A successful API design takes a mixture of software design and pedagogy.
There are plenty of people willing to work on bringing aviation into the information age, but it's a slow, costly process. Have to get the main stakeholders: the FAA, the commercial airliners, the pilots' unions, and the air traffic control unions to all agree on the way forward, and none of them particularly like to talk to each other. The systems we have now aren't particularly great, but they work and have enjoyed a decent safety and efficiency record... even though there's much room for improvement. But anyone trying to iron out the bugs in new software or systems will be blamed for not sticking with the "old reliable" and "certified" status quo.
The most progress could probably be made by experimental aircraft and private pilots, but there are a lot fewer around, since we haven't been training so many pilots for wars, and becoming a commercial airline pilot isn't as glamorous as it once was. Maybe in other countries with lower certification barriers, they could spearhead the use of ruggedized PDA tech and mesh network tech to accomplish a lot of cool stuff on the cheap.
I think one of the main reasons why there's so little 'improvement' in these things, is that they're very wary of using newer (and possibly less robust, less reliable) technology.
Similar to the fact that NASA is still using CPUs from 20 years ago, since they all have a proven track record, are resilient under stress, less prone to external influences, etc.
However I do think that newer technology used in parallel with the current existing hardware would in the end give us proof whether it's as reliable, more reliable, as useful, more useful, etc.
Durability, stress conditions, hostile external conditions and all those play a large role. The more complex systems become, the more unreliable generally as well. In this case, I'd go for KISS instead of newfangled stuff.
But even then, 50 years is quite a lot :)
Coz eternity my friend, is a long *ing time.
Are you back? I've missed you...
What doesn't kill you only delays the inevitable
"Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before and it has always been due to human error."
-HAL 9000
But seriously, the actual source of most plane crashes is a combination of a lot of factors: mechanical problems, pilot error, management practices (such as overworking pilots to the point where they're more likely to commit a pilot error), weather, a certain amount of bad luck, poorly maintained airport facilities (particularly in foreign countries), and errors by air traffic controllers. There's tons of redundancy and other checks to make it hard for any one of these to cause a crash (even pilot error: there are alarms and such that make it much easier for the pilot to do the right thing).
I am officially gone from
Please don't mention "aviation" and "IT" in the same sentence. There is a HUGE difference between something that must work all the time, and something that must work most of the time.
It seems to occur surprisingly often that the black box cannot be found, because the tail (e.g.) cannot be found. I would leave the existing black boxes in place and add a large number of very small additional devices: just a flash chip in a styrofoam ball. With a bunch of 'em, the chance of finding at least one would be significantly improved. It may be easier to get accepted a system that only adds redundancy, since it can't be less effective than the already-approved one.
Actually politics goes a long way to impede real progress in equipment design... The cockpit door being the most blatant of all of them.
For justice, we must go to Don Corleone
Seems like the author answers a lot of their own question. This post just feels like a rant from someone in the industry with a half-assed question tacked on the end, what gives?
held back by a combination of aircraft manufacturers, pilots unions and the slow gears of government bureaucracy
Does the article support the notion of the pilots unions fighting against modernization of flight recorders? No, it doesn't. Does common sense support such a notion? No, it doesn't either.
Really, this is not a place for union bashing. If you have an axe to grind, so be it. But don't try to wield your axe at every conceived opportunity, or you'll end up making yourself look silly - as you just did.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
According to a TV show I watched on the subject some a while back, British Airways have been taking live telemetry from their planes for years.
Pilot unions have objected to the collection and sharing of detailed accident data, citing privacy concerns of the flight crew.
I wasn't aware any reasonable expectation of privacy existed while working on a 4-8 person crew serving a couple hundred people in a space the size of a double-wide mobile home. Not to mention, just what other profession entitles you to privacy while at work, especially the sort of work where owners and direct supervisors are almost never in the same time zone as a given employee? They apparently feel entitled to privacy in a case where privacy would mean no oversight whatsoever.
Just have the darned black box broadcast all of its data once every millisecond. Put receivers on satellites and on grounds stations or even on other planes. Give the transmitter a range of several thousand miles, and come up with some scheme to avoid broadcast collisions (either time or code division multiplexing).
If a plane goes down go back to the recorded transmissions, of which there should be multiple copies.
Call me crazy, but data duplication might help in some way; particularly off site backups when a signal is available, coupled with multiple storage points on the aircraft itself.
https://www.eff.org/https-everywhere
If you stoop to RTFA you'll see there's a lot of sensible stuff in it, with the two main points being: flight data recorders record a limited (25h) sliding window of data, and that you have to go and fine them and sometimes this isn't possible. Both those make crash investigations harder than they might be, and delay the results. If you could get results more quickly and reliably, that'd obviously be a good thing.
The author doesn't suggest a sudden wholesale replacement of black boxes, but a supplementary mechanism for also transmitting data in real time. That data could be aggregated and mined without waiting for a crash to occur, potentially providing a much richer source of information about aircraft behaviors in both normal and abnormal operation.
He confuses the point a bit in some of his summary sentences by implying that he *is* talking about a prompt wholesale replacement of black boxes.
Well, to be fair modern aircraft have some silly things.
Take the ERJ-140 (regional jet) - turn on bleed air from either or both turbines without shutting off and disconnecting the APU bleed, and the APU will explode, shooting the compressor component of it straight out the tail of the Jet.
It (alone, anyways) won't crash the plane, but this is a simple as pushing a button before turning a knob... and the knob is surrounded by the buttons. Watch your fingers, eh?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
I've missed your melodramatic summaries. Welcome back!
Passengers are represented by unions?
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Sure... "lost" under the wreckage of the World Trade Center. Uh huh.
"He who can destroy a thing, controls a thing." --Paul Atreides, Dune
Really? Air France Flight 447 just falling apart in the sky going 537 mph at 35,000 is from a human failure? US Airways Flight 1549? Emirates Flight 407?
No, humans aren't the cause of all crashes, a chunk of them yes, but not close to "pretty much always".
Checking that out and looking up the causes of the accidents you'll see human error by the flight crew is a cause of some, but mechanical failure is a larger cause of accidents.
http://en.wikipedia.org/wiki/Category:Aviation_accidents_and_incidents_in_2009
And yes, I do have my pilot's license.
Given that "Cloud Computing" as a buzzword is only about two years old, and has yet to receive a great deal of commercial deployment, I think we can hardly blame the FAA, NTSB, Boeing, Airbus, and airlines for not deploying it Right The Heck Now.
What does that even mean, to use "Cloud Computing" for the "black box"? Cloud Computing has about as coherent of a definition as the previous buzzword du jour, "Web 2.0".
SirWired
A lot of technology in Avionics, for decades, has been stagnant. It might not seem so when we grovel over a F22 Raptor or the Russian PAK FA fighter. Not to belittle the development of these crafts, really it's the vector thrust that primarily puts them in their league. Much of the planes are the same as much older planes going as far back as the 60s. For example, MIL-STD 1553B is on that F22 Raptor and it probably has TADIL support and maybe even JTIDS if it's really 'bleeding edge'. MIL-STD 1553B is 1978, and despite it's problems and the fact it's a bus architecture, it's not going away and will be in use for decades to come in the field of avionics. Yes, there's 1553C and 1773 (1553 over fiber), but the only people using those are test labs; problem is, none of the terminals support anything but 1553B. Serial communications on those planes are far better than consumer serial, but they are too old and really just inconvenient for the consumer as to why they never took off (RS-539, RS-422 real RS-232 25pin Synchronous and Async when able). This is just the tactical communications technologies for the planes; airframe requirements pretty much lock those down to mere allowances for aesthetics more than anything else.
Why is this? Well, all the old technologies given to us by the forefathers of avionics works. Every piece of that plane is certified, making changes or deviations from those requirements astronomically expensive. For example, most terminals used in avionics are unique and rare items which also make them very expensive... 20 million USD for one that is operational; despite it's age. For any avionics system coming onto the market that claims to support any of the standards, a government program office has to allocate millions of dollars just in routine test procedures to be sure your component does nothing more or nothing less than what is precisely expected for any given scenario (this also means your machine has to mimic known bugs; if it doesn't then someone might develop a component that crutches it self against your "fix" and the end result a 747 crashes killing 243 people on board).
And that is the main reason technology in avionics moves so slow, just as it does slowly in every other critical field like medicine or cryptography (Lots of hospitals still rely heavily on old obsolete HP PA-RISC VME technology). (Yeah I know, your iPhone can crunch keys better than those ugly government doodads; but the iPhone isn't certified to handle it, and it's uncertain it will work every time in all conditions. That ugly government device will work, and provide the exact result, every time; rain or shine.)
Then we have people who have no idea what it's like to clean up passenger plane wreck, who think their simple uncertified and untested .99 cent iPhone locator software may some how locate a blackbox underneath a mile of water... no emitter can transmit through that much mass; there is no GPS locator that can locate a blackbox in the ocean that deep. That much salt water density, you'd have to be touching it with RFID. GPS locator technology is from the avionics industry... decades later... mind you. There's no technology the consumer uses that would help them find these black boxes more. Most of consumer technology is scraps from government/military technology after it's been used and abused, the private sector isn't creating anything fundamentally new. I know that hurts, but it's the truth, virtually all the R&D is on the governments dime.
Umm, no. You're almost a century out of touch with reality. What you say was true in 1930s.
Today, when an airplane crashes, the human has failed. Pretty much always. Technical issues that lead to crashes are very, very rare. If you were to place monetary bets, a winning strategy is to bet for human failure.
I believe this assertion to be true, but do not have data to support it. I'm certain the data exist, though.
However, there have been some recent mechanical failures that were very important to understand because of the wide-spread safety implications. I'm thinking mostly of the problem with lubrication of the horizontal stabilizer lead screw on MD83 aircraft from 10 years ago that resulted in at least one crash and the grounding of the fleet (and, now that I've reviewed the incident on Wikipedia, it also resulted in a revision of Alaska Airline's maintenance schedule).
While it would seem that most errors are pilot errors, we still need to pay attention to the mechanical ones.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
There is nothing technically preventing this. It's already being done. GE Aviation engines can be fitted with technology to report, in real time, the behavior of engines on a plane while it is still in the air.
It wouldn't be a stretch to extend the telemetry to other plane systems.
http://www.geae.com/services/information/diagnostics/tier.html
Not necessarily, An aircraft can do a lot of lurching which will destabilise the satellite antenna without risking the aircraft. But if a flight control snaps after several minutes of lurching, you will not know without on-board data storage.
Consciousness is an illusion caused by an excess of self consciousness.
Where are you going to get all the satellite bandwidth for this? Hell the agency with the biggest budget and most expensive planes, the United States Department of Defense, doesn't do this with their combat or transport aircraft.
For the 40-odd UAV orbits they are nearly tapped out for satellite bandwidth.
If they aren't now, give them 10 more years. ;)
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
I agree wholeheartedly. But still the human usually fails -- not always the pilot. Of course you need to draw a line somewhere, lest you classify, say structural engineering failures as human errors too. When we reduce controlled flights into terrain (CFITs) by an order of magnitude or two, then I can come back to revise my skewed worldview ;)
A successful API design takes a mixture of software design and pedagogy.
You're almost a century out of touch with reality. What you say was true in 1930s.
Today, when an airplane crashes, the human has failed. Pretty much always.
In a few cases in recent years (probably including the AF447 crash) the plane has been flying along on autopilot until the autopilot runs into something that it can't manage to fly through, and then it shuts down and dumps the problem on the pilots. In some cases they can handle weather that's too turbulent for a computer, in others they crash. Is that a 'human problem' or a programming problem or a 'flying into weather that we wouldn't try to fly through manually but we have an autopilot so that's OK' problem?
"Recommendations by the NTSB to the FAA have gone unheeded for many years. With all of the technological advancements that we work with in the IT field, what sort of best practices could be brought forward in transit safety?"
Answer: None. You're asking a bunch of people who presumably have IT experience to play armchair engineer and second guess the designers of embedded systems that are designed not only to record data on aircraft controls, time, and position, but to permit recovery of that data if the aircraft explodes, burns, falls into 2000 feet of water, then sits for a week. It's apples and oranges. Despite the fact that it seems like IT has rapidly advanced technology and the flight recorder tech is far behind, it's only a perception.
The true answer to "How could flight recorder tech be made better?" is both obvious and deceptive. It's easy for us to say things like "record all the controls, temperature, position of people, cockpit video, etc and live uplink it to the internet" and on the face of it have that seem like a good idea.
But probably very few of us here have experience or knowledge with the type of data that is useful in an accident investigation. Would cockpit video be more useful than audio? Other than allowing us to view people about to die or crash, it might not give us new information. It might be more useful to track flight controls and engine efficiency, or weather conditions, or the attitude of the flight attendants.
What problem are we trying to solve here? Just because technology can be "upgraded" doesn't mean it should be. Remember, if all you have is a hammer, everything looks like a nail. If all you are expert in is IT technology....
WTF didn't they put an interlock of some sort? FAIL.
A successful API design takes a mixture of software design and pedagogy.
There are good technical reasons why FDR data doesn't make sense to upload raw data automatically.
The pure FDR data is sampled at a high data rate, which varies according to model of FDR. The most modern systems also collect hundreds of data points at a time. This is discussed in the article, though I'd challenge some of their bandwidth calculations... the sample rates they quote seem very low (for modern systems), though I don't have my books in front of me.
What DOES make sense (and again, the article does address this), is having computing capability in the FDR (or outside of it, as it wouldn't need to be crash-worthy) that filters the data and ID's in real-time out-of-normal events and reports them.
In fact, most airlines already use a system like this, but not for the purpose of crash monitoring, but to detect aircraft problems in flight and alert ground crew so they can they can be prepared to fix them before the pilots even know there was a problem.
The issue is that this uplink capability can't replace the on-board FDR recording capability. That black box must still be there, as during the crash sequence, there is a good chance your satcom/etc systems will fail before the final crash. So this can augment, but not replace.
They also discuss adding a capability to comb through the complete raw data (you can just download it on landing as another route). Yep, great idea, but already being done by many airlines.
See http://www.boeing.com/commercial/aviationservices/brochures/Airplane_Health_Management.pdf
And in fact, the military is using the FDR data to check their pilot's proficiency as well as the aircraft performance:
See http://www.navair.navy.mil/PMA209/_Documents/MFOQA_101_20090224.ppt
That list is woefully incomplete. The complete list for the FAA only: (http://www.faa.gov/data_research/accident_incident) has more than twice the number of incidents as listed on wikipedia for the world.
Please don't twist my words. I don't claim there are no non-human-factor caused crashes, I just claim that a vast majority is human factors, and mostly cockpit human factors at that.
AF447 is, to the best of my knowledge, a case of the pilots getting confused by a single point of failure in the air data instrumentation. If you look around, you will find posts by pilots who faced similar issues, had similar ACARS messages sent out, and they recovered without problems as long as they followed procedures. Surely it did fall apart in the sky, but it didn't "just" fall apart, at least there is no reason to think this way so far. To me, that's not unlike China Air 006 but with a different ending.
USAIR 1549, the famous Hudson water landing -- well duh, it was not a human nor a mechanical problem. Force majeure. One example of it, so what.
Emirates 407 -- well thank you, because that was a classic case of human error. Funny coincidence of you mentioning it -- just see yesterday's TDWTF story about Command 696. ;)
A successful API design takes a mixture of software design and pedagogy.
How about the lesson, "Never save data that can only serve to get you sued out of existance if something bad happens".
Until there's tort reform in the USA to bring us in line with countries like Germany, this data will never be captured or saved.
Most of the data needed for accident investigations could be transmitted in real time for logging on the ground, the only need for a "black box" would be to cover periods where communication is lost - like in the last few minutes of a catastrophe. Like everyone, flight crews object to having every moment of their work day subjected to surveillance by their employers - hence their objection to transmitting flight data and crew conversations for recording on the ground.
The flight crew union objections could be overcome by having the data encrypted and logged in a system run by an international agency which alone has the keys to decrypt the data. The data could only be accessed when an accident report is filed which meets the agency's criteria. The agency would really only need to log a few days of telemetry, since accidents are invariably known immediately. Whenever a preliminary report is filed the relevant data would be preserved (but not necessarily released) until the matter is resolved.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
"For the past fifty years the technology behind aircraft flight data recorders has remained stagnant.
There's been enormous progress in flight recorders. The first ones only recorded a few basic items, like altitude, airspeed, attitude, and control positions. The recording mechanism used a stainless steel tape, on which diamond points scratched graph lines. (Those were really rugged. That stainless steel tape could survive almost anything and still be read.)
Today's recorders are (inevitably) digital, recording perhaps a hundred parameters. Most key engine and airframe data is logged. They also record both what the pilot's control positions are and what the aircraft control surfaces are doing, which allows distinguishing between pilot error and control failure. There's a separate cockpit voice recorder. Enough data is recorded that the data can be loaded into an aircraft simulator and played back to reproduce the events.
Few flight recorders are not recovered. In the last 10 years, there have been four failures to recover a flight recorder - two from 9/11, Air France Flight 447, and Siberia Airlines 1812. Of those, only Air France 447 is still a mystery in which flight recorder data would be useful. And, in fact, Air France 447 was "phoning home", over a low-bandwidth maintenance link, reporting trouble with the air data sensors.
So there's an argument for sending more data back on the maintenance links, but this does not involve "the cloud".
I agree that everything with safety implications should be subject of scrutiny. It's just that human factors are very widely misunderstood. You have mechanics who can inspect any flying hardware, but good luck finding a "mechanic" who can examine a pilot to determine if he/she is fit for flying that day.
A successful API design takes a mixture of software design and pedagogy.
The ATSB investigation found that an incorrect flex temp was applied, based on an incorrectly entered aircraft weight. This resulted in a lower than necessary engine thrust and consequently insufficient acceleration and airspeed.
On the others, I will agree with you.
1. The pilots must be trained how to specifically deal with taking over a system with unknown state.
2. Since #1 is prone to all sorts of problems, it's better to avoid. Thus pilots must be trained to oversee and keep current their mental image of the aircraft's status.
3. Since #2 breaks down, #1 is still important.
IIRC, in AF447 there were strong indications that the air data system was failing. A known problem. I think that weather only added to the airframe stresses, but primarily the pilots overstressed it.
Methinks that pilots need to be routinely reviewing airworthiness directives and similar documents, even foreign ones if they understand the language. Yes, I know, the poor chaps and gals barely have time enough to rest... At least that would give them a chance of thinking "hey, what if that's this problem".
In high stress situations, you don't have much in the leeway to think of unlikely scenarios like total failure of air data. Yet total air data system failures routinely seem to kill people :(
A successful API design takes a mixture of software design and pedagogy.
That's why they have the term CFIT, "Controlled Flight Into Terrain".
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
Really? Air France Flight 447 just falling apart in the sky going 537 mph at 35,000 is from a human failure? US Airways Flight 1549? Emirates Flight 407?
No, humans aren't the cause of all crashes, a chunk of them yes, but not close to "pretty much always".
Checking that out and looking up the causes of the accidents you'll see human error by the flight crew is a cause of some, but mechanical failure is a larger cause of accidents.
http://en.wikipedia.org/wiki/Category:Aviation_accidents_and_incidents_in_2009
And yes, I do have my pilot's license.
The breakup of AF 447 could very well have been pilot error. As a pilot, you are certainly aware of what your maximum entry speed into turbulence is for the aircraft you are flying.
Flying into a thunderstorm resulting in mechanical failure *is* the fault of the pilot.
The link I posted was for 2009, that link goes back to 2006.
Next week on slashdot, the aircraft that can post to twitter, and update it's own facebook status.
Air France 447 is now friends with Atlantic Ocean
Status: Crashed
You're absolutely correct about redundancy. There's a long chain of things that is supposed to happen before any flight. Here's what has to happen before I fly my little rental Cessna 172:
That isn't even all of it, and the list is more complete for a plane that actually has a black box. There are other things that happen along the way that aren't part of official checklists, including brake checks, validating compass and heading indicator accuracy, using the radio, and just paying attention for anything that doesn't feel right. There are checklists for take-off, climb, leveling, descent, landing, post-landing, and shut-down, not to mention all the emergency checklists. I've got a stall warning horn as well that is a function of the aerodynamics of the plane, and the autopilot lets me know if it's disabled. I fly a G1000 version of the C172 with two big displays, and it's got even more alerts, both visual and audio, to let me know when something is amiss, including when traffic is close (gotta love TCAS). I usually fly with flight following anyway, so ATC can help me avoid other planes (and vice versa). I'm still always on the lookout for other traffic, though.
If something goes wrong, it's almost certainly my fault that I didn't notice something, planned poorly, or flew beyond my skills (pilot error), with a small chance that the A&P and/or IA missed something (still human error), a very, very tiny chance that there was a mechanical issue that was not addressable with inspections, and an almost infinitesimal chance of simple bad luck.
You can never go home again... but I guess you can shop there.
I think they're including failure by the maintenance staff, airplane manufacturer, etc as human error.
Airlines are chronically unable to make profit, Aircraft manufacturers and suppliers don't do anything for free. This would have to be a government mandated system to ever be realized. Aviation is very safe in general and this is not the best place for governments to invest if the goal is to save the most lives per dollar spent.
I would love to see this (on the ground, of course). :)
You can never go home again... but I guess you can shop there.
Privacy concerns? Im sorry but if you are part of the operating crew of a modern airliner, the only privacy you should expect is in the bathroom.
Good-bye
You're crazy. We cannot even build automatic cars and you want computer-controlled planes? That just cannot work -- maybe for regular flight, but when anything out of the ordinary happens I very much prefer a human to be in control.
(+1, Disagree)
And, yes, pilot privacy is a concern because certain well-known air crashes have involved the airline and/or even government falsifying data to put the blame on the pilots (cue fingers wagged at France).
One of the, if not THE, most common causes of aircraft crashes issued by the National Transportation Safety Board is "pilot error". But, there's a reason for that. There's a lot that can go wrong in an airplane, and we're trained to do things about almost all of them (having a piece of FOD penetrate your delta-wing fuel tank on takeoff and essentially render your plane a molotov cocktail looking for a place to die excluded). When a private pilot ignores worsening weather and meets cumulo-granite, that's pilot error. Continued flight into known icing conditions, ditto. Running out of fuel, yep, same thing. Now, two out out of three of those are little-airplane-related, and the third often is, but running out ouf fuel has happened to the big-iron drivers, too, and they didn't admit it to get priority or emergency handling from air traffic control. By the same token, sometimes, pilots are required by COMPANY regulations to do things a particular way, and that comes out as "pilot error" too. And that is something that should be exposed to scrutiny. But, by the letter of the law, anything that happens on a flight is the responsibility of the senior pilot on the aircraft. There's a lot more that goes into Pilot In Command structure, too, but that's for another post.
Never ascribe to malice that which can adequately be explained by tenure.
That's basically a list of incidents that made the news. It doesn't include many of the GA incidents that make up the overwhelming majority of accidents, where almost 90% of accidents have pilot error as at least a contributing factor. GA pilots must be aware they they are far more likely to be the cause of an accident than is the plane.
And yes, I do have my pilot's license, too.
You can never go home again... but I guess you can shop there.
TWA Flight 800's official cause of the crash was the fuel tank spontaneously exploding, I can't think of a way the pilot could have caused that one either.
TWA800 - fuel tank exploded.
Rudder goes opposite control input- http://en.wikipedia.org/wiki/Boeing_737_rudder_issues - many crashes
AF 447 - likely due to pitot ice
So, if it is money the odds are the pilot, but it is hardly unheard of for a plane to fail.
Or ground crew.
GA is a different world, they don't have 50 million dollars of avionics and computers to fly for them.
I'm in Alaska so we have GA accidents all the time and some military (the C-17 and Blackhawk near Palmer), those GA accidents are almost always weather or pilot error.
But since the black box talk isn't going to apply to GA or military, I didn't bring small planes into this.
But I agree with you 100%.
What makes you think that flight 447 fell apart in the sky? Reports I read suggest that the crash investigators believe the plane was in tact and flying in a normal attitude when it hit the water: http://www.dailymail.co.uk/news/article-1282367/Air-France-crash-The-truth-disaster-killed-228-people.html
Even the wiki article suggests the reason for the crash is still unknown but the following facts are known:
The current working theory is that a thunderstorm in the area reached as high as 50,000 feet and could have disrupted the plane. Normally a pilot would fly around such a system but a smaller storm in front might have obscured the thunder storm from the flight's radar system and the crew didn't see it.
I find it unsettling how obsolete technologies are left in place in rail and air transport.
Modern airliners are really, really safe. Whenever there's a crash, there's almost certainly multiple unrelated problems. Therefore, there's almost certainly human error. There's also, almost certainly, at least one technical issue.
If you're only going to blame the crash on one thing, you can ignore the technical failures and pin it on the humans if you like. This has the advantage of annoying fewer living people: the pilots et al. are frequently not around to dispute anything, while there's plenty of people who worked hard on that equipment and don't want it blamed.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
And, yes, pilot privacy is a concern because certain well-known air crashes have involved the airline and/or even government falsifying data to put the blame on the pilots (cue fingers wagged at France).
In which case a mismatch between the data transmitted during flight and the data recorded in the black box could be cited as evidence.
There is, but when it fails, it allows the action. It's also not obvious when it's failed (no indicator or anything)
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Look at the programming language Ada, and its intended and actual use:
Ada is strongly typed and compilers are validated for reliability in mission-critical applications, such as avionics software.
We don't need pilots to fly planes normally. We need pilots to fly planes when something goes wrong.
The FAA needs to mandate the integration of peer-to-peer ecologies utilizing embedded synergies that create semantic communities and syndicate social mashups as well as capture rich-client dynamic APIs with aggregated long-tail feeds.
Web 2.0 bullshit generators are fun!
Coding with assembly is like playing with Legos. Coding an application in assembly is like building a car with Legos.
Today, when an airplane crashes, the human has failed. Pretty much always.
Blaming a failure on human cause is by far the easiest way to avoid having to fix anything. It also happens to be wrong in by far most cases, as when you look a little deeper you will almost always find issues such as lack of proper training, lack of sleep, horrible UI design, lack of warning signals, lack of communication and plenty of other issues. None of which are in the control of the human that is flying the plane.
Humans simply make mistakes and any robust systems has to be designed in such a way to handle those small mistakes, if it can't, it is the system that is at fault, not the human.
Yeah, its hideously expensive because its extremely rigorous. Otherwise people die in a giant fireball. Would you fly in something if the builders just said, "meh, good 'nuff"?
I haven't flown much recently but most of the flying I have done in the past was in planes that to me seemed somewhat out of date. There are a lot of old planes in the air, many of which need to be retired from service. I can only assume that the data recorders are of the same vintage as the planes in which they are installed.
http://www.acetonestudio.com
The biggest impediments are in the huge difficulties to get any new technology past the certification process and the cost of insuring against liability. (The liability issues around general aviation were ameliorated somewhat about 10-15 years ago with the passage of a law limiting the 'long tail' liability for older planes.)
My personal case in point - when I was taking flying lessons a long time ago, you could buy a brand new CB radio for about $50. An airplane VHF radio with not-that-much-different capabilities cost over $2000 at the time, had lousy audio and relatively poor reception compared to the CB radio.
The airplane radio had to pass both FCC and FAA (and, I think a couple of other institutions) certifications, each of which cost the manufacturer over $1 million for re-certification every time they wanted to change a resistor. Each of the parts had to go through the same process, which generally took several years. So the aviation radio was built out of ten-year-old parts using 8 year old designs, and the cost of each improvement had to be amortized over a few thousand units - so just getting certified can cost 1/4 to 1/3 of the cost of the part.
And the radios still suck.
Then, liability insurance was also about 1/3 of the retail cost of the radio. At that time if a private plane crashed, everyone within a mile of the crash sued the manufacturer of every component that had ever been on the plane. Still today, if a company makes a part that is on a commercial airplane, they are likely to get sued if the plane crashes, even if their part had nothing to do with anything, and their liability is essentially unlimited.
In one example I knew about (about 1985), a guy forgot to put fuel in his plane, took off and crashed into a house about 1/4 mile from the runway. One of the companies that was sued was the maker of the original OEM starters for that brand of airplane. They were sued for $millions. It cost them almost $5 million in legal fees to prove they were not at fault, even though their starter was not even on that plane - it had been replaced years before. They got out of the business, and never came back.
TOday we have the worst of possible worlds - the regulatory environment punishes innovation and makes it impossible for small companies to compete due to the infrastructure required to meet the regulatory requirements, and the liability environment stomps on them while they're down. So we have nothing but big monolithic industry giants with every incentive to not innovate, to not put the 'new thing' on. Boeing is being amazingly courageous in building the 787. They are betting the company not only on the marketability of the plane, but the potential liability.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
Good point, but... where I'm sitting at, yours, is a foreign country....
Atheism is a non-prophet organisation
Many years ago, my friend the airline mechanic took an interest in crash reports. He was suspicious that many 'pilot error' reports were misleading because he saw how the planes were maintained (badly). I wish there were time to tell some of his stories of neglect- sometimes tragic, sometimes comical (used condoms, panties & beer cans in the wing sections).
So at great cost in time and money he studied copies of the reports from each major crash. Sure enough the primary blame was put upon the defenseless dead pilots. After scouring the lengthy documents he was able to find indications of the real problems: equipment malfunctions. They were obliquely referred to, but they were there.
His theory was that the airlines, the manufacturers, the FAA and the entire industry had interests to protect. If the planes were revealed as defective or poorly maintained, they would lose millions. Always better to blame the pilot.
We may hope that maintenance is better now and that the true cause of crashes is being revealed. But do they have any incentive to reveal the truth?
...omphaloskepsis often...
The kinds of foreign countries I'm talking about are places where the latest and greatest ATC technology hasn't gotten there yet. Europe and Canada are generally pretty good, Burma not so much.
I am officially gone from
How big a problem is this? The author proposes we build satellite uplinks in every commercial airframe, from corporate jets to airliners, that they stream a staggering amount of data through some new satellites to unbuilt ground stations to retain this data for post-mortum analysis... Does this author have any idea how many airframes there are? Any idea what such a retrofit would cost per-plane? What the estimated downtime would be to retrofit this hardware into a thirty year old airframe? And, the big question, how long would it take to design, build, and certify just such an uplink - with, of course, SIX NINES uptime?
The only real problem the author seems to have is that tape isn't "cool" and other, cooler, options exist.
And let's not forget that 99.999% of information captured will never be needed, since the plane didn't have an "event".
Don't forget, the signal needs to be jam-proof, and has to work in any possible weather conditions - if it can't work in a storm, what is it's value?
Ken
Pitot ice is not an issue in cruise, as long as you recognize it as such. You look up a table or a nomogram in the aircraft manual, where the inputs are loading, altitude and maybe temperature, and the output is a throttle setting. Unless the aircraft is structurally damaged or iced, you'll fly within 10-20 knots of what you want. Heck, there is a first-hand account somewhere of doing just that by a pilot who flew same equipment, and lost air data. Of course if you get confused and try funky things, you're in for a world of hurt.
A successful API design takes a mixture of software design and pedagogy.
I don't say that if a human has failed, it is only his/her fault.
A successful API design takes a mixture of software design and pedagogy.
I didn't see if someone already mentioned this or not, but one thing to consider is that airplanes are incredibly expensive to purchase and operate, aircraft over 20-30years of age are still in heavy use. Not only do airlines have to keep up with routine maintenance and breakdowns but they also receive service bulletins from manufacturers and the FAA to replace/inspect their equipment frequently. Especially in the past 10-15 years airlines have been struggling with price wars, 9/11 and the economy in general. From a pure cost standpoint the industry wouldn't want upgrade their CVR's. They have plenty of other things that money could be spent on to increase performance/safety of airline travel. Take a look at navigation systems on aircraft. The point is CVR's provide a "decent" amount of information when there is an accident, the cost/safety gain is just not worth the investment for an already battered industry. As new aircraft are put in service CVR's will improve...airplanes have a long lifespan no one should be surprised 30 year old equipment is out of date.
The inventor of the black box flight recorder, David Warren, died recently. http://www.theaustralian.com.au/business/aviation/black-box-inventor-david-warren-dies-at-85/story-e6frg95x-1225895120709 David said in his talks that The RAAF went as far as to note that “such a device is not required the recorder would yield more expletives than explanations”. Live telemetry of aeroplane data could help revive this objection.
http://en.wikipedia.org/wiki/Pitot-static_system#Pitot-static_errors
blocked pitot tube will cause the airspeed indicator to register an increase in airspeed when the aircraft climbs, even though indicated airspeed is constant.
I could see this leading to a stall in short order depending on which instrument you are believing at the time.
I am looking forward to the recovery of the recorders from AF 447.
Passengers are represented by unions?
Not exactly a union, but this isn't that far off.
And rail passengers have been known to "strike" before -- by refusing to buy a ticket on a certain day in that case.
The inertial reference + GPS augmentation is there for a reason. Even in VFR, it's good airmanship to periodically verify that the artificial horizon matches up with real horizon. If you're over water or desert, then even in VFR I'd tend to trust artificial horizon first.
If you lost air data, then in cruise you can periodically do a full turn, and use the ground track to estimate wind vector (speed+direction), and your true airspeed. Of course things get trickier when you're trying to land. Even then if you get mean wind speed and direction from local weather report, you can figure out an offset to ground track speed to get back airspeed. Ideally you'd chose an airfield where you can do a long straight-in approach to a looong runway. Then you err on coming in fast, and hope there's enough runway to stop ;)
A successful API design takes a mixture of software design and pedagogy.
Blaming a failure on human cause is by far the easiest way to avoid having to fix anything. It also happens to be wrong in by far most cases, as when you look a little deeper you will almost always find issues such as lack of proper training,
Human failure
lack of sleep
Human failure
horrible UI design
Human failure on the part of the UI designer
lack of warning signals
A subsection of poor UI design therefore human falure
lack of communication
Human failure.
None of which are in the control of the human that is flying the plane.
Nobody said human failure = pilot error - except you.
Humans simply make mistakes and any robust systems has to be designed in such a way to handle those small mistakes, if it can't, it is the system that is at fault, not the human.
Who designed the system - humans.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I am part of the FLYHT, AeroMechanical Services Ltd. team and we have a data streaming product called FLYHTStream. This product is provided to our customers who use our combined airborne and ground systems to improve efficiencies, save money, track assets and reduce lost time due to maintenance or operational items requiring attention. FLYHTStream transmits the Flight Data Recorder (“FDR”) data in near-real time over the Iridium satellite network and can be triggered from the ground, by the pilot or automatically by our system installed on the aircraft. Our system works in conjunction with the black box. It is our hope that FLYHTStream will be used by airlines to analyze data during incidents by opening the lines of communication with the ground and giving the crew extra support to identify the problem as it is happening and help solve it. There have been concerns about the cost of the streaming and bandwidth, but the FLYHT solution makes that a non-issue as our system starts streaming based on a pre-identified set of triggers, it does not run through the whole flight. So the streaming only runs as the incident is happening and if it is a bonafied emergency situation and the customer is using our other cost saving tools, we do not charge for this service. We have demonstrated FLYHTStream as part of the BEA working group, Bureau d'Enquêtes et d'Analyses, the group that is investigating the AF 447 crash. There have been a number of articles about data streaming in the media recently and I have included one such link if you are interested. September 1, 2010: http://www.wired.com/autopia/2010/09/aviation-thinks-outside-black-box/