-T / T / +T | Comment(s)

Monday, April 7, 2014

Overview of ARINC 818 Supplement 2

by Paul Grunwald

In 2005, Airbus and Boeing introduced an effort to further capabilities for the new 787 and A400M programs, and a new standardization effort was initiated through the Digital Video Subcommittee of ARINC. The aim of the ARINC 818 specification was to provide a robust protocol to handle the high-bandwidth of modern avionics video systems and include the precise timings for line synchronous displays. ARINC 818 was based on the Fiber Channel Audio Visual (FC-AV) specification but drastically reduced the complexity. Fiber Channel remains the physical layer for the bus and also offers the advantages of routing and protocol capabilities found in modern networking. FC also is deterministic with low latency. ARINC 818 includes additional container error detection.

Avionics Digital Video Bus (ADVB), officially ARINC 818, was initially ratified in October of 2006 with great industry support and backing. Since then, ARINC 818 has been used as the video transport protocol for cockpit displays on the Boeing 787, Airbus A350 and A400M, C-130J, and the C-17, F15, F18 upgrade programs and numerous other commercial and military aircraft.

In January of 2013, ARINC received a proposal to update the specification with some features that had been implemented in ARINC 818 designs in previous years, but that were not covered in the specification. These included switching, channel bonding and bi-directional links. In addition, some new features were proposed such as higher speed links, provisions for encryption and compression, and color sequential video.

Throughout the spring and summer of 2013, industry participants from Airbus, Boeing, Cotsworks, DDC, Honeywell, SRB Consulting and Thales, along with Great River Technology as the industry editor, drafted Supplement 2 of the specification. A face-to-face meeting was held at ARINC in Annapolis, Maryland, in August of 2013, and a formal draft was produced. At the 2013 AEEC Mid-Term session held in Zagreb, Croatia, at the end of October 2013, the supplement was unanimously approved by the AEEC Executive Committee. ARINC formally published it as ARINC Specification 818-2 on December 18, 2013.

 

Bandwidth

At the time ARINC 818 was ratified, the fiber-channel protocol supported link rates of 1.0625, 2.125, 4.25 and 8.5 Gigabits per second (Gbps). Since then, link rates of 14.025 and 28.05 Gbps have been released with even higher speeds planned to meet market demand. A display at WQXGA resolution (2560 x 1600 pixels @ 24-bit color) at 30 Hz would need a bandwidth of 3,864 Mbps. ARINC 818-2 added 5.0, 6.375 (FC 6x), 12.75 (FC 12x), 14.025 (FC 16x), 21.0375 (FC 24x), and 28.05 (FC 32x) Gbps rates. The 6x, 12x, and 24x speeds were added to accommodate the use of high-speed, bi-directional coax with power as a physical medium. The 5 Gbps rate was added to accommodate so implementation specific speeds supported by certain FPGAs. Also added to specification was the provision to specify non-standard link rates for bi-directional return paths for applications such as camera control, where high speed video links are not required.

Compression and Encryption

ARINC 818 was originally envisioned as carrying only uncompressed video and audio. Applications such as high-resolution sensor, UAV/UAS with bandwidth limited downlinks, and data only applications are driving a need to compress and/or encrypt a link. There was a great deal of discussion about how much detail should be put into the specification. For example, should it define codecs, algorithms and key exchange? In the end, it was decided to only put flags in the ARINC 818 containers to indicate whether the payload (be it audio, video or data) was encrypted, compressed, or both. In sticking with ARINC 818 philosophy of maximum flexibility, the Interface Control Document (ICD) for each project specifies the implementation details.

Switching

To ensure 100 percent quality of service, ARINC 818 was designed as a point-to-point protocol. Since many of the newer implementations of the ARINC 818 have multiple displays, switching has become more important. To ensure interoperability, the specification formalized only a few hard requirements. To meet the goal of flexibility, it offered only guidance in addressing other details through the project ICD.

Because of Fiber Channel legacy, ARINC 818 containers have source and destination IDs. It is possible to route based on those addresses, though from a practical standpoint this would be hard to achieve for items such as data or audio, where the container size may change and latency becomes too large prior to the end of the payload. With video, the specification requires that active switching can only occur between frames. In effect, to prevent broken video frames, the switch must wait until the vertical blanking. Again, the ICD controls the implementation details.

Field Sequential Color

A Video Format Code (VFC) was added to support field sequential color. The field sequential color mode will typically send each color component in a separate container and more than just the traditional primary colors can be transmitted. Originally, field sequential color was developed by CBS in 1940 for early television broadcasting. Today, new LCD technologies are using it for cheaper displays that don’t require color filters and also being used for wearable, transparent displays such as head or helmet mounted displays.

Channel Bonding

One strategy to overcome link bandwidth limitations employs multiple links in parallel. The video frame is broken into smaller segments and transmitted on two or more physical links. This need may be driven by legacy cabling constraints or implementation costs where using an FPGA capable of two 4.25 Gb/s links may be cheaper than one capable of a single 8.5 Gb/s link.

For example, a WQXGA (2560 x 1600 pixels) image with 24-bit color depth at 60 Hz would require bandwidth of 737,280,000 B/s. With channel bonding, this image could be split and transmitted on two ARINC 818 4.25 Gbps links. The method of splitting the video again is controlled by the particular project’s ICD.

Data-only Links

Added to the specification was the provision for data-only links. Data-only links are typically used as command-and-control channels. For example, a normal ARINC 818 link from a camera or sensor would carry the video stream. A data-only link would go to camera to perform functions such as focus or white balance. Another example is a return path for touchscreen or bezel-button input while video is being transmitted to a cockpit display.

Data-only transfers can be of any size and may be comprised of multiple ADVB frames. Any special rules for packetization (e.g., the ADVB frames will be of a fixed size) must be specified in an ICD. Data-only ADVB link rates may be of one of the standard link rates described above, or may be at a different rate established by the ICD.

Bi-directional Camera Interfaces

In reality, a bi-directional camera interface is just a special case of a data only link but it was felt that some guidance for these classes of implementations be incorporated. In this case, a bit is provided indicating that the container is a sync marker and to synchronize on the Start of Frame Initiate (SOFi) symbol for the video channel. This allows the packet to be used for synchronization of multiple cameras as to make operations such as merging and blending easier. Once again, the project ICD will specify the camera control parameters and video timing tolerances.

Optical Performance

The ARINC 818 specification has never specified a physical layer, and there are both copper and fiber implementations in use today. Rather, it has pointed to other specifications such as ARINC 801 (Fiber Optic Connectors) and ARINC 802 (Fiber Optic Cable). In ARINC 818-2, there is now an optional ICD section for specifying optical performance to ensure system performance and interoperability. For transmitters, it recommends an ICD with the following parameters:

• Type of optical fiber in which the signal is injected

o Multimode or single mode

o Graded index or step index

o Core and cladding diameter

• Data rate

• Optical wavelength and maximum spectral width

• Minimum and maximum optical output power

• Peak-to-peak optical modulation amplitude and/or extinction ratio

• Maximum rise and fall times and/or eye diagram

For receivers the following should be added to the ICD:

• Type of optical fiber from which the signal is received

o Multimode or single mode

o Graded index or step index

o Core and cladding diameter

• Data rate

• Optical wavelength and maximum spectral width

• Minimum and maximum received optical power (CW)

• Signal detect assert and de-assert levels

Standard ICD’s can now be defined for each link rate.

CRC Calculation

One difficult implementation issue that arose with ARINC 818-1 was the correct calculation of the prior image CRC. The complexity of the CRC calculation means implementation errors can easily be made. A detailed example has been added showing each step in the Image CRC calculation. Example files may be downloaded at http://www.arinc818.com.

Summary

ARINC 818 has been adopted by major aerospace and military programs, and has become the de facto standard for high-performance military video systems. Already ARINC 818 is being evaluated for applications in industry medical and machine vision.

ARINC 818 video systems include heads-up displays, head-down multifunction displays, infrared and other wavelength sensors, optical cameras, radar, flight recorders, map/chart systems, synthetic vision, image fusion systems and video concentrators. These video systems are used for taxi and take-off assist, enhanced vision systems for landing, cargo loading, navigation, target tracking, collision avoidance and other critical functions. ARINC 818-2 adds features to the specification to accommodate complex, end-to-end video systems, including sensors, processing/switching and driving displays.

As demonstrated by the active participation in the development of this supplement to the specification, ARINC 818-2 has wide industry support from aircraft manufacturers and suppliers. With the addition of higher speeds, support for compression, encryption, networking and sophisticated display schemes, ADVB adoption will continue to grow and expand the mission profiles within and beyond avionics.

Paul Grunwaldis the director of business development at Great River Technology. His 27 year professional career includes positions at GE Intelligent Platforms/SBS, Network Architects, and Philips Semiconductors as well other positions in the semiconductor and software industry.

Live chat by BoldChat