Standards & formats
Onboard Ethernet: IENA, Chapter 10 and real-time acquisition
An acquisition network carries packets, not channels. What makes them usable in real time is the format: how a packet says what it holds, when it was acquired, and whether one went missing. Two formats dominate flight test, IENA and IRIG 106 Chapter 10; here is how each of them does it.
From frames to packets
A PCM frame identifies its parameters by position and dates them by rhythm: word 37 is pitch rate because it is word 37, and it was acquired one frame period after the last one. A network breaks both. Packets from different sources interleave, wait in switch queues, and can be lost. The format has to say explicitly what the frame said implicitly.
Three things, in every packet: which stream it belongs to and how its content is laid out; when that content was acquired; and where the packet sits in the sequence of its stream, so that a gap shows.
IENA, field by field
IENA is the flight-test packet format defined by Airbus. Its packets travel in UDP datagrams, usually multicast, with every field in big-endian byte order, and they all share the same header and trailer around their parameters:
scroll
- Key, 16 bits: the packet type, which stands for one source and one set of parameters. It is what a channel is in other formats.
- Size, 16 bits: the length of the whole packet, header and trailer included, counted in 16-bit words.
- Time, 48 bits: the time of the packet, in microseconds since 1 January of the current year. The year is not in the packet; it comes from elsewhere, and so does the turn of the year.
- Key status, 8 bits: how the parameters of this key are laid out, fixed by the configuration.
- N2 status, 8 bits: the state of the sender for this packet — time synchronisation lost or never acquired, an overflow, and a latency flag set when the packet left more than 100 ms after its time.
- Sequence number, 16 bits: a counter per key, incremented at every packet, which reveals any loss.
- End field, 16 bits: a fixed value, commonly 0xDEAD, that a receiver can check at the position the size announces.
Five ways to lay out the parameters
scroll
| Type | Content | Suited to |
|---|---|---|
| P, positional | Data only, identified by its position in a repeating pattern | Parameters sampled at a fixed rate |
| N, standard | A parameter identifier, then up to seven 16-bit words | Parameters at mixed rates, or sent when they change |
| D, standard with delay | As N, plus the delay between the packet time and the acquisition of the parameter | Parameters that need a date of their own |
| Q, message | A parameter identifier, a length, then a block of bytes | Bus messages and other variable-length data |
| M, message with delay | As Q, plus a delay field | Bus messages that need a date of their own |
A key carries one type only. The positional type is the most compact, and the most dependent on configuration: nothing in the packet says which parameter is which, so a receiver without the test database sees numbers without names.
Chapter 10 over UDP
An IRIG 106 Chapter 10 recorder can send on the network the very packets it writes to its medium. Each one carries its channel identifier, its data type, a 48-bit relative time counter and a per-channel sequence number, and the stream includes the TMATS setup and the time packets that tie the counter to absolute time. A small transfer header numbers the UDP datagrams and lets a packet larger than a datagram be split across several.
The strength of the format is that a stream and a recording are the same thing: a ground station reads it with the software that reads the files after the flight, and the description of the data travels with the data. The cost is a larger header than IENA for small, frequent parameters.
Network telemetry
The same logic now reaches the radio link. In its chapters 21 to 28, IRIG 106 defines a telemetry network standard, born from the US iNET programme, in which the aircraft is a node of an IP network that includes the ground: data messages, metadata, and a radio link that carries traffic both ways. It changes what telemetry can do — the ground can ask again for what it missed — and what it requires: an onboard network designed for it from the start.
Real time: latency, losses and time
- Latency is mostly waiting: a packet leaves when it is full or when a timer expires. With a few hundred parameters per packet, the filling time dominates; IENA practice quotes about 50 ms from acquisition to sending.
- Losses are invisible without numbering. Check the sequence numbers per key or per channel at every receiver, and read the drop counters of the switches.
- Time comes from the sender, not from the receiver: a packet dated on arrival carries the queueing of every switch on its way. Synchronise the senders, with PTP or IRIG-B, and trust their time stamps.
- Status bits are data: an IENA packet whose sender reports a lost synchronisation should colour every value it carries.
- Record the network as it is, as well as the parameters you decode: a capture with its own time stamps answers questions nobody thought of before the flight.
Choosing a format
It is rarely a free choice: the format is usually set by what the receivers already read — the test centre's ground station, the analysis software, the aircraft manufacturer's tools. Where there is a choice, IENA suits high-rate parameter streams sent to tools that hold the configuration database; Chapter 10 suits installations where the stream must describe itself and match the recording. Many installations carry both, and the decision is made per receiver, not per aircraft.