FDR Readouts were traditionally done manually with an experienced flight data expert sifting over plots of data. This has evolved over the years as technology has improved, but the key to a quality FDR Readout remains the human analyst reviewing the data. We are starting to see a growing trend in the flight data analysis community, however, in which more and more vendors are offering “automatic” Flight Data Recorder (FDR) readout solutions. We are sometimes asked by customers if we plan to offer a similar service. While we have considered offering an automated FDR Readout option, we have decided against it in favor of the old fashioned way of using a combination of expert manual labor along with modern technology. Our position is that, no matter how advanced a system claims to be, you cannot (and should not) take the human out of the FDR Readout process. These automatic offerings were born from the idea that the automated software engines used to detect Flight Operations Quality Assurance (FOQA) or Flight Data Monitoring (FDM) events could be used, with a little bit of adjusting, to determine whether or not parameters recorded on an FDR are valid and then automatically generate an FDR Readout report. The idea is certainly not a bad one. FOQA/FDM event detection engines continue to evolve and are better than ever. At Scaled Analytics, we have one of the best in the business. But detecting FOQA/FDM events and trying to discern whether or not a parameter is valid are two different things with the latter leaning towards artificial intelligence. In the past, we have done some software configuration work for vendors that deliver these automated FDR Readout systems. In our experience, there are cases that are difficult or simply impossible to automate. The two types of failures in these automatic systems are false negatives, in which a valid parameter is flagged as invalid, and false positives, in which an invalid parameter is flagged as valid. The serious problem, of course, is a false positive. These are the ones that sneak through and you have no way of knowing that there is a problem until the FAA, or worse – the NTSB – is reviewing your flight data and FDR Readout reports and uncovers the problem. While it is true that many parameters are relatively easy to validate and are good candidates for an automatic FDR Readout, others really need to be validated by a human being. The biggest complaint that we received while doing configuration work for these types of systems was the number of false negatives. But, in order to flush out those false negatives by “tweaking” the detection algorithm, one would increase the risk of creating a false positive. Today we no longer do configuration work for such systems. Sometimes the error in the readout is not with the data itself but rather the parameter database documentation or the software load. Parameter values can be off by subtle factors that may seem valid to an automated system, but to someone with operational experience, they do not seem “quite right”. Some parameters, such as a trim command, could appear as erroneous data spikes in certain phases of flight. Discerning whether or not they are data spikes or normal operation of a trim switch should really be done by a qualified human being. Our team of analysts have over 90 years combined experience performing FDR Readout reports and we have run into more than a few cases where we would find errors in documentation, despite the fact that the data looked “pretty good but not quite right”. I will not go into all the examples of cases we found that we thought would be difficult to automate. Proponents of automated systems would likely retort with examples of how their system could be modified to handle that special case. But the real challenge is handling that special case that no one has discovered yet. We do not want any of our customers to be the first to discover them! So why are we bothering with these automated readouts anyway? There is certainly quite a bit of competition in the FDR Readout business and every vendor is looking for a competitive edge. Automating the process is definitely one way to reduce one’s costs as you remove the need to pay a highly skilled individual to perform the analysis. Reducing turnaround is also another competitive advantage and we can certainly respect that, but by utilizing a combination of modern technology and manual validation, we can produce quality, confidence instilling FDR Readout reports in half a day or less for urgent situations. Getting that time down to 15 minutes (for example) does not seem worth the price of uncertainty. Especially when the required time window for completion of an FDR Readout is rarely shorter than that of a C-Check. This post is certainly not meant to bash those vendors offering automated systems and services but rather to give operators a little bit of insight into some of the options available for FDR Readouts. In fact, we also employ a certain level of automation where possible in our own service. We understand that in today’s economy, there is a market for low cost offerings and we certainly cannot criticize those vendors that chose to cater to that market segment. At Scaled Analytics, however, our FDR Readout Service will continue to cater to those customers looking for a thorough, professional, high quality FDR Report, validated by an expert, at a very reasonable price. And we have no plans to change that model any time soon.
Sky Analyst FDR can simplify the process for completing your annual Flight Data Recorder (FDR) readout serviceability checks.