When is a Frame Not a Frame – The Sequel
So avid readers will remember the importance of superframe sequence numbering from my previous blog, and be wondering why this is such an issue. Surely you just number 16 superframes, and Bob’s your Uncle.
Let’s take a simple example to start the blog going. Here is a superframe with character fields as this makes it easy to see what is happening.
Here is data for one flight, which, again for simplicity, is data that will not vary through the flight.
Heavy metal fans will be pleased to see AC-DC sneek into my blog, but actually this aircraft, G-ACDC is a Tiger Moth that my wife and I were lucky to fly in on our 10th wedding anniversary.
Clearly this is fictitious, as a Tiger Moth would not make it from London Heathrow (IATA code = LHR, ICAO code = EGLL) to Singapore (ICAO = SIN, ICAO = WSSS) in one sector! Note that it is common for text strings to be long enough to accept a string of the maximum length, and pad with zeros, blanks or similar. So, if ICAO airport identifiers are being used, the return journey would be:
Some aircraft don’t behave
Staying with ICAO codes, and with our shuttle from London to Singapore, here is what the next flight can be:
So now our aircraft is registration “SG-ACDC” travelling from “ EGL” to “LWSS”.
For those who think I am making this up, there is a fleet of aircraft flying around where the superframe data is misaligned in this way. The problem arises on a complete flight or not at all, and applied to about half the flights.
While this example uses text fields to make it easy to see what is happening, the same slippage arises in numerical fields where it can be far more difficult to identify erroneous data from correct data.
The Legal Position
The tricky thing about the aircraft in question is that most of the parameters included in the superframe are mandatory parameters required by the Aviation Authorities to support accident investigations. The parameters in the case in question include date, time, fuel quantities etc. Therefore the aircraft was certified with a system that fails to mandatory record data correctly. Either the person who signed this off got lucky when they tested the installation and it happened to work on that day, or they were aware of the error but turned a blind eye.
More disappointingly, over the years there have been many FDR Readouts performed and it is simply incredible for all of these to always have “got lucky”. With a 50:50 chance of this error occurring, and we know that over 100 readouts have been required, the chance of this is about one in a billion billion billion. Clearly the data in these superframes is not being checked, otherwise the problem would have been resolved by now.
The Practical Position
Now that we know this problem exists, do we go back to the operator, aircraft manufacturer or Authority and tell them this data is not recording properly, or do we spend time designing a unique algorithm that will look into the superframe data and work out whether the information is misaligned or not, then try to fix it automatically? At what point does a sticking plaster become a cover up?
My view is that this is a problem that should be corrected, because there is a possibility that one day an accident investigator will need to look at the data and use it to determine the cause of an accident. Then is not the time to start trying to work out whether the superframe data slipped or not.