(Note: This article was originally published on April 26, 2021).
The core component of any Flight Data Monitoring or FOQA program is the “Event”. Some may also refer to it as an “Exceedance” or “Deviation”, but no matter the term, it normally refers to the same thing. In this blog, I am going to refer to them as Events.
So what exactly is an FDM Event?
Basically, an FDM Event is a set of conditions that, when met, are to be noted and stored in your FDM database. Note that an Event does not have to only represent something that has “gone wrong”. An Event could include things such as “Flight Control Checks” or “Takeoff Flaps Set” – normal occurrences that you just want to have stored in a database.
In most FDM software systems, Events are programmed in some sort of high-level programming language, normally proprietary to the software system. You do not need to worry about those details for this blog, but let’s take a look at a common event as an example to see how it could be defined in a software system.
One common event is “Excessive Bank Angle Below 1000 ft”.
This one is pretty straight forward.
You would tell the system to monitor bank angle when the aircraft is below 1000 ft and, when that condition is met, look for bank angle greater than some limit. For example, a Bank Angle between 20-25 degrees could be a Low severity event, 25-30 Medium and anything over 30 is High Severity.
Your FDM system will be set up with a number of these types of events and part of the software’s “smarts” is sifting through your flight data to automatically detect these predefined events.
When you are developing your FDM or FOQA program, you want to decide what events you want to monitor. Your software or service provider should be able to provide some guidance, but you will also want to exercise some discipline when setting up your program.
Remember that one of the main purposes of an FDM or FOQA program is to look at data trends and try to identify and correct small issues before they become big issues. While an FDM program can certainly monitor for more serious events, you should not be depending on your FDM program to detect reportable occurrences such as:
- Engine Failures
- Hard Landings
- High Speed Rejected Take Offs
Why not?
The main reason (in my opinion) is that, depending on how often you are downloading and sending data, your FDM or FOQA data is not anywhere near real-time data. If you are downloading and sending your flight data once a week for processing, that Hard Landing notification you received could be a week old. If you send your data less frequently, it’s potentially even worse.
In that case, how many flights have there been since the flight with the hard landing?
If you are using a wireless recorder, you should be able to get your results within a few minutes of landing, but you still need a fairly robust set of procedures in place to ensure the aircraft is held at the gate for a maintenance inspection.
The key point here is that an FDM or FOQA program should never replace the requirement for crew to report significant, “reportable” events.
Having said that, having the data available for those events is a tremendous aid in investigating what led up to the reportable occurrence, but FDM should not be depended on for catching such occurrences – it is still the responsibility of the crew to report.
A goal of your FDM program is to try to catch the precursors to some of these reportable events so you have fewer of them in the first place.
So, what makes a good event, then?
This is only my opinion, but I think there are three main qualities of a good FDM event: it must be measurable; it must be actionable; and it must make sense.
Measurable:
When you are setting up your FDM or FOQA program, keep in mind that you will be limited by the data that is available to you. For example, you may want to detect long landings, but if positional data such as latitude and longitude are not recorded, or they are not very accurate, then you will not be able to monitor that event (unless you plan to upgrade your hardware).
A common challenge we see customers run into is that they want to monitor approach speed deviations. Some aircraft record Vref but many do not. In those that do not, we can calculate it if Gross Weight and flap position is recorded. Flap Position is almost always available, but Gross Weight is about 50/50.
Where Gross Weight is not available, we have seen operators try to monitor this event based on the max gross weight, but this just caused an abundance of nuisance events. The event they were trying to monitor was just not measurable with the data given and it ended up being a frustrating exercise that provided no safety or operational benefit.
Actionable:
Events you monitor should be actionable. By that, I do not mean that you should be taking an action against any and every detected event but, rather, after reviewing a few weeks’ or months’ worth of data, you can identify changes that need to take place to improve operations (or confirm that no changes are required).
For example, when I started out in Flight Data Monitoring, we used to routinely monitor for high rates of descent at the top of descent with relatively restrictive limits. This event was frequently triggered, but after a few discussions with the airline safety officer, he conceded that he did not really know what, if anything, he should do about it.
It was not a safety issue, nor was it a passenger comfort issue. We ultimately agreed that we should just remove the event – it was not actionable.
It Makes Sense:
Finally, any event you define should make sense. This sounds obvious, but it is surprising how often operators get confused by their own events.
I recently wrote a blog about keeping your FDM or FOQA program simple and this falls into that category. If your event is so complicated that you need to take a half-hour every time you see it to remind yourself what the conditions are and why you are monitoring it in the first place, is it really worth having in your program?
I do not have a specific example to provide (these are so unique that I would probably single out an operator if I gave a specific example), but when developing your events, just keep in mind that you are not trying to establish a flight test program here – just monitor operational safety.
Keep your events easy to understand and you will get much more value from your program than if you try to over complicate it.
Again, remember that one of the main points in an FDM program is to monitor your trends over time so you can better manage operational safety and efficiency. Building a set of events that helps you achieve that goal is the foundation of an effective (and efficient) FDM or FOQA program.
If you need help, your software of service provider should be able to provide you with guidance. But do not be intimidated – once you understand the basics of FDM in general and events in particular, you will be well on your way to building your own events that help you get the most out of your FDM 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.
