Standards & formats
ARINC 717 and 573: reading the frames that feed a flight data recorder
Airliners and many helicopters send their flight data to the recorder in the same slow, rigid format: twelve-bit words, four one-second subframes, a sync word at the head of each. Recording that stream is easy; making sense of it is not. Here is how the frame is built, what the data frame layout adds, and where decoding goes wrong.
Where ARINC 717 sits
On a transport aircraft, flight parameters come from dozens of systems, over ARINC 429 buses, discretes and analog lines. A flight data acquisition unit — FDAU, or DFDAU when it also processes the data — gathers them, samples each at the rate the regulations and the operator require, and packs them into one serial stream. That stream feeds the crash-protected flight data recorder and, through an auxiliary output, often a quick access recorder whose media the operator downloads for flight data monitoring.
ARINC 573 defined that stream for the first generation of digital flight data recorders, at 64 words per second. ARINC 717 kept the same frame structure and extended it to higher word rates, which is why the two names travel together: a reader for one reads the other once it knows the rate.
The frame, word by word
The unit of the stream is a 12-bit word. Words are grouped into subframes of exactly one second, and four subframes make a frame of four seconds that repeats for as long as the recorder runs.
- Word rate: 64, 128, 256, 512 or 1,024 words per second in most installations, fixed for a given aircraft — from 768 to 12,288 bits per second.
- Sync words: the first word of each subframe is a fixed pattern — 247, 5B8, A47 and DB8 in hexadecimal for subframes 1 to 4 — so a decoder knows both where a subframe starts and which one it is.
- Data words: every other word is a sample slot. A parameter owns given bits of given words in given subframes; a slow parameter may appear once per frame, a fast one several times per subframe.
- Superframe: parameters that change very slowly share one slot across 16 frames, a 64-second superframe, told apart by a frame counter carried in the stream.
scroll
Inside a word, a parameter can take all twelve bits or only a few, and one that needs more resolution can spill over two words. Values may be plain binary, two's complement, BCD or a single discrete bit, then scaled by a resolution and an offset, or by a calibration table. None of that is carried in the stream: it all comes from the documentation.
The electrical side
The recorder input uses Harvard bi-phase, or HBP: a self-clocking code with a transition at every bit boundary and an extra one in the middle of each 1, so the receiver recovers the clock from the data itself. Auxiliary outputs, such as the one that feeds a quick access recorder, may use bipolar return-to-zero, or BPRZ, instead. A receiver set to the wrong coding sees noise — or, worse, plausible garbage.
For a flight-test tap, the rule is the same as on any certified line: high impedance, listen only, qualified for the installation, and agreed with whoever holds the aircraft's certification. Nothing the flight-test recorder does — powering up, failing, being disconnected — may disturb the line that feeds the flight data recorder.
The data frame layout: the document that matters
The frame structure is the same on every aircraft; what each word means is not. That meaning lives in the data frame layout: the document, supplied by the airframer or the operator, that gives for each parameter its words, bits and subframes, its sample rate, its coding and its conversion to engineering units. Layouts are specific to a type, often to a fleet, sometimes to a single aircraft after a modification, and they are frequently supplied under a non-disclosure agreement.
ARINC 647A standardises an electronic form of that documentation, so that software can load a layout instead of someone retyping it from a PDF. Use it when it exists: most decoding errors are transcription errors.
Recording ARINC 717 in a flight-test installation
Flight-test teams tap the acquisition unit's output for a simple reason: it carries dozens of aircraft parameters, already sampled, that would otherwise each need their own interface and wiring. Recorded next to the test channels, it puts the aircraft's own view of the flight on the same time base as the instrumentation.
- Record the stream as received, bit for bit, and time-stamp it on the installation's common time reference. Decoding at record time throws away the chance to correct a layout later.
- In an IRIG 106 Chapter 10 file, an ARINC 717 stream is commonly recorded as a PCM channel, its frame described in the TMATS.
- Keep the frame-sync status with the data: a period without lock must appear as missing data, never as frozen values.
- Log which layout revision was used for each flight: the same aircraft can change layout after a modification.
Where decoding goes wrong
scroll
| Symptom | Likely cause | Check |
|---|---|---|
| No lock at all | Wrong word rate, or the wrong line coding | Measure the bit rate on the line; try each standard rate |
| Lock, but values jump from one second to the next | Subframes mixed up: sync words not checked in sequence | Verify that subframes 1 to 4 follow each other |
| Plausible but wrong values | Layout from another type, fleet or revision | Decode a parameter known on the ground |
| Values off by a factor of two, or with the wrong sign | Wrong bit range, or two's complement read as plain binary | Compare with the layout's resolution and sign convention |
| A slow parameter stuck or jumping | Superframe counter misread | Check that the frame counter steps once per frame and cycles every 16 |
| Slow drift against the test data | Stream time-stamped by an independent clock | Time-stamp on the installation's common reference |
After ARINC 717
Newer aircraft move flight data onto networks: recorders built to ARINC 767 take their data over Ethernet, and parameter lists grow well beyond what a serial stream of 12-bit words can carry. ARINC 717 will nonetheless stay in service for decades on existing fleets, and on every one of them, the frame described here is what feeds the recorder.