IRIG 106 Chapter 10 - Digital Recording Standard

Introduction:

As data recorder manufacturers raced to build the latest and greatest products, increasing sample rates, adding data types, introducing solid state memory, etc., the divergence of proprietary data formats used in recordings and in the setup files grew. These numerous proprietary formats required inventive ways to share data, exporting it into common format, or by partnering with the developers of analysis and display software to add support for their bespoke format. Creating recorder setup files required device specific software, and when it came to upgrading the hardware the end users felt locked in.

The Inter-Range Instrumentation Group’s telemetry section saw the need for standardisation and stepped in with IRIG 106 Chapter 10, a “computer-compatible digital data acquisition and recording standard”. At the time of writing, the RCC publish the latest revision in 2019.

IRIG 106 Chapter 10 defines particular aspects of the compliant digital data recorder as outlined in the table below.

Aspects defined by IRIG 106 Chapter 10
Section	Aspect
10.3	Operational requirements
10.4	The physical interface for data access
10.5	The data access / interface file structure
10.6	Data format definitions
10.7	Recorder control and status
10.8	Declassification
10.9	The host platform interface to the recorder’s removable media
10.10	The ground-based recorder interface
10.11	Data Interoperability

 

The standard has specific interest in the compatibility of multiplexed synchronous and asynchronous digital inputs including pulse code modulation (PCM), Military Standard 1553 data bus, time, analogue, video, ARINC 429, discrete, Universal Asynchronous Receiver and Transmitter (UART) containing Recommended Standard (RS)-232/422/485 communication data.
Without going into too much detail, let us take an overview of the individual sections of Chapter 10.

 

Section 10.3 - Operational requirements:

It was with on-board flight test recorders in mind when IRIG 106 Chapter 10 was first conceived. Section 10.3 defines how such recorder can become 100% compliant, guaranteeing interoperability of recorders, recorder media, and recorded data. Later refinements brought Ground-Based Recorders into the fold.

As a minimum the compliant recorder shall have a data download port, a recorder control and maintenance port, and an external power socket. These ports should comply with the relevant sections.

The standard does not govern internal hardware architecture, the physical size or form factor of the recorder and removable memory.

It requires any downloadable or transferable data to be clean of system management, error detection and correction or any other formatting required by internal processes.

Any removable memory, or the recorder itself, should be able to be removed from the aircraft and taken to a ground station for transfer as defined in sections 10.4, 10.9, and 10.11. Commercial Of The Shelf (COTS) media should be supported, i.e. the manufacturer should not be locking the end user into a bespoke removable media supply.

Interfaces to on-board recorder media shall be IEEE 1394b or Ethernet compliant. The structure of the recorded data itself is controlled by IRIG 106.

Recorder setup configuration files can be stored either within the recorder or on the removable memory and must comply with IRIG 106 Chapter 9 Telemetry Attributes Transfer Standard (TMATS). The setup files stored on the removable media are given priority over those stored on the recorder.

The operational requirements also go into some depth about recorder data streaming and how this may be accomplished. This is quiet detailed and I’ll address it in a section of its own.

 

Section 10.4 – Data Download and Electrical Interface:

IRIG 106 Chapter 10 describes three types of download interface ports; Fibre Channel, IEEE 1394b (aka Apple’s Firewire), and Ethernet. Any or combinations of these are permissible. The physical, signalling, and command protocols have been adapted from STANAG 4575. We will go into a little more detail on this soon.

A Fibre Channel Recorder Download Interface will be made from copper, with a transmission signalling rate of 1.0625 gigabaud.

With some defined exceptions the fibre interface must also conform to the standards laid down by the International Committee for Information Technical Standards (INCITS) “Fibre Channel – Private Loop SCSI Direct Attach” TR19-1998, superseded by their technical report “Fibre Channel – Device Attach” TR-36-2004. Visit https://www.incits.org/ for further information.

IEEE 1394b Recorder Interface communication shall be in full compliance with IEEE 1394b protocol. Data packets sent and received shall be asynchronous transmissions, with the IEEE 1394b packets encapsulating Serial Bus Protocol (SBP) -2 formatted packets for the transport of commands and of data. Recorder devices are to use SCSI command set(s) which are to be encapsulated in SBP-2 operation request blocks.

An Ethernet Recorder Interface, if fitted as a data download port, should use FTP and / or iSCSI protocols. If iSCSI protocol is implemented, the host ground system is to be defined as the initiator whilst the recorder acts as the target.

The recorder’s Ethernet interface should also support the Telenet protocol to provide a bi-directional text based terminal connection over TCP/IP. Telenet has been revised a number of times, and at a minimum, the version implemented in the recorder shall be compliant with Internet Engineering Task Force (IETF) Requests for Comment (RFCs) 854, 855, and 1184. Unlike some of the other standards mentioned thus far, the Internet Engineering Task Force (IETF) is an open standards organization. You can learn more at https://www.ietf.org/.

IRIG 106 Chapter 10 goes on to define naming, addressing, and Target Logical Unit Number Assignment, but all this lies outside the scope of this introduction.

 

Section 10.5 – Interface File Structure Definitions:

The Inter-Range Instrumentation Group sought a file structure that would be manufacturer independent, they sought commonality, a structure that would allow backward and forward compatibility for the duration of the standard. This, after all, was the entire point of IRIG 106 Chapter 10. Rather than design a new files structure they opted for the tried and tested STANAG 4575 section 3.

Section 10.6 – Data Format Definitions:

Data shall be formatted in accordance with IRIG 106 Chapter 11. A Time Data Packet shall be the first dynamic data packet at the start of each recording. These are to be treated like any other data channel, and shall be generated at a minimum frequency of 1 Hz.

Whilst covered by Chapter 11, the diagram below provides a guide to this format

Data Format for both Single and Multiple Channel Recordings

 

Section 10.7 – Recorder Control:

Chapter 10 mandates that the recorder should be controlled using either or both discrete inputs, and / or serial communications port. The discrete inputs should have priority over those given via the serial port which shall be compatible with both RS-232 and RS-422 full duplexed serial communications.

Optionally, the recorder may be controlled over a Fibre Optic Channel, IEEE 1394b, or Ethernet as discussed in Section 10.4.

As an example, Safran Data Systems’ MDR flight test recorder has a dedicated 44 pin D-Sub connector for remote control and access to media. In addition to eSata, GigE, RS-232, and RS-422, there are discrete input pins for starting and stopping a recording, to erase, and declassify. There are output pins allowing external hardware to register record status, erase stats, error status, etc.

The RS-232/422 ports are required to function simultaneously without requiring prior selection. Status requests by either port shall be returned on both ports simultaneously, though the standard makes an exception for when commands arrive at both ports at the same time, when it allows that “unexpected results may occur”.

The standard declares that the download of the data should be available via RS-232/422, and goes on to provide details of the default serial interface; 38400 baud, one start bit, 8-bit data, no parity, and one stop bit.

 

Section 10.8 – Declassification:

As of IRIG 106-17, this section was moved to Appendix 10-B. This appendix goes into some depth that I will not repeat, as to the sanitization of classified data, in particular the algorithm used to erase secure data.

 

Section 10.9 – Host Platform Interface to Recorder Media:

Chapter 10.9 offers two methods for reading data from the recorder’s removable memory module (RMM) and to write a recorder setup configuration file (RSCF) to the RMM. These are IEEE 1394b (Apple’s Firewire high speed serial communications bus) and IEEE 802.3 (Ethernet), it is not incumbent for both protocols to be supported. All physical aspects, power, and signalling levels must apply to these respective standards.

 

Section 10.10 – Ground Based Recorders:

The main functional requirements of a Ground Based Recorder are around the following aspects.

a. Recorder Interface
b. Recorder Data Format
c. Recorder Media
d. Recorder Command and Control (if it is to be controlled remotely)

Optionally, the ground based recorder may support replay, reproduction and display of Chapter 10 recordings. IRIG 106 Chapter 10 defines basic replay, reproduction, and interoperability requirements, but does not venture to define data display.

An Ethernet interface for remote control is the minimum requirement of the 2019 standard. Optionally ground based recorders can implement additional interfaces and support remote data access and / or data streaming. If iSCSI, RS-232/422, IEEE 1394, and / or Fibre Channels are implemented, this should be in accordance with sections 10.4 and 10.7. All remote command and control functions should be implemented following the same rules.

The same data format rules apply to ground recorders as to airborne recorders, as do those to do with storage media. Playback should not require the movement of the storage media from one slot to another.

 

Section 10.11 – Data Interoperability:

IRIG 106 considers all files within a recorder, on removable memory modules, on COTS media, or that are unaltered single file downloads, to be in need of full compliance to the file structure definitions of section 10.5 and the data format rules of section 10.6.

The standard then defines the rules surrounding the modification of these files, for example in the downloading of a subset of data. When this happens the resulting files need to remain compliant in terms of file structure and data format. Checksums, etc., need to be recalculated.

All recordings downloaded to the host computer should have the files extension *.ch10 (or *.c10 when limited to three characters).

Strict sequential filenames conventions also apply, beginning with the word file, a sequential number, and where possible the Date Created, Time Created, and Time Closed in the format DDMMYYYY_HHMMSSss_HHMMSSss. These time stamps should be separated by an underscore. No spaces nor other non-numeric characters are allowed.

E.G. file0001_04041984_20100001_21040430.ch10.

Similar rules govern directory naming and recording file names on the ground recorder itself, and for the transferring of data files so that compatibility between organizations can be fully achieved. Data transfer files go by the file extension *.tf10 (or *.t10) rather than the *.ch10 extension. Recording directories shall use the extension *.df10 (or *.d10). The standard goes into further details on these subjects, but they are beyond the scope of this introduction.