(Note: This article was originally published on December 9, 2020).
In our Introduction to Flight Data Monitoring article, we took a high level look at what a Flight Data Monitoring or FOQA program is. Then we went into a little more detail looking at the modern recording options available on aircraft today. Now we will take a look at what what we actually do with the flight data recovered from the aircraft as part of routine monitoring and analysis.
Data Conversion
Once flight data is recovered from the aircraft, whether it is for an accident investigation or FDM/FOQA, it needs to be processed so that it can be used for analysis. The data recorded on a flight recorder (whether FDR or QAR) is stored as a series of 1’s and 0’s. Before it can be of any use to us, it needs to be converted to meaningful “engineering units” such as Altitude and Airspeed.
This is accomplished through the use of a parameter database file or data map file. At Scaled Analytics, we utilize the industry standard FRED file, but most software providers have their own proprietary format they use to do this conversion. You may come across the terms, “FFD”, “LFL”, “LFD”, among others, but they all serve the same general purpose.
How a FRED file is constructed and how it works is beyond the scope of this article, but an important point to note is that FRED files are normally aircraft type specific. So a 737-400 FRED file likely would not work with data from an A320-200.
But they even vary within a given aircraft type. So that 737-400 FRED file above may only work for “some” 737-400 aircraft, while other 737-400 aircraft would require a completely different FRED file.
Before your software or service can make sense of the data, it will need to be configured with the FRED file that is appropriate for your specific aircraft. Many software and service providers charge a “configuration” or “setup” fee for new aircraft types. A good portion of this fee will go towards developing and testing the FRED file (or the vendor’s equivalent) since it is such a critical piece of the flight data analysis system.
Event Detection
Once the data is converted, it is then further processed by the Flight Data Monitoring/FOQA system. The typical system will go through a process of separating and identifying flights, identifying flight phases (Take Off, Cruise, Approach, etc.) and detecting events.
Detecting events is arguably the core of any Flight Data Monitoring system. An “Event” is sometimes referred to as an “exceedence”. This would be a flight condition that has gone beyond the norms of the Standard Operating Procedures or operational limitations of the aircraft. Some examples of Flight Data Monitoring / FOQA events include:
- Excessive Bank Angles
- Low/High Airspeed on Approach
- Hard Landing
- Excessive Localizer or Glideslope Deviation
A Flight Data Monitoring system will be configured with events that are applicable for a given operator’s aircraft types and type of operation. Events are certainly not cast in stone and can (or at least, should) be able to be easily modified as required.
Different vendors utilize different techniques and algorithms to detect FDM/FOQA events. Some vendors are better than others and all reputable vendors will consider their event detection algorithms proprietary information. And rightly so. A great deal of engineering and analysis work goes into developing a robust event detection engine.
Some vendors, including Scaled Analytics, also detect data points at various phases of flight for all flights – whether or not an exceedence or “event” has been detected. We refer to these as “snapshots” and are very useful for trending data during normal operations – not just when something goes wrong.
Data Validation
Once data has been processed, an analyst will typically validate the data. In the past, an analyst would spend a good amount of his/her day validating the flight data and assessing whether or not detected events were valid or false.
Flight data, like any recorded data, can be subject to recording errors. Issues with the recording system may also cause problems that would result in the Flight Data Monitoring system generating a large number of false events.
The good news is that flight data today is much more reliable than it was 15 or 20 years ago. With a robust event detection engine, an analyst today does not need to spend nearly as much time validating events and data as one did in the past, but it is still a task that should be undertaken in some capacity to ensure the integrity of the results of the Flight Data Monitoring. As the old saying goes, “Garbage In = Garbage Out.”
Analyzing the Results
Once data is validated and the analyst has confidence in the data collected, it comes time to sift through the data and try to make sense of it all.
Unfortunately, this is an area where many organizations and service providers fall short. Many times, I have seen a report of the “Top 10 Events”. Numbers 1 and 2 are normally Taxiing too fast and descending too quickly above 10,000 ft. The decision makers look at reports like those and ask, “so what”?
The real benefit to a Flight Data Monitoring program – or any data analysis activity – is that a skilled analyst can sift through the data and make sense of what is being collected. It is certainly beyond the scope of this blog to describe the thought process of an analyst with 20+ years of experience, but an experienced analyst can look at the “top level” data and knows what questions to ask and how to use the tools at his/her disposal to get the answers to those questions.
As a simple example, consider the traditional “Top 10 Events” report mentioned above. Assume that Unstable Approach shows up in the top 10 list. It would be easy to simply say we need to send a memo out to our pilots and perhaps spend more time in the simulator working on approaches until the trend improves.
But an experienced analyst will start digging into the data to find more details surrounding the unstable approaches. He/she might ask (and find answers to) questions such as: Has this trend gotten worse over time? Is this related to weather? Is it related to a particular airport or region? Is it related to the introduction of a new fleet of aircraft? Etc.
Interestingly, during this analysis, Flight Data Monitoring / FOQA specific software comes less into play, making way for third party specialized data analysis and data mining tools such as Excel (shown on the right), SQL Server Business Intelligence and R Programming language (to name but a few).
For an example of how to use Excel’s PowerPivot for flight data analysis, have a look at our Excel for Flight Data Analysis video.
It is with the analyst that a Flight Data Monitoring / FOQA program can truly improve flight safety. Otherwise, the program is just a system for collecting flight data. The analyst provides the information he/she has obtained by sifting through the data and presents it to the decision maker(s) in order to take steps to ensure the continued safe and efficient operation of the organization.
Telling the Story
Of course, the analyst needs effective tools to report findings to those decision makers. Third party tools again come in handy, but many Flight Data Monitoring tools also provide some good capabilities in this area.
Charts are by far the most commonly used tool for assisting in the telling of the flight data story. A good chart can make the complex simple and easy to understand. Conversely, a poor chart can be completely incomprehensible or, even worse, tell a story that simply is not true. Again, this is where a skilled, experienced analyst is of tremendous value.
Finally, flight animation can also be used to help an audience understand the details of a specific flight. Although flight animation is quite popular because of its very nature, it is not particularly useful as an analysis tool. There have been rare cases where an animation has proven useful to understand an accident/incident, but it is mostly used as a presentation tool to help a primarily non-technical audience understand a specific flight.
Having said that, it is still useful in Flight Data Monitoring to demonstrate a flight that may be representative of a trend that is being observed, or as a training tool to assist in demonstrating the ideal manner in which a particular maneuver should be flown.
Summary
Analyzing flight data is the main purpose of a Flight Data Monitoring program. Event detection, data analysis and reporting one’s findings certainly make up the core of any program.
We have covered quite a bit of information here, but in reality, we have barely scratched the surface of the activities an analyst performs in his/her busy day or of the capabilities of a modern FDM/FOQA software system. Hopefully, however, you now have a better understanding of how the data collected from a typical aircraft data recorder can be used to help improve aircraft operational safety and efficiency.
Next, we’ll take a look at how we can take all of this information and “close the loop” on our Flight Data Monitoring program.
Let’s keep in touch
Sign up to get notified of new blog posts, videos or other news and information related to flight data.
