The origins of the Flight Data Monitoring (FDM) process date back over twenty years and are enshrined in ICAO regulations. One of these states that “A flight data analysis programme shall be non-punitive and contain adequate safeguards to protect the source(s) of the data.” This need for data security has been implemented in various forms including data de-identification, restrictions of access to the data (e.g. keeping the computers in locked rooms) and control of access to data using a “gatekeeper”. Should a significant event occur, the gatekeeper’s rôle is to make contact with the crew of that flight, find out not only what happened but why this happened, and report back to an FDM committee with his findings. This process is only undertaken in serious cases, the vast majority of flights being processed without crew contact.
A further element of FDM, and particularly of its equivalent, the Flight Operations Quality Assurance (FOQA) process carried out in the USA, is the assumption that flights are all similar and we can use statistical quality control processes to manage flight operations. That is, variations will be around a normal baseline and we can monitor deviations from the norm to detect unsafe characteristics in the operation.
The Elephant in the Room
This assumption that all flights are the same and all quality control will manage variations arising from external influences such as the airport design, air traffic control etc. ignores the obvious “elephant in the room”, that pilots are not all the same. If we compare Capt “Sully” Sullenberger who successfully ditched an A320 with no power on the Hudson River with the crew of the Colgan Dash-8 who crashed in Buffalo, it is fairly clear that the standards of airmanship vary significantly.
Augmenting the System
So, here are the three factors I want to put together.
- Pilots have varying levels of skill and experience.
- Pilots are professionals and able to learn from new information.
- Flight data is a source of information about a flight.
The logical next step is to give every pilot access to the flight data for his flight, so that, if he chooses, he may review a flight and use this to help him learn about things that happen in service and not just in the simulator.
The goal here is to help pilots to learn from their own flights, without waiting for the safety department and gatekeeper to intervene. Pilots will be able to view flights that didn’t go quite as expected, but were still well within safety limits, and learn from these flights in a way that is not possible with the current implementation of FDM. The data will need to be presented in a suitable format, suitable for a smaller screen.
These two concepts, of data security and pilot data access, are not incompatible. The analogy is pay. An airline pays the pilot’s salary into a bank and with electronic banking the pilot can view his bank balance. Of course there are a few people in the airline who know how much each pilot is paid, but this information is not freely available, and each pilot can only see his own bank balance, not how much his colleagues are paid. So it can be with flight data. The safety department could see all flight, with the existing gatekeeper protocols and security still in place, but at the same time each pilot could see the flights that he flew on.
Who Flies the Aeroplane?
When you next see a pilot checking his smart phone, he might be checking how fast he rotated the aircraft on his last flight, and quietly congratulating himself on a textbook takeoff. After all, it’s the pilot who flies the aeroplane, not the gatekeeper.