The ARINC 818 "Avionics Digital Video Bus" standard was released in January 2007. Even before its official release, major programs by both Airbus (A400M military transport) and Boeing (787 Dreamliner) adopted the protocol for their critical video subsystems. Since it is now being used in military, commercial and business aircraft, many avionics vendors may need to implement the protocol in the near future to maintain compatibility.
The ARINC Digital Video Committee advanced the standard to meet the special needs of high bandwidth, low latency video in mission critical avionics. The committee included a broad cross-section of the avionics community and aircraft manufacturers, including Airbus, Barco, Boeing, EADS, Goodrich, Honeywell, Kollsman, Lockheed Martin, Rockwell Collins, GE Aviation (formerly Smiths Aerospace), Thales and others.
Prior to the adoption of ARINC 818, there was no standard for avionics video, making each new cockpit design more expensive due to proprietary video formats required by displays and video systems. The ARINC 818 committee reviewed several technology options for the standard, including DVI, GigE and Fibre Channel-Audio Video (FC-AV). The committee chose unidirectional FC-AV (defined in ANSI InterNational Committee for Information Technology Standards 356-2002) as the starting point for ARINC 818 because of its low latency, speed options, data integrity, embedded data, display timing flexibility and the proven field experience of FC-AV in military applications such as the C-130 Avionics Modernization Program and the F/A-18E Super Hornet.
For the unfamiliar, there is a learning curve associated with the FC-AV protocol and its terminology. Tom Johnson, a design engineer at Rockwell Collins HGS, related his experience: "Six months ago, I had only heard about ARINC 818, and now I have an FPGA [field-programmable gate array] design [for a head-up display] that receives and transmits," he said. "The most challenging part was deciphering the specification."
The specification is available online from ARINC, and other readily available resources will help reduce the learning curve, including two industry Web sites — www.fcav.info and www.arinc818.com — that define terms and provide implementation examples, white papers and design guides.
Like FC-AV, the Advanced Digital Video Bus (ADVB) is an adaptation of Fibre Channel that adds video and image transport capabilities. Whereas the FC-AV standard intends to support a very broad set of industries and applications, ADVB focuses specifically on the needs of avionics video. ADVB is simplified over FC-AV because it is unidirectional, and has no requirements for link initialization, flow control or other Fibre Channel exchanges such as port log in. Although simplified, ADVB retains attributes of Fibre Channel that are beneficial for mission critical video applications, such as high speed, high reliability, low latency and flexibility.
ARINC 818 is a point-to-point, 8B/10B encoded protocol for serial transmission of video and data. The protocol is packetized, video-centric and very flexible, supporting an array of complex video implementations including the multiplexing of multiple video streams onto a single link or the transmission of a single stream over a dual link for ultra-high bandwidth.
Four different timing classes, A through D, are defined. Class A is asynchronous, like moving a.bmp [bitmap] file from one place to another, whereas Class D is for stringent pixel synchronous systems. Care must be taken to appropriately match the classes of interconnected ARINC 818 systems.
Christian Matt, a development engineer with EADS Deutschland, who implemented an ARINC 818 transmitter for a Digital Map Generator advises: "Define all ARINC 818 options in detail very early [in an Interface Control Document], and use only the minimal required options to facilitate testing."
Packet Structure
The ARINC 818 standard refers to the basic transport mechanism as an ADVB frame. It is important to refer to these packets as "ADVB frames" rather than simply "frames" to eliminate potential confusion with video frames.
The start of an ADVB frame is signaled by a SOFx Ordered Set and terminated with an EOFx Ordered Set. Every ADVB frame has a header comprised of six 32-bit words. These header words pertain to such things as the ADVB frame origin and intended destination and the ADVB frames position within the sequence. The "payload" contains either video or video parameters and ancillary data. The payload can vary in size but is limited to 2,112 bytes maximum. To ensure data integrity, all ADVB frames have a 32-bit Cyclic Redundancy Check (CRC) calculated for data between the SOFx and the CRC word. The CRC is the same 32-bit polynomial calculation defined for Fibre Channel.
The ARINC 818 specification, like FC-AV, defines a "container" as a set of ADVB frames used to transport video. In other words, a video image and data are encapsulated into a container that spans many ADVB frames. Within a container, ARINC 818 defines objects that contain certain types of data. That is, certain ADVB frames within the container are part of an object.
The four types of objects found within a container are: Object 0 — Ancillary Data; Object 1 — Audio (not used); Object 2 — Video (progressive or interlaced odd); and Object 3 — Video (interlaced even).
Link speeds. In addition to the Fibre Channel 1x, 2x, 4x and 8x rates, ARINC 818 permits "in between" rates that are not compliant with Fibre Channel but represent legacy FCAV systems.
Implementations that use the Fibre Channel rates of 1.0625, 2.125, 4.25 and 8.5 Gbps will have the benefit of compatibility with COTS Fibre Channel development tools such as protocol analyzers and traffic generators. Sticking to these rates will also eliminate potential hazards for using Fibre Channel chips and transceivers outside of their intended operational speed.
Timing classifications. The ARINC 818 standard itself does not place constraints on the timing of the ADVB frames during transmission or the methods of synchronizing at the pixel, line or frame level. Synchronization methods and ADVB frame timing constraints must be captured in the Interface Control Document (ICD). However, ARINC 818 Appendix C establishes four Synchronization and Segmentation Classes (A-D) that enumerate the possibilities for timing constraints on the ADVB link: asynchronous, frame, line or pixel synchronous.
An example of how ARINC 818 transmits color SXGA (Super eXtended Graphics Array) provides a good overview. SXGA RGB (Red, Green, Blue) requires about 236M bytes/sec of data transfer (1280 pixels x 3 bytes per pixel x 1024 lines x 60 Hz). Adding the protocol overhead and blanking time, a standard link rate of 3.187 Gbps is required. ARINC 818 "packetizes" video images into Fibre Channel (FC) frames. The payload of the first FC frame in a sequence contains container header data that accompanies each video image.
Each SXGA video line requires 3,840 bytes, which exceeds the maximum FC payload length. Therefore, each video line is divided evenly into two FC frames. Because the display that this transmitter drives requires "line synchronous" timing, this transmitter is classified as Class C, line synchronous.
Transporting an SXGA image requires the "payload" of 2,048 FC frames. Additionally, a header frame is added, making a total of 2,049 FC frames.
ARINC 818 allows for flexibility in the implementation of the video interface. This flexibility is desirable, because of the diverse resolutions, grayscales, pixel formats and frame rates of avionics display systems. However, this flexibility is a problem for equipment venders hoping for some degree of interoperability.
The ARINC 818 specification intends that an ICD accompany particular ADVB implementations. The ICD will specify parameters of the link such as link speed, image resolution, synchronization scheme, frame rate, etc. Typically, a military program, or commercial avionics development program, will have an associated ICD.
A particular piece of equipment that is compliant with ARINC 818 is not necessarily interoperable with another piece of equipment compliant with ARINC 818, unless they are both made to the same ICD.
The sidebar, "ARINC 818 Evaluation and Planning Strategy" (page 37) has a recommended strategy to plan for implementation of ARINC 818. Following the steps will save time in learning the protocol, and facilitate a smoother implementation.
For those implementing ARINC 818 into a programmable device, Christian Matt, of EADS Deutschland advises: "Implement the whole ARINC 818 design in a programmable device, meaning external SerDes (Serializer/Deserializer, which converts parallel to serial data, and vice versa) have some limitations that can be problematic for ARINC 818 due to Fibre Channel running disparity requirements. These limitations are discussed in the ARINC 818 ‘Implementer’s Guide.’ Using a FPGA that doesn’t provide support for the Fibre Channel physical layer complicates the design."
Johnson, of Rockwell Collins, chose a device with built-in support for Fibre Channel. "I used a Xilinx Virtex 5 (multi-platform FPGA) family part," he said. "The CoreGen Wizard made my first implementation example quite simple and I had a working receiver in simulation within two days."
As ARINC 818 propagates through avionics systems for both military and commercial aircraft, investing a few days early-on to understand the protocol, create a draft ICD and investigate implementation options will save valuable time before a proposal is needed that requires an ARINC 818 interface.
Systems Impacted by ARINC 818
Multifunction, Primary Flight Displays
Head-up, Helmet-Mounted displays
Cockpit Recorders
Mission Processors
Video Concentrators
Enhanced Vision Systems
Forward Looking Infrared
Radar Systems
Map, Chart Systems
Cockpit Simulators
ARINC 818 Evaluation and Planning Strategy
It is best to evaluate the effort to incorporate ARINC 818 at least six months before it is needed in an avionics system. Following the four steps outlined below will help one understand the time, cost and manpower that will be required to implement ARINC 818.
Familiarize yourself with the ARINC 818 specification and protocol. For those not familiar with Fibre Channel, it will take a couple of passes through the document to become familiar with the terminology and protocol. Before reading the specification itself, it is good to look at a summary of the protocol, found at www.fcav.info. Here FC-AV (ARINC 818) terms are defined, and there are a number of good figures that explain the protocol.
Understand other system elements. Typically, the cockpit multifunction or primary flight displays will determine the video resolution, timing and update rate for the entire video system. If a Helmet-Mounted Display is the end display, video latency may be the key design parameter. The point is a downstream receiver typically drives the key design parameters to an upstream ARINC 818 transmitter. Transmitters and receivers must be designed to the same synchronization class defined in Attachment C of the ARINC 818 specification.
Create a draft Interface Control Document (ICD). Two ARINC 818 systems aren’t compatible unless they are built to the same ICD. Attachment B in the ARINC 818 specification offers a list of key parameters that should be included in an ICD. An ICD may require only a one-page document that includes parameters such as data rate, video resolution, frame rate, color encoding, scan type (progressive/interlaced), video timing information and video synchronization class.
An example ICD and an ICD template can be found at www.ARINC818.com, as well as an ARINC 818 ICD Timing Calculator that includes many common video formats.
Review the ARINC 818 "Implementer’s Guide." This is a free resource available at www.ARINC818.com. It provides practical advice on how to implement ARINC 818 into an FPGA and includes many lessons learned from real implementers, as well as component compatibility information.
Evaluate implementation options. Depending on time, space and budget considerations, designers can create their own IP, use an IP Core, or add a PMC or other form factor card.