ARINC 767 but not the plane
Always one for a gratuitous picture of a nice aeroplane, here is a 3D model of a Boeing 767.
And here is a Boeing 787
This is the standard that defines the flight data recorder format used on the Boeing 787 Dreamliner. It’s nothing to do with the Boeing 767 which, of course uses the ARINC 717 data format. Why do we do this? To confuse, annoy and make life difficult for the novice black boxer.
The key difference between the old and new black box data formats is to do with sample timing.
The old 717 format recorded samples in sequence, so their time was determined by their position in the queue of data.
(OK, for those who understand about data sampling and transfer latency, this is not precisely correct, but it’s a good enough explanation for those who do not, and if you do know, you should know enough to accept the small inaccuracy and keep quiet).
Each four-second pattern of data was called a Frame and this pattern was repeated throughout the flight.
The newer standard defines an Enhanced Airborne Flight Recorder (EAFR) which incorporates voice, data, data link and image recording functions.
The data recording part stores data in Frames, but there can be many different types of Frames, sampled at different intervals and with different contents. Why call them Frames? To confuse those who spent a lifetime working with Frames that were something different, I suspect.
Now, here is the key clue you need before reading the hard bit that follows. Each Frame contains a TimeStamp that tells you when the data inside the Frame was recorded. Imagine you want Air Data comprising airspeed and altitude recorded twice a second, and 1,000 seconds into the flight the aircraft is accelerating through 200kts and 3,000ft. You would get frames like this:
“Air Data”, 1000.0, 200.0, 3000.0
“Air Data”, 1000.5, 201.0, 3005.0
“Air Data”, 1001.0, 202.0, 3010.0
“Air Data”, 1001.5, 203.0, 3015.0
It’s a very trivial example, but you can see how the data measurements are named and given a time of recording.
When Timestamps Go Wrong
There have been a number of issues with inconsistent frame time tags in ARINC 767 data. Although rare, here are three types of error we have seen in the past:
• Time tags have been noticed to jump by a very large value, e.g. over 1000 hours.
• Frame time tags start after over an hour into the flight.
• For every 16 seconds of valid data, another 16 seconds worth of data was missing, resulting in half of the flight not being recorded.
A recently seen inconsistency is that frame time tags are often later than expected, typically by 50 milliseconds. While late time tags may appear at random, it often occurs every 5th 1Hz frame.
Storing Data For Analysis
Flight data analysis software generally stores parameter data within standard arrays as the data structure is both efficient and straightforward. ARINC 717 data is recorded at a regular time interval, and therefore time series data can be stored accurately within an array.
While the frame time tags in ARINC 767 data should increment at a specified frequency, it is possible for a frame time tag to fall on any millisecond from the start of the recording. This arbitrary timing cannot be represented in a standard array, and would require a more complex data structure for accurate representation. For compatibility with the existing processing implementations for ARINC 717 data, we store frame parameter data within arrays which represent data being recorded at a specific frequency.
In the case of time tags which do not directly match the frequency (e.g. a 1Hz frame time tag incrementing by a value other than 1000 milliseconds) the data has to be aligned to a whole number index within the array. This simple algorithm had already been implemented to handle various cases of missing data, but in the new case of frame time tags being late the algorithm was always deciding to pad the array with an empty value.
The real problem arises when an early frame time tag appears, so you have data that was recorded before it was expected. When the time discrepancy is below half of the frame’s frequency, this is arguably not the most accurate placement of data within an array. The processing algorithm has been modified to place the frame’s data at the closest array index, rather than adding padding when a time tag is below half of the frame’s frequency.
Well, I am glad we cleared that up for you. See the related blog about the Fred format of documentation which is used by the ARINC 767 recorders at https://www.flightdatacommunity.com/meet-fred/
Finally, I’d like to thank Glen Kirkup for writing all the hard stuff this week, and for his weeks of patience fathoming out the data errors in the ARINC 767 format data.