Is it technically feasible for a flight data acquisition unit parametric feed, normally directed to the crash-survivable digital flight data recorder, to be also transmitted in real time?
Of course!
Flight Data Telemetry
The following links provide background on flight data recording:
wps word per second
bpw bits per word (12 bits in one word in ARINC 717)
bps bits per second
Bbs Bytes per second (8 bits in a Byte)
MB MegaByte (1,000,000 Bytes)
kbps kilo bits per second (1000 bits)
kBps kilo Bytes per second
GB Giga Byte (1,000,000,000 Bytes)
For the sake of this discussion, I will assume the ARINC 717 standard 512 words per second, each word being 12 bits.
512 wps x 12 bpw = 6144 bps = 768 Bps = 2.7 MB per hour,
6-44 MB per flight cycle.
Data rate is just over 6 kbps
360 operational hours per month (block time) = 1 GB per month
I presume the data is reasonably compact, but it might be possible to accumulate data and send it in larger packages, that could be squeezed, albeit you need to catch up if something goes wrong.
In general, the approach has been for crash survivable recording to have mandatory data parameters most valuable to crash investigators. Without knowing in advance what is going to fail, the mandatory data parameters offer the greatest chance to filter through each scenario with at least rudimentary clues. It will not tell you exactly what broke, but it should tell you what isn't working and what happened as a result.
Other systems, notably Aircraft Condition Monitoring System (ACMS), offer the operator access to parameters from a catalog, based on programmable event triggers that can/could be re-programmed remotely. ACMS offers a much more surgical approach to data collection that is based somewhat on understanding what you are looking for.
ARINC 717 describes an audio (bi-phase) recording interface capable of 2048 words per second, and ARINC 767 describes a Ethernet-based recording interface that has no practical limit. Reports from operators of Boeing 787 (the airplane) in particular are suggesting a flight could generate hundreds of MB.
What about audio recording?
I would assume four audio channels as a minimum. Each audio channel would be communicated in digital form, using three narrow band channels for voice/crew mic and one high band channel for an area mic.
3 bits x 8 kHz sampling = 24 kbps x 3 channels = 72 kbps
3 bits x 16 kHz sampling = 48 kbps
Total for voice recording is about 120 kbps (or about 54 MB per hour).
Audio telemetry would only be used under non-normal scenarios, never routinely.
Inflight Data Link
Iridium streaming rates are limited to 2400 bps which is inadequate for even just mandatory data parameter recording. Any use of Iridium would need to be a reduced parameter set or reduced recording rate.Recording data rates to crash survivable memory are driven somewhat by the length of the recording. Mandatory data parameter recording accumulates over a longer duration at a slower rate than audio recording, conversely over a shorter duration and at a much higher relative recording rate.
In the case of telemetry, the emphasis is more on the "here and now" and as such, I would expect that there might be some debate on the merits of audio transmissions (in the manner described), as audio transmissions would consume about 20 times the data rate as the mandatory data parameter transmissions.
If 126 kbps were available, both the mandatory data parameters and the mandatory voice and area audio inputs would be transmitted.
Inmarsat SwiftBroadBand products would have the throughput, even SB200, as could Ku/Ka satcom systems, and ATG (GoGo, LTE) terrestrial systems.
Cost is a factor, so it makes sense to control the telemetry feed based on triggered events, rather than sending blindly. Ideally, you would send all the data all the time.
Cash-flow sensitivity tends to diminish the value of cost-avoidance scenarios. Flight recording has real value, and catching a trend before it turns into a catastrophe is laudable. But under stressed finances, the justification for investing in equipment and monthly service charges is hard pressed to be compelling in light of tasks deemed more urgent, or directly tied to daily operation.
Cloudy Day Scenarios
Anyone can look up in the sky and enjoy the sunny day, and wish it would last forever. When everything is working well, things are simpler and predictable.Aviation catastrophe usually involves some distress to airplane systems, in unexpected combinations of failures and state. Power may fluctuate, equipment may end up in a power-up reset or trying to recover a radio log on, or worse, locked up all together. Navigation sensor and other input references may become unreliable or unavailable. Data buses may be interrupted or severed. Ships attitude may prevent line of sight communication, whether terrestrial or satellite. All of this can happen repeatedly. Sinister acts may interfere with system functionality, which introduces another dimension of pain.
Any contemplation of a telemetry solution
must account for the likely conditions
in assessing its ability to continue to operate as desired.
Flight Recorder background discussion at the following link
My assumption was to replicate the data feed going to the recorder, and in this case the voice recordings use a novel "relative" approach using just three bits. I think we might favor a more traditional voice and area mic coding algorithm, if using telemetry, that would inflate the data link demands above what I calculated.
The sad reality is that both AF447 and MH370 reveal that there is a very real cost to uncertainty and the unknown. As a society with unending curiosity, and with an industry fomenting to learn and prevent repeated failings, we can't be satisfied with not knowing. The costs for searching are substantial, both in real dollars and delayed corrective actions. Considering air transport alone, we have something around 15,000 tails. At $100,000,000 in search cost, we could have spent $6,000 for every tail.
Frankly, $6,000 isn't enough if you are asking to for new equipage. If we commit that budget to data link service charges using existing equipment, assuming we avoid a lost ship every five years, works out to about $3.28 a day.
A minimum service is aircraft tracking. Assume the tracking data provides assurances that the crash-survivable recorders are located. Assuming 12 hour flight day, works out to about $0.27 per hour for communicating position (or any telemetry you can squeeze in).
I would favor an event-driven system that sends bursts when needed (the quiet and dark philosophy), which could greatly increase the volume of data in real-time transmission.
Emirates is offering passengers up to 600 MB of Internet service for $1.
3 MB for DFDR and 54 MB for CVR cover one hour of flight data.
A ten hour flight would generate less than 600 MB. This, using Inmarsat SBB.
Let's be clear, a passenger's good will may be more tangible with a satisfying inflight experience, than the benefits from telemetry, which in the best of days bears no fruit.
Not long ago, I would have been surprised to hear of paying less than $0.50 for one MB. Now, apparently, with a breakage model, you can get up to six MB for one penny.
My basic presumption is aircraft location leads us to crash survivable recorders. A telemetry solution is appealing and feasible, but in the end, I am adamant that no radio system can provide the level of recording we expect in the DFDR and CVR. It's not a choice of either or. In that vein, we can leverage the aircraft recording equipment if only we can find it.
Connected recorders (such as ACMS) offer the ability to react to unexpected scenarios both using onboard processing and using remote commands. A telemetry solution can switch from routine to verbose mode if the ground senses unexpected routing or if the onboard sensor exceeds a threshold.
Safety investigators and human factors specialists have a difficult task in revealing cause from effect. We surely will benefit from increased awareness through higher reporting rates, more extensive and insightful data analysis, and greater sensory awareness, in particular using video.
Peter Lemme
peter@satcom.guru
Copyright 2015
All rights reserved
