With every new plane crash, it seems like clockwork that people start calling for “real time data monitoring” or “real time FDR/CVR streaming”. This discussion is nothing new. It was common when I started working with flight data more than 15 years ago and my mentors were hearing of it for years before I entered the industry. After reviewing a few comments on social media, I decided to write this article, not so that I can spread my personal opinion on the subject, but rather to try to provide some technical (and other) considerations for those that choose to join the discussions. As someone with considerable experience in flight data recorder analysis, I find it frustrating to see some of the comments being made on social media by people that are no doubt knowledgeable in their respective fields of expertise, but are not knowledgeable on flight data recorders. In order to look at some of the technical challenges associated with transmitting flight data in real time, we need to look at how a typical modern flight data recorder works and do a bit of math. As I started writing this article, I did a quick check of Flightradar24.com and found that there were about 13,000 aircraft in the air globally at 1000 EDT on a Monday morning. These are transport aircraft and do not include military or general aviation aircraft (for the most part). So for the purposes of our discussions, this should be a reasonable representation of the aircraft that would require “real time” data streaming. But don’t worry – even if you think this number is too large, we get into some conservative estimates below. Of those 13,000 aircraft, let’s assume that the average FDR data frame size is 128 Words Per Second (WPS). If you want to learn what a data frame is and what “Words Per Second” means, check out our YouTube video (https://www.youtube.com/watch?v=NYvYlQme96g) as it is beyond the scope of this article. This assumption is likely very conservative as I would expect the average data frame size to be 256 WPS or more as more modern aircraft enter service, but let’s work with 128 for this exercise. A 128 WPS data frame receives and stores data at a rate of 192 bytes per second (128 WPS) * (12 bits/word) / (8 bits/byte). With 13,000 aircraft in the air, that represents 2,500 kB/s. That doesn’t sound too bad in today’s world of high speed internet. But we cannot transfer this data over your typical Wi-Fi network. To get global coverage, this needs to be a satellite enabled solution (at least, today it does). A quick search on Wikipedia shows that the Iridium network can handle transfer rates of 2.3 to 2.4 kb/s (https://en.wikipedia.org/wiki/Iridium_Communications). That’s kilo BITS per second. So that translates to around 300 Bytes/second. Inmarsat’s SwiftBroadband service allows for guaranteed service of up to 650 kb/s or 81 KB/s, but it does not offer coverage at the poles – something that cannot be overlooked with today’s polar routes. What is difficult to determine from online resources is the total bandwidth that these satellites can support (perhaps a satellite communications engineer reading this can shed some light), but at the very least, transmitting 2,500 kB/s (20,000 kb/s) of data to a satellite network (assuming it is even possible) is going to use up a considerable amount of the available bandwidth – at significant cost. Of course, there are ground stations along with data compression algorithms that might be able to pick up some of the slack, but that leaves a lot of slack that needs to be picked up. Not to mention, I still stand behind my initial statement that an average of 128 WPS data frame is likely very conservative. And we haven’t even begun to discuss the costs associated with this, assuming it is technically feasible. AND, we have not yet considered streaming the CVR audio yet. There are (normally) four separate channels that are recorded on each CVR. So we must now ask the satellite networks to effectively handle 4×13,000 = 52,000 “phone calls” at once (albeit one way), all while sending the above mentioned flight data. The challenges are not only technical, though. Like it or not, there are going to be political challenges with a globally distributed system such as this. Imagine a US registered aircraft flying a polar route over Northern Russia. Where does the data get stored? How does it get routed? How will operators from other nations feel about using the satellite system of another state to capture, transmit (and potentially store) flight data. We are asking a lot more than we currently are from a Global Positioning System. The issues are not just limited to bandwidth, either. The system needs to be incredibly robust. Imagine an aircraft inverted in poor weather in the South Pacific – the system will need to continue to transmit data and audio under such conditions. Significant flight testing will be involved. So what is the solution? I would rather ask the question, “what is the problem”? What problem does data streaming solve (assuming it’s technically feasible to implement)? If it can improve search and rescue efforts, then that is a huge advantage. But I am not sure that it will. In some of the recent accidents (excluding Malaysia Air 370), the aircraft positions immediately before the accidents were available on radar and ACARS messages were sent and received. So we have been receiving positional data (or data that could help determine position). I am not convinced real time data streaming would provide much benefit. It is also serious speculation to assume that it would have helped locate Malaysia Air 370. The two main reasons I think that the data streaming discussion surfaces are, first, that some people believe that the accident investigation community has a poor record of recovering flight data and cockpit voice recorders (they don’t – their record is quite exceptional – less than 20 globally since 1965). But secondly, and probably more likely, is that we live in an age where we want information now. We don’t like to wait. I will agree with these people somewhat in that it is in the interest of flight safety to get accurate and reliable information as quickly as possible, but I don’t think that streaming data is the solution (at least not yet). Perhaps, instead, improvements can be made to the Underwater Locater Beacon (ULB). This is a device that is triggered if a recorder comes into contact with water and is designed to “Ping” so that recovery personnel can locate it. Perhaps improvements can be made to increase their transmission strength to help reduce data recovery time. Alternatively, at least one company, DRS Technologies, has developed a “deployable” flight data recorder which is designed to separate from the aircraft in the event of a crash. This helps to keep the recorder out of any post crash fire and also allows for it to float on water until recovered. A plane crash is a very tragic, emotional event that always seems to get people talking about aviation – whether they are in the aviation industry or not. My heart certainly goes out to the friends and families of those lost or missing in these recent accidents. I realize this is no consolation, but we are getting safer and better as an industry. We need to continue that trend with frank, but educated discussions on practical methods we can employ to continue to make ours the safest method of transportation for years to come.

Consulting Services

Scaled Analytics has significant experience in the use of flight data for investigating aircraft incidents and accidents.

FDR Readouts

Sky Analyst FDR can simplify the process for completing your annual Flight Data Recorder (FDR) readout serviceability checks.

Aircraft Maintenance

Sky Analyst AOG is a cloud-based flight data analysis system that allows maintenance personnel to troubleshoot aircraft issues.