Take a step ahead with an upgrade to ARINC 818 Revision 3 Avionics Digital Video Bus

For advances of the 21st century, greater bandwidth and flexibility are required. The challenge is how to satisfy ever-expanding bandwidth and resolution requirements while retaining the versatility required to manage almost any video format. This ARINC is now being worked with hundreds of planes and upgrades. This version now specifies 28 Gb/s speeds, allowing it to expand. For high-speed avionics systems, the ARINC 818 has become the real standard.

Interpreting ARINC 818: ARINC 818 is the encoded 8B/10B point-to-point protocol for video and data serial transmission. The Protocol is packaged, video-centered, and very versatile, allowing the multiplexing of multiple video streams on one single link.

Even before its introduction, ARINC 818 has already been adopted by two major aerospace programs, the Boeing 787 and the Airbus A400M. In the aircraft, a growing amount of information is given in the form of photographs, which passes through a complex video system before reaching the display in the cockpit and crew.

Infrared and other wavelength sensors, optical cameras, radars, flight recorders, map/chart systems, synthetic sights, image integration systems, multifunctional head-up, and heads-down displays, video concentrations, or other subsystems are among the video systems available.

Systems Video is used for taxi and departure assistance, cargo loading, navigation, target tracking, collision prevention, and other essential features. ARINC 818 builds on the protocol of the Audio Fiber Channel (FC-AV as specified by ANSI INCITS 356-2002), which is commonly used on the F18 and C130AMP video systems.

Although FC-AV has been used on various systems, each implementation has been specific. ARINC 818 offers an opportunity to standardize high-speed video systems.

We heard the clients who use our tools. We have made solutions providing the best industry standards and continue to refine the software and hardware tools ourselves.

But why prefer ARINC 818 over other Video and Data bus?

The Advanced Digital Video Bus (ADVB) is a fiber channel adaptation that adds capabilities for video and image transportation. Whereas a very wide range of industries and applications are supported in the FC-AV standard, ADVB focuses especially on the needs of avionics video.

ADVB is made simpler through FC-AV, as it is unidirectional and doesn’t have a connection initialization, flow control, or other fiber channel exchange requirement such as port connections.

Although simplified, ADVB maintains Fibre Channel attributes that support vital mission video applications, such as high speed, high reliability, low latency, and flexibility. To merge images in real-time, such as symbology or cursors, all the imagery must be uncompressed while overlaying digital map images or real-time videos.

The video needs considerable bandwidth without compression. Present ARINC 818 operations use up to 3Gbps with 8.5Gbps requirements.

Since FC frame (packet) CRCs are used, ARINC 818 provides high data integrity. Packaged video enables simple data integration and generates multiplex multiple video streams for one connection link.

Timing Classifications: Appendix C of ARINC 818 sets out four Synchronization and Segmentation Classes (A-D) that describe asynchronous, frame, line, or pixel synchronous for timing constraints of the ADVB Link.

Table 1 shows the different timing classifications for ARINC 818. The Interface Control Document (ICD) shall accompany the implementation of such ADVB projects in compliance with the ARINC 818 specification.

The ICD defines link parameters including link speed, image resolution, synchronization scheme, frame rate, and so on. Two systems of ARINC 818 will not be compatible if they aren’t built on the same ICD component.

Generally, there will be an ICD associated with a military program or commercial avionics development.

Table 1. ADVB Synchronization Segmentation Classification

A brief introduction to the new features/additions in ARINC 818 Revision 3:

A new proposal to update the specification again with some extra features and clarifications was sent to the ARINC committee in the fall of 2018.

A display emulation mode for testing, latency budget guidance, and fixing of certain typographical errors in previous versions are additions to the specification.

Guidelines for using 64/66 Bit Encoding at speeds above 10Gbit are the key addition to ARINC 818-3.

1. Display Emulation

As different organizations improve ARINC 818 systems both internally and externally, circumstances can occur where the test equipment used for exercise equipment can behave differently than the new equipment being introduced, resulting in variations in timing and slight differences in performance.

Many image grabbers operate with full picture buffers or video generators. Often this is achieved because of the way it is possible to implement video hardware like a DVI chip.

These devices need a complete video frame to be present in the memory before it can be transferred to the DVI chip to format and send to the video or display monitor.

However many implementations use a FIFO (first-in, first-out) buffer for implementations that are vital to safety when a video line (or even a partial line) is transmitted immediately.

This is achieved to minimize latency so that the video is displayed to the operator as quickly as possible.

2. Latency

Head Down-Displays (HDD), Head-Up Displays (HUD), and Head-Mounted Displays (HMD) inside the aircraft are very sensitive to latency.

The pilot uses videos for real-time visual guidance and sees the external world in the background superposed. Special contributions to latency should be taken into account, such as the collection of images, image rendering, video processing, etc.

Latency-sensitive implementations typically use FIFO’s to/from the ARINC 818 clock domain and to achieve latency for up to a few video lines (microseconds).

A dual/triple frame buffers can be used for implementations that are non-sensitive to latency and the video frames are stored inside a memory device, and so imposes a latency of one video frame (milliseconds) by displaying the previous frame.

For instance, two FC-packets will transmit a VESA Standard SXGA video with 1280 pixels, 1024 rows 24 bpp, and a refreshing rate of 60 Hz.

So FIFO FC row will generate one video line latency (15.6 uses in this case). An FC FIFO packet can generate about a half-line latency (7.8 usec).

The appropriate latency for the ARINC 818 transmitter and the ARINC 818 receiver may, as required, be specified following device demands.

It is necessary to consider the overall device latency budget and to assign the correct latency to the ARINC 818 interface for the design and implementation of the display system.

3. New Speeds and Link Encoding

Table 2. ADVB Data Rates

The Fiber Channel speed road map was normally accompanied by ARINC 818-1 and ARINC 818-2 with a couple of exceptions for technology such as CoaXpress. Bandwidth specifications and requirements are growing due to display densities and developments in semiconductor technology.

In that respect, new speeds, as well as guidelines on how to incorporate connection encoding, are added to the ARINC 818-3 spec. Table 2 shows the various specified ADVB Data rates.

The speed of 10Gb has been introduced because of the hardware implementation of 10GB Ethernet (IEEE 802.3) by several silicon vendors. 12GB were added as this is the highest speed for many of the FPGAs available (as of 2019). To follow the road map, Fiber Channel 16X and 32X have been added.

4. Encoding on ARINC 818 Links

ARINC 818 adopted the Fiber Channel conventions by using the definition of selected sets to identify markers for manufacturers such as SOF, End-of-Frame (EOF), IDLE, etc.

These declared sets do not exist anymore in the physical layer for 64B/66B encoding. That is, as is the case for 8B/10B encoding, there is no more 10 bit or K28.5 characters or disparity monitoring.

Instead, 64B/66B is a polynomial encoding based on a completely different transport system, which refers to the FC-FS-5 as SOF, EOF, and special functions of Idle.

The 64B/66B scrambling process is shown in Figure 1. The implementation of 8B/10B is well defined in the specification and is not repeated here.

ARINC 818-3 guides developers with experience and the requirements of 8B/10B, also now want to migrate to the above 10x ADVB bandwidth (64B/66B encoding required).

Figure: 64B/66B scrambling process

Various Applications: While ARINC 818 has been specifically designed for avionics applications in the sensor Fusion application, the protocol has already been used for multiplexing multiple sensor outputs on a single, high-speed connector. 

Copper (Twinax or STP) or fiber can be applied in ARINC 818 (1.0625Gbps), and high speed (2Gbp+) implementations can either use 850nm of MM fiber (<500m) or SM fiber 1310nm (up to 10km).

ARINC 818 is ideal for applications that require few conductors (slip-around turrets), low weight (aerospace) (aerospace, ships) (aerospace, ships).

Summarizing: Transmitter implementations no longer require logic for switching between EOF terminators to push beginning running disparity to negative.

The 64B/66B encoding process uses polynomial scrambling to encrypt consistent transmission Words where the two bits referred to as “sync Header” are used for every transmission Word.

In opposition to the 64- bits below the 64B/66B polynomial does not scramble the synchronization header bits.

Also, these two bits must always be either “01” indicating that the Transmission Word is a Data Transmission Word, or “10” indicating that the Transmission Word is a Control Transmission Word.

Note: There is a free resource available from ARINC818.com. It offers practical guidance on how to incorporate ARINC 818 into an FPGA and provides various lessons learned from real implementers, as well as information on component compatibility.