Using ARINC 818 Avionics Digital Video Bus (ADVB) for Military

Displays
Jon Alexander, Tim Keller, Great River Technology Corporation (USA)

ABSTRACT

ARINC 818 Avionics Digital Video Bus (ADVB) is a new digital video interface and protocol standard developed
especially for high bandwidth uncompressed digital video. The first draft of this standard, released in January of
2007, has been advanced by ARINC and the aerospace community to meet the acute needs of commercial aviation
for higher performance digital video. This paper analyzes ARINC 818 for use in military display systems found in
avionics, helicopters, and ground vehicles. The flexibility of ARINC 818 for the diverse resolutions, grayscales,
pixel formats, and frame rates of military displays is analyzed as well as the suitability of ARINC 818 to support
requirements for military video systems including bandwidth, latency, and reliability. Implementation issues
relevant to military displays are presented.

Keywords: Military, Displays, ARINC 818, Fiber optic, Video, Interface

1 INTRODUCTION

ARINC 818 Avionics Digital Video Bus (ADVB) is a new digital video interface developed especially for high
bandwidth uncompressed digital video. ADVB is a point-to-point interface that is built upon the lower layers of
Fibre Channel. The ADVB interface protocol can be used between various video sources found in military systems
(including cameras and synthetic video systems), video distribution systems, and cockpit and crew station displays.

The Digital Video Subcommittee of ARINC advanced this standard to meet the special needs for higher bandwidth
video for avionics. The subcommittee initially considered several available technologies for the foundation of
ADVB. In the end, the decision was made to base ARINC 818 on Fibre Channel – Audio Video (FC-AV - ANSI
INCITS 356-2002).

FC-AV defines a protocol for transmitting AV streams using Fibre Channel sequences and exchanges. Several
military aircraft programs have successfully used FC-AV for the distribution of video including F/A-18E and the C-
130 Aircraft Modernization Program (AMP). Like FC-AV, ADVB is an adaptation of Fibre Channel that adds
video and image transport capabilities. But 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 login. Although simplified, ADVB retains attributes of Fibre Channel that are
beneficial for military video applications, such as high speed, high reliability, low latency, and flexibility.

2 ADVB TECHNICAL OVERVIEW

2.1 ADVB Lower Layers

ADVB serializes data using 8b/10b encoding. In the simplest terms, the scheme assigns a single byte of data to two
possible 10-bit codes. Typically, one code has more ones than zeros and the other more zeros than ones. An 8b/10b
Serializer inserts one of the two codes to balance the cumulative number of ones and zeros transmitted. This
provides DC balance and guarantees a transition density such that the receiver PLL can recover the embedded clock.
8b/10b receivers check that a neutral running disparity of the link is maintained. That is, the receiver verifies that
the cumulative number of ones does not exceed the cumulative number of zeros by more than one. This represents a
first stage of data integrity checking performed by the link.
The serialization clock used for ADVB is independent of any video clocking. In cases where video is transferred
from standard sources, such as cameras or computers, the ADVB embedded clock runs asynchronously to the pixel
clock of the native video source. It is important to recognize this asynchronous aspect of ADVB in contrast to other
point-to-point video connections, such as DVI, where the pixel clock is provided to the receiver from the link. Since
it is asynchronous, ADVB receivers are only able to recover the ADVB link clock (which are the established rates of
table 2), but not the original pixel clock of the transported video. Because of this, receiver synchronization must be
addressed for all ADVB implementations. Section 2.7 below discusses synchronization schemes for ADVB.

Moving up the layers of Fibre Channel, the ADVB link is organized in 32-bit words (four 8b/10b characters), and all
packet payloads must be multiples of 4 bytes. Fibre Channel defines 32-bit ordered sets that are “non-data” words
that demarcate such things as the beginning of a packet or the end of a packet. For instance, a typical ADVB packet
is preceded by a Start of Frame Normal (SOFn) comprised of four 8b/10b codes (such as K28.5 D21.5 D22.1 D22.1
for a Class 3 SOFn). Ordered sets are also used as the stuffing characters between packets. ADVB uses Idle
Ordered sets as the “fill” between ADVB packets. Required ordered sets and packet header information result in a
link overhead of less than 3%. The websites www.arinc818.com and www.fcav.info provide detailed description of
the layers for these standards.

2.2 ADVB 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.
Figure 1 shows the construction of all ADVB 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 (Source_ID, Destination_ID) and the ADVB frames position within the
sequence (SEQ_CNT). The payload is variable in size, but is limited to 2112 bytes maximum. All ADVB frames
have a 32-bit CRC calculated for all data between the SOFx and the CRC word. The CRC is the same 32-bit
polynomial calculation defined for Fibre Channel.

(total bytes) 4 24 4 -2112 4 4

Idle OS S Frame Payload C E Idle OS

Fill O Header (ADVB Container data) R O Fill
F C F

Word 1 R_CTL, Destination ID

Word 2 CS_CTL, Source ID
Word 3 Type, F_CTL
Word 4 SEQ_ID, DF_CTL, SEQ_CNT
Word 5 OX_ID, RX_ID
Word 6 Parameter

Figure 1 - ADVB Frame

2.3 ADVB Container Structure

The ARINC 818 Specification, like FC-AV, defines a Container as a set of ADVB frames used to transport video
and audio. 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 Object Types are defined in Table 1

In ADVB, Object 0 is a single ADVB frame that contains data relevant to that container. Object 1, if used, contains
audio information, and Objects 2 and 3 contain video payload. For interlaced formats, Object 2 is used for odd field
payload and Object 3 is used for even field payload.
 ADVB Frame 0 ADVB Frame 1 ADVB Frame 2 ADVB Frame N ADVB Frame 0
---------
ADVB Container (one video frame) Next Container
(Next video frame)

Figure 2 - ADVB Container Structure

Object 0 Ancillary Data Object Type Number 5xh

Object 1 Audio Data Object Type Number 4xh
Object 2 Video Data Object Type Number 1xh | 2xh
Object 3 Video Data – Interlace even field Object Type Number 1xh | 2xh

Table 1 - ADVB Container Object Types

In most cases, a single Container maps exactly to a single video frame (note: this is also a single FC sequence).
However, it is permissible to have less than a frame transported in one container. This may be the case where curser
information for a Head Up Display (HUD) needs to be updated faster than the video frame rate. In this case, a
fractional part of the frame may be assigned to the container so that the occurrence of the Object 0 ADVB frames is
more frequent. The cursor location data can then be loaded in these Object 0 ADVB frames that occur more
frequently, perhaps several times per video frame.

Figure 3 shows a progressive video format that requires Object 2 only. The ADVB container has a single ADVB
frame for object 0 and the remaining are Object 2 ADVB frames containing video information.

Object 0 – ADVB Frame Object 2 – Video Payload ADVB frames

---------

ADVB Container
SOFi Figure 3 - ADVB Container - Progressive Video EOFt

Figure 4 shows an interlaced video format that uses Object 2 for odd fields and Object 3 for even fields.
Object 0 – ADVB Frame Object 2 – Odd field ADVB frames Object 3 – Even field ADVB frames
------- -------

ADVB Container
SOFi O EOFt
Figure 4 - ADVB Container - Interlaced Video

2.4 Link Speeds

Table 2 lists the link speeds to be used for ARINC 818. 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.
 Rate Notes Rate Notes
1.0625 Gbps FC 1x rate 2.5 Gbps
1.5 Gbps 3.1875 Gbps
1.62 Gbps 4.25 Gbps FC 4x rate
2.125 Gbps FC 2x rate 8.5 Gbps FC 8x rate

Table 2 - ADVB Data Rates

2.5 Flexibility and Interoperability

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 Interface Control Document (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.

2.6 Vertical and Horizontal Line Timing

To interface with a wide range of digital displays, ARINC 818 allows for implementations that impose horizontal
and vertical video timing on the ADVB link. A typical implementation may set the ADVB container rate to be the
same as the vertical frame rate of the transported video. Horizontal line timing may also be imposed on the
transmission of ADVB frames.

2.7 Synchronization and Segmentation Classes

As mentioned, ADVB will have its own embedded clock that will run asynchronous to source video pixel clocks.
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 ICD. However, ARINC 818 Appendix C establishes four synchronization and
segmentation classes that enumerate the possibilities for timing constraints on the ADVB link: asynchronous, frame,
line, or pixel synchronous.

The synchronization and segmentation classes address four separate variables that characterize delivery and timing
of ADVB frames with respect to the video timing. Specifically, the classes address the following:

• Vertical timing – the rate at which video frames are sent over the ADVB
• Horizontal timing –the rate (and uniformity) at which video lines are sent over the ADVB
• Segmentation – any constraints on how video lines are loaded in ADVB frames
• Jitter - the variance in arrival times of video lines

Table 3 summarizes the classes according to these four parameters; beginning with least constrained ADVB
asynchronous case (A1 with no vertical or horizontal timing imposed and no special segmentation) and moving to
the most constrained synchronous case (D3 with perfect vertical and horizontal timing and orderly line segmentation
into ADVB frames).

The particular class used for an ARINC 818 implementation depends on system level requirements. For instance,
some military systems will be concerned about hazardous stale video. To prevent the possibility of stale imagery
residing within the display unit, the use of a full image memory buffers may be prohibited. In this case, the display
unit will have only line FIFOs to buffer incoming data.

CLASS Non-Line Synchronous CLASS Line Synchronous

Variable A1 A2 A3 B1 B2 B3 C1 C2 D1 D2 D3
Stable vertical period? NO NO NO YES YES YES YES YES YES YES YES
Stable horizontal period? NO NO NO NO NO NO YES YES YES YES YES
Object 0 or Line NO OBJ 0 Lines NO OBJ 0 Line Line Line Line Line Line
Segmentation?
Vertical jitter? YES YES YES YES YES YES YES Ext. YES YES NO
sync
Horizontal jitter? YES YES YES YES YES YES YES Ext. NO NO NO
sync

Table 3 – Summary of Synchronization and Segmentation Classes

Receiver designs based on a line FIFO will require that the ADVB transmitter deliver line data according to
horizontal timing requirements. These requirements will stem from the scan requirements of the display unit. Since
horizontal scanning must be precise for some displays, the arrival times of line data will also need to be precise. This
type of ADVB link is referred to as line synchronous. Classes C1, C2, D1, D2, and D3 are line synchronous.

Classes A1, A2, A3, B1, B2, and B3 are not line synchronous. For these classes there are no timing constraints for
the ADVB frames within that container. When these classes are used, and when a display requires precise
horizontal scanning, full image buffering must be included in the receiver design.

2.8 Object 0 Data

ARINC 818 can support various resolutions, grayscales, pixel formats, and frame rates for military displays.
Information about these parameters is contained in Object 0 which is carried by the first ADVB frame of each
container.
st
Object 0 – 1 ADVB Frame
---------

The first ADVB frame consists of:

• ADVB Frame header – 6 Words
• Container Header – 22 Words
• Ancillary data – 4 Words
Figure 5 – Object 0 ADVB Frame

In addition to the ADVB frame header, the first ADVB frame holds the Container Header and the Object 0 Ancillary
data. The Container Header specifies characteristics of the container objects within the ADVB stream. Parameters
in the Container Header include the frame rate of the video and the size (in bytes) of the objects within the container.
Also within the Container Header is a container count (which in most cases will be a video frame counter) and an
optional container time stamp. The time stamp may be used for such applications as avionic cockpit video
recorders.

The Ancillary data includes more specific attributes of the video being transferred such as image resolution and
whether the video is interlaced or progressive. The Ancillary data also specifies the format of pixels within the
video payload.

Additional words in the Ancillary data include a CRC calculated on the entire image (within the container) and user-
defined parameters to be transmitted to the receiver. There is also a mechanism within the Object 0 ADVB frame to
extend the Ancillary data size. In this extended mode, the ARINC 818 specification defines the method to transfer
color palette data or HUD curser focal point data.
 3 EVALUATION OF ADVB FOR MILITARY DISPLAY SYSTEMS

3.1 General Requirements for Display Systems

HUD HMD
or ADVB connections
UFCD

Primary Secondary Crew

Cockpit Cockpit Station
Cockpit Displays Displays Displays
Recorders
Cockpit

Video Distribution

Simulation
Camera Video And Test
IR Camera video Mission Computer
Computers Generated
Video

Figure 6 - Typical ADVB Connections in Military Display Systems

The ADVB connections indicated in Figure 6 must support a broad range of video types. These connections are
heterogeneous with respect to required bandwidth, image resolution, frame rate, pixels definitions (e.g., color versus
monochrome) and the required class of synchronization. In modern avionics, the primary flight displays are likely to
be high resolution (XGA or higher), 24-bit RGB, with refresh rates of 60 Hz to support the smooth update of
primary flight Symbology, and clear line and text presentation. These displays may be multi-function displays
(MFDs) that receive more than one video source and perform real-time blends of the video. The Head-up displays
may be monochrome with background information updated at slower frame rates, but with cursor information
updates at rates of 60 Hz or higher. Crew Stations displays will have significantly different requirements for
resolution and update rate depending on the mission. Many of these may be low information content. But for other
applications, such as electronic surveillance, displays will tend to be higher resolution.

Video sources within the architecture will be equally varied in color, resolution and frame rate. For instance, future
moving map systems may be of increasing resolution and color depth, while monochrome IR cameras will be of
significantly lower resolution. These IR imagers may have native frame rates less than 30Hz and video update rates
from radars might be slower still.

3.1.1 Bandwidth Considerations

Although many military platforms use compression to greatly reduce required bandwidth; cockpit video involves
target and image recognition, image fusion, and the fine lines and textual information of graphic overlays, for which
any losses (due to compression) could be hazardous. For this reason, cockpit display systems require uncompressed
video. Compression methods, such as JPEG2000, can provide some degree of compression with minimal or no loss,
but other requirements unique to avionics, such as the real time blending of video from two input streams (such as
symbology information overlaid on other video), and latency (Compression Codecs add latency), require the video
be in an uncompressed form. ARINC 818 does not address the transport of compressed video directly, but rather,
assumes that the video is uncompressed prior to transport. Without compression, high-resolution video requires
 significant bandwidth. For instance, SXGA requires over 2 Gbps of bandwidth (using 24 bit color, at 60Hz). The
near term bandwidth needs for UXGA approaches 4 Gbps.

3.1.2 Image Resolutions

In a recent survey of avionic displays Desjardins and Hopper find 1200 sizes of displays in the military avionics
market segment [4]. Among these are many non-standard sizes such as 799 by 820 for the C-17 cockpit MFDs and
a 457 x 587 for MMFDs on the CH-47SD.

The reasons for the variance in resolution and non-standard sizes stem from the fact that military displays are most
often ruggedized commercially available AMLCD glass (you use what you can find) and there is almost always a
size constraint for the cramped space of a cockpit. For this reason, non-standard resolutions are likely to be common
in future displays.

ADVB can support numerous resolutions within military video systems. ADVB is flexible and allows for any row
and column sizing. The ICD specific to the military program will specify the resolution and the Object 0 ADVB
frame word 0 will have this data embedded. Word 0 of the Ancillary data is defined as:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Number of Columns
Number or Rows Frame/Field

Figure 7 – Ancillary Data Word 0 - Image Resolution

The least significant 4 bit of this word specify whether the video is progressively scanned (frame based) or
interlaced (field based). Although future cockpit displays using AMLCDs may tend to be progressively scanned,
existing sensors within the system may output interlaced video. For reasons of flexibility and to eliminate the need
for a scan converter, ADVB allows for different video formats to exist within the system. Having resolution and
frame field information embedded in the incoming stream will allow future displays to detect and adapt to the
different video formats. MFDs that accommodate both progressive and interlaced video would simply adapt in real
time to the format.

3.1.3 Pixel Formats

Like the scalability of resolution, ADVB allows for pixels to be defined in an equally flexible way. As pointed out,
military display systems will encounter many types of video that serve varying mission purposes. Primary flight
functions will require color, whereas monochrome may be adequate for HUD displays. An increased color depth
will be important for maps and weather radars, whereas other computer-generated graphics may work with reduced
color pallets.

3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

CI P PA PAO PTN Bits/Subpixel A Bits/Subpixel B Bits/Subpixel C Bits/Subpixel D

Color Prior CRC Pixel Aspect Pixel Packing

Information Valid Flag Ratio (Width: Array Table
Height) Order Number
Figure 8 – Ancillary Data Word 1 - Pixel Definition

The imagery can come from many sources with a diversity of pixel formats. Infrared sensors may stream 14-bit
monochrome, whereas visible light cameras for may use 4:2:2 YCbCr encoded color. Sources of computer rendered
graphics will also vary in pixel definition.

ADVB is flexible with respect to pixel definition. The pixel definition for the ADVB container is captured in
Ancillary data word 1 (Figure 8). Within Word 1, ADVB defines a Color Information (CI) code that specifies
whether the pixels are color or monochrome and the packing method used (such as RGB, RGBA, or YCbCr). Also
within word 1 are codes for Pixel Aspect ratio (PA) and a Pixel Array Order (PAO). Among avionics displays, not
all scanning is left to right and top to bottom. Scans such as bottom to top, left to right are common. The PAO code
of ADVB identifies the scan precisely.

The packing table number code specifies how the pixels are packed into 32-bit ADVB transmission words. The
ARINC Specification addresses 8, 10, 12, and 16 bit packing methods that may be useful for monochrome camera
data, as well are common color pixel definitions. The Bits/Sub pixel fields identify the number of bits used for each
sub pixel with the minimum (0h) being one bit and the maximum (Fh) being 16 bits.

3.1.4 Video Update Rates

The imagery used in military display system can come from many sources with many native frame rates. The
slowest of these may be at a “null” rate where images are only sent as needed. An example might be a single page
of information related to flight plan or maintenance status. In contrast, dynamic video within the system may be
transmitted at the refresh rate of the displays. Such will be the case with primary flight displays that must achieve
smooth Symbology updates.

Designers of future avionics display systems will need to deal with a wide range of video update rates from null to
over 60Hz. ADVB is flexible with respect to video update rates. The ICD specific to the military program will
specify the rates used. The video frame rate is captured in the Container Header (the first ADVB frame) Word 4,
byte 0. This single byte code corresponds to the frame rate shown in Table 4

Code Frame rate per second Code Frame rate per second
00h Null (aperiodic) 06h 50
01h 15 07h 60
02h 20 87h 60 * 1000 / 1001 (59.94 NTSC)
03h 24 08h 50 (VESA DMT)
83h 24 * 1000 / 1001 09h 60 (VESA DMT)
23h 24 (segmented frames) 0Ah 75 (VESA DMT)
A3h 24 * 1000 / 1001(segmented frames) 0Bh 85 (VESA DMT)
44h 25 (PAL) 0Ch 50 (VESA CVT)
45h 30 0Dh 60 (VESA CVT)
C5h 30 * 1000 / 1001 (29.97 NTSC) 0Eh 75 (VESA CVT)
06h 50 0Fh 85 (VESA CVT)

Table 4 – ADVB Frame Rates

3.1.5 Color and Luminance

Other requirements that are unique to military display systems are much broader luminance ranges and careful
control of display chromaticity.

The need for sunlight readability, and at the same time, very dim power output during nighttime missions, creates
challenging display luminance requirements. Military displays meet these requirements through backlights within
the display unit. There also exists the requirement for compatibility with night vision equipment. Modern cockpit
displays typically have selectable modes where the display chromatic characteristics are shifted to reduce
interference with night vision goggles.

In some military vehicles, adjustments in backlight illumination can be made by an operator in response to existing
lighting conditions and/or the requirements of the mission. Similarly, NVIS modes might be selectable by bezel
button. But to reduce the demands on time challenged war fighters, automated luminance and color control is
desirable. ADVB includes mechanisms for the automatic adjustment of backlight power and the automatic shifting
of color to meet NVIS requirements by way of the Object 0 Ancillary data word 3.
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

Parameter 2 Type Parameter 2 Data Parameter 1 Type Parameter 1 Data

Figure 9 – Ancillary Data Word 3

Word 3 contains two half-word parameter fields where the most significant six bits (the parameter type field)
indicates one of several parameters defined in ARINC 818. The parameter data is contained in the lower 10 bits of
each half word.

With parameter type = “000010” (2h) the parameter is the daytime back light brightness control. For this parameter,
000h equals the minimum luminance setting and 3FFh equal the maximum luminance setting. The response curve
will be dependant on the display. With parameter type = “000011” (3h) the parameter data is defined as a night or
NVIS backlight brightness control. For this parameter, 000h equals the minimum luminance setting and 3FFh
equals the maximum luminance setting. The response curve will be dependant on the display.

With parameter type = “000100” (4h) the parameter data is defined as the Gamma power function where the data
field identifies the Gamma correction to be used for the incoming data. This parameter may also be used for
automatic adjustment based on ambient light conditions or based on mission needs.

3.1.6 Latency

In many instances, latency requirements will be demanding within military video systems. For instance, the latency
in HUDs must be minimal for assisted take-off, landing, and perhaps other demanding combat functions. Similarly,
helmet mounted displays (HMDs) will require low latency. Too much latency between head motion and HMD
image updates can cause sickness. HUD and HMD video is updated at a very fast rate based on the synthesis of
camera and other real-time sensor data. For these applications, ADVB line-synchronous implementations can be
used to minimize latency to well below 1 ms. This is because ADVB line-synchronous implementation imposes
horizontal timing on the link.

When there is no horizontal timing imposed on the link, the receiver must be constructed with full image buffers so
that precise timing can be imposed on the display scanning. For instance, a Ping/Pong receiver scheme might
collect an incoming video frame in one buffer, while the previously captured image in the other buffer is being
scanned to the display. With one image fully stored, correct horizontal timing can be imposed on the scan.
However, such a scheme adds one frame of latency to the system. For HUD and HMD systems, unwanted latency
comes from video cameras, the computational system, the display, and all video connections. One frame of latency
from the ADVB link might be unacceptable within the overall latency budget.

With ADVB line synchronous implementations, the horizontal timing exists on the ADVB link, and the receiver
requires only a line FIFO rather than a full image buffer. This reduces latency from a frame time down to a line
time. For 60Hz video, this might result in the latency contribution of 16.7ms being reduced to below 20 us.

3.2 Reliability and Safety

Fibre Channel has gained a wide acceptance in storage area network (SAN) applications and the data integrity
requirements for SANs are as stringent as those of avionics display systems. The proven track record of Fibre
Channel in SANs, and the recent successes of FC-AV in avionics display upgrade programs were big reasons for
basing ADVB on Fibre Channel.

There are several levels of integrity checking for the ADVB link. At the lowest level, ADVB de-serializer will
verify the integrity of the 8b/10b link by checking running disparity and checking that all 8b/10b codes are valid.
Most SerDes for Fibre Channel have this ability to flag disparity errors and code violations.

At the next level, the ADVB frames carry a 32-bit CRC for verification of video payload. This is essentially
checking the integrity of transmitted video line data. ADVB also establishes in the Object 0 Ancillary data, a field
for a CRC computed over the entire video frame. ADVB receivers will be able to validate the integrity of the
incoming video stream at these three levels.

It is common for military cockpit display systems to have requirements for Hazardously Misleading Information
(HMI). Hazardously Misleading Information is defined as displaying misleading or false information that leads to
hazardous conditions. The system level requirement may be couched in terms of a probability of HMI occurring
during use.

A primary mechanism for HMI is the presentation of stale imagery that has been captured in a memory buffer
internal to the display unit - even when that video is no longer being updated due to other system failures. To
eliminate this as a mechanism, ADVB provides a container count and an image CRC that the receiver can verify is
changing. For even more safety critical cases, display units may be designed without full image buffers; having
instead only line buffers for the incoming video.

Line buffer ADVB receiver designs require that the ADVB transmitter deliver line data according to specific timing
requirements. These requirements stem from the scan requirements for the display. Since horizontal scanning must
often be precise, the arrival times of line data will also need to be precise. As discussed in section 2.7, this type of
ADVB link is referred to as line synchronous. ARINC 818 allows for line synchronous implementations (Classes
C1, C2, D1, D2, and D3) that meet this requirement.

3.3 Implementation Example – SXGA Line Synchronous

Figure 10 below is an example of line synchronous transmission of ADVB frames for color SXGA (1280 x 1024),
24 bit RGB pixels at 60 Hz. The timing between all ADVB frames is fixed by keeping the number Idle Ordered sets
between the ADVB frames fixed. This implementation is for a 3.1875 Gbps link.

Each image payload ADVB frame (denoted by FC1 – FC 2048) carries exactly one half line of data (480 words for
payload, 489 words for the entire ADVB frame). The timing of the ADVB frames, which is controlled by the
number of Idle Ordered Sets between ADVB frames, is orthogonal. That is, the occurrence of the SOFn Ordered
Sets that lead each video line will occur at fixed intervals, or in this case, every 1252 words. This sets the horizontal
line rate to 63.65 KHz.

The Object 0 ADVB frame (denoted as FC0) is followed by a long period of 5008 Idle ordered sets in order to make
the occurrence of the SOFi occur on the same fixed interval as the SOFn. Having the SOFi occur orthogonally may
be useful for the receiving circuitry where the vertical sync is generated upon receipt of the SOFi and this vertical
sync must coincide with the regenerated horizontal syncing derived from the SOFn. The last frame (FC 2048)) is
followed by a long period of 40201 Idle Ordered Sets in order to adjust the video frame rate to 60 Hz.

This implementation is classified, as a Class D3 line synchronous, since lines are segmented into ADVB frames
uniformly and there is no vertical or horizontal jitter in the transmission. However, the jitter requirement may be
difficult to achieve in the transmitter, especially where a FIFO is used between a local clock the Fibre Channel clock
domains. For this reason, the ICD should allow tolerances for jitter. Unlike analog CRT monitors, AMLCDs used
in military displays are more tolerant of jitter in the horizontal timing.
 489 – Values in Italics are the total number of 32-
bit words.

Figure 10 – SXGA Line Synchronous Example

3.4 ADVB with Multiple Video Streams

ADVB allows for multiple video streams to be time multiplexed on a single ADVB link. This may be of benefit in
sensor fusion applications where several video sources are synthesized to achieve a superior composite image. For
instance, long wave IR, short wave IR and visible spectrum video might be synthesized for better day/night and all
weather vision. For this application ADVB can be used as a single fiber optic transport from the sensor pod to
image processing equipment.

Figure 11 shows how ADVB frames can be interleaved on the link. This example assumes all video sources are
frame locked within the sensor pod (with all video frames more or less synchronous). In this case, the ADVB
container rates are the same and all three containers are transported within a single frame time.

The three sensors lead to three separate ADVB containers on the link. These containers are uniquely identified by
the source ID (S_ID) within each ADVB frame header. The ADVB receiver can de-multiplex these video streams
based on the source ID.

Any synchronization classes described in section 2.7 can be used in this type application. The example below
indicates frame synchronization, but this may not be required by the system. Similarly, horizontal line timing might
be imposed on the ADVB frames.

-------------------------------------------------------------------------------------------------------------------------------
Sensor 1 Sensor 2 Sensor 3 Sensor 1 Sensor 2 Sensor 3
Object 0 – ADVB Frames Object 2– Video Line data

Sensor 1 Container (S_ID = 1) Sensor 1 Container (S_ID = 2) Sensor 1 Container (S_ID = 3)

----------------------------------------------------------------------------------------------------------------------------------
Sensor 1 Sensor 2 Sensor 3 Sensor 2 Sensor 3
Object 2– Video Line data

Figure 11 – Sensor Fusion Example

A second example where time multiplexing may be of benefit is the insertion of slow rate or null rate video within a
primary video stream. This may be radar images embedded within Symbology video or perhaps a queried
informational page embedded within a live video stream.

A possible means to accomplish this with ADVB is to exploit the vertical blanking period within the primary video
stream. This can be done in cases where the primary video retains line synchronous timing (as in figure 10). The
slower rate video ADVB frames can be inserted within the blanking periods (between SOFi and EOFt). These
inserted ADVB frames represent a second container on the link and they may be transmitted as null rate video
(without vertical or horizontal timing imposed). For an implementation like this, the receiver would accumulate the
slow rate video in a separate image buffer such that it could be displayed upon request (perhaps via bezel button) or
perhaps blended with the primary video. As with the previous example, the two containers would be uniquely
identified by source IDs.

3.5 Implementation Considerations

The ARINC 818 Specification does not specify the ADVB physical medium to be used. The ADVB physical layers
are to be established in the ICD. Other ARINC Specifications are referenced that address the choices for fiber-optic
connectors, cabling, and active devices. These Specifications include ARINC Specifications 801, 802, 803, and
804.
Since ADVB is based on Fibre Channel, it is expected that future ADVB implementations will leverage the optical
transceivers in existence for Fibre Channel. Due to the wide spread use of Fibre Channel, these are low cost
components with numerous vendors. For any connection less than 500 meters, 850 nm transceivers may be used
with multi-mode fiber. For systems with connections expected to exceed 500 meters, 1310nm transceivers can be
used with single-mode fiber. For 1.0625 Gbps interfaces, copper interfaces using differential twin-ax can be used.

Fibre Channel is widely used and has been around for many years. For this reason, there are many vendors and
devices available for the design of ARINC 818 interfaces. PLD and FPGA vendors, recognizing the demand for
high-speed serial interfaces in modern electronics, are embedding Fibre Channel compatible PHYs in their product
offerings. Xilinx and Altera dominate the landscape for PLDs, FPGAs, and CPLDs. Both vendors offer products
with built in high-speed serial interfaces blocks. In most cases these are simple 8b/10b SerDes that can be used to
fulfill existing serial standards, such as Fibre Channel, PCI Express, XAUI, SONET, Gigabit Ethernet, and SDI. In
a few cases the high-speed interface is more complex. The RocketIO of the Xilinx Virtex2 Pro supports a 32 bit
wide interface with embedded functionality used in Fibre Channel – such as CRC computation, elastic buffering,
and EOF insertion.

4 CONCLUSIONS

ADVB is a point-to-point interface that is built upon the lower layers of Fibre Channel. The ADVB interface
protocol can be used between various video sources found in military systems (including cameras and synthetic
video systems), video distribution systems, and cockpit and crew station displays. Unlike other commercial video
standards, ADVB can be easily adapted to meet the special needs of military display systems for speed, latency,
reliability, and flexibility. ADVB can accommodate the diverse resolutions, grayscales, pixel formats, and frame
rates found within military display systems. ADVB allows various synchronization methods including
implementations that impose horizontal and vertical video timing on the ADVB link. ADVB’s packetization
scheme allows for the multiplexing of more than one video stream onto a link and allows non-video data to be
embedded in the video stream.

The ARINC 818 Specification intends that an Interface Control Document (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.

REFERENCES

1. ARINC Project Paper 818 (Draft 4): Avionics Digital Video Interface, High Data Rate.
(http://www.arinc.com/aeec/projects/digital_video/index.html)
2. Fibre Channel – Audio Video (FC-AV) (ANSI INCITS 356-2002, 25 Nov 2002)
3. Fibre Channel–Framing and Signaling Interface (FC-FS) (ANSI / INCITS 373-2003)
4. D. Desjardins, D. Hopper, "Military display market segment: avionics", Proceedings of SPIE Volume
5801, 2005, pp. 161 – 170
5. B. E. Brendle, Jr, "Cockpit development in the Crew integration & Automation Testbed advanced
technology development program", Proceedings of SPIE Volume 5080, 2003, pp. 91 –107
6. D. Desjardins, D. Hopper, "Military display market segment: Helicopters", Proceedings of SPIE Volume
5443, 2004, pp. 88 –106
7. D. Desjardins, D. Hopper, "Military display market segment: wearable and portable", Proceedings of
SPIE Volume 5080, 2003, pp. 346 –359
8. E. F Hitt, "Roadmap for Implementing Network Centric Capability for Military Aircrews", Proceedings
of SPIE Volume 5443, 2004, pp. 21 –28
9. E. Bernard, Jr, "COTS LCDs in the Cockpit - friend or foe?", Proceedings of SPIE Volume 5080, 2003,
pp. 120 –128