If a plane travels over mainland, it would be no problem to store data only on the black box, as it would be easy to recover in an accident. We would have to enable the satellite uplink only on planes crossing the oceans. I don't think that would generate that much of data.

Sounds like a job for some kind of distributed peer-to-peer (or is that air-to-air?) network. A bittorrent of the skies.

While crossing the ocean aircraft are generally out of easy contact with ground stations for hours at a time. They're using long-range HF radios or even the data-only CPDLC system.

Some comments I've in other discussions brought up plane-to-plane communications, but other craft aren't commonly close enough to have any relevant weather information to share. (I'd extrapolate to think you'd have similar issues reliably transmitting data.)

Some fascinating comments below this post by the way: http://www.weathergraphics.com/tim/af447/

Why does each plane have 88 data streams? Why 12 bytes per stream? Why 50 Hz? That's over 8 kilobits per update, 412 kbps.

With 16-bit precision, you can get 528 sensor updates for the same amount of bandwidth. Let's cut that in half (~250 sensors) and reduce the frequency to 30 Hz, then we've gone from 825 kbps to 274.5 kbps. Multiply by 8000 planes, that's 1.8 Gbps aggregate. With stream compression, a lot less.

Challenging? Sure. But I think even my restatement is too much data. Maybe send data less often if everything is within "normal operating parameters." I bet most sensors don't need 16 bits of precision, or to be updated even once per second. Cut my estimate to 10%, that's <30 kbps per plane, <200 Mbps total. Easy!

More than once per second (in fact, more than many times per second) means the difference between FOD ingress failure mode and, say, a spontaneous single blade failure in a turbine, between a synchro follower field inversion (think of a compass needle flipping around in an electromagnetic coil forcing the table it sits on to try to re-orient itself to the new reality) and a hard manual input, between externally-induced overtemp and a fire starting in the monitored system, not to mention vibration-induced momentary shorts playing all kinds of hell on both digital and analog control systems.

People really ought to try to grasp how quickly things can go wrong in the real world, and how difficult it can be to tell what made the nice shiny silver bird look like the crumpled foil discard of a cigarette pack smeared with a poorly-preserved meat jelly. You only have to see one used-to-be jet (complete with used-to-be pilot) before you start wondering how anyone could make sense of it -- and that's with the physical evidence in hand.

You only have to transmit data when something is wrong. You can use software to determine when to start sending updates.

Remind me not to hire you for anything mission-critical.

There certainly are cases with well-understood causes (e.g. birds flew into both engines to make them stop), but I guess there are cases that originally caused from combination of previously-unknown failure pattern; since the failure pattern understood enough to write a software to detect, it may likely be backed up by some fail-safe mechanism.

I don't know much about aircraft controlling software, so this is only a guess from my experience of general system software crash recovery; usually the hardest case is caused by something I've never imagined to happen.

You have to re-construct the flight before things go wrong to know when things went wrong. Maybe something you thought was right turned out to be an error given a different parameter. Kinda like debugging I guess.

When a plane is flying and not transmitting anything, is the reason that nothing's wrong, or that the system that sends updates when something goes wrong (possibly among others) is broken?

No. Part of failure analysis is understanding what led to the failure in the first place. If you only transmit when something goes wrong, you may end up knowing what went wrong, but not why And why is usually just as important.