Let me tell you a story. Once upon a time I was sitting in a meeting in Washington at the offices of the Flight Safety Foundation (FSF). Around the table were the main suppliers of flight data analysis software and services, and we had been called together by the FSF to discuss how we could contribute to their safety program. There was a strong will to work together as, in general, aviation safety professionals tend to be humanitarians first and businessmen second.
The meeting was going well and we agreed that we needed to define a common set of safety events. These are points in a flight where safe operation has been compromised, although not necessarily to the point of becoming hazardous. At that point the FSF explained that the event definitions they were using were proprietary to another company and could not be shared.
So, being humanitarians first and businessmen second, we decided these barriers had to be broken down in the interests of flight safety. Enter the POLARIS project.
The POLARIS project gives FDS an opportunity to do something new and fresh, and put into the public domain a set of event definitions that anyone, and in particular aviation safety professionals, can view, use or help to improve. That meeting led, indirectly, to some decisions about the structure of the POLARIS programme.
Decision 1: Publish the event definitions.
Each FDM company has its own algorithms, and so we lack common ground in the industry. There’s much benefit to be gained through sharing and comparing safety data and this lack of standardisation hinders what should be the most open of discussions.
Decision 2: Focus on safety parameters.
As I said earlier, sharing safety data is an invaluable process. Since 2006 FDS customers have had the benefit of comparing their safety event rates against other FDS customers operating similar types. This has been particularly useful for airlines new to Flight Data Monitoring.
Our experience tells us that as soon as different customers change their event thresholds, this process, while still useful, becomes devalued. The approach FDS is taking is to concentrate on the parameters that airline safety specialists want to monitor. These parameters (KPVs) can be compared with thresholds to create events, but will also allow for cross-operator comparisons to be carried out easily and meaningfully, and will not change as threshold settings are varied.
Decision 3: Publish the Algorithms
In exactly the same way that 50% of all tennis players will lose their match, so 50% of all safety managers who carry out a comparison study will come out worse than the other operator. The immediate (and entirely natural) reaction is to look for a way to explain the unpleasant result. There may be valid operational differences, but the safety managers will also look for technical excuses such as “We fly more often so we have more events.”, “The algorithms must be different.” or “You cannot be comparing like for like.”
The best solution to these technical complaints is to publish the algorithms, so that specialists can see for themselves whether there are any valid reasons to explain variations.
A spin-off of this approach is that safety professionals may have ideas about how to improve matters and develop the art of safety monitoring. An open dialogue in this arena can only benefit the aviation safety world.
Decision 4: Release as Open Source
It is, by now, only a small step to release the software used for flight data analysis as Open Source. The logic here is simple.
- A piece of software is the most precise definition of an algorithm as it removes all ambiguity. As a consequence, less effort is needed to document the algorithm.
- If airlines adopt the same software, they can be certain that their parametric data may be shared with other companies certain in the results of any comparison.
- The Open Source approach also leads to improvements in quality as errors may be found by software engineers other than the original author.
- Finally, I hope that this tool may be of use to academic institutions who otherwise could not afford to be involved in FDM and similar fields.
This sequence of logical decisions led to announcement of the POLARIS Open Source project in May 2010, since when little has been visible because the FDS development team has been working on the website that supports our customers.
The summer of 2011 saw the start of work on the analysis suite in earnest, and the creation of the POLARIS community website. Finally in the autumn of 2012 we are ready to release sections of the POLARIS to the public and start our adventure in earnest.