What is ARINC 717? A practical guide for flight data engineers

ARINC 717 is the binary wire format that Flight Data Recorders (FDR) use to write flight parameter data. Almost every commercial aircraft built since the 1990s emits data in this format. If you’re building anything that touches FDR analysis — exceedance detection, FOQA programs, incident replay, post-flight reports — you’ll meet ARINC 717 within the first hour.

The spec PDF is hundreds of pages and the airlines who paid for it don’t share it freely. Most teams end up reverse-engineering pieces from sample files. This post is the explainer we wish we’d had when we started.

The shape of an ARINC 717 stream

Strip away the marketing language and ARINC 717 is straightforward:

• Words — the atomic unit, 12 bits each (not bytes — the encoding pre-dates the modern convention).
• Subframes — typically 64 words, each starting with a known sync word that the parser uses to find subframe boundaries.
• Frames — typically 4 subframes, one second of data each. So one frame is four seconds of cockpit/aircraft state.
• Sync sequence — the four canonical sync words are 583, 1464, 2631, 3512 (or in hex, 0x247, 0x5B8, 0xA47, 0xDB8). These mark which subframe inside a frame the parser is on.

If your parser doesn’t find the sync sequence within the first kilobyte of a file, you almost certainly have the wrong format — either it’s been wrapped (more on that below), or the file isn’t ARINC 717 at all.

Encodings inside the words

A 12-bit word isn’t just a number. Depending on which parameter it represents, the same 12 bits can be:

• NRZ — straightforward unsigned integer, scaled into engineering units (e.g. altitude in feet).
• BCD — binary-coded decimal, used for digital readouts.
• Discrete — bit-packed flags, each bit a yes/no state (gear up, flaps down, ILS captured).
• SSM — Sign/Status Matrix, two bits reserved for sign + signal status. Common for control surface deflections.
• Manchester — a bit-level encoding for synchronisation-sensitive parameters.

A real parser has to know, for each word position in the subframe, which encoding to apply. That mapping is the parameter map — and it’s not in the ARINC 717 spec itself. The spec defines the wire format; the parameter map is per-aircraft, per-vendor.

The parameter map problem

Two Airbus A320s from different airlines can produce identical-looking ARINC 717 streams that decode to completely different parameters. The mapping lives outside the standard — usually in a vendor document called the Data Frame Layout or DFL, sometimes only released after NDA.

Practically, this means:

1. You can read the wire format with a generic ARINC 717 parser.
2. You can’t translate it into “altitude_ft” or “pitch_deg” without knowing which word holds what.
3. The DFL for any given aircraft is the bottleneck for getting useful output.

We’ve seen multi-million-dollar FDR analysis software get scoped down to a single aircraft type because the parameter maps for other types weren’t available to the implementing vendor. It’s a real constraint.

Vendor wrappers: DLU and friends

Here’s where it gets messier. The on-disk file you actually receive from an aircraft is rarely raw ARINC 717. It’s usually wrapped in a vendor format.

The most common wrapper we see in Indian aviation is Honeywell DLU — Data Logging Unit. A DLU file has:

• A custom header (typically ~600 KB of padding + metadata).
• Records of fixed size (48 bytes each in the common variant).
• A record-type field that distinguishes “data” records from “status” records.
• The actual ARINC 717 stream embedded inside the data records.

If you point a generic ARINC 717 parser at a DLU file, it will find no sync words and bail out — because the sync sequence is inside the data record payload, not at the start of the file. You need a DLU-aware decoder that strips the wrapper first.

Other vendors have their own wrappers. The L3 Communications units use a different one. Honeywell’s newer SSFDR variants are different again. Each wrapper requires its own decoder layer.

What “good” looks like for an FDR pipeline

If you’re evaluating FDR software (your own, or a vendor’s), here’s the checklist that actually matters:

1. Can it stream-parse multi-GB files? Single-flight FDR dumps from modern aircraft are 30–80 MB. A retrofitted long-range fleet’s monthly archive can be hundreds of GB. Pipelines that try to load the whole file into memory die at scale.

2. Does it have an explicit vendor wrapper layer? If the docs only mention “ARINC 717,” it doesn’t handle DLU or SSFDR wrappers. Test with a real file from your fleet before signing anything.

3. Are the parameter maps configurable per-aircraft? Hardcoded maps for one aircraft type are a dead-end. The map needs to be data, not code.

4. What does it do with unrecognised sync errors? ARINC 717 files in the wild always have some corruption. Strict parsers that bail at the first error are useless; the right behaviour is to tolerate a configurable max number of consecutive sync errors and skip the bad bytes.

5. Can you audit the decode? Every output parameter should be traceable back to the source bytes it came from. This matters when the DGCA or any regulator asks why your flight data says what it does.

What we built

Aviation AI Pro implements all five points above. Streaming parser. Pluggable parameter maps (we ship Hawker 850XP first, others in flight). Dedicated DLU decoder layer. Configurable error tolerance. Sample-level provenance so every decoded parameter can be traced to a byte offset.

We wrote the C++ ARINC 717 parser ourselves (~7,000 lines of C++17) and ran it in shadow mode against a Python implementation for the same input file. The two parsers disagreed on a fundamental field — we wrote about that here — and that disagreement is the kind of thing you only catch if your tooling is built to surface it.

If you’re running an FDR program at an Indian carrier and you’ve outgrown spreadsheets or you’re stuck on a sunset vendor, we’d be glad to talk. Aviation AI Pro is built for the same regulatory rigor smaller airlines need, without the seven-figure consultancy.

---

Glossary for newcomers:

• ARINC — Aeronautical Radio Inc., the standards body. The “717” is just the document number.
• FDR — Flight Data Recorder, the “black box” (which is actually orange).
• FOQA — Flight Operations Quality Assurance, the program that uses FDR data to find safety trends.
• DGCA — Directorate General of Civil Aviation, India’s aviation regulator.
• DLU — Data Logging Unit, Honeywell’s recorder model that wraps ARINC 717.